Menu
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
エンジニアとして手を動かす作業全般で必ず発火させる: コードを書く / テストを書く / リファクタ / バグ修正 / E2E spec 追加 / 既存仕様への小さな修正など、コードに触る作業すべて。「実装して」「テスト書いて」「リファクタして」「バグ直して」のような依頼を受けたとき、または基本設計が済んで実装フェーズに入るときに発火。基本作業は TDD（テスト先書き → 最小実装 → リファクタ → コミット）で進め、要件が大きければ適切な小ささに分割しつつサイクルを回す。発火しないのは要件定義 / 基本設計の対話中（まだ手を動かしていない時）だけ。
| name | basic-design |
| description | 要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。 |
要件（What / Why）が固まった後、実装に入る前に「どう作るか」の構造を固めないと、実装中に方針がブレたり、後から大きな手戻りが発生する。基本設計は「後から戻ると痛い決定」を一通り決めるフェーズ。
逆に、関数の名前や引数、エラーメッセージの文言まで設計 md に書くのは過剰。実装中の判断は実装フェーズに任せる方が、設計と実装の重複管理を避けられる。
要件定義から続けて basic-design に入った時点では、context が rich で「もう全部分かっている」ように感じる。しかし要件定義で固まったのは Why / What であって、How (アーキ / データモデル / シーケンス) はまだ判断していない。
「Why が固まった ≠ How が決まった」を区別する。
呼ばれた直後にやることは:
dialogue-principles skill を呼ぶ (このフェーズ全体が対話モードなので、最初に対話の規律を効かせる)context が rich でも、最初のメッセージは設計書を書くことではなく「これから何を議論するか」を依頼者と確認すること。
| 言い訳 | 反論 |
|---|---|
| 「context が十分にあるから書ける」 | Why が分かっても How は決まっていない |
| 「依頼者が忙しそうだから書いて確認してもらおう」 | 書いた後の修正コストの方が大きい |
| 「シンプルな案件だから」 | シンプルこそ対話が早く済む。書き直しの方が遅い |
| 「過去類似案件の設計から類推できる」 | 類推は仮説。依頼者と検証してから書く |
要件と既存資産を踏まえて、以下を 対話で固める。「やること」は「設計書を書く」ことではなく「設計判断を依頼者と固める」こと。テンプレを最初に出して埋めにいかない。1 トピックずつ依頼者と議論し、合意を取り、最後にまとめて md に書き起こす。
要件によって全部必須ではない。要件に合わせて選び、対話の中で「これは設計判断が必要」と分かったトピックだけ固める。
例 (合意後の表現):
[ Browser ]
│ HTTP
▼
[ Web Router ]
│
├── /users → users.ts
├── /orders → orders.ts
└── /reviews (新) → reviews.ts ← 今回追加
│
▼
[ DB ]
例 (合意後の表現):
orders (既存)
+ review_status: TEXT -- 新規追加
+ reviewed_by: TEXT (FK) -- 新規追加
+ reviewed_at: INTEGER -- 新規追加
reviews (新規 table)
- id: TEXT (PK, UUID v7)
- order_id: TEXT (FK → orders.id)
- reviewer_id: TEXT (FK → users.id)
- decision: TEXT ('approved' | 'rejected')
- note: TEXT (nullable)
- created_at: INTEGER
例 (合意後の表現):
[Admin UI] → GET /reviews/pending → [Server]
│
└→ SELECT * FROM orders WHERE review_status = 'pending'
◄─ rows
[Admin UI] ◄ rendered list
[Admin UI] → POST /reviews/{order_id}/approve → [Server]
│
└→ UPDATE orders SET review_status='approved'
└→ INSERT INTO reviews ...
何を決めるか: 既存コード / spec / migration / permission への影響
議論する観点: 既存テストの修正、データ migration、permission の見直し
依頼者と何を引き出すか: 影響範囲、修正必要な箇所、permission の境界変更
合意したら: 影響リストで表現
エンドユーザー価値を守るために、依頼者の発言を無批判に受け入れない。
依頼者の指摘や反論に「あ、確かに、そうですね」と即引き下がるのは迎合の一種。同意する前に:
賛成するなら自分の根拠を述べ、反対するなら根拠を示す。本当に依頼者の指摘が正しければ修正する。両立するなら追加質問する。
basic-design は対話駆動。アーキ / データモデル / シーケンス / 論理設計を依頼者と固めるには、以下を厳守する。
深い議論は 1 つずつ。複数を 1 メッセージに混ぜると依頼者が回答しづらい。軽い確認 (Yes/No 程度) なら複数 OK。
質問はクローズな選択肢で出すのを基本に。AskUserQuestion ツールが使える場面では使う。
議論の節目で「ここまでの理解はこうです、合ってますか?」を 依頼者が確認サインを出す前に こちら側から出す。節目の例:
「サマリ → 確認」を pattern 化する。依頼者が違和感を感じたタイミングで戻れる。
設計トピック (アーキ / データモデル / シーケンス / 論理設計 / 既存資産への影響) ごとに「このトピックで合っているか」を明示的に確認してから次へ。一気に md に書いてからレビューを求めない。
「たぶんこういう意図だろう」で進めない。不明点が出たらその場で質問。依頼者の沈黙を「OK」と解釈しない。
proactive な対話の型に加えて、依頼者が以下のサインを出した時は必ず「私の理解はこうです、合ってますか」と確認する:
認識合わせの形式: 「私の理解は次のとおりです: [箇条書きでサマリ]。合ってますか？ずれている点はありますか？」
設計判断に複数案がありそうなら必ず propose-options skill を呼んで「複数案＋メリデメ＋推奨」のフォーマットで整理する。一案だけポンと出すのは禁止。
例:
propose-options フォーマットで議論するこのフェーズの守備範囲は「後から戻ると痛い決定」まで。以下は実装フェーズに任せる:
これらは slice-tdd skill が実装中に判断する領域。設計 md に書くと、実装と二重管理になる。
設計の中核は「責務分離」。何でもかんでも分割するのでも、何でもまとめるのでもなく、責務として独立しているかで判断する:
判断軸: 「今、責務として分かれているか」。分かれていないなら抽象化しない、分かれているなら今の段階で抽象化する。
判断軸: 「責務として同じか / たまたま同じか」を必ず分ける。
「明らかに後で問題になる決定」（DB スキーマの根本ミス、permission の設計ミス、後から変えられない命名、責務分離の根本ミス）は YAGNI に縛られず指摘する。「今要らない」と「後で痛い」は別物。
要件定義で固まった Why と、依頼者が示す設計案（「こういうアーキにして」「この table 構造で」）が整合していないと感じたら、代案を提案する。設計フェーズでも一人前の開発者として「言われた通りに設計する」だけが仕事ではない。
例:
押し付けではなく選択肢として提示する。代案を出すときは propose-options skill のフォーマット（複数案＋メリデメ＋推奨）に乗せる。
docs/working/<title>/基本設計.md を新規作成する。同じディレクトリには既に define-requirements skill が作った 要件定義.md がある前提。
ディレクトリ構成:
docs/working/<title>/
├── 要件定義.md ← define-requirements skill が作った
└── 基本設計.md ← この skill が作る
基本設計.md の構成:
# <機能名> — 基本設計
> このドキュメントは進行中の設計メモ。実装後もそのまま残す（振り返り・PR レビューで参照される）。
> 削除のタイミング・要否は依頼者または外側の仕組みで別途判断する（あなたは削除しない）。
## 1. アーキテクチャ
[必要なら ASCII 図]
## 2. データモデル
[ER または table 定義差分]
## 3. シーケンス
[必要なら ASCII シーケンス図]
## 4. 論理設計
- 責務分離: ...
- 状態遷移: ...
- バリデーション: ...
- エラーケース: ...
## 5. 既存資産への影響
- 影響する既存ファイル: ...
- 影響する既存 spec: ...
- migration 影響: ...
- permission 影響: ...
## 6. 完了の定義（実装フェーズが満たすべきもの）
- [ ] [E2E で検証可能な観測条件 1]
- [ ] [E2E で検証可能な観測条件 2]
- ...
- [ ] D5: skill-reviewer が違反パターンを検出する機能を持つ- [ ] skill-reviewer が違反パターンを検出する機能を持つ (= 内容で書く)### skill-reviewer の機能 の下に内容を書く)handoff-docs skill を呼んで、自己完結性の規律を効かせる。設計の議論が完全に固まってから書き起こす。途中段階で md にしない。理由: ドキュメントの構造が議論を縛り、未決論点の存在が見えにくくなる。
依頼者が明示的に「一旦見たい」「ドキュメントに起こして」と言った場合のみ、その時点までの合意で書く（暫定であることを冒頭に明記）。暗黙に「これで合意できたから書こう」と判断しない。
基本設計が固まったタイミングで、規模や複雑度を判断して「第三者レビューを入れる価値あり」と感じたら、依頼者に pre-implementation-reviewer subagent を呼ぶことを提案する。自動では呼ばない（毎回呼ぶと Opus コストが嵩む）、提案に留める。
判断基準:
提案の形式:
基本設計が固まりました → docs/working/<title>/基本設計.md
この設計は <理由> なので、pre-implementation-reviewer の第三者レビューを入れる価値ありそうです。呼びますか？
依頼者が「呼んで」と言ったら、Task ツールで pre-implementation-reviewer subagent を起動する。レビュー結果は依頼者と一緒に議論する材料として扱う（main session が機械的に対応/非対応を決めない）。
基本設計.md は別セッションのエージェントが読んで実装に進む成果物。次フェーズへ渡す前に、handoff-docs skill を呼んで引き継ぎ可能性を点検する（handoff-verifier で文脈ゼロ点検し、Yes になるまで穴を直す）。
pre-implementation-reviewer（妥当性）と handoff-docs 経由の点検（引き継ぎ可能性）が両方効く場面では、妥当性が先・引き継ぎ可能性が後。中身の妥当性がまだ固まっていないのに引き継ぎ可能性を点検しても、中身が変われば書き直しになるため。
設計が固まり md を更新したら、次のフェーズ（実装）に進む案内を出す:
基本設計が固まりました → docs/working/<title>/基本設計.md
このセッションのコンテキストはもう使わないので、節約したい場合は:
1. /clear でこのセッションをリセット
2. 新しい入力で次のメッセージを送ってください:
@docs/working/<title>/要件定義.md @docs/working/<title>/基本設計.md slice-tdd で実装を進めて
そのまま続けても問題ありません。
強制ではなく任意のガイド。設計 md があれば context 再現できるので、依頼者が選べばよい。