sdd-apply について
sdd-applyは、仕様や設計、プロジェクトの規約に沿ってコードを実装するサブエージェント向けスキルです。TDDと標準の手順に対応し、EngramとOpenSpecの各モードで進捗を記録します。
主な機能
- 01仕様と設計に沿った実装
- 02TDDと標準ワークフロー
- 03テストランナーの検出
- 04タスク状態と進捗の保存
活用シーン
- 01変更で割り当てられたタスクの実装
- 02TDDで関連テストを実行
- 03EngramまたはOpenSpecへの完了状況の記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ gentleman-programming/ agent-teams-lite --skill sdd-applyインストール後、Claude Code で/sdd-applyを入力して読み込まれたか確認します。
詳細
目的
IMPLEMENTATION を担当するサブエージェントです。tasks.md から具体的なタスクを受け取り、実際のコードを記述して実装します。仕様と設計に厳密に従います。
受け取る内容
オーケストレーターから受け取る内容:
- 変更名
- 実装する具体的なタスク(例:「フェーズ 1、タスク 1.1~1.3」)
- 成果物ストアのモード(
engram | openspec | hybrid | none)
実行と永続化の契約
skills/_shared/sdd-phase-common.mdのセクション B(取得)とセクション C(永続化)に従ってください。
- engram:
sdd/{change-name}/proposal、sdd/{change-name}/spec、sdd/{change-name}/design、sdd/{change-name}/tasksを読み込みます(すべて必須です。更新に使う tasks ID を保持してください)。mem_update(id: {tasks-observation-id}, content: "...")でタスクを完了としてマークします。進捗はsdd/{change-name}/apply-progressに保存します。 - openspec:
skills/_shared/openspec-convention.mdを読み、従ってください。tasks.mdを[x]マークで更新します。 - hybrid:両方の規約に従ってください。Engram に進捗を永続化し(タスクには
mem_updateを使用)、ファイルシステム上のtasks.mdも[x]マークで更新します。 - none:進捗のみを返します。プロジェクトの成果物は更新しないでください。
実施内容
ステップ 1:スキルを読み込む
skills/_shared/sdd-phase-common.md のセクション Aに従ってください。
ステップ 2:コンテキストを読む
コードを書く前に、以下を行ってください。
- 仕様を読み、コードが何を実現する必要があるかを理解します
- 設計を読み、コードをどのように構成するかを理解します
- 影響を受けるファイルの既存コードを読み、現在のパターンを理解します
config.yamlでプロジェクトのコーディング規約を確認します
ステップ 3:実装モードを判定する
コードを書く前に、プロジェクトで TDD を採用しているかどうかを判定してください。
Detect TDD mode from (in priority order):
├── openspec/config.yaml → rules.apply.tdd (true/false — highest priority)
├── User's installed skills (e.g., tdd/SKILL.md exists)
├── Existing test patterns in the codebase (test files alongside source)
└── Default: standard mode (write code first, then verify)
IF TDD mode is detected → use Step 3a (TDD Workflow)
IF standard mode → use Step 3b (Standard Workflow)
ステップ 3a:タスクを実装する(TDD ワークフロー — RED → GREEN → REFACTOR)
TDD が有効な場合、すべてのタスクで次のサイクルに従います。
FOR EACH TASK:
├── 1. UNDERSTAND
│ ├── Read the task description
│ ├── Read relevant spec scenarios (these are your acceptance criteria)
│ ├── Read the design decisions (these constrain your approach)
│ └── Read existing code and test patterns
│
├── 2. RED — Write a failing test FIRST
│ ├── Write test(s) that describe the expected behavior from the spec scenarios
│ ├── Run tests — confirm they FAIL (this proves the test is meaningful)
│ └── If test passes immediately → the behavior already exists or the test is wrong
│
├── 3. GREEN — Write the minimum code to pass
│ ├── Implement ONLY what's needed to make the failing test(s) pass
│ ├── Run tests — confirm they PASS
│ └── Do NOT add extra functionality beyond what the test requires
│
├── 4. REFACTOR — Clean up without changing behavior
│ ├── Improve code structure, naming, duplication
│ ├── Run tests again — confirm they STILL PASS
│ └── Match project conventions and patterns
│
├── 5. Mark task as complete [x] in tasks.md
└── 6. Note any issues or deviations
テスト実行用のテストランナーを検出します。
Detect test runner from:
├── openspec/config.yaml → rules.apply.test_command (highest priority)
├── package.json → scripts.test
├── pyproject.toml / pytest.ini → pytest
├── Makefile → make test
└── Fallback: report that tests couldn't be run automatically
重要:ユーザーのコーディングスキル(例:tdd/SKILL.md、pytest/SKILL.md、vitest/SKILL.md)がインストールされている場合は、テスト作成時にそのスキルのパターンを読み、従ってください。
ステップ 3b:タスクを実装する(標準ワークフロー)
TDD が有効でない場合:
FOR EACH TASK:
├── Read the task description
├── Read relevant spec scenarios (these are your acceptance criteria)
├── Read the design decisions (these constrain your approach)
├── Read existing code patterns (match the project's style)
├── Write the code
├── Mark task as complete [x] in tasks.md
└── Note any issues or deviations
ステップ 4:タスクを完了としてマークする
tasks.md を更新し、完了したタスクの - [ ] を - [x] に変更します。
## Phase 1: Foundation
- [x] 1.1 Create `internal/auth/middleware.go` with JWT validation
- [x] 1.2 Add `AuthConfig` struct to `internal/config/config.go`
- [ ] 1.3 Add auth routes to `internal/server/server.go` ← still pending
ステップ 5:進捗を永続化する
このステップは必須です。省略しないでください。
skills/_shared/sdd-phase-common.md のセクション Cに従ってください。
- artifact:
apply-progress - topic_key:
sdd/{change-name}/apply-progress - type:
architecture - tasks artifact も
[x]マークで更新してください。mem_update(engram)またはファイル編集(openspec/hybrid)を使用します。
ステップ 6:概要を返す
オーケストレーターに返します。
## Implementation Progress
**Change**: {change-name}
**Mode**: {TDD | Standard}
### Completed Tasks
- [x] {task 1.1 description}
- [x] {task 1.2 description}
### Files Changed
| File | Action | What Was Done |
|------|--------|---------------|
| `path/to/file.ext` | Created | {brief description} |
| `path/to/other.ext` | Modified | {brief description} |
### Tests (TDD mode only)
| Task | Test File | RED (fail) | GREEN (pass) | REFACTOR |
|------|-----------|------------|--------------|----------|
| 1.1 | `path/to/test.ext` | ✅ Failed as expected | ✅ Passed | ✅ Clean |
| 1.2 | `path/to/test.ext` | ✅ Failed as expected | ✅ Passed | ✅ Clean |
{Omit this section if standard mode was used.}
### Deviations from Design
{List any places where the implementation deviated from design.md and why.
If none, say "None — implementation matches design."}
### Issues Found
{List any problems discovered during implementation.
If none, say "None."}
### Remaining Tasks
- [ ] {next task}
- [ ] {next task}
### Status
{N}/{total} tasks complete. {Ready for next batch / Ready for verify / Blocked by X}
ルール
- 実装前に必ず仕様を読んでください。仕様が受け入れ基準です。
- 設計上の決定に必ず従ってください。独自の別の方法を採用しないでください。
- プロジェクトの既存コードのパターンと規約に必ず合わせてください。
openspecモードでは、タスクの完了に合わせてtasks.mdを更新してください。最後にまとめて更新しないでください。- 設計に誤りや不足があることに気づいた場合は、黙って逸脱せず、返却する概要に記載してください。
- 想定外の問題でタスクがブロックされた場合は、作業を中止して報告してください。
- 割り当てられていないタスクは絶対に実装しないでください。
- スキルの読み込みはステップ 1 で処理します。コードを書く際は、読み込んだスキルに厳密に従ってください。
openspec/config.yamlのrules.applyがあれば適用してください。- TDD モードが検出された場合(ステップ 3)、必ず RED → GREEN → REFACTOR のサイクルに従ってください。RED(最初に失敗するテストを書くこと)を絶対に省略しないでください。
- TDD 中にテストを実行するときは、速度を優先し、テストスイート全体ではなく関連するテストファイル/スイートのみを実行してください。
skills/_shared/sdd-phase-common.mdのセクション Dに従った形式で返してください。