con un clic
implement-direct
// Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
// Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
Linear phase-loop orchestrator for single-feature implementation plans. Use for medium-complexity work where transparent human-in-the-loop phase review is preferred over factory automation.
Implementation entry point. Use to execute a completed specification. Auto-detects the decomposition tier (Direct, Incremental, or Factory) from spec artifacts and dispatches to the matching execution sub-skill.
Decompose a single-feature specification into a linear, phase-by-phase implementation plan. Use this for medium-complexity work — single feature, one or two components — where transparent human-in-the-loop phase review is preferred over factory automation.
Scaffold, status-check, and manage specification directories. Use when creating a new spec, reading spec status, transitioning between phases, or logging decisions on a spec in .start/specs/.
Create a comprehensive specification from a brief description. Runs requirements gathering, solution design, and decomposition — routing decomposition to one of three tiers based on a complexity classifier: Direct (no plan), Incremental (linear phase plan), or Factory (parallel units with holdout scenarios).
Factory loop orchestrator for multi-feature or multi-component implementation manifests. Use for high-complexity work with parallel-eligible workstreams and holdout-scenario evaluation.
| name | implement-direct |
| description | Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition. |
| user-invocable | false |
| argument-hint | spec ID to implement (e.g., 002), or file path |
Act as a lightweight implementation orchestrator that executes specifications without intermediate plan or manifest artifacts. You delegate all coding work to specialist agents and verify the result through drift detection. Use TDD: failing test first, minimal code to pass, then refactor.
Implementation Target: $ARGUMENTS
DeliveryUnit { title: string // human-readable name area: string // backend | frontend | data | infra | docs refs: string[] // requirements/solution sections to read acceptance: string // what "done" looks like }
DirectResult { filesChanged: string[] testStatus: string // All passing | X failing | Pending driftFindings: string[] // from validate skill constitutionFindings?: string[] // from validate constitution mode blockers?: string[] }
State { target = $ARGUMENTS spec: string // resolved spec directory path (or arbitrary doc path) requirements?: string // path to requirements.md if present solution?: string // path to solution.md if present contextDocs: string[] // any other relevant docs (refactor briefs, bug reports) units: DeliveryUnit[] mode: Standard | Agent Team result: DirectResult }
Always:
Never:
Use the specify-meta skill to resolve the spec directory if $ARGUMENTS is a spec ID.
If $ARGUMENTS is a file path or freeform brief, treat it as the primary context document and skip spec-meta resolution.
Discover available context:
$ARGUMENTSIf none of these are available, report: this skill requires at least one context document. Ask the user for a brief or file path.
Present what was discovered:
Offer optional git setup:
match (git repository) { exists => ask the user to choose between Create feature branch and Skip git integration none => proceed without version control }
Read all discovered context documents.
Decompose the work into the smallest set of delivery units that covers all acceptance criteria:
Present the decomposition. Ask the user to choose between Approve, Adjust, Add units, or Recommend higher-tier mode.
Ask the user to choose:
Recommend Agent Team only when units >= 3 and they share state. Otherwise Standard is sufficient.
For each delivery unit:
match (mode) { Standard => { Load units onto the task list. For independent units: launch ALL in a single response (parallel fire-and-forget). For dependent units: launch sequentially. Update the task list as results arrive. } Agent Team => { Create tasks for the team with unit metadata. Spawn teammates per area (backend, frontend, etc.). Assign tasks. Monitor via automatic messages. } }
Each subagent prompt includes:
Extract from each result: files changed, test status, blockers.
Drift handling: ask the user to choose between Acknowledge, Update impl, Update spec, or Defer.
If constitution violation is L1 or L2, block — do not present completion until resolved.
Read reference/output-format.md and present completion summary.
match (git integration) { active => ask the user to choose between Commit + PR, Commit only, or Skip none => ask the user to choose between Run tests, Manual review, or Done }
In Agent Team: send sequential shutdown_request to each teammate, then disband the team.