mcpField
B
build

build

github.com/camacho開発386 回インストール
リポジトリ

build について

build は、承認済みプランのタスクをサブエージェントで実行し、結果を検証して進捗を報告する開発スキルです。プランのない小規模なホットフィックスや範囲の明確な変更にも対応し、どちらの手順にも検証ゲートを設けています。

主な機能

  1. 01依存関係に沿ったタスクのバッチ実行
  2. 02並列可能なタスクへのサブエージェント割り当て
  3. 03完了したバッチのコミット
  4. 04回数制限付きの検証実行
  5. 05サブエージェントを使わない順次実行

活用シーン

  1. 01承認済みの複数ステップのプランを実装
  2. 02プランなしで小規模なホットフィックスを適用
  3. 03コードレビュー前に変更を検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/camacho/ai-skills --skill build

インストール後、Claude Code で/buildを入力して読み込まれたか確認します。

詳細

/build

サブエージェント経由で計画タスクを実行し、検証して報告します。

告知:「/build を開始します — サブエージェントをディスパッチして計画を実行します。」

前提条件

  • /review（Step 4）で計画が承認済みであること、または計画なしの1文のスコープ／ホットフィックスであること
  • リンクされたワークツリーで作業していること（プライマリではないこと）

計画がある場合

1. 読み込み

ai-workspace/plans/<name>.md を読みます。タスクを順序付きのバッチにまとめます。

  • 同じステップ内のタスク、または並列実行と指定されたタスクは1つのバッチにまとめます
  • 先行タスクに依存するタスクは、別の逐次バッチにします
  • タスクごとにファイルパス、テストの期待事項、受け入れ基準を記録します
2. バッチを実行

バッチは順次実行します。バッチ内のタスクはサブエージェント経由で並列にディスパッチします。

タスクごとのエージェント選定：

計画の構成エージェント備考
「テストを書く」と「実装する」が別々のタスクtest-writer（RED）、続いて implementer（GREEN）このペア内では順次実行
「テスト付きで X を実装する」という複合タスクimplementerTDD を内部で実施
ドキュメントのみのタスクdoc-writer

並列実行の安全性： 異なるファイルを変更する場合にのみ、タスクを並列にディスパッチします。

サブエージェントへのプロンプト — 各エージェントに以下を提示します：

You are implementing Task N: [task name]

## Task Description
[FULL TEXT from plan — paste it, don't make the subagent read the file]

## Context
[Where this fits, what earlier batches produced, architectural decisions]

## Working Directory
[Absolute path to worktree]

## Project Conventions
- TDD: write failing test first, make it pass, refactor
- Commit after task completes (conventional commits) AND ensure your work is on disk before reporting DONE — the inter-batch step commits a batch boundary, but your task-level commits make recovery from inter-batch failures cleaner
- TypeScript strict, ESM, Biome, Vitest, Pino logger, no barrel exports
- Self-review before reporting back

## Report: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT

応答への対応：

ステータス対応
DONEタスクを完了として記録
DONE_WITH_CONCERNS懸念事項を確認 — 正確性／スコープに関するものなら、続行前に対処
NEEDS_CONTEXT不足しているコンテキストを提供して再ディスパッチ
BLOCKED状況を判断：コンテキストを追加するか、より高性能なモデルを使うか、作業を細分化するか、人間にエスカレーションするか
タスクが保護対象ファイルに触れる直ちに停止 — 決してディスパッチしない

何も変更せずに BLOCKED を再試行してはいけません。

バッチ間チェック — 各バッチの後、リグレッションがないことを確認し、次のバッチを始める前にそのバッチの成果をコミットします。

pnpm typecheck && pnpm test
git -C "$WORKTREE" add -A
git -C "$WORKTREE" commit -m "<type>(<scope>): batch N — <summary>"

バッチ内のタスクごとのコミットは可能な範囲で行いますが、バッチ境界でのコミットは必須です（/task の不変条件 REQUIRE batch.commit BEFORE batch.next に従います）。検証を終えてもコミットしていないバッチは、次のバッチが失敗したりセッションが終了したりすると、すべての作業が失われる可能性があります。wip-checkpoint Stop フック（ADR-008）はセッション終了時にダーティな状態をバックストップとして記録しますが、バッチ間でコミットすれば復旧時の状態を整理できます。サイドリファレンスに単一のダーティ状態の塊を残すのではなく、ブランチ履歴でバッチ単位の粒度を保てます。

3. 検証（必須ゲート）

すべてのバッチが完了した後：

pnpm validate

出力を読みます。証拠なしに成功を主張してはいけません。失敗した場合：

  1. 失敗を診断します
  2. 修正します（サブエージェントをディスパッチするか、小さな問題なら直接修正します）
  3. pnpm validate を再実行します
  4. 修正と検証のサイクルは最大3回です。それでも失敗する場合は停止して報告します。

検証に合格するまで、Step 6（/review）を開始することはできません。

4. 報告
Build complete.
Tasks: <completed>/<total>
Validate: PASS
Next step: /review (Step 6)

DONE_WITH_CONCERNS の懸念事項があれば記載します。ビルド中に行った判断を .branch-context.md に反映します。

計画がない場合（ホットフィックス／1文のスコープ）

直接実装します — スコープが小さい場合、サブエージェントによるオーケストレーションは行いません。

  1. TDD：失敗するテストを書く（RED）、修正を実装する（GREEN）、リファクタリングする
  2. 最小限の変更：欠陥のみを修正し、それ以外には手を加えません（ホットフィックス）
  3. 根本原因：コミットメッセージ本文に記録します（ホットフィックス）
  4. 検証：pnpm validate — 同じ必須ゲート、最大3回

Codex / Cursor のフォールバック

サブエージェントのディスパッチは行いません。メインセッションでタスクを順次実行します。同じ検証ゲートが適用されます。

連携

関係スキル
呼び出し元/task（Step 5）
依存先/blueprint（Step 3）+ /review による計画承認（Step 4）
後続/review によるビルドレビュー（Step 6）

コメント

Markdown 対応