mcpField
M
make-readme

make-readme

github.com/gupsammy開発27638 回インストール5 日前に更新
リポジトリ

make-readme について

make-readme は、プロジェクトの README.md を生成するスキルです。新規・既存プロジェクトの説明を整えたい開発者向けで、作業ディレクトリを調べて質問を行い、構成や詳しさを決めます。

主な機能

  1. 01マニフェストからプロジェクト情報を確認
  2. 02既存の README.md を確認
  3. 03質問でドキュメントの希望を収集
  4. 04構造化された README を生成
  5. 05プラグインコレクションの一覧に対応

活用シーン

  1. 01新規プロジェクトの README.md を作成
  2. 02既存プロジェクトの説明を再構成
  3. 03プラグインコレクションのコンポーネント一覧を作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/gupsammy/claudest --skill make-readme

インストール後、Claude Code で/make-readmeを入力して読み込まれたか確認します。

同梱ファイルreferences/badges.md

詳細

README Maker

あらゆるプロジェクトのプロフェッショナルな README.md を生成します。50 行の最小構成から 600 行の包括的な構成まで対応し、shields.io バッジ、スタイル付きヘッダー、構造化されたセクションを含められます。ユーザーに質問して希望を確認した後、README 全体を一度に作成します。

Step 1 — プロジェクトのコンテキストを検出する

質問する前に、作業ディレクトリをスキャンして手がかりを探します。

  • package.json、pyproject.toml、Cargo.toml、go.mod を Glob で検索し、最初に見つかったファイルを読み込んで、プロジェクト名とバージョンを事前入力されたデフォルト値として抽出します。
  • README.md がすでに存在するか確認し、上書きする前にユーザーに警告します。
  • 検出したマニフェストファイルから主要な言語を特定します。
  • プラグインコレクションの検出では、サブディレクトリ内の */.claude-plugin/plugin.json と */package.json を Glob で検索します。サブマニフェストが 3 件以上見つかった場合、Step 2 でプラグインコレクションを事前選択し、その件数を記録します。
  • マニフェストが見つからない場合は事前入力をスキップし、Step 2 でユーザーからの入力だけを頼りにします。

Step 2 — 第 1 ラウンドの質問（常に実施）

AskUserQuestion で 4 つの質問をします。検出したコンテキストに合致する選択肢があれば、可能な範囲で事前選択します。

#headeroptions
1"プロジェクトの種類"ライブラリ／パッケージ · CLI ツール · Web アプリ／API · デスクトップアプリ · プラグインコレクション
2"言語"Python · JavaScript/Node · Go · Rust
3"詳細度"最小 · 標準 · 包括的
4"ライセンス"MIT · Apache-2.0 · GPL-3.0 · ライセンスなし

プロジェクトの種類の定義：

  • プラグインコレクション／モノレポ — それぞれが独自のバージョンと説明を持つ、インストール可能な複数のコンポーネント（プラグイン、パッケージ、拡張機能）を含むリポジトリです。コンポーネントディレクトリの表（Step 4）と、セクションごとのバージョンバッジが自動的に有効になります。

詳細度の定義（選択肢の説明として含めます）：

  • 最小 — 小規模なユーティリティ、内部ツール、または用途が明確に 1 つのもの
  • 標準 — コントリビューターや外部ユーザーを想定するオープンソースプロジェクト
  • 包括的 — 公開 API、活発なメンテナー、または大規模なコミュニティを持つ成熟したプロジェクト

詳細度が最小の場合は Step 3 をスキップし、Step 4 に進みます。

Step 3 — 第 2 ラウンドの質問（標準／包括的の場合のみ）

AskUserQuestion で 4 つの質問をします。

#headermultiSelectoptions
1"セクション"true機能一覧 · デモ／スクリーンショット · 設定ドキュメント · API リファレンス
2"追加項目"trueコントリビューションガイド · ロードマップ · FAQ · 謝辞
3"バッジ"trueライセンス · CI／ビルド · カバレッジ · バージョン／リリース · ダウンロード数 · スター数＋フォーク数 · セクションごとのバージョン
4"スタイル"falseシンプル · 中央揃え · スタイル付き

スタイルの定義（選択肢の説明として含めます）：

  • シンプル — 次の行に > tagline を置く、プレーンな # Title
  • 中央揃え — <div align="center"> ブロックを使い、タイトル、タグライン、バッジ行を中央揃えにします。
  • スタイル付き — 中央揃えに加えて、すべての H2 および H3 見出しに絵文字の接頭辞を付けます。H2 のデフォルト： ✨ 機能、🚀 クイックスタート、⚙️ 設定、📖 API、🤝 コントリビューション、 🗺 ロードマップ、❓ FAQ、📄 ライセンス。プラグインコレクションのコンポーネント用 H3 には、🧠 🔍 💻 ✍️ 🤔 🎬 🔧 📦 🛠️ から選び、アルファベット順ではなくコンポーネントの分野に合わせます。

