specsfy-05-tasks

仕様をタスクに分解する

必須の準備

このスキルを実行する前に、プロジェクトのルートで必ず $specsfy-setup を読み込んでください。自動引き継ぎの場合は、この手順の前にもう一度読み込んでください。会話で確認済みのルートを再利用し、セットアップで未解決の項目が示された場合は先に進まないでください。

インタラクションモード

インタラクションモード：perguntas。 質問を作成する前に、.specsfy/Spec.md の Contrato de perguntas numeradas を読み、適用してください。

計画でのデータベース保護

Laravel プロジェクトでは、タスク [TEST] を計画またはリリースする前に .agents/skills/specsfy-setup/scripts/check_database_safety.mjs --project <raiz> を実行してください。計画では、.env.testing、APP_ENV=testing、 および .env のデータベースと明確に異なるテスト用データベースを維持する必要があります。

結果が PENDING の間は、テストタスクを完了状態にできず、このスキルはランナーを呼び出しません。結果が IGNORED の場合は、構造やレコードを削除するコマンドを除外してください。タスク、テスト、準備、回帰テスト、Definition of Done のいずれにも、migrate:fresh、migrate:refresh、migrate:reset、migrate:rollback、db:wipe、schema:drop、prisma migrate reset、DROP DATABASE、DROP SCHEMA、DROP TABLE、TRUNCATE、RefreshDatabase、DatabaseMigrations、または同等のものを決して含めないでください。

specs/<estado>/<NNNN>-<slug>/spec.md のセクション 14. Tarefas を埋めてください。このファイルを唯一の信頼できる情報源とし、各タスクは小さく、検証可能で、順序付けされ、そこに定義された ID に関連付けられている必要があります。

会話のオーケストレーション

この手順を完了したとき、または別の手順の作業を検出したときは、 Pendência detectada: <descrição> — ação: resolvendo nesta etapa と通知し、その作業がこの手順の範囲に属する場合は解決してください。担当を切り替える場合は、 Transição automática: $specsfy-05-tasks → $<destino> — motivo: <motivo> — resultado esperado: <resultado> と通知し、確認を求めたりコマンドを繰り返したりせず、直ちに移行先のスキルを読み込んでください。同じ会話を続けてください。この手順に必要な修正を行った後は、 Retomada automática: $<destino> → $specsfy-05-tasks — pendência resolvida: <resultado> と通知し、直ちに再開してください。サイクルを避けるため、引き継ぎのたびに状態を再評価してください。引き継ぎの確認は求めないでください。機密性の高い操作には、引き続き個別の承認が必要です。

前提条件

1. specs/defined/<NNNN>-<slug>/spec.md で指定された仕様を読み、 Formato: Specsfy/2.0、Definition Gate: Passed、および Status が Defined、Planned、Implementing のいずれかであることを必須とします。後者の 2 つは、後続手順で検出された未解決事項を自動的に再計画する場合に限り受け入れてください。
2. ゲートの通過が確認できない場合は、仕様の検証を実行してください。
3. 実際のスタック、コマンド、パスを把握するためにリポジトリを調査してください。PHP では TDD に Pest を使用してください。PHP を使用しない Node プロジェクトでは、パスやコマンドを生成する前に、採用するランナーを尋ね、Vitest を推奨してください。
4. 計画の前にモニターを実行してください。

node .agents/skills/specsfy-setup/scripts/monitor_context.mjs \
  --project .

スタック、アプリケーション、ルール、永続化の兆候を使用して、要件を新たに推測することなく、変更と併せてドキュメントを計画してください。 5. アーキテクチャ、データ、または受け入れ条件を変える判断が不足している場合は、その旨を通知して $specsfy-02-backlog に自動的に戻ってください。判断後、仕様がすでに承認されている場合は $specsfy-update-spec を、初期定義中の場合は $specsfy-03-specify を使用してください。

生成

.specsfy/templates/custom/Tasks.md が存在する場合はこれを契約として使用し、存在しない場合は .specsfy/templates/Tasks.md を使用してください。<raiz>/specs/<estado>/<NNNN>-<slug>/spec.md のセクション 14. Tarefas と 15. Ordem de execução の内容のみを置き換え、他のすべてのセクションを保持してください。

