Interview, then write SPEC and GOAL

Interview the user, capture what to build in SPEC.md, and how the agent should execute and verify it in GOAL.md.

Use this when

Use this when a rough coding idea is too vague to hand to Codex for a long autonomous run and the user first needs to settle scope, completion checks, safety boundaries, and required tools.

How it runs

1. Ask the user what the finished feature should do, what is out of scope, which edge cases matter, what could go wrong, and what evidence would prove completion; write those decisions in SPEC.md.
2. Point out ambiguous requirements with concrete interpretations and have the user resolve product decisions instead of letting the coding agent silently choose.
3. Write GOAL.md with the ordered work, a progress scorecard, quick checks for each iteration, slower final checks, memory files for long runs, approval boundaries, and required evidence.
4. Confirm that the tools, permissions, environment, and tests exist; stop as not ready when anything essential is missing, and start the long-running task only after approval.

Done when

✓ The planning files say what to build, how to judge it, and when to stop. Every done_when completion check names observable evidence, the quick and final checks can actually run, the environment is ready, and unresolved decisions are clearly marked not ready.

Why it works

Goal Forge makes the user decide what success means before an agent spends hours coding. The two files give Codex a stable target, repeatable checks, memory across a long run, and an honest not-ready state when important information is missing.

Implementation note

In the source workflow, /goal is Codex's long-running task mode. SPEC.md describes the product decision; GOAL.md tells Codex how to execute and verify it; PLAN.md, ATTEMPTS.md, and NOTES.md preserve progress and learning across the run.

Source: Forward Future ↗graded C · 55/100 — how grades work →

More maintenance loops