プロジェクトの種類がプラグインコレクションの場合、セクションごとのバージョンバッジが事前選択されます。

Step 4 — README を生成する

最小構成

次の 5 つのセクションをこの順序で配置します。タイトル＋タグライン、説明の段落（何か、誰のためか、なぜ必要か）、構文ハイライト付きのコピー＆ペースト可能なコマンドを含むインストール方法、最小限の動作する例とコメント形式の期待される出力を含む使い方、SPDX 名と LICENSE ファイルへのリンクを含むライセンス。

標準／包括的な構成

Round 2 で選択されたセクションのみを含め、次の順序で構成します。

  1. ヘッダーブロック — Round 2 で選択したスタイルを適用します（以下のスタイルを参照）
  2. コンポーネントディレクトリテーブル — プラグインコレクションタイプのみ。各コンポーネントのアンカーリンク、バージョン、主要なスキルや機能を一覧にしたコンパクトな Markdown テーブルです。サブディレクトリ内のマニフェスト（*/.claude-plugin/plugin.json、*/package.json）を Glob で検索し、コンポーネントを自動検出してテーブルに事前入力します。ヘッダーブロックの直後に配置します。
  3. 目次 — 包括的な構成のみ。存在するすべての H2 セクションへのアンカーリンクを自動生成します。画像（バージョンバッジ）や絵文字を含む見出しは GitHub のアンカー生成が不安定なため、リンク先の各見出しの 前の行 に <a id="slug"></a> を単独で配置し、目次からは #slug でリンクします。 例： 
    <a id="installation"></a>
## 🚀 Installation  ![v1.0](...)
    目次の項目：- [インストール](#installation)
  4. 説明 — 解決する課題、対象ユーザー、主な差別化要因について、2～3 文で記述します。
  5. 機能（選択された場合） — 能力を箇条書きで記載し、現在形で統一した並列形式にします。
  6. デモ／スクリーンショット（選択された場合） — ![Demo](demo.gif) をプレースホルダーとして記載し、実際の GIF またはスクリーンショットのパスに置き換えるよう指示します。
  7. インストール — 前提条件のブロックに続けて、番号付きのインストール手順を記載します。
  8. 使用方法 — 標準では例を 1 つ、包括的な構成では見出し付きの例を複数記載します。
  9. 設定（選択された場合） — 「名前・型・デフォルト・説明」の Markdown テーブルを記載します。
  10. API リファレンス（選択された場合） — 各関数／エンドポイントについて、シグネチャ、1 行の説明、最小限の例を記載します。
  11. コントリビューション（選択された場合） — フォーク → クローン → ブランチ → コミット → PR の 5 つの手順を記載します。
  12. ロードマップ（選択された場合） — 予定されている機能のチェックリストを - [ ] 形式で記載します。
  13. FAQ（選択された場合） — H3 の質問と、簡潔な段落形式の回答を 2～3 件記載します。
  14. 謝辞（選択された場合） — クレジットへのリンクを記載します。
  15. ライセンス — SPDX 名と LICENSE ファイルへのリンクを記載します。

包括的な構成では、各 H2 セクションの後に [⬆ トップに戻る](#readme) を追加します。

ヘッダーブロックのスタイル

シンプル： # Project Name の後に > One-line tagline. を記載します。

中央揃え： タイトル、タグライン、バッジ行を <div align="center"> で囲み、タイトルには <h1>、タグラインには <p>、バッジには Markdown のバッジ構文を使用します。

スタイル付き： 中央揃えと同様にします。Step 3 の絵文字リストに従い、すべての H2 と H3 の先頭に該当する絵文字を付けます。目次またはコンポーネントディレクトリテーブルからリンクされる各 H2 と H3 の前に <a id="slug"></a> を追加します。

バッジ URL

バッジ行を組み立てる際は references/badges.md を読み込みます。ここには、サポートされているすべてのサービスの完全な URL パターンと置換方法が記載されています。Language = Other の場合、ユーザーが言語名を指定しない限り、技術スタックのバッジ行は省略します。

セクションごとのバージョンバッジ（プラグインコレクションおよびライブラリタイプ）：

![v{VERSION}](https://img.shields.io/badge/v{VERSION}-blue?style=flat-square)

コンポーネント／セクションの見出しと同じ行に、&nbsp; で区切って配置します。

### 🧠 plugin-name &nbsp; ![v0.7.5](https://img.shields.io/badge/v0.7.5-blue?style=flat-square)

バッジにより GitHub が自動生成するアンカーが予測できなくなるため、これらの見出しの前には必ず <a id="slug"></a> を配置します。

Step 5 — 作成と要約

現在の作業ディレクトリに README.md を作成します。README.md がすでに存在する場合は、上書きする前に確認してください。

作成後、簡潔な要約を出力します。

  • 書き込んだファイルパス
  • 含めたセクション
  • ユーザーが置き換える必要のあるプレースホルダー値：USER/REPO、PKG、ワークフローのファイル名、スクリーンショット／GIF のパス、および説明本文

コメント

Markdown 対応