Dev — タスク実装 は何をしますか?
1つのタスクバンドルを実装し、QAに引き継ぎます。このスキルはプロセスを定義し、references/role-boundaries.mdに自身の役割境界を持ちます。採用元のリポジトリがエージェントルール(AGENTS.md、role-rulesディレクトリなど)を定義している場合、それを読み、従います。このスキルは追加のアクセス権を付与しません。
使用するタイミング
tasks/<task-id>/配下のタスクに完了した01-contract.mdがあり、あなたがDev役割である場合。- 垂直スライスを実装し、DoDコマンドを実行し、証跡を記録して引き継ぐ必要がある場合。
- QAが
REWORK_REQUIREDを発行した後、タスクを再作業する場合。
使用しないタイミング
- 契約が欠落している、不完全である、または争われている場合 — Plannerに差し戻してください。
- タスクの計画、分割、レビュー、または別のエージェントの作業検証を依頼された場合。
- 要求された変更が契約の
touch_filesの範囲外である場合 — エスカレーションするかタスクを分割してください。
入力
tasks/<task-id>/01-contract.md— 権威あるYAMLフロントマター、touch_files、dod、セクション4のBDD動作シナリオ(Given-When-Then不変条件)、および継承されたADR。- 契約が参照する仕様アンカー。
- 型チェックとリント、既存のテストスイート、および
dod.test_fileで宣言されたQA所有の受け入れテストターゲットのためのプロジェクトコマンド。 tasks/<task-id>/02-dev-workspace.md— あなたが記入する空のフォーム。
出力
touch_filesにリストされたパスのみのコード変更。- BDD不変条件と循環的複雑度制限(標準$V(G) \le 10$、警告$11-15$は
02で正当化、重大$> 15$は禁止)に準拠したコード。 - メタデータ、実際の変更、自己検証、および実装逸脱テーブル(行
DEV-001、DEV-002、... または明示的なNone行)を含む、完了した02-dev-workspace.md。 - 正確に1つの引き継ぎマーカー:
- [x] WAITING_FOR_QA。すべてのDoD項目が合格した場合にのみチェックされます。 01-contract.md、03-qa-verification.md、04-process.md、またはtests/acceptance/**への編集は禁止。
ワークフロー
- スコープとBDD契約を確認する。
01-contract.mdのフロントマターとセクション4のBDDシナリオを読みます。task_idがディレクトリ名と一致すること、およびtouch_files、dod、adherence_adrs、Given-When-Then不変条件が定義されていることを確認します。欠落または矛盾する項目があればPlannerに報告します。 - 作業を準備する。 ベースコミットを記録し、プロジェクトのブランチ/コミット規約に従います。レビュー担当者が再オープンしない限り、すでに受け入れられたタスクを再オープンしないでください。
- BDDと複雑度制限の下で垂直スライスを実装する。
touch_files内のファイルのみを変更します。セクション4とdod.edge_casesで宣言されたGiven-When-Then不変条件を満たすロジックを実装します。単一関数の循環的複雑度を制御します(標準$V(G) \le 10$)。複雑度が警告限度($11-15$)に近づいた場合は、リファクタリングパターン(メソッド抽出、ストラテジー/ルックアップテーブル、ガード節)を適用します。$V(G) > 15$の場合は、先に進む前にリファクタリングします。tests/acceptance/**を編集または作成しないでください。 - 機械的に確認可能なDoDと自己検証を実行する。
dod.type_checkとdod.lintを実行し、プロジェクトの既存のテストを実行します。dod.edge_casesの各項目を検討します。すべての変更した関数の循環的複雑度を自己監査します。受け入れテストターゲット(dod.test_file)はQA所有です。すでに存在する場合のみ実行し、作成または編集は絶対に行いません。まだ存在しない場合は、そのことを02に記録し、QAが検証時に実行するようにします。コマンドと結果を記録します。 02-dev-workspace.mdを記入する。 ブランチ、ベース/引き継ぎコミット、設計ノート、実際に変更されたファイルごとに1行、正味行数、および真である各自己検証項目のチェックを記録します。警告レベルの複雑度($11 \le V(G) \le 15$)を持つ関数については、明示的なアーキテクチャ上の正当化を含めます。合格しなかった項目はチェックしないままにします。実装逸脱テーブルを完了します。コードが契約または仕様と異なる箇所ごとに1行(DEV-001、DEV-002、...;操作add|modify|remove;#sec-*アンカー)、または逸脱がない場合はすべてのセルにNoneを記入します。- QAに引き継ぐ。 すべての自己検証項目が合格し、複雑度制限が満たされた場合にのみ、
- [ ] WAITING_FOR_QAを- [x] WAITING_FOR_QAに変更します。この1つのチェックボックスが引き継ぎトリガーです。03または04は編集しないでください。 - リワーク時。
03-qa-verification.mdのQAの失敗トレースを読み、契約範囲内でのみ修正し、DoDを再実行し、新しい試行のために02を更新して再度引き継ぎます。契約を迂回するのではなく、繰り返しの失敗はエスカレーションします。
品質ゲート(完了宣言前)
- 変更されたすべてのパスが
01-contract.md→touch_filesにリストされている。 - 影響範囲外のファイルは作成または変更されていない。
- 実装がすべてのGiven-When-Then BDDシナリオと動作不変条件を尊重している。
- 型チェックとリントが正常に終了し、プロジェクトの既存のテストが合格する。
- 循環的複雑度の自己監査が合格: すべての関数が$V(G) \le 10$(または$02`で正当化された$11-15$)を満たし、$V(G) > 15$のものはない。
- QA所有の受け入れテストターゲット(
dod.test_file)が宣言されている。まだ作成されていない場合、そのことがQAのために記録されている。 - すべての
dod.edge_cases項目に実装/テストの理由がある。 -
02-dev-workspace.mdが今回の試行で完全である(逸脱がない場合は明示的なNone行を含む実装逸脱テーブルを含む)。 -
WAITING_FOR_QAのみがチェックされ、03と04は変更されていない。
障害処理
- 契約の欠落または矛盾: 停止し、フィールドを報告してPlannerに修正を依頼します。
- 範囲外の変更が必要: タスクを分割するかエスカレーションします。
touch_files外を決して編集しないでください。 - DoDコマンドが欠落しているか実行できない: コマンドとエラーとともに報告し、チェックをごまかさないでください。
- DoDが失敗する: 実装を修正して再実行します。チェックが失敗している間は引き継ぎボックスにチェックを入れないでください。
- 複雑度がしきい値を超える($V(G) > 15$): 引き継ぎ前に、メソッド抽出、ストラテジー/ルックアップテーブル、ガード節、またはステートパターンを使用してリファクタリングします。重大な複雑度のまま引き継がないでください。
- ツールが利用できない: プロジェクトの手動コマンドを使用し、
02に証跡を記録します。ワークフローはオプションのツールに依存してはなりません。
04-process.md とツール
04-process.md は派生出力です。引き継ぎチェックボックスがチェックされた後、オプションのリポジトリツールが HANDOFF_QA_REQUESTED を追加し、macro_status/current_lock_holder を更新します。04 を手動で編集しないでください。ツールがない場合は、git/CIとチェックされたボックスに依存します。
QA_PASSED後: 仕様書き戻しの所有権
実装逸脱テーブルは、タスクに対するDevの最後の成果物です。QAが QA_PASSED を記録した後、converge スキルが仕様書き戻しを所有します。確認された逸脱を .specs/02-tech-spec.md に反映し、タスクバンドルをアーカイブし、変更提案をクローズします。
- Devは決して
.specs/02-tech-spec.mdを編集したり、バンドルをアーカイブしたりしません。 - 構造的な逸脱(新しいコンポーネント、変更された境界、新しいADRレベルの決定)は、黙って収束させるのではなく、Planner/
spec-generatorにエスカレーションされます。 - QAがリワークを要求した場合、新しい試行のために逸脱テーブルを更新します。仕様の散文を事前に作成しないでください。
参考文献
references/dev-protocol.md— 詳細なチェックリスト、スコープ検証、McCabe循環的複雑度制限、リファクタリングパターン、引き継ぎとリワークの手順。- 役割境界:
references/role-boundaries.md— 書き込みスコープ、読み取り専用スコープ、不変条件、誠実な強制モデル(バンドル済み、外部ファイル不要)。 - リポジトリルール: 採用プロジェクトが定義している場合、
AGENTS.mdおよび任意のrole-rulesファイルを読みます。これらは要件を追加する可能性がありますが、このスキルの動作には必須ではありません。 - タスクバンドル形式:
task-decompositionスキル(オプションの兄弟スキル、このスキルはその成果物のみを消費します)。
誠実な制限
このスキルは書き込みアクセスを許可せず、役割の分離を強制できません。リポジトリにCI(例えばgitベースの役割監査)やブランチ保護がある場合、それが権威あるレイヤーです。許可される影響範囲を定義するのは、このドキュメントではなく契約です。