version: "1.0.0" 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.