Stats
Actions
Tags
How this skill is triggered — by the user, by Claude, or both
Slash command
/hikyaku:builder [{DOC_ROOT}] [buildID|next][{DOC_ROOT}] [buildID|next]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
`$ARGUMENTS[0]` のワークフローパスから企画・設計ドキュメントを読み込み、実装フェーズを実行する。`$ARGUMENTS[1]` で buildID を指定できる（省略時は次のビルドを自動選択）。
$ARGUMENTS[0] のワークフローパスから企画・設計ドキュメントを読み込み、実装フェーズを実行する。$ARGUMENTS[1] で buildID を指定できる（省略時は次のビルドを自動選択）。
Hikyakuは PLAN → ARCHITECT → BUILD の3フェーズで構成されるAIエージェント協働開発ワークフロー。
/hikyaku:planner → planning/ を生成（完了済み）
↓
/hikyaku:architect → architecture/ + tasklist.md + build-{NN}/issue.md を生成（完了済み）
↓
/hikyaku:builder → build-01/ を実装 → handoff.md → PR
/hikyaku:builder → build-02/ を実装 → handoff.md → PR ← あなたはここ
...（ビルド数分繰り返し）
$ARGUMENTS[0]/
├── tasklist.md # ビルド一覧（ARCHITECT で作成済み、BUILD で PR列を更新）
├── planning/ # 企画ドキュメント（PLAN で作成済み、参照のみ）
│ ├── questions.md # 企画段階の質問と回答
│ ├── user-stories.md # ユーザーストーリー
│ └── retrospective.md # 振り返り（PLAN で作成）
├── architecture/ # 設計ドキュメント（ARCHITECT で作成済み、実装時に差分があれば更新）
│ ├── codebase-survey.md # 既存コード調査結果（任意）
│ ├── design-questions.md # 設計段階の質問と回答
│ ├── decisions.md # 設計判断ログ（ADR、任意）
│ ├── tech-stack.md # 技術選択（任意）
│ ├── db-schema.md # DBスキーマ（任意）
│ ├── interfaces.md # インターフェース定義（任意）
│ ├── conventions.md # 共通規約（任意）
│ └── retrospective.md # 振り返り（ARCHITECT で作成）
├── build-01/ # 完了済みビルド
│ ├── issue.md # ビルド定義（ARCHITECT で作成済み）
│ ├── plan.md # 実装計画
│ ├── test-spec.md # テストシナリオ
│ ├── handoff.md # 申し送り → 後続ビルドが参照
│ └── retrospective.md # 振り返り
├── build-02/ # ← これから作業するビルド
│ ├── issue.md # ビルド定義（ARCHITECT で作成済み）
│ ├── plan.md # ← BUILD で作成
│ ├── test-spec.md # ← BUILD で作成（テストシナリオ）
│ ├── questions.md # （必要時のみ）
│ ├── handoff.md # ← BUILD で作成
│ └── retrospective.md # ← BUILD で作成
└── ...
あなたは実装フェーズの1ビルドを担当する。企画・設計は別セッションで完了済み。 設計ドキュメント（architecture/）と先行ビルドの handoff.md を読んでコンテキストを復元し、実装→検証→申し送り→PRまでを完結させる。
やらないこと:
設計ドキュメントの更新について:
作業の開始前に必ず以下を実行する。
<SKILL_ROOT>/references/templates.md: 各種成果物のテンプレート（必須）<SKILL_ROOT>/references/retry-policy.md: エラー発生時のリトライ方針（必須）.hikyaku.config を読み込む（存在する場合のみ）$ARGUMENTS[0] が指定されている場合 → その値を DOC_ROOT として使用する$ARGUMENTS[0] が未指定で .hikyaku.config に doc_root が設定されている場合 → その値を DOC_ROOT として使用する.hikyaku.config に base_branch が設定されている場合 → origin/{base_branch} を使用するgit remote show origin | grep 'HEAD branch' | awk '{print $NF}' でデフォルトブランチ名を抽出し、origin/{branch} 形式で使用する.hikyaku.config で未設定の場合はデフォルト値を使用する）
code_review: デフォルト truesecurity_review: デフォルト true{DOC_ROOT}/instruction.md: ワークフロー独自のインストラクション（存在する場合のみ）以降のステップでは DOC_ROOT を $ARGUMENTS[0] の代わりに、BASE_BRANCH を origin/main の代わりに使用する。
なお、インストラクションは次の優先順で適用する。上位の指示が下位と矛盾する場合は、上位を優先すること。
→ すべて読み込めたら Step 1 へ。必須ファイルが読み込めなかった場合はユーザーに報告して終了。
$ARGUMENTS[0]/tasklist.md を読み込む$ARGUMENTS[1] が数値の場合: 該当する buildID のビルドを対象とする$ARGUMENTS[1] が省略または next の場合: PR列が空かつ、依存ビルド（dependencies列）のPR列がすべて埋まっているビルドの中から、最小のbuildIDを選択する注意: buildID の数値順は実行順序と一致しない場合がある（ビルド分割により後から追加されたビルドが、数値上は大きいが依存グラフ上は先に実行すべきケースがある）。必ず dependencies 列に基づいて判断すること。
→ すべて完了したら Step 2 へ。対象ビルドが見つからない、または依存ビルドが未完了の場合はユーザーに報告して終了。
以下の順でドキュメントを読み込む:
$ARGUMENTS[0]/build-{NN}/issue.md — 対象ビルドの定義（やること/やらないこと/受け入れ基準）$ARGUMENTS[0]/build-{NN}/ に既存の成果物（plan.md, test-spec.md, handoff.md 等）がないか確認する
$ARGUMENTS[0]/architecture/codebase-survey.md — 既存コードの構成・規約・拡張ポイント（存在する場合）$ARGUMENTS[0]/architecture/decisions.md — 設計判断ログ（存在する場合）
decisions.md に追記し、さらに $ARGUMENTS[0]/build-{NN}/handoff.md にも記録する
$ARGUMENTS[0]/architecture/ — その他の関連する設計ドキュメントを参照$ARGUMENTS[0]/build-{NN}/handoff.md を読み込む
→ すべて読み込めたら Step 3 へ。
→ Step 4 へ。
$ARGUMENTS[0]/build-{NN}/questions.md でユーザーに質問する$ARGUMENTS[0]/build-{NN}/plan.md を作成する
NNは buildID をゼロ埋め2桁にしたもの（例: buildID 3 → build-03）→ 承認を得たら Step 5 へ。フィードバックがあれば plan.md に反映し、Step 4 の承認からやり直す。
テストケースの洗い出し過程のコンテキスト消費を避けるため、メインセッションでは直接作成しない。
$ARGUMENTS[0]/build-{NN}/test-spec.md を生成させる
plan.md, issue.md, architecture/ 配下の関連ドキュメントAgent に渡すフォーマット指定:
## フォーマット（必ず従うこと）
```markdown
# Build {NN}: {ビルド名} テストシナリオ
## {テスト対象クラス/モジュール名}
### {メソッド名}: {シナリオ名}
- Given: （前提条件）
- When: （操作）
- Then: （期待結果）
```
**記載ガイドライン:**
- 正常系・異常系・境界値を網羅する
- Given/When/Then は具体的な値を含める（例: `Given: メールアドレス "[email protected]" のユーザーが登録済み`）
- 1シナリオ = 1つの検証観点に絞る。表形式は使わないこと
→ 承認を得たら Step 6 へ。フィードバックがあれば test-spec.md に反映し、Step 5 の承認からやり直す。
→ Step 7 へ。
全ての項目がパスするまで Push しない。
→ Step 8 へ。
機械的検証（lint / test / build）だけでは検出できない品質・規約・セキュリティ観点をレビューする。スコープ逸脱や規約違反、セキュリティ問題を申し送り作成前に潰す。
code_review と security_review が共に false の場合はこのステップをスキップして Step 9 へcode-reviewer と security-reviewer を並列起動する（code_review が false の場合は security-reviewer のみ、security_review が false の場合は code-reviewer のみ起動する）
{DOC_ROOT}/build-{NN}/）、{DOC_ROOT}/build-{NN}/plan.md, {DOC_ROOT}/build-{NN}/issue.md, {DOC_ROOT}/architecture/conventions.md（あれば）, {DOC_ROOT}/architecture/codebase-survey.md（あれば）git status — 変更ファイル一覧（未追跡含む）git diff — unstaged 差分git diff --cached — staged 差分git diff $(git merge-base {BASE_BRANCH} HEAD)..HEAD — base ブランチ（Step 0 で解決した BASE_BRANCH）からの コミット済み差分。再開セッションや途中コミットを含むビルドではこの差分にしか実装が現れないcode-reviewer: スコープ準拠 / 規約準拠 / バグ・ロジック誤り / 冗長性security-reviewer: OWASP 系のセキュリティパターン違反、および /security-review へのエスカレーション判定agents/code-reviewer.md および agents/security-reviewer.md を参照security-reviewer の指摘を優先採用する/hikyaku:build-manager $ARGUMENTS[0] を呼び出して新ビルドを追加する。現在のビルドはそのまま進めるsecurity-reviewer のエスカレーション判定が「推奨」の場合、指摘一覧の最後に以下を提示する:
⚠️ security-reviewer は本ビルドを「セキュリティ感度の高い変更」と判定しました
該当カテゴリ: （security-reviewer の出力をそのまま転記）
より深い監査のため、Step 9（申し送り作成）に進む前に `/security-review` の実行を強く推奨します。
ユーザーに「Step 9 に進む前に /security-review を実行するか」を確認する
/security-review を実行する（builder からは自動起動しない）。完了したらユーザーが手動で本セッションに戻り、Step 9 へ進むエスカレーション判定が「不要」の場合は、この処理をスキップして Step 9 へ進む
→ ユーザー選択に応じて対応後、Step 9 へ。
$ARGUMENTS[0]/build-{NN}/handoff.md を作成する
→ Step 10 へ。
$ARGUMENTS[0]/tasklist.md のPR列を更新し、Pushする注意: 後続ビルドのセッションは、このPRがマージされてから開始すること。後続ビルドは main ブランチの tasklist.md を参照して依存ビルドの完了を確認するため、マージ前に開始すると依存が未完了と判定される。
→ Step 11 へ。
/hikyaku:retrospective $ARGUMENTS[0] build-{NN} を呼び出して振り返りを実施するBuild {NN} が完了しました。
次のビルドを開始するには、新しいセッションで以下を実行してください:
/hikyaku:builder $ARGUMENTS[0]
実装中に以下の状況が発生した場合、/hikyaku:build-manager $ARGUMENTS[0] を呼び出してビルドの追加・変更を行う。
build-manager がユーザー承認を含むビルド管理の全手順を実行する。
呼び出しタイミング:
build-manager 呼び出し後の対応:
PRレビューで指摘を受けた場合、同じセッションまたは新しいセッションで以下の手順で修正する:
$ARGUMENTS[0]/build-{NN}/plan.md を参照してコンテキストを復元する$ARGUMENTS[0]/build-{NN}/ 配下 — plan.md, issue.md, test-spec.md, handoff.md$ARGUMENTS[0]/architecture/ 配下 — interfaces.md, db-schema.md 等$ARGUMENTS[0]/planning/ 配下 — 企画レベルの変更があった場合（稀）/hikyaku:retrospective $ARGUMENTS[0] build-{NN} を呼び出す（既に retrospective.md が存在する場合は追記モードで動作する）Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub tak-solder/hikyaku --plugin hikyaku