Stats
Actions
Tags
From yutaura-toolkit
新規リポジトリの立ち上げ時に、存在意義・スコープ・ロードマップ・成功条件などを多角的にヒアリングし、README.md / docs/ 配下の設計文書（charter / roadmap / architecture）/ CLAUDE.md を体系的に整備する。文書を「揺るがない部分」と「揺らぎ得る部分」に分離して保守性を高めるのが特徴。Use when: (1) 新しいリポジトリを作成した直後、(2) 既存リポジトリの目的やロードマップを整理し直したいとき、(3) 「このリポジトリって結局何のためにあるんだっけ」が曖昧になったとき。
How this skill is triggered — by the user, by Claude, or both
Slash command
/yutaura-toolkit:repo-kickoffThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
新規リポジトリの「**なぜ・なに・どう・いつ・誰が**」を 9 視点でヒアリングし、文書の **更新頻度（不変・準不変・可変）に応じて分離** して出力する。
新規リポジトリの「なぜ・なに・どう・いつ・誰が」を 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 は 「アーキテクチャ上重要な決定」 を context / decision / consequences の形で記録する（Michael Nygard 由来の標準的な使い方）。文書の変更履歴ではない（それは git log で十分）。
- 対象リポジトリのパス（カレントか、明示指定か）
- 既存ファイルの有無（README.md, docs/, CLAUDE.md）
- 「新規立ち上げ」か「既存リポジトリの再整理」か
既存ファイルがある場合: 上書きせず、内容を読み込んでヒアリングのベースラインに使う。最終アウトプットは差分提案として示す。
references/interview-questions.md の 9 視点に沿って質問する。
ヒアリング戦術:
TBD で残してよいヒアリング後、以下を判定する:
必須項目（🔴）の充足率 = 埋まった必須項目数 / 全必須項目数
TBD だらけになり、後で誰も読まない置物になります。あと N 項目だけ追加で考えてみませんか？」とユーザーに提案TBD（次回更新時に決定） と明示）references/output-templates.md のマッピング表に従って、ヒアリング結果を各ファイルに振り分ける。
判断基準:
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/ ファイルの役割と読む順序を案内
| # | 視点 | 主要トピック | 出力先 |
|---|---|---|---|
| 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 を参照。
このスキルが避けるべき失敗:
TBD だらけのドキュメントを生成: 充足率 < 50% なら生成保留（Step 3 のルール）.claude/rules/）を別途整備する場合に併用npx claudepluginhub yutaura/claude-marketplace --plugin yutaura-toolkitProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.