Plan and Build: Spec-then-Implement Chain
WorkflowDrafts a concise implementation spec from the request, then implements it and verifies with the project's own check.
Usage
echo "<your request>" | octomind workflow plan-and-build Reads your request from stdin. Add --dry-run to validate and print the plan without
running any steps.
Pipeline
-
Produce a concise behavioral spec for the request below, in the standard spec shape. This is an AUTONOMOUS, non-interactive run — no human can answer questions, so resolve ambiguity with documented defaults (record each…
- 2 gate Conditional
- build developer:general
Implement the following spec end to end in the current project. Make the changes precisely — touch only what the spec requires. Respect its Guardrails section as hard constraints, and cover every requirement and accepta…
- blocked developer:brief
The spec ended NEEDS CLARIFICATION — no implementation was attempted. Extract the open questions from the spec below into a short numbered list the user can answer to unblock the build, then stop. Start with exactly: `B…
Definition
# Title: Plan and Build: Spec-then-Implement Chain
#
# Public workflow: turn a well-scoped request into a concise implementation
# spec, then implement that spec and prove it with the project's own check.
# The minimal two-step prompt chain with a deterministic gate at the end —
# use this when the diff is roughly describable up front; reach for the
# develop loop when conformance is uncertain. Public roles only.
name = "plan-and-build"
description = "Drafts a concise implementation spec from the request, then implements it and verifies with the project's own check."
# ── 1. Plan: request → implementation spec ───────────────────────────────────
[[steps]]
name = "plan"
role = "developer:spec"
session = "fresh"
prompt = """
Produce a concise behavioral spec for the request below, in the standard spec shape.
This is an AUTONOMOUS, non-interactive run — no human can answer questions, so resolve
ambiguity with documented defaults (record each under Assumptions) rather than asking.
Scope it to the change actually requested. Cover: EARS requirements with stable IDs
(FR-001…), each with at least one scenario or acceptance criterion; the error, boundary,
and dependency-unavailable cases; the Guardrails the implementer must respect; what is
explicitly out of scope; and the project's real verification command (tests / build /
lint) mapped to the criteria it proves. Ground every cited path with tools.
Describe behavior, not implementation. Do not write the implementation.
<request>
{{input}}
</request>
"""
# ── 2. Gate on the spec status, then build ───────────────────────────────────
[[steps]]
name = "gate"
conditional = true
condition = { output = "plan", matches = '(?m)^SPEC STATUS: READY' }
on_match = ["build"]
on_no_match = ["blocked"]
[[steps.run]]
name = "build"
role = "developer:general"
session = "fresh"
prompt = """
Implement the following spec end to end in the current project. Make the changes
precisely — touch only what the spec requires. Respect its Guardrails section as
hard constraints, and cover every requirement and acceptance criterion it states.
When the implementation is done, run the spec's verification command (tests /
build / lint). Iterate until it passes. Then report the exact command you ran
and its output as evidence — do not assert success without it.
<spec>
{{plan}}
</spec>
"""
[[steps.run]]
name = "blocked"
role = "developer:brief"
session = "fresh"
prompt = """
The spec ended NEEDS CLARIFICATION — no implementation was attempted. Extract
the open questions from the spec below into a short numbered list the user can
answer to unblock the build, then stop.
Start with exactly: `BLOCKED ON CLARIFICATION — no changes made.`
<spec>
{{plan}}
</spec>
"""