Add auto/prep/implement workflow commands#3
Conversation
Ships three new namespaced commands that wrap the speckit pipeline: - speckit.opsmill.prep — specify → plan → critique → tasks (+ alignment check against an upstream PRD when $ARGUMENTS contains one), stopping before implementation. - speckit.opsmill.implement — runs the implement loop in clean-context subagents from an existing tasks.md, then review, then a final report to opsmill-implement-report.md. Subagent briefs are project-agnostic: the orchestrator resolves AGENTS.md, CLAUDE.md, CONTEXT.md, and the project constitution (if present) and passes absolute paths. Local test-pass policy covers unit, integration, and E2E (when locally runnable), with a graceful 'deferred' path for E2E suites that need CI-only infrastructure. - speckit.opsmill.auto — thin orchestrator: prep, then implement, then extract. Bumps extension version to 1.1.0 and broadens the top-level description to mention the new trio. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extraction is now a manual follow-up so the user can review the implementation report (and any deferred review findings) before promoting content into dev/. The auto command stops after the implement sub-skill returns. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extract is now a manual command across the board — no auto-fire after implement. Users who want the old behavior can re-wire it on the consumer side via .specify/extensions.yml (snippet shown in README). README's hooks table and surrounding prose updated to match. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
BeArchiTek
left a comment
BeArchiTek
left a comment
There was a problem hiding this comment.
Code review — auto/prep/implement workflow commands
Docs/config-only change, so the findings are about command-reference resolution, the autonomous-workflow logic, and consistency with the rest of the repo.
Dominant theme — naming. The same sibling commands are referred to by three different name forms, only one of which is actually registered. extension.yml registers them as dotted commands (speckit.opsmill.{prep,implement,auto}). The new files also refer to them as hyphenated skills (speckit-opsmill-prep) and, in several places, as speckit.auto.prep / speckit.auto.implement — a namespace registered nowhere. Recommend standardizing every sibling reference on the registered speckit.opsmill.* form and reconciling the "invoke the … skill" wording with the fact that these ship as slash commands. Inline comments mark each site; the two user-facing ones (the abort message and the retry next-step in implement.md) are the highest priority because they send a user to a command-not-found.
Additional findings outside the diff hunks
CHANGELOG.md — no [1.1.0] entry. extension.yml is bumped to 1.1.0, three commands are added, and the after_implement → extract hook is removed, but the changelog still tops out at [1.0.0]. The file states it follows Keep a Changelog / SemVer, so a release with no entry leaves the hook removal and the new commands undocumented.
README.md:6 — command count stale. The intro still says the extension provides "three workflow commands" and lists only extract/retrospect/summary; auto/prep/implement are absent, so a reader using the README as the command inventory won't discover them.
README.md:131 — provenance stale. "Command bodies in v1 are verbatim lifts … no other content changes" no longer holds — auto/prep/implement are authored from scratch in this release, not lifts.
extension.yml:46 — tags not updated. The tags: list (opsmill/extract/retrospect/summary/workflow) gains no auto/prep/implement/autonomous tag, reducing registry discoverability.
|
|
||
| ## Outline | ||
|
|
||
| You are running the **implementation + review tail** of the speckit pipeline. This command picks up where `speckit.auto.prep` leaves off: it expects a feature directory under `specs/` containing `spec.md`, `plan.md`, and `tasks.md`. It does **not** generate or modify those documents — it executes them. |
There was a problem hiding this comment.
speckit.auto.prep is not a registered command — the registered name is speckit.opsmill.prep. The same speckit.auto.* form recurs at lines 28 and 99.
| Before any work begins: | ||
|
|
||
| 1. Resolve the target spec directory (from `$ARGUMENTS` or the most recently modified `specs/<feature>/` with a `tasks.md`). Record the absolute path; you will pass this to every subagent. | ||
| 2. Verify `spec.md`, `plan.md`, and `tasks.md` all exist. If any are missing, abort with a clear error directing the user to run `speckit.auto.prep` first. |
There was a problem hiding this comment.
High — user-facing dead-end. This abort directs the user to run speckit.auto.prep, which doesn't exist; the registered command is speckit.opsmill.prep. Anyone hitting this recovery path gets command-not-found and is stuck. Use speckit.opsmill.prep.
| 1. Resolve the target spec directory (from `$ARGUMENTS` or the most recently modified `specs/<feature>/` with a `tasks.md`). Record the absolute path; you will pass this to every subagent. | ||
| 2. Verify `spec.md`, `plan.md`, and `tasks.md` all exist. If any are missing, abort with a clear error directing the user to run `speckit.auto.prep` first. | ||
| 3. Read `tasks.md` end-to-end and identify the chunking boundaries (see "Chunking strategy" below). Build a numbered list of chunks with their task IDs. | ||
| 4. Verify the working tree is clean (or only contains expected prep artifacts). If it is dirty in unrelated ways, surface that and pause. |
There was a problem hiding this comment.
Phase 0 says to pause on an unexpectedly dirty tree (and abort in step 2 if docs are missing). When this command runs via auto's Phase B — an explicitly hands-off, non-interactive run — there is no user to resume a pause, so the orchestrator either hangs or proceeds on a dirty tree and contaminates the HEAD@start..HEAD@now review diff. Worth defining how these stop-conditions behave under an autonomous parent.
| 4. Verify the working tree is clean (or only contains expected prep artifacts). If it is dirty in unrelated ways, surface that and pause. | ||
| 5. Note the current `HEAD` commit — you will diff against it for the review and report. | ||
|
|
||
| ### Phase 5 — Implement (looped, clean-context subagents) |
There was a problem hiding this comment.
Phase numbering jumps 0 → 5 → 6 → 7. The intent is to mirror the upstream specify→plan→critique→tasks numbering (which lives in prep), but nothing here says so, so an agent executing this file literally may read 1–4 as missing/skipped phases. A one-line note ("Phases 1–4 run in prep") would remove the ambiguity.
|
|
||
| 3. **Wait for the subagent to return**, then: | ||
| - Pull its outcome lines into your running ledger of chunk results. | ||
| - Verify `tasks.md` checkboxes for that chunk are now `[X]` (re-read the file). If the subagent forgot to tick them, do it yourself and amend or add a fixup commit. |
There was a problem hiding this comment.
"amend or add a fixup commit" — the amend branch rewrites the subagent's commit SHA, but that SHA is recorded in the Phase 7 chunk ledger (§2) and may already be referenced, so the final report can cite a commit that no longer exists. Prefer a fresh fixup commit, or capture the rewritten SHA back into the ledger.
| ### Phase A — Preparation (delegated to `speckit.auto.prep`) | ||
|
|
||
| Invoke the `speckit-opsmill-prep` skill with the user's feature description (`$ARGUMENTS`) verbatim. |
There was a problem hiding this comment.
This (and line 39 for -implement) instructs invoking speckit-opsmill-prep as a skill, and line 24 claims the workflow "runs identically across any harness that supports skill discovery." But the extension ships these only as slash commands (registered under extension.yml provides:) — there is no skill of that name. On a literal Skill-tool lookup the hand-off won't resolve, which breaks auto's entire purpose. Either publish prep/implement as skills, or change this to invoke the speckit.opsmill.prep command and soften the skill-discovery claim.
| - 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 auto-prep loops (re-running plan/critique/tasks to fix spec drift), let it run to completion. Do not interfere. | ||
| - Capture the spec directory path it produced — you will pass it to Phase B. |
There was a problem hiding this comment.
The spec-dir path hand-off to Phase B has no deterministic contract — prep only emits the path as a prose Completion bullet (prep.md:127). If prep runs in a clean/forked context, the orchestrator must parse the path out of free text; on failure, Phase B falls back to implement's "most recently modified specs/ with a tasks.md" default and can silently target the wrong feature. Consider having prep return the path in a fixed, parseable form.
| - If the alignment check inside auto-prep loops (re-running plan/critique/tasks to fix spec drift), let it run to completion. Do not interfere. | ||
| - Capture the spec directory path it produced — you will pass it to Phase B. | ||
|
|
||
| If `speckit-opsmill-prep` reports it stopped early (e.g., alignment never converged within its retry budget), surface the failure to the user and stop. Do not proceed to implementation on a misaligned spec. |
There was a problem hiding this comment.
This guard assumes prep "reports it stopped early … and stop[s]". But on unconverged drift prep (5e, prep.md:118) just writes verdict 🛑 UNRESOLVED into alignment-check.md and its prose summary, then returns normally — there is no structured stop signal. So auto can read a success-shaped summary and proceed to implementation on a known-misaligned spec, exactly what this guard is meant to prevent. Define an explicit failure signal that prep returns and that auto checks.
|
|
||
| If you decided to run the check: | ||
|
|
||
| - For each URL in `$ARGUMENTS`, fetch its content using the harness's web fetch tool (in Claude Code: the `WebFetch` tool). Extract the requirement-bearing sections. |
There was a problem hiding this comment.
5b hard-codes a web-fetch tool, with a fallback only for gated/404/network URLs — not for a harness that has no web-fetch capability. Since 5a already decided to run the check based on a URL in $ARGUMENTS, an agent in a no-fetch harness is committed to the check but cannot resolve the source PRD and has no "tool absent" branch. Add a fallback for that case.
| 2. **Re-run Phase 2 (Plan)** to refresh `plan.md` against the corrected spec. | ||
| 3. **Re-run Phase 3 (Critique)** to validate the corrected spec/plan. | ||
| 4. **Re-run Phase 4 (Tasks)** to regenerate `tasks.md` against the corrected plan. | ||
| 5. **Re-run Phase 5c–5d** (do **not** re-resolve the source PRD — keep the same source) to confirm the drift is gone. |
There was a problem hiding this comment.
The remediation loop is underspecified: step 5 re-runs "5c–5d" (which only write a verdict), not 5e's own branch, so an agent has no instruction to re-enter the loop decision; and the point at which the "2 remediation passes" counter increments (line 116) is never stated. Net effect: it can over- or under-run the budget. Suggest making 5e the explicit loop body and stating when the counter ticks.
2 participants
Summary
speckit.opsmill.prep— specify → plan → critique → tasks (+ PRD alignment check when$ARGUMENTScontains a PRD or URL), stops before implementation.speckit.opsmill.implement— clean-context subagent implement loop → review → final report, picking up from an existingtasks.md.speckit.opsmill.auto— thin orchestrator: prep → implement. Does not run extract — that stays a manual follow-up so the user can review the implementation report first.AGENTS.md,CLAUDE.md,CONTEXT.md, and the project constitution (when present) and pass absolute paths. Test framework is discovered from the repo (no pytest/k8s assumptions). Local-pass evidence is required for unit, integration, and E2E tests, with a gracefuldeferred — local E2E not supportedpath for suites that need CI-only infrastructure.after_implement→speckit.opsmill.extracthook. Extract is now manual everywhere. Consumers who want the old auto-fire can re-wire it via.specify/extensions.yml(snippet in the README).Test plan
specify extension add --dev <this checkout>resolves all six commands (extract, retrospect, summary, auto, prep, implement)./speckit.opsmill.prep <feature description>produces a spec dir withspec.md,plan.md,tasks.md, and (when a PRD URL is given)alignment-check.md./speckit.opsmill.implement <spec-dir>dispatches per-chunk subagents, producesopsmill-implement-report.md, and the report contains a populated local-pass evidence table./speckit.opsmill.auto <feature description>chains prep → implement end-to-end without prompting between phases, and stops before extraction (does not invokespeckit.opsmill.extract)./speckit.implement(native command) completes, the consumer is not prompted to run extract anymore (hook removed)./speckit.opsmill.extractstill works as a manual follow-up.🤖 Generated with Claude Code