# Sdd Architect > 新機能の仕様設計を行う（Requirements → Design → Tasks） Use when this capability is needed. - Skill: `tomevault-io/sdd-architect` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/sdd-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/sdd-architect/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/sdd-architect --- # SDD Architect スキル ## このスキルを使うタイミング - 新機能の開発を開始するとき - 仕様書を作成・更新するとき ## 手順（MUST）— Phase A〜D フロー ### Phase A: インタビュー（`/profile` 実行時のみ） 0. `/profile` コマンドで起動した場合、`profile.md` のインタビュープロトコルに従い要件を収集する 1. インタビュー完了後、プロファイルドキュメントをユーザーに提示して **STOP** 2. **禁止**: `sdd_scaffold_specs`、`sdd_sync_kiro`、ファイル/ディレクトリ生成、validate-gap/validate-design の自動実行 3. ユーザーが明示的に「OK」「進めて」等の承認を与えるまで待機する 4. ユーザー承認後 → Phase B に遷移 ### Phase B: 仕様策定（ユーザー承認後に遷移） 以下のステップを順番に実行する。**validate-gap / validate-design / lint_tasks は各コマンド内でプログラム的に自動連鎖実行される。** 1. **Steering 確認** - `sdd_kiro steering` を実行して既存のドキュメントを確認 - 新機能の開発方針が全体の方向性（Product/Tech/Structure）と合致しているか確認 - 必要に応じて `sdd_kiro steering --feature --prompt "..."` で更新 - 結果をユーザーに報告する 2. **specs ディレクトリ作成** - `sdd_kiro init --feature ` を実行 3. **Requirements 作成 + validate-gap（自動連鎖）** - `sdd_kiro requirements --feature ` を実行 - validate-gap がプログラム内で自動実行され、結果が返される - Greenfield（`src/` が空）の場合、validate-gap は自動スキップされ、その旨が報告される - validate-gap 結果に問題がある場合、requirements.md を修正して再実行する（最大3回） - ★ **ユーザー確認**: requirements の内容と validate-gap 結果をユーザーに報告し、承認を得る 4. **Design 作成 + validate-design（自動連鎖）** - `sdd_kiro design --feature ` を実行 - validate-design がプログラム内で自動実行され、結果が返される - validate-design 結果に問題がある場合、design.md を修正して再実行する（最大3回） - 影響ファイル（Impacted Files）を明記すること - ★ **ユーザー確認**: design の内容と validate-design 結果をユーザーに報告し、承認を得る 5. **Tasks 作成 + lint_tasks（自動連鎖）** - `sdd_kiro tasks --feature ` を実行 - lint_tasks がプログラム内で自動実行され、フォーマット検証結果が返される - **配置ルール**: `specs/tasks.md` はリポジトリ全体のタスクリスト用。機能固有のタスクは `specs//tasks.md` に配置する - 各タスクに `(Scope: ...)` を **必ず** 付ける - 形式: `* [ ] Task-N: タイトル (Scope: \`glob1\`, \`glob2\`)` - ★ **ユーザー確認**: tasks の内容をユーザーに報告し、承認を得る ### Phase C: PR 作成 6. **ブランチ作成・コミット・PR作成** - `feature/` ブランチを作成する - 仕様書一式（requirements.md, design.md, tasks.md, scope.md 等）をコミットする - `gh pr create` で PR を作成し、URL をユーザーに報告する - **コミットメッセージ**: 日本語で記述（例: `feat: の仕様書一式を作成`） **セッション終了**: PR 作成後、このセッションは終了。レビュー対応は人間または別セッションで行う。 ### Phase D: 確定（ユーザー手動実行） 7. **Finalize（PR承認後にユーザーが手動実行）** - PR のレビュー・承認が完了した後、ユーザーが `/finalize` を実行する - `sdd_kiro finalize --feature ` が3文書の整合チェックを行う - 日本語の仕様書が `*_ja.md` にリネームされ、英語への翻訳準備が整う - 生成されたプロンプトに従い、英語の仕様書（Source of Truth）を作成する ## 運用（Ops） ### 仕様変更リクエストの処理（Pending Changes） Implementer が `sdd_request_spec_change` で生成した申請を処理するフロー。 1. **申請の監視** - 定期的に `.kiro/pending-changes/` ディレクトリを確認する - 未処理のMarkdownファイル（例: `req_YYYYMMDD_HHmm.md`）があれば内容をレビューする 2. **レビューとマージ** - 申請内容が妥当か判断する - **妥当な場合**: - `specs/tasks.md` や `specs//*.md` に変更内容を手動で反映（マージ）する - 反映時は整合性を意識する（RequirementsとTasksの乖離など） - **妥当でない場合**: - 却下理由をコメントするか、Implementerに修正を指示する（状況に応じた対話） 3. **申請ファイルのクローズ（削除）** - マージまたは却下が完了したら、該当する申請ファイルを削除する - **注意**: ファイル操作ツール（`apply_patch` の Delete や `bash` コマンド `rm` 等）を使用して確実に削除すること - ※アーカイブが必要な場合は `.kiro/archive/` 等へ移動してもよいが、原則は削除で完了とする ## 重要なルール - Scope は最小権限で設定する（`src/**` のような広い範囲は避ける） - ★ マークのステップでは必ずユーザーの承認を待つこと - validate 結果に問題がある場合は修正して再実行すること（最大3回まで。超過時はユーザー判断に委ねる） - 各ステップの結果（validate-gap / validate-design / lint_tasks）は必ずユーザーに報告する --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/yohi) — claim your Tome and manage your conversions.