How a sprint works

Seven phases. Each one saves an artifact. The next one reads it. Context flows from start to finish.

The flow

/think  -->  /nano  -->  build  -->  /review  -->  /security  -->  /qa  -->  /ship
  |           |           |           |             |               |        |
  v           v           v           v             v               v        v
think.json  plan.json  (code)   review.json   security.json    qa.json  ship.json

Each phase produces a JSON artifact in .nanostack/. The next phase reads previous artifacts to understand what happened before it. No phase works in isolation.

Why this order

The sequence is not arbitrary. Each phase depends on the output of the one before it.

  • /think defines the problem. Without it, /nano plans a solution to the wrong thing.
  • /nano lists every file and step. Without it, the build has no scope boundary.
  • /review catches structural bugs. It needs the actual code to exist first.
  • /security audits the implementation against OWASP and STRIDE before QA. Catching auth, secret, and injection issues early avoids re-running browser tests after a security fix.
  • /qa tests from a user perspective. It runs after review and security so it exercises the version that already passed structural and security checks.
  • /ship creates the PR. It reads every previous artifact to generate the sprint journal.

What connects them

JSON artifacts in .nanostack/. Each file follows a strict schema. The agent reads these files automatically at the start of each phase.

.nanostack/
  think.json       # scope mode, value prop, risks
  plan.json        # files, steps, size classification
  review.json      # findings, auto-fixes, pass results
  security.json    # vulnerabilities, grade, threat model
  qa.json          # test results, bugs found, coverage
  ship.json        # PR url, journal, CI status

The artifacts also enable multi-agent coordination. When /conductor splits work across agents, each agent reads shared artifacts to avoid conflicts.

What stops the sprint

Not every sprint reaches /ship. The pipeline halts when it hits a blocking condition:

  • Blocking issues in /review that cannot be auto-fixed and require human judgment.
  • Critical or high-severity vulnerabilities found by /security.
  • Test failure rate above the WTF threshold in /qa (more than 20% of tests show unexpected behavior).
  • Token budget exceeded. Each phase tracks consumption. If the remaining budget cannot cover the next phase, the sprint stops with a summary of what was completed.
  • Circuit breaker. If an agent enters a fix-break-fix loop (three consecutive failed attempts on the same issue), the sprint halts and reports the stuck point.

When a sprint stops, every artifact produced so far is preserved. You can resume from the last successful phase or start fresh.

PreviousWorkflowsNext/think