• Spec が Planned または Implementing の場合は、未完了であることを明示し、編集前に Ato II を再開して、Status: Defined、Plan Gate: Pending、Delivery Gate: Pending に設定します。変更後の計画では、それ以前の Gate と証拠は有効ではありません。
• すでに Defined の spec を編集する場合は、編集前に Plan Gate: Pending と Delivery Gate: Pending に設定します。
• 更新時には既存の ID を保持し、完了済みタスクの番号を振り直さないでください。
• 最小限のセットアップ、不可欠な基盤、優先順位順のストーリー、締めくくりの順に整理します。
• ストーリーは、それぞれ独立して実証できる垂直スライスとして維持します。
• Interface para pessoas が Sim の場合は、セクション 10 に記載された画面、メニュー、メインナビゲーション、フォーム、アクションについて、データレイヤーや API に加えて明示的なタスクを作成します。ナビゲーション、送信、検証、エラーからの復旧、およびサイドパネルやモーダルなど、選択した表示パターンについて、インターフェイスの動作テストを含めます。登録済みのインターフェイススタックのコンポーネント、規約、ランナーのみを使用し、各タスクでは実際の React ブロック、shadcn/ui と ReUI のコンポーネント、またはルートを指定します。作成または変更したすべてのブロックについて、用途、ファイル、API、状態、利用者、再利用ルールを記載するよう INTERFACE.md を更新するタスクを含めます。 React プロジェクトでは、各画面タスクの PREP に、実装前に $specsfy-specialist-react-ui-components を使用することを記載します。このスキルは、プロジェクト内の実際のコンポーネントの検索、再利用、適応を支援します。インストールされていない場合は、検出されたスペシャリストをインストールするために $specsfy-setup に戻ってから、[CODE] タスクを許可します。これらのタスクは、セクション 14 の必須サブセクション #### Fase de interface にまとめます。登録された各画面には、少なくとも 1 つの専用タスクを割り当てます。この成果物を汎用的なバックエンドタスクに含めてはなりません。
• 各 AC について、spec に記載された Gherkin を参照して設計する、個別の [TEST] [TDD] タスクを作成します。これらのタスク全体で、機能全体、および各 US、FR、NFR について、少なくとも 3 つの異なる TDD ケースを具体化します。
• .feature ファイルや step definition のタスクは作成せず、spec の Gherkin を実行しないでください。
• PHP では、TDD タスクは Pest テストを指定し、SPECSFY マーカーを必須とします。Node では、ユーザーが確認したランナーと test:tdd スクリプトを使用します。
• 各 [CODE] タスクは、同じスライスの直前の TDD タスクで RED になったことを前提とします。
• タスクでスキーマ、テーブル、カラム、インデックス、リレーション、永続モデルを作成または変更する場合は、別の [CODE] [MIGRATION] タスクを作成します。このタスクでは、プロジェクトの migrations ディレクトリ内にあるバージョン管理対象のファイルを指定し、TDD テストに依存させ、新しい構造を使用するコードより前に配置します。
• [MIGRATION] タスクの VERIFY には、check_database_safety.mjs が承認したコマンドを 2 つ記録します。1 つはテストデータベースに migration を適用するコマンド、もう 1 つは migration の状態を確認するコマンドです。このタスクなしで Plan Gate を承認しないでください。
• スライスで manifest や構造的な設定を変更する場合は、.specsfy/STACK.md 用の [DOC] タスクを作成します。データベース、スキーマ、永続モデル、テーブル、フィールド、リレーション、migration を変更する場合は、必須の .specsfy/DATABASE.md 用 [DOC] タスクを作成します。
• アプリケーションの変更では、タスクの締めくくりに PROJECT.md のレビューを含めます。重大な影響がない場合は、内容を不自然に追加するのではなく、証拠の中で理由を説明するよう求めます。
• すべての [CODE] タスクで、EXECUTE の前に $specsfy-documentator によって docs/ を独立して再構築することを必須とします。変更前からドキュメントが存在する場合も同様です。
• ある規約が確認済みのルールになった場合は、.specsfy/RULES.md 用の [DOC] タスクを作成します。
• 各タスクには、固有の成果、正確なパス、検証可能な基準を指定します。
• [MIGRATION] タグは [CODE] または [OPS] と併用する場合にのみ使用します。パスは、検出されたスタックに応じて database/migrations/、migrations/、prisma/migrations/、または supabase/migrations/ 配下にします。
• 既存のテーブルの読み取り、クエリ、使用だけでは、それ自体は [MIGRATION] を必要としません。計画で構造を作成または変更する場合は、このタグが必須です。
• 解決済みの Tasks.md テンプレートで定義されている PREP、EXECUTE、VERIFY、VISUAL、EVIDENCE、IMPROVE の各項目を、この順序どおりにすべてのタスクへ付けます。
• VISUAL 項目は、依頼の有無にかかわらず必須です。開発中にシステムの境界、間隔、マージン、padding、タイポグラフィを確認します。インターフェイスがない場合は、具体的な理由を添えて Não aplicável と記載します。
• 各項目は、タスク固有の成果として記述し、汎用的な定型文をコピーしないでください。
• タスクの作成時には、親タスクと各項目を未完了のままにします。実装スキルは、証拠が得られた時点で各項目を更新します。
• IMPROVE 項目には、具体的に実施した改善を記録するか、改善が不要だった場合はその理由を記載します。
• spec で Evidence Contract: 1 が宣言されている場合、完了した各 [CODE] タスクには、task、refs、files、および commands（run と exit）を含む specsfy:evidence JSON コメントを付けます。このコメントはタスクブロック内に生成し、別ファイルには記載しないでください。
• タスク間でファイル、変更可能な状態、依存関係を共有しない場合に限り、[P] を付けます。
• 依存関係は ID で宣言します。表示順だけに依存しないでください。
• 適用されるすべての FR、NFR、AC を網羅します。明確な理由があるセットアップ／仕上げ作業を除き、参照のないタスクは作成しないでください。
• 汎用的な例やプレースホルダーは含めないでください。 標準形式：

