| name | execution-specificity |
| description | Use when writing or reviewing implementation plans, roadmaps, tickets, or task lists that claim to be execution-ready — especially before handing work to another agent or session. |
Execution Specificity
This skill enforces a non-negotiable quality bar for plans, tasks, tickets, and documents that claim to be ready for execution.
It is authoritative and reusable across workflows.
Scope
This skill applies whenever an agent produces:
- Implementation plans
- Roadmaps
- Tickets or task lists
- Execution checklists
- Architecture or refactor plans
- Any artifact described as “ready to implement”
Core Rules
1. No Vague Tasks (MANDATORY)
Tasks MUST NOT be abstract.
Forbidden examples:
- “Implement backend logic”
- “Hook up frontend”
- “Improve performance”
- “Refactor as needed”
Every task MUST specify at least one of:
- A system or subsystem
- A layer (frontend, backend, persistence, infra)
- A file, module, or directory
- A concrete behaviour or contract
2. Explicit System Boundaries
Each task or plan section MUST make clear:
- What is in scope
- What is explicitly out of scope
- Which systems or layers are affected
- Which systems are intentionally untouched
Ambiguous boundaries are not allowed.
3. Unknowns Must Be Surfaced
If part of the work depends on missing information, unclear behaviour, or future decisions:
- The unknown MUST be stated explicitly
- The risk or impact of the unknown MUST be described
- The task MUST indicate how the unknown will be resolved
Unknowns may not be hidden inside vague language.
4. Acceptance Criteria Required
Every execution-ready task or phase MUST define:
- What “done” means
- How correctness can be verified
- What observable change will exist after completion
If “done” cannot be described, the task is not execution-ready.
For tickets specifically, the tickets-and-logbook skill defines the concrete body format (Problem / Approach / Dependencies / Acceptance Criteria / Testing) that satisfies these rules — use it rather than inventing a parallel structure.
5. Decomposition Discipline
Large tasks MUST be decomposed until:
- Each unit can be reasonably implemented and reviewed
- Each unit has a single dominant intent
- Failure modes are understandable
Over-decomposition is allowed; under-decomposition is not.
When NOT to Apply
- Brainstorms, option surveys, and early drafts that don't claim execution-readiness — label them as such instead of specifying them prematurely
- Single-step tasks where the "plan" is the action itself
Enforcement
If an artifact claims to be execution-ready but violates any rule above:
- The artifact is invalid
- The agent MUST revise it before proceeding
- Downstream workflows must not rely on it
Intent
This skill exists to prevent:
- Plans that sound complete but cannot be executed
- Hidden ambiguity
- “Someone else will figure it out” task descriptions
- Fragile handoffs between agents and humans
Clarity is a prerequisite for execution.
