Dev — タスク実装

1つの計画済みタスクバンドルをDev役割として実装します。契約を読み、touch_filesのみを変更し、機械的に確認可能なDoDを実行し、02-dev-workspace.mdを記入してQAに引き継ぎます。タスク契約が存在し、実装を割り当てられた場合に使用します。計画、タスク分割、アーキテクチャ、QA検証には使用しないでください。

Dev — タスク実装 とは?

このスキルは、タスク契約書(tasks/<task-id>/01-contract.md)に基づき、1つのタスクバンドルを垂直スライスとして実装し、機械的に確認可能な完了条件(DoD)を実行した後、QAに引き継ぐDev役割のワークフローを定義します。主な特徴は、契約で指定されたtouch_filesのみを変更し、BDDのGiven-When-Then不変条件を遵守し、循環的複雑度を$V(G) \le 10$に制限することです。すべての変更は02-dev-workspace.mdに記録され、実装逸脱(deviation)テーブルが必須です。すべてのDoD項目が合格した場合のみ、WAITING_FOR_QAをチェックしてQAに引き継ぎます。このスキルはClaude Code、Cursor、CodexなどのAIエージェント向けで、役割境界を明確に定義し、契約外のファイル変更や複雑度超過などはブロックし、QAからのリワーク指示には契約範囲内で修正対応します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/formal-you/agent-skills-suite/tree/HEAD/.agents/skills/dev

Installed? Explore more 生産性&コラボレーション skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

プレビュー

スキル README より

Dev — タスク実装 preview

ドキュメント

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/** への編集は禁止。

ワークフロー

  1. スコープとBDD契約を確認する。 01-contract.md のフロントマターとセクション4のBDDシナリオを読みます。task_id がディレクトリ名と一致すること、および touch_files、dod、adherence_adrs、Given-When-Then不変条件が定義されていることを確認します。欠落または矛盾する項目があればPlannerに報告します。
  2. 作業を準備する。 ベースコミットを記録し、プロジェクトのブランチ/コミット規約に従います。レビュー担当者が再オープンしない限り、すでに受け入れられたタスクを再オープンしないでください。
  3. BDDと複雑度制限の下で垂直スライスを実装する。 touch_files 内のファイルのみを変更します。セクション4と dod.edge_cases で宣言されたGiven-When-Then不変条件を満たすロジックを実装します。単一関数の循環的複雑度を制御します(標準$V(G) \le 10$)。複雑度が警告限度($11-15$)に近づいた場合は、リファクタリングパターン(メソッド抽出、ストラテジー/ルックアップテーブル、ガード節)を適用します。$V(G) > 15$の場合は、先に進む前にリファクタリングします。tests/acceptance/** を編集または作成しないでください。
  4. 機械的に確認可能なDoDと自己検証を実行する。 dod.type_check と dod.lint を実行し、プロジェクトの既存のテストを実行します。dod.edge_cases の各項目を検討します。すべての変更した関数の循環的複雑度を自己監査します。受け入れテストターゲット(dod.test_file)はQA所有です。すでに存在する場合のみ実行し、作成または編集は絶対に行いません。まだ存在しない場合は、そのことを02に記録し、QAが検証時に実行するようにします。コマンドと結果を記録します。
  5. 02-dev-workspace.md を記入する。 ブランチ、ベース/引き継ぎコミット、設計ノート、実際に変更されたファイルごとに1行、正味行数、および真である各自己検証項目のチェックを記録します。警告レベルの複雑度($11 \le V(G) \le 15$)を持つ関数については、明示的なアーキテクチャ上の正当化を含めます。合格しなかった項目はチェックしないままにします。実装逸脱テーブルを完了します。コードが契約または仕様と異なる箇所ごとに1行(DEV-001、DEV-002、...;操作 add | modify | remove;#sec-*アンカー)、または逸脱がない場合はすべてのセルにNoneを記入します。
  6. QAに引き継ぐ。 すべての自己検証項目が合格し、複雑度制限が満たされた場合にのみ、- [ ] WAITING_FOR_QA を - [x] WAITING_FOR_QA に変更します。この1つのチェックボックスが引き継ぎトリガーです。03 または 04 は編集しないでください。
  7. リワーク時。 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ベースの役割監査)やブランチ保護がある場合、それが権威あるレイヤーです。許可される影響範囲を定義するのは、このドキュメントではなく契約です。

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

formal-you/agent-skills-suite

Run a bounded brownfield change (bugfix, small feature, behavior tweak) against an existing spec or codebase: proposal -> one task bundle -> dev/QA -> converge -> archive. Use when an existing spec or codebase needs an incremental change (bugfix, small feature, behavior tweak) and a full PRD is overkill. Do not use for greenfield requirements (use prd-generator), architecture decisions (use spec-generator), or pure task slicing (use task-decomposition).

formal-you/agent-skills-suite

Fold confirmed implementation deviations back into the technical spec after a task reaches QA_PASSED, archive the task bundle and close the change proposal. Use when a task bundle records a checked QA_PASSED verdict and its 02-dev-workspace.md deviation log is ready to be written back. Do not use while implementation or QA is still running, and do not use to invent spec content.

formal-you/agent-skills-suite

Use on Windows for unexpected DSH sandbox access denials: workspace writes or listing fail, or an ordinarily readable path cannot be read. One bundled command inspects the path and every ancestor and repairs the ACL problems it proves in that same run. Expected confinement denials need no ACL repair.

formal-you/agent-skills-suite

Run the Gate 1 deterministic static check on task bundles before development starts and follow the Gate 2 review checklist. Use when task contracts exist under tasks/ and you need to verify blast radius, diff budget, declared-file topology, traceability anchors, spec anchor coverage, inherited ADRs, machine-checkable acceptance criteria, and DAG acyclicity. Do not use for code execution, CI pipeline construction, AST/complexity checks, or test audits (owned by quality-engineering).

関連スキル