repokit

repokit

gh CLI を通じて GitHub リポジトリを、明示的な次の 4 つのモードで設定します。

• about. リポジトリ自体の内容（README、マニフェスト、コード）から、1 行の About 説明と絞り込んだトピックを推測し、現在設定されている内容と比較して表示したうえで、承認された内容を適用します。
• labels. ワークフローのラベルを用意します。issuekit が作業の追跡と優先順位付けに使う ライフサイクルと優先度のセット、およびリポジトリの AI レビューツールに PR の確認を依頼する 自動化ラベルです。不足しているラベルを作成し、既存のラベルのずれを調整します。
• setup. 作成済みのリポジトリを一度の処理で標準に合わせます。標準のリポジトリ設定（マージコミットのみ、マージ後にブランチを削除）を適用し、基本ファイル（公開設定に応じた LICENSE、README、.gitignore、AGENTS.md）を用意してから、デフォルト設定で質問せずに about と labels を実行します。これは設定を行うものです。gh repo create はユーザーが実行します。
• docs. リポジトリの docs/ にある成果物の番号を振り直し、ディレクトリ一覧が作成順に並ぶようにします。各成果物のファイル名の先頭に、作成時期に基づくゼロ埋め連番を付けます。リポジトリごとに一度行う移行で、再実行しても安全です。

4 つの作業を 1 つのスキルにまとめているのは、どれも「このリポジトリを標準に合わせる」という目的に応えるからです。ユーザーが読む対外的な紹介文、issue ワークフローで使うラベルの語彙、新しいリポジトリが最初に備える設定とファイル、そして他のキットが作成する成果物の命名を整えます。

実行するタイミング

ユーザーが GitHub 上のリポジトリを設定したい場合、依頼内容に応じてモードを選びます。

• about. 「リポジトリの説明を設定して」「トピックを追加して」「About の紹介文を書いて」「このリポジトリにタグを付けて」「リポジトリの About を更新して」。
• labels. 「ワークフローのラベルを用意して」「このリポジトリのラベルを設定して」「issuekit のラベルを追加して」「優先度ラベルを追加して」「ai-review ラベルを追加して」「blocked ラベルがない」。
• setup. 「この新しいリポジトリを設定して」「このリポジトリを構成して」「このリポジトリを自分の慣例に合わせて」「このリポジトリを設定して」や「リポジトリのメタデータを設定して」のように意図が漠然としている依頼には、包括的な setup を選びます。これは従来の「about の後に labels を提案する」という回答を包含します。
• docs. 「ドキュメントのファイルに番号を付けて」「docs の番号を振り直して」「ファイル名の先頭に番号を付けて」「docs が日付順に並ばない」「ドキュメントのファイル名を移行して」。setup では実行しません。setup は新しいリポジトリを標準に合わせるもので、新しいリポジトリには番号を振り直す成果物がないためです。

モードが明確でない場合は、まず質問してください。 4 つのモードを提示し、何かに手を加える前にユーザーに選んでもらいます。

各モードの内容は modes/ の下にある個別のファイルに記載されています。上記のリストに従ってモードを選び、該当するファイルを読んで、その指示に従ってください。このルートに記載されている内容はすべてのモードに適用され、モードのファイルでは繰り返しません。

• モード about → modes/about.md を読み、その指示に従ってください。
• モード labels → modes/labels.md を読み、その指示に従ってください。
• モード setup → modes/setup.md を読み、その指示に従ってください。
• モード docs → modes/docs.md を読み、その指示に従ってください。

事前確認（すべてのモード）

docs はこのセクションと次のセクションの例外です。 作業ツリー内のファイル名を変更しますが、GitHub は一切呼び出さないため、gh もリモートも必要ありません。ローカルのみのリポジトリで実行できます。必要な確認事項は、専用のファイルに記載されています。以下は about、labels、setup に適用されます。

GitHub を呼び出す前に、ツールと対象を確認します。

gh --version                                          # gh installed?
gh auth status                                        # authenticated?
gh repo view --json nameWithOwner -q .nameWithOwner   # which repo? (the current dir's remote)

