| name | repo-kickoff |
| description | 新規リポジトリの立ち上げ時に、存在意義・スコープ・ロードマップ・成功条件などを多角的にヒアリングし、README.md / docs/ 配下の設計文書（charter / roadmap / architecture）/ CLAUDE.md を体系的に整備する。文書を「揺るがない部分」と「揺らぎ得る部分」に分離して保守性を高めるのが特徴。Use when: (1) 新しいリポジトリを作成した直後、(2) 既存リポジトリの目的やロードマップを整理し直したいとき、(3) 「このリポジトリって結局何のためにあるんだっけ」が曖昧になったとき。 |
Repo Kickoff
新規リポジトリの「なぜ・なに・どう・いつ・誰が」を 9 視点でヒアリングし、文書の 更新頻度（不変・準不変・可変）に応じて分離 して出力する。
このスキルが解く課題
新規リポジトリは作った直後が最も「目的が明確」な瞬間。しかし数か月後には「なぜ作ったか」「どこまでやる予定だったか」「何が完了条件か」が忘れられ、目的不明の負債と化す。
最初に体系的に言語化し、文書を性質ごとに分離して残す ことで、将来の自分・他人・AI が文脈を取り戻せるようにする。
設計原則: 揺るがない / 揺らぎ得る を分離する
文書の保守失敗パターンの多くは、更新頻度の異なる情報を同一ファイルに混ぜる ことに起因する。「不変であるべき存在意義」と「日々変わる技術スタック」を 1 ファイルに書くと、技術スタック更新のたびに不変領域も触られ、結果としてどちらも信頼できなくなる。
このスキルは出力ファイルを 3 段階の Stability に分離する:
| Stability | 意味 | 変更時の重み |
|---|
🪨 stable | プロジェクトのアイデンティティ。原則として変えない | 重い（ADR 必須） |
🌀 evolving | 計画・ロードマップ。フェーズ進行で更新される | 中（明示的な更新タイミング） |
🌊 living | 実装・運用の現状。日々書き換えられる | 軽い（自由に更新） |
各文書の冒頭に Stability バッジ + 最終更新日 + 直近の変更 ADR リンク をセットで配置する。
出力ファイル構成
README.md — 外部向け要約 + 使い方（Stability: 🌊 living）
CLAUDE.md — AI 協働の文脈情報（Stability: 🌊 living）
docs/
├── README.md — docs/ の読む順序ガイド
├── charter.md 🪨 stable — Why / 課題 / 想定ユーザー / Out of Scope / 撤退条件
├── plan.md 🌀 evolving — フェーズ / マイルストーン / 各フェーズの完了条件
├── architecture.md 🌊 living — 技術スタック / 設計判断 / 運用
└── decisions/ — ADR (Architecture Decision Record)
├── 0000-template.md
└── 0001-record-architecture-decisions.md
ADR の使い方
ADR は 「アーキテクチャ上重要な決定」 を context / decision / consequences の形で記録する（Michael Nygard 由来の標準的な使い方）。文書の変更履歴ではない（それは git log で十分）。
- 任意: architecture.md の細かい設計判断
- 必須: charter.md の改訂（不変領域が変わるときの履歴を残す）
- 推奨: plan.md のフェーズ大幅見直し
ワークフロー
Step 1: 起点の確認
- 対象リポジトリのパス（カレントか、明示指定か）
- 既存ファイルの有無（README.md, docs/, CLAUDE.md）
- 「新規立ち上げ」か「既存リポジトリの再整理」か
既存ファイルがある場合: 上書きせず、内容を読み込んでヒアリングのベースラインに使う。最終アウトプットは差分提案として示す。
Step 2: 多角的ヒアリング
references/interview-questions.md の 9 視点に沿って質問する。
ヒアリング戦術:
- 必須視点を先に: 視点 1（Why）, 2（Scope）, 5（Roadmap）, 6（Success/Sunset）は必ず聞く
- 段階的に: 一度に全項目を投げない。視点ごとに区切る
- 「未定」を許す: 必須項目以外は
TBD で残してよい
- 既存情報を活用: 既に README.md などに書かれている内容は再ヒアリングしない
- 自分の言葉で要約: 答えを受けたら必ず「つまり〜という理解で合ってますか」と返して確認
Step 3: 充足度判定（空欄拒否ルール）
ヒアリング後、以下を判定する:
必須項目（🔴）の充足率 = 埋まった必須項目数 / 全必須項目数
- 充足率 < 50%: 生成を保留。「このまま生成すると
TBD だらけになり、後で誰も読まない置物になります。あと N 項目だけ追加で考えてみませんか？」とユーザーに提案
- 充足率 >= 50%: 生成に進む（ただし未充足項目は
TBD（次回更新時に決定） と明示）
Step 4: 構造化と出力先の決定
references/output-templates.md のマッピング表に従って、ヒアリング結果を各ファイルに振り分ける。
判断基準:
- 内容が薄ければ docs/ 分割せず README.md / CLAUDE.md に節として含める
- 視点 9（AI 協働）は CLAUDE.md にのみ書く（README に混ぜない）
- 不変系の情報は charter.md にのみ書く（重複させない）
Step 5: 出力生成
references/output-templates.md のテンプレートを使い、ファイルごとにドラフトを生成する。
出力時の必須要件:
-
Stability ヘッダ: 各 docs/ ファイル冒頭に以下を付ける
> **Stability**: 🪨 stable
> **最終更新**: 2026-04-30
> **直近の変更 ADR**: なし（初版）
-
空欄を残さない: 未定項目は TBD（次回更新時に決定） のように明示する
-
相互リンク: README → docs/、docs/ 同士もリンクで繋ぐ
-
AI 協働文脈は CLAUDE.md に集約: ドメイン用語・触れてほしくない領域などは CLAUDE.md に
-
docs/README.md を生成: 各 docs/ ファイルの役割と読む順序を案内
Step 6: ユーザー確認とコミット
- 生成したファイル一覧と各ファイルの目的を要約して提示
- ユーザーが内容を確認して微調整
- ユーザーが OK したら git add & commit を提案（コミット強行はしない）
9 視点と出力先の対応
| # | 視点 | 主要トピック | 出力先 |
|---|
| 1 | プロダクト・事業 (Why) | 存在意義 / 課題 / 想定ユーザー | docs/charter.md 🪨 |
| 2 | スコープ (What) | やる / やらないこと / 隣接プロジェクトとの境界 | docs/charter.md 🪨 |
| 3 | エンジニアリング (How) | 技術スタック / アーキテクチャ / 主要設計判断 | docs/architecture.md 🌊 |
| 4 | 品質・運用 (Quality) | 非機能要件 / テスト / 監視 / デプロイ | docs/architecture.md 🌊 |
| 5 | ロードマップ (When) | MVP / フェーズ / 完了条件 | docs/plan.md 🌀 |
| 6 | 成功・撤退 (Success/Sunset) | KPI / 完了条件 / 撤退条件 | docs/charter.md 🪨 |
| 7 | コラボレーション (Who) | メンテナ / 貢献ポリシー | README.md |
| 8 | リスク・制約 (Risks) | 技術的リスク / 法的制約 / 前提 | docs/charter.md 🪨（不変系）or docs/architecture.md 🌊（技術系） |
| 9 | AI 協働 (CLAUDE.md 特有) | AI ルール / ドメイン用語 / 触れてほしくない領域 | CLAUDE.md |
詳細な質問項目は references/interview-questions.md を参照。
詳細なテンプレートは references/output-templates.md を参照。
アンチパターン
このスキルが避けるべき失敗:
- 全項目を機械的に質問: ユーザーが疲弊する。必須を絞り、未定を許す
- 既存の README を上書き: 既存内容は読み込んでベースラインにし、差分提案にする
TBD だらけのドキュメントを生成: 充足率 < 50% なら生成保留（Step 3 のルール）- CLAUDE.md と README に同じ内容を重複: 役割を分離（README = 外部向け / CLAUDE.md = AI 協働文脈）
- 「やらないこと」を聞き逃す: 視点 2 の Out of Scope は最重要。明示的に質問する
- 撤退条件を空欄で済ます: 視点 6 の撤退条件は将来の判断に効く
- charter.md を ADR なしで書き換える: 不変領域の変更は必ず ADR で履歴を残す
- architecture.md と ADR で同じ決定を二重管理: ADR は「決定の根拠」、architecture.md は「現状の構成」。ADR から architecture.md にリンクするだけにする
連携するスキル
- claude-code-rules: プロジェクト固有のルール（
.claude/rules/）を別途整備する場合に併用
- tuning: 既に立ち上げ済みのリポジトリの設定を後から調整する場合
