Example Artifacts

The finalize command reads three draft documents and produces three final documents. Each step applies a gap checklist to catch what the draft author missed. Here is the User Requirements gap checklist from the actual prompt:

Personas and actors

• Are all user roles identified? (end user, admin, system/cron, API consumer, reviewer)
• Is there a “system” actor for automated processes (scheduled imports, background jobs, migrations)?
• Are there external systems that act as users? (webhooks, CI/CD, monitoring)

Non-functional requirements (almost always missing from drafts)

• Performance targets — response time, throughput, batch size limits
• Data volume expectations — how many records in year 1? Year 3?
• Availability — is downtime acceptable? For how long?
• Security — authentication, authorization, input validation, secrets management
• Accessibility — WCAG level, keyboard navigation, screen reader support

Edge cases and error states

• What happens when an external API is down?
• What happens when the database is full or corrupt?
• What happens when two users edit the same thing?
• What happens on first run with no data?

The finalize command produced this task table structure as part of the final implementation plan for this website. Each phase has a goal, dependencies, and a table of atomic tasks with status tracking:

Phase 01: Homepage and Core Layout

Goal: The site has a functional homepage with the workflow-first
design, responsive navigation, and all shared layout components.

| No   | Status | Started (PST) | Completed (PST) | Description          |
|------|--------|---------------|------------------|----------------------|
| 01.1 | Open   |               |                  | Create global.css... |
| 01.2 | Open   |               |                  | Implement BaseLayout |
| 01.3 | Open   |               |                  | Implement Nav...     |

Status transitions: Open → Started (with PST timestamp) → Completed (with PST timestamp). Tasks marked Blocked get a reason appended to their description. One commit per phase, only when all tasks are complete and verification passes.

The implement command follows this exact sequence for each phase. This is from the actual prompt that drives phase execution:

1. Read state — Read final.plan.md, find the active phase, read the phase plan.

2. Execute tasks in order — For each task, top to bottom:

• Mark it Started with a PST timestamp in both plan files
• Read the phase plan’s Context section for implementation guidance
• Do the work (write code, create files, write tests)
• Mark it Completed with a PST timestamp

3. Run verification — Execute the checks listed in the phase plan (tests, lint, behavioral checks). Fix failures until green.

4. Write Phase Summary — Record what was created, modified, or configured.

5. Commit — One commit per phase, message reflects the phase scope. Do not push.

The prompt is designed to be run repeatedly — it picks up where it left off by reading plan state.