Skip to main content
Suspec
workflow / six steps

The loop

Six steps for moving agent work from request to review — the spec is the unit; Pull, Task, and the formal review are optional.

  1. 01Pull
  2. 02Spec
  3. 03Task
  4. 04Run
  5. 05Review
  6. 06Close

six points / six steps

Pull · Spec · Task · Run · Review · Close

note

Each point creates or checks the record the next point needs. Inventory and Change Plan appear for brownfield or structural work.

prep records

  • Inventory maps what already exists.
  • Change Plan records what must survive.
  • Finding carries a reusable lesson forward.
010203040506

workflow / six steps

The loop at a glance.

Six steps around the hexagon; the inscribed triangle is the spine — Spec, Run, Close. Each pass leaves a file the next step can use.

  1. 01
    Pulloptional

    Point the spec's sources at the origin, or capture the raw request verbatim in an intake file first.

  2. 02
    Spec

    State the requirements one per id, each with the check that verifies it. The spec is the unit.

  3. 03
    Taskoptional

    When one spec splits into parallel slices, hand each agent a bounded packet. Most work needs none.

  4. 04
    Run

    The worker implements the spec, runs every check, and pastes the real output beside each requirement.

  5. 05
    Reviewoptional

    A non-implementer checks the evidence per requirement; the full review packet is reserved for substantial changes.

  6. 06
    Close

    Merge, record the decision, save any durable finding, and update the board. Close feeds the next pull.

Close feeds the next Pull — the loop closes

01

Pull

optional

Point the spec's sources at the origin — a ticket, an issue, or self. When you want the raw request kept verbatim, capture it as an intake file first. Intake is optional; the spec is the unit.

pwrcheckevidence

## INTAKE-42 — Add dark mode to marketing site

- Requested by: design

- Scope: homepage and global shell only

- Deadline: launch week

- Links: SPEC-design-system, CHANGE-website-launch

02

Spec

Write requirements one per ID. Add the check for each one.

pwrcheckevidence

### AC-003 — Global shell includes nav and footer

A Shell component renders on every route via app/layout.tsx.

- Nav: logo, links, mobile hamburger below lg.

- Footer: copyright, links, colophon line.

Verify with: npm run build passes; every generated page contains

exactly one <nav> and one <footer>.

03

Task

optional

Only when one spec splits into parallel slices — most work is one spec → one implementer, no task file. When you do split, hand each agent a bounded packet: scope, do-not-change, Verify commands.

pwrcheckevidence

## TASK-shell

Scope: implement Shell component per AC-003.

Do not change: homepage content, analytics.

Verify:

- npm run build passes

- grep finds 1 <nav> and 1 <footer> per page

04

Run

Implement the spec (or the task, when split); paste real evidence per requirement.

pwrcheckevidence

## Execution

$ npm run build

✓ Compiled successfully

Route (app): /, /kitchen-sink

$ grep -o '<nav>' out/index.html | wc -l

1

05

Review

optional

A non-implementer checks evidence per requirement. The formal packet is optional for a small change you verified — the judgment isn't.

pwrcheckevidence

| AC | Result | Evidence |

|-------|-------------|---------------------------|

| AC-003| Pass | 1 nav, 1 footer found |

| AC-009| Unverified | manual resize pending |

06

Close

Merge, record any decision, save durable findings, and update the board.

pwrcheckevidence

## FINDING-tailwind-v4-syntax

When adding custom keyframes in Tailwind v4, use plain CSS

classes rather than escaped utility prefixes to avoid PostCSS

parse errors.

Ready to run it?

Copy the starter kit and write one spec. The same loop handles the next task.

Source: docs/02-basic-workflow.md

Set up your workspace