Smithery is now a part of Arcade.dev! Read more in our announcement here
BEFORE dispatching any implementation agent or starting to code - if you're about to write "Task(subagent_type=..., prompt=...)" for implementation, or about to implement a plan yourself, STOP and...
Use this skill when you're about to:
Task() for implementation workThe prompt you write IS the brief. If you're about to send an implementation agent a task, that task description needs review first.
Ask yourself: "Am I about to have code written (by me or an agent)?" If yes → domain review first.
Core principle: Task briefs contain design flaws. Domain experts catch them before implementation, not code reviewers after.
Real-world data: A "straightforward serialization" brief reviewed by domain expert found 8 issues (3 critical type safety bugs, 3 important design gaps, 2 minor improvements). Cost: 5 minutes review. Savings: hours of debugging and refactoring.
NO IMPLEMENTATION FROM AN UNREVIEWED BRIEF
Review coverage is inherited, not re-earned per dispatch:
A capable implementation agent will sometimes catch a brief flaw mid-task and deviate with justification. Treat that as the last line of defense, not the plan — require agents to report deviations, never to silently absorb them.
MANDATORY for:
Dispatch an additional per-brief review when:
Read brief → Implement → Code review finds issues → Refactor
Cost: Implementation time + refactoring time + context switching
Read brief → Domain experts review brief → Fix brief → Implement with corrections
Cost: 5 minutes review
Savings: Hours of rework
If you have the Agent tool available:
Use the Agent tool to dispatch domain-appropriate expert agents — project
personas where the roster has the right lens (pairing complementary lenses,
e.g. an invariant tracer plus a premise auditor, catches more than two passes
of the same lens), general-purpose with a role line otherwise.
Dispatch the agents with a prompt similar to this format:
Agent(subagent_type="general-purpose", prompt="""
**Role:** You are a [domain] expert specializing in [specific area].
**Task:** Review this task brief for technical correctness and design flaws.
**Brief location:** [path to brief]
**Review focus:**
1. [Domain-specific concerns - e.g., serialization format, data types, security, industry standards]
2. Edge cases and error handling
3. Performance implications
4. Best practices compliance
5. Integration considerations
6. Coherence with overall plan
7. Task complexity and whether it should be decomposed
8. Task ordering — does every task's inputs exist by the time it runs?
**Provide:**
1. List of issues (Critical/Important/Minor)
2. For each: what's wrong and recommended fix
3. Things done well
4. Overall: "Ready to implement" or "Needs revision"
**Note:** Review the BRIEF/DESIGN, not code. Focus on flaws that cause problems during implementation.
""")
Plan-level reviews must include a sequencing pass. Walk the task list in order and check each task's inputs against what earlier tasks actually produce. The recurring failure is a task that measures something scheduled before the task that makes it measurable — an acceptance run, calibration sweep, or conformance probe ordered ahead of the wiring it exercises. It reads fine task-by-task, because each task is individually correct; only the order is wrong. It surfaces as a dead-end partway through execution, after the earlier tasks are already committed.
Concretely, for each task ask: what does this consume, and which earlier task produces it? A task whose answer is "the thing it's verifying" is misordered. This is the durable Consumes/Produces contract the plan should already carry — the review is where a missing or circular one gets caught.
If Task tool not available:
STOP and ask your human partner: "I need to have a domain expert review this brief before implementing. How should I dispatch a consulting agent in this environment?"
Don't skip review because tool isn't obvious. Escalate to get the right mechanism.
Now dispatch implementation agent with corrected brief.
Use code-reviewer to catch implementation gaps.
Serialization tasks: "Data serialization expert specializing in format design, type safety, and versioning"
Security tasks: "Application security specialist focusing on OWASP Top 10, attack vectors, and secure design patterns"
Networking tasks: "Distributed systems expert specializing in protocols, error handling, and network reliability"
Database tasks: "Database architect specializing in schema design, indexing strategies, and query optimization"
Algorithm tasks: "Algorithm specialist focusing on complexity analysis, edge cases, and correctness proofs"
Concurrency tasks: "Concurrency expert specializing in race conditions, deadlocks, and synchronization patterns"
| Excuse | Reality |
|---|---|
| "Brief is simple/straightforward" | Task 16 "straightforward serialization" had 8 issues. Simple briefs hide complex issues. |
| "Brief has TDD steps already" | TDD tests the implementation, not the design. Flawed design → passing tests for wrong behavior. |
| "Not security-critical" | Technical correctness matters everywhere. Type safety bugs, data loss, performance issues affect all code. |
| "I know this pattern" | Familiarity causes assumptions. Expert finds issues you overlook because "I've done this before." |
| "Domain review is overkill" | Minutes of review vs hours of debugging. The ratio has narrowed with stronger models, but it has not inverted — and the worst flaws (unimplementable designs, wrong approaches) still cost a full implementation cycle. |
| "I can see issues myself" | Then fix them in the brief BEFORE implementing. Domain expert systematically finds what you miss. |
| "We already reviewed the plan, so we don't need a review for this task brief" | True ONLY if the brief is lifted from the reviewed plan without additions. If the brief paraphrases, extends, or deviates — review the delta. |
| "The implementation agent will catch brief flaws" | Sometimes it will — that's the last line of defense, not the plan. Flaws it absorbs silently become code. |
If the plan behind the brief was never domain-reviewed and you think ANY of these thoughts, STOP and dispatch domain expert:
All of these mean: Dispatch domain expert first. The only legitimate skip is documented inheritance: the brief is the reviewed plan's task, verbatim.
CRITICAL: If you're using subagent-driven-development, domain review of the PLAN is a mandatory gate before the first dispatch.
Before any task dispatch:
1. DISPATCH DOMAIN EXPERT(S) to review the plan ← MANDATORY
2. ADDRESS findings, revise plan ← MANDATORY
For each task:
3. READ the task from plan
4. If the brief deviates from the reviewed plan, is novel/high-risk,
or had no plan review: dispatch a focused brief review first
5. Dispatch implementation subagent (brief quotes the plan; agent must
report any deviations, never absorb them silently)
6. Code review
7. Fix code review issues
Why both reviews:
Skipping domain review = implementing flawed designs. Code review can't fix architectural problems.
Add domain review as first step before parallel execution:
1. Load plan
2. For each task: Dispatch domain expert, collect issues
3. Review all domain feedback with human
4. Execute tasks in parallel with corrections applied
Prevention vs remediation. A review costs minutes; a flawed brief costs an implementation cycle plus debugging plus rework. The exact ratio shifts with model strength — implementation agents now catch some brief flaws themselves — but the asymmetry survives because the worst brief flaws (unimplementable assertions, wrong approach, vacuous tests) produce work that looks done and fails later, which is the most expensive failure shape there is.
Worked example from practice: a reviewed implementation plan for a determinism-contract branch had two MAJOR flaws caught by plan review — an assertion targeting a container with no defined order, and a mutation check that was a silent no-op. Each would have burned a full subagent session and produced a false-confidence test suite.
Task: "Implement data serialization using NumPy npz format"
Without domain review:
With domain review:
Task briefs lie. Not maliciously - they're written without complete knowledge. Authors don't know every edge case, anti-pattern, or domain best practice.
Domain experts find the lies before they become bugs.
Every plan, before the first dispatch. Every brief that goes beyond the reviewed plan. No silent exceptions.
