القائمة
Use when a scoped implementation can be delegated to an implementation subagent and then independently reviewed for spec compliance before code quality.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | subagent-driven-change |
| description | Use when a scoped implementation can be delegated to an implementation subagent and then independently reviewed for spec compliance before code quality. |
Use this workflow only when the task has a clear spec, acceptance criteria, and file ownership. Keep tightly coupled or architectural decisions in the parent session unless the user explicitly asks for delegation.
Required subagents: implementer, spec-reviewer, and code-quality-reviewer.
Each subagent prompt must include the full task text, relevant spec excerpts, non-goals, acceptance criteria, file ownership, constraints, expected tests, and any command limits. Do not rely on hidden chat history or a previous subagent's memory.
implementer with one bounded task and the complete context it needs.implementer returns BLOCKED or NEEDS_CONTEXT, resolve that before continuing.implementer returns DONE_WITH_CONCERNS, read the concerns before review and decide whether to fix, narrow scope, or continue.spec-reviewer with the original task, relevant spec excerpts, changed files, and implementer report.code-quality-reviewer only after spec review reports compliance.Implementation worker status values: DONE, DONE_WITH_CONCERNS, BLOCKED, NEEDS_CONTEXT.
Spec reviewer status values: COMPLIANT, ISSUES_FOUND, NEEDS_CONTEXT.
Code-quality reviewer status values: ACCEPTABLE, ISSUES_FOUND, NEEDS_CONTEXT.
Final handoff must list what changed, tests run, contract impact, security impact, remaining risks or TODOs, and whether the spec acceptance criteria are fully met.
Use when a stakeholder request is rough, ambiguous, or underspecified and needs clarification before planning, writing a spec, or creating issues.
Use after a grill-change session is complete to turn the agreement record into an intent-first spec candidate and vertical TDD-ready issue briefs.
Use when a stakeholder request is rough, ambiguous, or underspecified and needs clarification before planning, writing a spec, or creating issues.
Use after a grill-change session is complete to turn the agreement record into an intent-first spec candidate and vertical TDD-ready issue briefs.
Use to run a bounded security-review, patch, and retest loop that stops on green, on no diff, or on a repeated identical finding.
Use before handing off an implementation to compare the diff against the spec, tests, docs, contracts, and safety rules.