spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
feature-spec と対をなす 基本設計書 1 本 を作る単機能スキル。成果物は
docs/dev/<対象>/basic-design.md。仕様が「何を満たすか（REQ-#）」を定義するのに対し、
基本設計は 「どう実現するか」 を定義し、各機能を REQ-# へ紐づけて
要求に紐づかない機能 = スコープ外混入 を機械検出可能にする。
/feature-spec <対象>
の改訂モードへ回す（設計側で要求を勝手に足さない。それがスコープドリフトの発生源）。docs/test/<対象>/ は testing スキル群の担当。docs/dev/<対象>/basic-design.md。CLAUDE.md / AGENTS.md 等）に成果物の配置規約があればそちらを優先する。docs/dev/<対象>/spec.md（REQ-# を参照して機能一覧を導出する）。docs/test/<対象>/test-analysis.md（テスト条件 TC-#。観測点・境界の洗い出しに使う）docs/test/<対象>/test-case.md（テストケース CASE-#。設計が想定する入出力と突合する）docs/dev/definition-of-done.md（完成の定義）spec.md が無くても作れる。ユーザーの直接指示・任意のレビュードキュメントを入力に
設計書を書いてよい。ただしその場合、機能一覧の「対応要求」列が - になり、
セルフ機械検査が「要求に紐づかない機能」として検出する。
先に /feature-spec <対象> を実行して仕様を確定させることを推奨する 旨を利用者へ伝え、
それでも進めるなら検査 NG が出ることを了解のうえで進める。AskUserQuestion（推奨案を先頭）で確認する。
本スキルでは 設計方式の選択・既存構成を変えるか否か・分割の粒度・改訂提案の採否 が
これに当たる。トレードオフのある選択は選択肢と代償を添えて訊く。references/ に置く。references/template.md（basic-design.md の雛形）。| 機能 | 対応要求 | 概要 | のテーブル で書く。REQ-# を必ず書く。1 機能が複数要求にまたがるなら REQ-01/03 と併記する。REQ-# を書かない（spec.md に無い ID は機械検査で検出される）。/feature-spec の改訂モードで要求として立てる ことを提案する。test-case.md があるときは CASE-# との対応が取れるかを確認する（機械検査も突合する）。引数は <対象名>。省略されたら docs/dev/ 配下の既存ディレクトリを一覧して選択を求める。
docs/dev/<対象>/basic-design.md の存在で 作成モード（無い）と 改訂モード（ある）に
分岐する。
docs/dev/<対象>/spec.md を読む。無ければ原則 1 に従い、/feature-spec の先行実行を
推奨したうえで、進めるかを利用者に確認する。test-analysis.md / test-case.md / definition-of-done.md）の有無を確認し、
あるものだけを読む。何を読んで何が無かったかを利用者へ 1 行で報告する。リポジトリを調査して、設計の前提になる事実を集める:
spec.md の REQ-# を 1 件ずつ辿り、実現に必要な機能へ分解してテーブルにする。
REQ-# が少なくとも 1 つの機能から参照されているかを確認する（要求の取りこぼし検出）。references/template.md の構成でドラフトを作り、承認後に
docs/dev/<対象>/basic-design.md へ書き込む。必須セクションは
機能一覧 / モジュール構成 / インターフェース / データフロー の 4 つ。
後述の「セルフ機械検査」を実行し、NG があればその場で直してから完了宣言する。
既存の docs/dev/<対象>/basic-design.md を検出したら改訂モードに入る。
以下の入力源を横断して、まだ設計へ反映されていない 指摘・提案を集める。 入力源は疎結合で、どれか 1 つでもあれば成立する:
docs/test/<対象>/ 配下のテスト成果物の「改善提案」セクション
（test-design.md / test-analysis.md 等。設計の観測可能性・テスト容易性の指摘が集まる）docs/test/<対象>/test-review-*.md の「未解消の指摘」spec.md の改訂で増えた REQ-#（機能一覧に未反映のものが無いか突合する）収集した提案を一覧で提示し、AskUserQuestion（推奨案を先頭）で採否を確認する。
各提案には「反映すると設計のどこが変わるか」（機能追加 / インターフェース変更 /
モジュール移動）を添える。インターフェースの破壊的変更 はその旨を明示する。
採用された提案だけを basic-design.md へ反映する。
REQ-# を確認する。対応要求が無い機能は反映せず、
/feature-spec <対象> の改訂モードで要求を立てることを提案する。spec.md から要求が消えている場合、それを参照する機能行は孤児になる。
機能ごと落とすか、要求を復活させるかを利用者に確認する。作成モードと同じ（下記）。
終了前に、test-review の決定論スクリプトを design-doc モードで自分に対して実行する。
<review-check.sh のパス> design-doc docs/dev/<対象> [docs/test/<対象>]
docs/dev/<対象>）。docs/dev/<対象> から
docs/test/<対象> を自動導出する）。REQ-# 参照必須と実在 /
test-case.md があれば CASE-# との対応突合。次の順で探し、最初に見つかったものを使う:
skills/testing/test-review/scripts/review-check.sh~/.claude/plugins/ 配下等。プラグインの配置は環境で変わるため実在確認をしてから使う）どちらにも無ければ検査をスキップし、その旨を利用者へ明示する（例:
「review-check.sh が見つからないためセルフ機械検査をスキップした。testing-skills を
install するか、/test-review <対象> design-doc で別途ゲートを通してほしい」）。
スクリプトの不在を理由に設計作成を失敗させない（原則 1: graceful degradation）。
NG は形式契約の違反であり事実なので、利用者判定を待たずにその場で直す。
ただし「対応要求が - の機能がある」NG は、要求側を足さないと直せない。この場合は
自分で要求を捏造せず、/feature-spec <対象> の実行を提案 して NG が残る旨を明示する。
SKIP（test-case.md が無い等）は問題ではない。
以下を全て満たしたら 「<対象> の基本設計は完了」と明言 して閉じる。満たしていない項目が あれば、何が残っているかを列挙して先へ進めない。
spec.md の有無、任意入力で読んだもの）。docs/dev/<対象>/basic-design.md が規約パスへ書き込み済みで、必須 4 セクションを持つ。REQ-#）が入っている、または - が残る理由を利用者へ明示済み。完了後の次の一手として、以下を 提案するに留める（本スキルは実行しない）:
/test-review <対象> design-doc/test-design <対象>test-case.md から実装計画を組み立てるREQ-# 参照必須で
機械検出する。まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
「レビューして」「diff をレビュー」「〇〇観点で見て」「PR に出す前にセルフレビュー」などユーザーがコードレビューを依頼したら、観点・レンズ名を挙げていなくても必ず使用する。作業ブランチの diff を複数観点(design / test / yagni、条件付きで spec 等)で並列レビューし統合報告するオーケストレーションスキル。既定は diff 内で完結する fix 指摘のみで、既存コードへの改善提案(リファクタ候補の洗い出し)は起動引数 --improvement の明示時のみ報告する。コードの修正は行わない。