also

Syntax

also: <pass>, <pass>

What it does

Lists finishing passes that run once, in order, only after the goal is met — and are skipped entirely if the loop failed. Think of them as the chores you want done on a green result but don't want cluttering the core cycle: polish the code, run a security scan, update the docs, tidy imports. They run after the done when check has already passed, so they can't be what makes the loop go green — the goal is the goal, and also is the after-work.

Reach for it when a task has a hard, verifiable core plus a few nice-to-haves that don't each deserve their own pass/fail gate. Keeping them out of done when matters: if you fold "and the docs are updated" into the predicate, a docs miss keeps the whole loop red and burns retries on the wrong thing. As an also pass it runs best-effort on success instead. The flip side is the rule of thumb: if a pass needs its own verification — its own test or scan that must pass — it isn't a finishing pass, it's a real stage. Promote it so it gets a proper done when and back-edge. Use also only for work that's fine to run once, unchecked, at the end.

Example

also: polish the code, run a security check, update the docs

loop "add the CSV export endpoint":
  goal: GET /reports.csv streams the report as CSV
  done when "pnpm test reports" passes
  each cycle: plan, then act, then observe
  also: update the API docs, add a changelog entry

Common mistakes

• Putting verifiable work in also. A finishing pass runs once and isn't checked. If the pass must be proven correct, it belongs in done when or its own stage — not here.
• Expecting it to run on failure. also passes are skipped when the loop never met its goal. Don't stash cleanup you need on every exit here — use a hooks: on stop line for that.
• Overloading it with core work. "also: build the feature" isn't a finishing pass — the feature is the goal. Keep also for genuine after-work (polish, docs, scans), and let the goal carry the real deliverable.

Related