User Input
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Outline
You are running the full speckit pipeline end-to-end. The user's input (above) is the feature description that will seed the specification phase.
This skill is a thin orchestrator over two sibling skills:
speckit-opsmill-prep — Specify → Plan → Critique → Tasks (+ spec/ask alignment check)speckit-opsmill-implement — Implement → Review → Final report
Run them back-to-back, making all decisions autonomously. Do not stop to ask the user for input between phases — if a sub-phase requires choices (clarification questions in specify, research decisions in plan, drift remediation in alignment), use your best judgment and proceed. The user expects a hands-off, one-shot execution. Extraction (speckit-opsmill-extract) is not run by this command — the user invokes it manually after reviewing the implementation report.
Each phase below is executed by invoking the named skill (e.g. via the agent's Skill tool). Skills are agent-agnostic, so this workflow runs identically across any harness that supports skill discovery — not only those exposing speckit slash commands.
Phase A — Preparation (delegated to speckit-opsmill-prep)
Invoke the speckit-opsmill-prep skill with the user's feature description ($ARGUMENTS) verbatim.
- This covers Specify → Plan → Critique → Tasks and the trailing spec/ask alignment check.
- The sub-skill commits its own artifacts after each phase via
speckit-checkpoint-commit.
- If the alignment check inside prep loops (re-running plan/critique/tasks to fix spec drift), let it run to completion. Do not interfere.
Read prep's status line. speckit-opsmill-prep ends its output with a literal final line:
STATUS: <READY|BLOCKED> | SPEC_DIR: <absolute spec-dir path> | REASON: <...>
Parse that line — do not infer success from the prose summary:
- Take
SPEC_DIR from this line as the spec directory to pass to Phase B. This is the deterministic hand-off; do not scrape the path out of free text.
- If
STATUS: BLOCKED (e.g., alignment never converged within its retry budget, or a phase could not complete), surface the reason to the user and stop. Do not proceed to implementation on a misaligned or incomplete spec.
- Only proceed to Phase B when
STATUS: READY.
Phase B — Implementation tail (delegated to speckit-opsmill-implement)
Invoke the speckit-opsmill-implement skill with the SPEC_DIR path from Phase A as its argument. Because you pass an explicit spec-dir path, the sub-skill runs in autonomous-parent mode: its Phase 0 stop-conditions abort with a STATUS: BLOCKED line instead of pausing for a user.
- This covers Phase 0 (Preflight) → Phase 5 (Implement loop in clean-context subagents) → Phase 6 (Review) → Phase 7 (Final report).
- The sub-skill writes
<spec-dir>/opsmill-implement-report.md and commits it.
Read implement's status line. speckit-opsmill-implement ends its output with a literal final line:
STATUS: <DONE|INCOMPLETE|BLOCKED> | SPEC_DIR: <...> | REASON: <...>
STATUS: BLOCKED — a Phase 0 stop-condition aborted before any implementation (no report written). Surface the reason in the final summary; do not retry from this orchestrator.STATUS: INCOMPLETE — blocked tasks or missing local-pass evidence; capture that for the final summary. The user decides whether to re-run.STATUS: DONE — all chunks completed with evidence.
In every case, do not retry from this orchestrator.
Completion
After both phases are complete, provide a brief summary:
- Feature name and spec directory
- Whether the alignment check inside auto-prep required retries (and how many)
- Number of tasks completed (from the auto-implement report)
- Any review findings that were fixed inline vs. deferred
- Any notable decisions you or the sub-skills made autonomously
Do not open a PR, push, run extraction, or start a new feature. The user takes it from there — extraction (/speckit.opsmill.extract) is intentionally left as a manual follow-up so the user can review the implementation report first.