菜单
新規リポジトリの立ち上げ時に、存在意義・スコープ・ロードマップ・成功条件などを多角的にヒアリングし、README.md / docs/ 配下の設計文書（charter / roadmap / architecture）/ CLAUDE.md を体系的に整備する。文書を「揺るがない部分」と「揺らぎ得る部分」に分離して保守性を高めるのが特徴。Use when: (1) 新しいリポジトリを作成した直後、(2) 既存リポジトリの目的やロードマップを整理し直したいとき、(3) 「このリポジトリって結局何のためにあるんだっけ」が曖昧になったとき。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
herdr で別 workspace / pane で動く独立した Claude Code エージェントに作業を依頼し、返信を受け取るための定型手順。宛先特定 → 自己完結メッセージ送信 → 進捗確認 → 返信受領を、herdr CLI（Bash 経由）で安全に実行する。特に「テキスト投入だけでは submit されない」2段階送信の落とし穴を構造的に回避する。Use when: (1) 「別のエージェントに依頼」「他の workspace / pane の agent にメッセージ」「herdr でエージェント間連携」と言われたとき、(2) 独立して動いている別セッションの Claude Code に作業を渡して結果を受け取りたいとき、(3) 複数 workspace のエージェントを協調させたいとき。同一セッション内の subagent 起動（Agent tool / SendMessage）には使わない。
Claude Code の rules ファイル（.claude/rules/*.md）を作成・改善するためのスキル。新規プロジェクトへの rules 導入、既存 rules の分析・リファクタリング、条件付きルールの設計に使用。「rules を作成したい」「CLAUDE.md を整理したい」「ルールを追加したい」といった要求時にトリガー。
重要な意思決定を、複数の役割エージェントを並列起動して多角検証する skill。Devil's Advocate を必須枠として、時間軸・立場軸・論理軸・価値軸の 4 カテゴリから固定役を常駐させる。決定の「逆戻り可能性」に応じて 3 役 / 5 役 / 7 役を自動選択し、テーマに応じてアドホック役 (Maintainer / Adversary / Historian など) を追加する。Use when: (1) アーキテクチャ・技術選定など中長期に効く判断、(2) 撤退・廃止・大規模リファクタなど後戻りコストが高い判断、(3) 採用・組織変更・体制変更など人に関わる判断、(4) 「これでいいのか自信がない」と感じる根幹判断。普段の小さな判断には使わない。
Claude の振る舞いをユーザーの好みに合わせて調整する。フィードバックや要望を分析し、最適な設定ファイル（skills, rules, CLAUDE.md）を特定して更新案を提示する。Use when: (1) Claude の振る舞いを変えたいとき（「次からこうして」「こうなって欲しい」「これはやめて」）, (2) 既存の skill・rules・CLAUDE.md を改善・整理したいとき, (3) 新しいルールや方針を追加したいとき, (4) 設定の整理統合やリファクタリングをしたいとき
| name | repo-kickoff |
| description | 新規リポジトリの立ち上げ時に、存在意義・スコープ・ロードマップ・成功条件などを多角的にヒアリングし、README.md / docs/ 配下の設計文書（charter / roadmap / architecture）/ CLAUDE.md を体系的に整備する。文書を「揺るがない部分」と「揺らぎ得る部分」に分離して保守性を高めるのが特徴。Use when: (1) 新しいリポジトリを作成した直後、(2) 既存リポジトリの目的やロードマップを整理し直したいとき、(3) 「このリポジトリって結局何のためにあるんだっけ」が曖昧になったとき。 |
新規リポジトリの「なぜ・なに・どう・いつ・誰が」を 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/）を別途整備する場合に併用