• gh がない、または認証されていない場合は、その旨を伝え、https://cli.github.com / gh auth login を案内してください。別の方法で回避しないでください。
• GitHub リモートがない場合（repo view の呼び出しが失敗する場合）は、停止してその旨を伝えてください。repokit は GitHub 上に存在するリポジトリを対象に動作するためです。これは setup にも当てはまります。リポジトリの作成（gh repo create）はユーザーが行い、repokit は作成後に開始します。
• シェルも gh も使えない場合（ブラウザベースのエージェントなど）、gh を呼び出すことはできません。ユーザーから提供された情報に基づいて判断し、説明やトピックを設定するコマンド、gh label create のブロック、gh repo edit の設定行など、実行するための正確な gh コマンドをコードブロックとして出力してください。setup のひな形ファイルも同様です。各ファイルをパス付きのフェンス付きブロックで出力してください。

このスキル全体に適用される安全方針。 リポジトリの説明、トピック、ラベル、設定は、外部に公開される情報です。すべての変更を実行前にプレビューし、承認を得てください。ユーザーの指示なしに GitHub 上で変更が行われないようにします。 例外は setup です。ユーザーはデフォルト設定での実行を依頼しているため、設定を適用し、引き継ぎ時にすべての変更を報告します。実行するコマンドは、変更を監査・再実行できるよう、必ずそのまま提示してください。

再実行しても安全です。 すべてのモードで既存の状態との差分を調整するため、変更のないリポジトリで repokit を再度実行しても、変更は提案されず、何も変更されません。いつでも安全に再実行できます。

検出（すべてのモード）

提案を行う前に、リポジトリの現在の状態を一度読み取ります。これは各モードが差分調整の基準とする情報であり、保護措置も早い段階で確認できます。選択したモードで必要な情報と、保護措置に関するフラグを取得します。

# guardrail flags + about state
gh repo view --json isArchived,isFork,isTemplate,description,homepageUrl
gh api repos/{owner}/{repo}/topics --jq '.names'    # current topics (about mode)
gh label list --json name,color,description          # current labels (labels mode)

setup では、差分を確認する設定も追加で取得します。正確なフィールドは、モードのファイルに記載されています。

変更を行う前に、保護措置に関するフラグを確認します。

• アーカイブ済み（isArchived: true）。GitHub はアーカイブ済みリポジトリのメタデータ編集を拒否するため、停止し、まずアーカイブを解除するようユーザーに伝えてください。
• フォークまたはテンプレート（isFork / isTemplate）。メタデータが継承されている場合や使い捨てのものである場合が多いため、続行する前にこのリポジトリを編集する意図があるか、ユーザーに確認してください。

注意事項

• 明示的な依頼がない限り、リポジトリのトピックを一括削除したり、標準セット外のラベルを削除したりしないでください。デフォルトは破壊的な変更ではなく、追加と整合です。
• ライフサイクルと優先度のマップは、issuekit との共有契約です。両方の名前空間で同じ名前を使い、色と意味も同じにします。説明文は repokit のものを正式なものとします。自動化用のセットは repokit のみのものです。issuekit はトラッカーを運用し、ai-review はプルリクエストに対して機能するためです。
• repokit は語彙を用意しますが、適用はしません。 ここでどのモードを使っても、イシューや PR にラベルが付くことはありません。#42 を high と判断するのは作業内容についての判断であり、issuekit の create と triage の役割です。AI レビューを依頼するかどうかは、作成者が自分の PR で決めます。repokit が保証するのは、その判断を表す語が存在することだけです。この線引きがあるからこそ、稼働中のトラッカーがあるリポジトリでも、ラベルモードを安全に再実行できます。
• repokit はコミットしません。 setup はスキャフォールドファイルを書き込みますが、ステージングはしません。docs は名前を変更したファイルをステージングします。それらをまとめてコミットするのは、コミットスキルまたはユーザーの役割です。
• ラベルでは名前空間ごとに1つだけという制約を強制できないため、書き込み側で対処する必要があります。 GitHub では、1つのイシューに critical と low を同時に付けても問題ありません。また、ここでそれを防ぐことはできません。repokit が担うのは語彙を用意するところまでです。相互排他はラベルを適用する側が書き込み時に強制します。そのため、このルールはこのマップではなく issuekit にあります。
• リポジトリで既に管理されている内容を優先してください。既存の名前空間にあるスキームは labels の既存スキーム確認で処理し、管理されている概要やトピックは about で項目ごとに整合します（無条件に上書きすることはありません）。また、setup は既存ファイルを上書きしません。標準セットは置き換えではなく、追加として提案してください。
• 人が読む出力のスクレイピングではなく、gh の構造化 JSON（--json／--jq、トピック API）を優先してください。JSON フィールドは安定した契約ですが、表示テキストはそうではないためです。