Host Repo Init Skill

hane の各 skill（start-dev / design-doc / acceptance-test / qa など）は、 host repo が一定のディレクトリ・ドキュメント慣習を採用していることを 前提に動く。このスキルは、その初期セットアップを対話で行う。

このスキルの価値は「固定のファイルを置くこと」ではなく、repo ごとに異なる選択を 対話で決め、hane が前提とする慣習の単一の出所になることにある。選択肢を持たず 固定構造を吐くだけならテンプレート repo やシェルスクリプトで足りる。

手順

1. 前提確認

• カレントが git repo であることを確認する（でなければ git init を提案する）。
• .gitignore に .claude/worktrees/ が含まれているか確認する。無ければ追記を 提案する（start-dev / ship / design-doc がここに worktree を作るため）。

2. 既存状態のスキャン

docs/{design,adr,acceptance,test-perspectives}/、docs/process.md、.claude/rules/、 tpl.config.json、status: * ラベルの有無を調べる。このスキルは冪等で、既に存在するものは 上書きせず skip する。スキャン結果を踏まえて次の質問を出す。

3. 選択をユーザーに確認

以下を対話で確認する（既に存在するものは「採用済み」として扱い、質問から除いてよい）。

1. 採用するドキュメントディレクトリ — docs/design/（Design Doc）/ docs/adr/（ADR）/ docs/acceptance/（受け入れテスト）/ docs/test-perspectives/（TPL）のうちどれを採用するか。複数選択可。
2. ADR のファイル名規約 — GitHub 番号ベース（<番号>-slug.md、hane の既定。 ADR-8 参照）か、日付ベース（YYYYMMDD-NN-slug.md）か。 docs/adr/ を採用する場合のみ訊く。
3. TPL の id 形式: issue-number（TPL-<番号>。ADR・AT と同じ GitHub 番号ベースで、 hane の既定）か、date-sequence（TPL-YYYYMMDD-NN。tpl-tools の既定）か。 docs/test-perspectives/ に TPL がまだ無い場合のみ訊く。TPL がある repo、tpl.config.json が ある repo、tpl を --config 付きで呼んでいる repo（package.json の scripts 等）では訊かない （既存の運用を作り変えない）。
4. status: * ラベル運用 — start-dev / ship が Issue の進捗を status: ready / blocked / on-hold / implementing / designing / designed / in-review ラベルで追跡する運用を採用するか。
5. .claude/rules/ ディレクトリ — repo 固有の authoring ルール（ADR の言語など） を置くディレクトリを作るか。

4. scaffold する

回答に基づき、以下を生成する。既存ファイルは上書きしない（skip して記録する）。

テンプレートアセットのコピー元

各 TEMPLATE.md は hane plugin 内の skill アセットをコピーする（複製・再生成 しない）。コピー元はこの init skill のディレクトリからの相対パス:

コピー後、内容は変更しない。各テンプレート冒頭の HTML コメントに規約（ファイル名・ 言語・番号規約）が書かれているので、host repo 側で追加の説明は不要。

tpl.config.json の生成

docs/test-perspectives/ が無いか、TPL がまだ無い（空か .gitkeep だけ）ときだけ、repo 直下に選んだ id 形式を 書いた config を作る。tpl.config.json が既にあるか、tpl を --config 付きで呼んでいる repo では作らない （--config で渡したファイルが優先され、作った config は読まれない）。.gitkeep は無ければ作る。 TPL を書く /tpl-tools:test-perspective と検証の tpl CLI はこの idFormat に従い、config が 無ければ date-sequence になる。

{
  "idFormat": "issue-number",
  "topics": []
}

topics（TPL の topic の統制語彙）は host が育てる。空のあいだ tpl validate は topic を検査しない。 tpl init は使わない（idFormat を選べず、常に date-sequence を書くため）。

ディレクトリに TPL が既にある repo では .gitkeep も config も作らない。config が無いまま TPL-<番号> のファイルがあれば、tpl.config.json に "idFormat": "issue-number" を足すよう レポートで案内する（足さないと後継の skill と tpl validate は date-sequence を前提にする）。

status: * ラベルの作成

ラベル運用を採用する場合、以下を gh label create "<name>" --color <hex> --description "<desc>" で作成する（既存ラベルは skip）:

色は任意（例: ready=緑、blocked=赤、on-hold=グレー、それ以外=黄系）。

docs/process.md スケルトン

選択した内容を反映した最小限の docs/process.md を生成する。含める節:

• ドキュメントのライフサイクル — アイデア（Issue）→ 設計（docs/design/、採用時のみ） → 決定（docs/adr/、採用時のみ）の流れ。
• ブランチ・worktree ルール — main への直 push 禁止、worktree は .claude/worktrees/<branch-name>、ブランチ命名（feat/ fix/ docs/ chore/ refactor/ + kebab-case）。
• 採番規約 — 選んだ ADR ファイル名規約。AT も同じ番号ベース。TPL の id は tpl.config.json の idFormat に従う（選んだ形式を書く）。
• ラベル運用 — 採用した場合のみ、status: * の遷移を記す。
• 各ドキュメント種別を採用した場合は、対応する skill（/hane:design-doc / /hane:acceptance-test / /tpl-tools:test-perspective）で記録を作る旨を 1 行ずつ書く。

process.md は host repo がその後育てる前提のスケルトン。冒頭にその旨を明記する。

5. 結果のレポート

生成したファイル・ラベルと、既存のため skip したものを一覧で報告する。

6. 完了後の案内

次のステップを短く示す:

• host repo の CLAUDE.md に hane の利用を 1 節追記する（このスキルは CLAUDE.md の内容には踏み込まない — repo 固有のため）。
• /hane:start-dev で最初の開発を始められる。
• docs/test-perspectives/ を採用した場合は、TPL を書く skill と検証の CLI を入れる: /plugin install tpl-tools@kompiro-hane と @kompiro/tpl-tools。tpl-tools が marketplace に 載る前に kompiro-hane を追加していた場合、install は見つからずに失敗するので、先に /plugin marketplace update kompiro-hane を実行する。

冪等性

このスキルは何度実行しても安全であること。2 回目以降の実行では、既に存在する ファイル・ディレクトリ・ラベルはすべて skip し、不足分だけを補う。実行のたびに created / skipped の内訳をレポートする。

スコープ外

• host repo の CLAUDE.md の生成・編集（repo 固有すぎる。利用者に追記を促すのみ）。
• 既に独自の慣習で運用している repo の移行・整合（このスキルは不足を埋めるだけで、 既存の構造を作り変えない）。