version: "1.0.0" name: smart-plan-rush-exec description: Delegate narrow implementation slices from a parent smart thread into locked-down rush child runs. Use when the parent can define an explicit child contract with task, context paths, write paths, create paths, acceptance criteria, allowed commands, and allowed skills, and when the parent will retain final review and integration. Do not use when scope is broad, cross-cutting, ambiguous, decision-heavy, or requires broad tool, MCP, or network access.

Smart Plan Rush Exec

Use this skill only in the parent smart thread. Keep the child rush run narrow, contractual, and disposable.

Workflow

1. Read `references/decomposition.md` before slicing work.
2. Define one explicit child contract per slice:

• task
• context_paths
• write_paths
• create_paths
• acceptance_criteria
• allowed_commands
• allowed_skills

1. Reject delegation unless every field is specific enough to enforce mechanically.
2. Launch the child through tb__smart_plan_rush_exec, not through ad hoc shell commands.
3. Treat child output as a bounded implementation attempt, not as final judgment.
4. Read `references/final-review.md` before accepting or integrating child work.

Refuse Fan-Out

Do not delegate when any of these are true:

• The write scope is broad or ambiguous.
• The task needs product or architecture decisions mid-flight.
• The work crosses many layers or directories and cannot be reviewed as one narrow slice.
• The child would need broad network, MCP, browser, or tool access.
• The child would need to invent its own decomposition.
• The parent cannot describe concrete acceptance criteria up front.

When delegation is unsafe, continue locally in the parent thread or re-slice the task first.

Contract Rules

• Keep write_paths as the smallest practical file or directory set.
• Keep create_paths empty unless file creation is required.
• Keep allowed_commands to exact safe patterns needed for verification or formatting.
• Keep allowed_skills empty by default.
• Allow MCP only through explicitly named skills that truly require it.
• Expect the child to escalate instead of broadening scope.

Parent Duties

• Own decomposition.
• Own fan-out limits and write-scope separation.
• Own final review, integration, cleanup, and any revert decision.
• Own final verification after child work returns.

Resources

• Read `references/decomposition.md` when splitting work.
• Read `references/final-review.md` before accepting child output.
• Copy `assets/checks/scope-guard.md` into .agents/checks/smart-plan-rush-exec-scope.md when opting a repo in.