next

/next — single-step project loop

Advance ONE task to completion, then stop and report. Do not chain tasks unless the user explicitly says "keep going" or auto-mode is on.

0. Resolve context

• The current repo's CLAUDE.md declares Vault: (absolute path) and Project: (slug). Read them. If either is missing, stop and ask.
• Paths: STATE=$VAULT/wiki/hot.md · INDEX=$VAULT/wiki/index.md · LOG=$VAULT/wiki/log.md · TASKS=$VAULT/wiki/projects/$PROJECT/tasks.md

1. Perceive

• Read hot.md for orientation ONLY. It is lossy (~500 words) — never treat it as task state.
• Read tasks.md. This is the single source of truth for what to do.
• Parse entries: id / title / status / repo / acceptance / depends_on / notes.

2. Decide

• Candidate = first entry with status: todo whose every depends_on id is status: done, scoped to repo == this repo (or unscoped).
• If none: report why (empty queue / all blocked / deps unmet) and stop.
• If the task is non-trivial or irreversible (schema, auth, infra, data-loss surface), run the /think loop first and capture the decision in the task's notes before acting.

3. Claim

• Set the chosen task to status: doing, write tasks.md. (Respect scripts/wiki-lock.sh if the vault ships it.)
• This keeps the in-flight task visible if the session dies mid-run.

4. Act

• Execute in THIS repo: write code, run the build/test commands the repo's CLAUDE.md defines.
• Do the smallest change that satisfies acceptance. Do not gold-plate beyond it.

5. Verify against acceptance

• Mark done ONLY if acceptance is demonstrably met (test/command output, not assumption).
• If it cannot be met: set status: blocked, write a one-line reason in notes, stop. Never mark done on a guess.

6. Record

• Update the task (status: done or blocked; append outcome to notes).
• Append a dated line to log.md: YYYY-MM-DD T-NNN <title> -> done|blocked (<one-line outcome>).
• If the work yielded reusable knowledge (a decision, a gotcha, a config), file it into the vault via the wiki skill / /save so it compounds. Skip for trivial mechanical tasks.
• Run update hot cache so the next session starts oriented.

7. Report

• One short summary: which task, what changed, done vs blocked, and what's next in the queue.

Guardrails

• Durable state lives in tasks.md and log.md — never hot.md.
• Keep work local. The web-reaching paths are /autoresearch and /clip — run them deliberately, and never inside a repo whose vault project holds customer/tenant data. /next itself does not egress.
• One writer at a time on tasks.md; if a write races, re-read and retry.
• The vault commits itself via its own auto-commit hook — don't double-commit it. Commit the CODE repo per its own conventions.