version: "1.0.0" name: delegation-plan description: Write plans intended for a cheaper or less capable implementation model. Use when the user asks for a plan suitable for another LLM, junior engineer, intern, cheaper model, coding agent, or implementation delegate.

Delegation Planning

Use this skill to write implementation plans for a capable but lower-reasoning executor.

Goal

Write a plan that removes ambiguity without doing the implementation reasoning that the delegate can do cheaply.

Think like a senior engineer and prompt engineer:

• Specify the objective, constraints, and success criteria.
• Define clear boundaries and decision rules.
• Leave routine code navigation and implementation details to the delegate.

Planning principles

• Do not paste full implementations unless the exact code is the requirement.
• Do not provide large code blocks that solve the task.
• Prefer descriptions of required behavior over exact replacement snippets.
• Give file/module targets, not line-by-line edits, unless the location is genuinely ambiguous.
• State what must not change.
• State how to handle known edge cases.
• Include validation commands and expected outcomes.
• Include escalation criteria: when the delegate should stop and ask.

Required structure

Use this structure unless the user requests another format:

# <Task title>
 
## Objective
<One paragraph describing the user-visible behavior to achieve.>
 
## Scope
-In scope: <files, modules, behavior>
-Out of scope: <explicit non-goals>
 
## Constraints
-<compatibility, minimality, performance, style, or API constraints>
 
## Implementation guidance
1.<Concrete step with target files/modules and intended behavior.>
2.<Concrete step.>
3.<Concrete step.>
 
## Edge cases
-<case>: <required handling>
 
## Tests
-<test to add/update and what it should prove>
 
## Validation
Run:
-`<command>`
 
Expected result:
-<what passing looks like>
 
## Stop and ask if
-<condition that requires human/senior decision>

Specificity calibration

Use more detail for:

• Non-obvious invariants.
• Risky migrations.
• Security, data loss, auth, or compatibility concerns.
• Places where multiple valid implementations would conflict with user intent.

Use less detail for:

• Obvious syntax.
• Mechanical refactors.
• Test fixture boilerplate.
• Exact code the delegate can infer safely from surrounding code.

Anti-patterns

Avoid:

• Writing exact helper functions when a behavior description is enough.
• Replacing the delegate's design work with full code.
• Hiding choices as assumptions.
• Saying "update tests" without naming the behavior each test must verify.
• Over-constraining harmless implementation details.

Final self-check

Before finalizing, verify:

• A motivated intern could start without guessing the goal.
• The delegate still has meaningful implementation work to do.
• Every ambiguity that affects correctness has a rule or escalation path.
• The plan says how to prove the change works.