- [ ] T001 [TEST] [TDD] [US-001] Derivar teste Pest do BDD da spec em tests/Feature/AuthTest.php — Refs: FR-002, AC-003 — Depends: none
- [ ] T002 [CODE] [US-001] Implementar validação em app/Services/AuthService.php — Refs: FR-002, AC-003 — Depends: T001

ID の後に使用できるタグ：[P]、[TEST]、[TDD]、[CODE]、 [DOC]、[OPS]、[US-NNN]。

検証

次を実行します：

node .agents/skills/specsfy-05-tasks/scripts/validate_tasks.mjs specs/<estado>/<NNNN>-<slug>/spec.md --allow-draft

ユーザー向けインターフェースがある場合は、次も実行します：

node .agents/skills/specsfy-05-tasks/scripts/validate_interface_tasks.mjs specs/<estado>/<NNNN>-<slug>/spec.md

重複 ID、無効または循環依存、存在しない参照、BDD シナリオが 3 つない項目、 個別の TDD タスクがない AC、feature/US/FR/NFR ごとに先行タスクまたは TDD ケースが 3 つない計画、TDD の先行タスクがないコード、チェックリストの欠落または順序違い、一貫性のない親項目と項目、ブロック中のタスクの進捗、曖昧なタスクを修正します。サイクルは最大 3 回までです。 エビデンス契約では、同じバリデーターがファイルの欠落、無効な参照、exit: 0 のないコマンド、エビデンスのない完了済みタスクも拒否します。

Plan Gate: Pending のままでも構造検証に合格した場合は、自動的に $specsfy-06-tdd-bdd を prepare モードで呼び出します。このモードでは spec の BDD を使って TDD の先行タスクを作成し、RED を確認して、そのテストタスクのみを完了します。続いて、このスキルを自動的に再開して、次を行います：

1. --allow-draft を付けてバリデーターを再実行します；
2. Plan Gate を Passed に変更し、Status: Planned に設定します；
3. 結果を「Act II のゲート — 計画」に記録します；
4. --allow-draft を付けずに実行します。

Plan Gate の後に、specsfy transition <id> planned を実行します。会話によってスコープ、依存関係、または必要な能力が変わる場合は、再計画の前に $specsfy-interviewer を呼び出し、根拠を添えて Effort を更新します。

厳格モードでは、[CODE] タスクの TDD 先行タスクが 1 つでも未完了の場合、Plan Gate: Passed は拒否されます。検証に失敗した場合は、Status: Defined、Plan Gate: Failed、Delivery Gate: Pending を維持し、ブロッカーを報告します。

報告

タイプ別および合計の件数、クリティカルパス、[P] の機会、ID のカバレッジを報告します。また、ゲートに合格した場合は、$specsfy-07-implement を自動的に通知して読み込みます。tasks.md は決して作成しないでください。

必要に応じて参照する専門家

専用チェックリストが必要な技術、データ、インターフェース、または運用の作業を分解する際は、references/specialists.md を読みます。