バックエンド実装時に使用。DRY原則遵守。コーディング規約準拠。
中文简介正在准备中。当前显示原文说明。
Use when independent bounded tasks benefit from delegation during implementation
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Choose delegation by total effort: briefing, implementation, rediscovery, integration, and rework. The parent may implement or fix code directly. Do not require a particular implementation model or forbid the parent model from writing code. Select available models for task difficulty and use the runtime's actual tool contract.
Delegate only work with clear ownership, interfaces, acceptance criteria, and useful independence. Parallel tasks must not edit the same files or depend on unfinished shared state. Give each worker concise requirements, relevant source paths, the workspace, constraints, and expected verification; do not ask it to transcribe a complete implementation from a plan.
Use implementer-prompt.md as an optional brief template. The controller integrates results, resolves dependencies, and can handle a small fix itself. Workers report evidence and uncertainties; they do not launch extra reviewers. Maintain a concise progress record only when it aids resumption, using existing runtime records where available.
Run appropriate tests while implementing. After integration, use the project's independent quality-check and its review budget. There is no mandatory task-by-task review, spec/quality double review, or additional whole-branch reviewer. A targeted investigation can still be requested when a concrete unresolved concern requires another perspective; account for it in the existing review budget.
The task-brief and workspace scripts remain optional utilities for larger handoffs. Legacy task review/re-review templates are optional formats for an explicitly selected quality-check investigation, not additional gates. Do not create their ledgers, snapshots, or packages unless the chosen workflow needs them.
Workers report changed files, test evidence, deviations from the design and limitations to the controller; the controller records the deviations. Before completion, verify the integrated result; the report to the user follows the final-message rule in documents/development/development-policy.md §1.0 "承認後の進め方" (deviations from the design only; test evidence goes into the PR body). Continue integration within existing authorization and project branch policy.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
バックエンド実装時に使用。DRY原則遵守。コーディング規約準拠。
中文简介正在准备中。当前显示原文说明。
Use before implementing any feature, behavior change, or refactor - settles requirements and design, then gets the design independently reviewed and approved by the user before code is written
中文简介正在准备中。当前显示原文说明。
作業開始時に使用。mainブランチでの作業禁止。Issue先行作成必須。
中文简介正在准备中。当前显示原文说明。
UI実装後の検証時に使用。agent-browser CLIでブラウザ上の動作を手動検証する。「UIを確認」「画面テスト」と言われたら使用(プロジェクトの E2E スイート実行は quality-check Step 5(推奨度・範囲で自動実施または確認)/ server-startup が担当)。
中文简介正在准备中。当前显示原文说明。
DBマイグレーション作成時に使用。バージョン番号競合防止。mainブランチ確認必須。
中文简介正在准备中。当前显示原文说明。
Use when independent tasks benefit from parallel work without shared state or sequential dependencies
中文简介正在准备中。当前显示原文说明。