Guides Overview

Use the workflow maps to find your next step. Links in each diagram open the guides for that part of the work.

Standard cycle

Standard work starts differently for new and existing projects. Both entry paths support full completion or finishing after implementation review.

Start with your project

New project · Greenfield

1. Scoper
2. Architect
3. Auditor

Existing project · Brownfield

1. Auditor
2. Scoper
3. Architect

↓ Both continue with

1. Developer Approve the plan, then build
2. Tester Full verification
3. Implementation Reviewer

↓ Follow your cycle's completion policy

Default

Full deliverable

1. Documenter
2. Final Reviewer
3. Synchronizer

↓

Your sign-off decision

Follow the full workflow

By your explicit choice

Finish after implementation review

Implementation Reviewer checks whether the cycle can finish

Every requirement has current evidence. No required work remains.

↓

Your sign-off decision

Choose the shorter finish

Arrows show normal handoffs after the required checks pass. You invoke each role explicitly and decide whether to accept the finished work.

The default policy is FULL_DELIVERABLE. The shorter policy, IMPLEMENTATION_REVIEWED, omits normal documentation, final review, and synchronization. A passing implementation review alone is not enough: Reviewer must also confirm that no required work remains. Required documentation still needs Documenter’s evidence through recovery.

This map shows normal completion. Developer and Tester can also use incremental checkpoints, but full verification is still required before implementation review. Tester and Reviewer need independent chats.

Documentation cycle

Use this route to document existing behavior in a Brownfield project, including creating missing guides. Start with a standalone Documenter assignment while no cycle is active.

Existing behavior · Brownfield only

Invoke Documenter with a standalone documentation assignment

↓ Start with Auditor before documentation edits

1. Auditor Establish existing behavior and project constraints
2. Scoper Define audiences, targets, boundaries, and outcomes
3. Architect Establish existing technical contracts and coverage
4. Documenter Save documentation and checked evidence
5. Final Reviewer Independently assess accuracy and acceptance coverage
6. Synchronizer Reconcile the current documents, assessments, and evidence

↓

Your sign-off decision

Follow the documentation workflow

You invoke each role explicitly. Final Reviewer needs a fresh, independent chat. All six roles must pass their full checks before your sign-off decision, including when the assessed documentation needs no changes.

This cycle covers prose, guides, project guidance outside managed blocks, and ordinary comments or docstrings. It omits Development, Testing, and implementation review. Required behavior, test, configuration, or tooling changes need your decision about scope or a separate implementation cycle.

Expedited cycle

Use expedited work for a clearly defined change in an existing project that needs none of the skipped roles. The agent checks eligibility before the cycle starts.

Eligible existing projects · Brownfield

Normal path

Expedited work

1. Developer Approve the plan, then build and self-check
2. Implementation Reviewer Review the change against your request and the evidence

↓

Your sign-off decision

Start an expedited cycle

If a skipped role is needed

Switch to standard work

The same cycle continues with its request and existing work.

1. Auditor
2. Follow the standard cycle Full deliverable by default

Continue after promotion

You invoke each role from its handoff. Reviewer needs an independent chat. Required checks and corrections must be complete before your sign-off decision.

Expedited work skips separate scoping, architecture, auditing, testing, documentation, final review, and synchronization. Developer’s self-checks do not replace Tester’s independent verification. This path is different from choosing to finish a standard cycle after implementation review, which keeps the earlier standard checks.

Switching an active expedited cycle to standard work is called promotion. An active role can promote when a skipped role is needed. At sign-off, it needs your authorization; asking for rework that needs a skipped role also authorizes the switch. Promotion is one-way for the cycle and preserves unfinished corrections. Choosing the shorter standard finish is a separate decision.

Implementation and testing

In standard work, choose whether Tester runs after all implementation or checks testable outcomes along the way. Both options work for new and existing projects and with either standard completion policy.

Standard work · Both completion policies

Developer prepares the implementation plan

↓

You approve the plan

Review and approve the plan

↓ Choose when Tester runs

Default

Test after implementation

1. Developer Finish all approved implementation and self-checks

Choose when testing happens

By your explicit choice

Test in increments

1. Developer Build and self-check a testable outcome
2. Tester Check that outcome and affected earlier behavior

↺ After a pass, return to Developer

Developer checks the results. Repeat for remaining outcomes.

Alternate between Developer and Tester

↓ Once all implementation and Developer checks are complete

1. Tester Full verification of the final work
2. Implementation Reviewer

Continue with your cycle's completion policy

Follow each handoff in the assigned role's chat. Tester works independently from Developer; Reviewer needs a fresh, independent chat. Passing increments does not replace full verification before implementation review.

When testing happens is separate from how you work with Developer. Either path works with AUTONOMOUS, STEPWISE, or CODE_WITH_ME. Returning from Tester keeps that mode’s permissions and pauses; a passing checkpoint does not grant more coding permission.

You can change when Tester runs during a cycle. Assigned testing and recovery finish their required route before Developer applies the change. If a check finds a problem, follow the corrective handoff before continuing this flow. Expedited work has no separate Tester phase; requesting incremental testing promotes it to standard work.

Change completion policy

For an active standard cycle, you can ask to use the full workflow or finish after implementation review. The allowed route depends on the current step. Changing the policy does not accept the work or remove any requirement.

Active standard cycle · Your explicit choice

Ask to change the completion policy

↓ First, check whether a change is allowed

Recovery and outstanding corrections are finished. Normal documentation, final review, and synchronization have not started.

↓ Follow the route for the current step

At an earlier workflow step

Change either way

At Scoper, Architect, Auditor, Developer, Tester, or implementation Reviewer

1. Choose the full workflow or the shorter finish
2. Keep the current role's assignment Checkpoints and blockers stay in place

Change the policy during earlier work

Two later opportunities

Both need a passing implementation review and full verification that still apply, with no blocking question.

At the Documenter handoff

Choose the shorter finish

Before Documenter starts its normal work, ask to finish after implementation review.

1. Implementation Reviewer Assess whether the cycle can finish under the shorter policy

Only after Reviewer confirms that no required work remains:

↓

Your sign-off decision

Check whether the cycle can finish

Awaiting sign-off on the shorter finish

Return to the full workflow

Ask for the full workflow. Earlier work that still applies does not need to repeat.

1. Documenter
2. Final Reviewer
3. Synchronizer

↓

Your sign-off decision

Return to the full workflow

If the conditions are not met, the policy stays unchanged; the request is not saved to apply later. A policy change does not run a role. Follow the handoff and use an independent Reviewer chat when review is next.

After returning to the full workflow, you can choose the shorter finish again before Documenter starts its normal work. Reviewer must reassess it; an earlier eligible result is not enough. Corrective work by Documenter or Synchronizer does not count as starting their normal phases, but any required corrections must still be finished. Changed work follows its recovery route before a change that needs current review evidence.

Ask a workflow role outside Navigator to make the change. Repeating the current policy leaves the state and records unchanged. For a new cycle, include your choice with the request; it does not carry over from the previous cycle. Finished cycles stay closed, and a policy request alone does not promote expedited work.

Rework and recovery

You can request a change during an active cycle, including while awaiting sign-off. An agent can also find a problem that needs correcting. Both routes keep the same cycle and send the work to the role responsible for it.

Standard work · Both completion policies

Your request

Change the work

Tell the current agent what you want to be different.

Request a change

A problem is found

Correct the work

The agent records the problem and identifies who owns the fix.

Handle review findings

↓ If the correction belongs at another workflow step

1. Save the correction and where to return The agent gives you the responsible role's invocation
2. The responsible role corrects and checks its work It decides which affected work, if any, must run again

↓ Does other work need to repeat?

No

Return directly

The correction is complete. No other work needs to run again before returning.

Yes

Repeat affected work

Follow the saved handoffs through the affected roles. Each repeats its required work and checks before returning.

See how reruns are chosen

↓ After the correction and any required reruns

Return to the saved step: resume its work or recheck sign-off readiness

Follow the saved return route

You invoke each role from its handoff; the agents save the route. A correction within the current step stays there without adding a return route. Finishing recovery does not itself make the cycle ready for sign-off.

If another correction interrupts recovery, the agent keeps the earlier work and return instructions. It handles the newest correction first, then returns to the earlier one. Reviewer reassesses its findings when review resumes; another role cannot close them on Reviewer’s behalf.

Reruns depend on affected work already produced, including implementation and test evidence from unfinished phases. Future work alone does not need a rerun. A specific correction can return before unrelated work is finished, but standard work still needs full Developer and Tester completion before returning to Reviewer. Material changes to Developer’s approved plan need your approval before coding.

The shorter completion policy stays in place during recovery. Required fixes can still go to Documenter, final Reviewer, or Synchronizer without starting their normal phases. If a correction affects the shorter finish’s evidence, implementation Reviewer must reassess it before sign-off readiness. See corrections under the shorter policy.

In expedited work, corrections stay with Developer or implementation Reviewer. If a skipped role is needed, the cycle becomes standard work, starting with Auditor. Unfinished corrections are preserved when the route changes.

Resume interrupted work

Continue from the project checkout that contains the saved STANDARDS files and the work done so far. A new chat does not start a new cycle. You do not need to rebuild the workflow from chat history or edit the state files.

Standard, expedited, or documentation · Saved active cycle

1. Open the checkout with the saved work Keep the STANDARDS files and project changes together
2. Follow the latest handoff If role work is next, invoke the role named in the handoff
3. The agent checks the saved state against the current files Read the request, approvals, reports, blockers, and recovery instructions

Resume from the handoff

↓ Follow what the saved work needs next

Work can proceed

Continue the assigned work

Resume the role's task, checkpoint, or correction

Check which earlier results still apply. Follow any saved recovery route before returning to the normal workflow.

See how each role resumes

Waiting for you

Respond to the pending decision

Your answer or approval

Answer the saved question, review a proposed plan, or decide whether to sign off. The agent records your decision and the next step.

Handle a pending decision

Resuming does not approve a plan, clear a blocker, or accept the work. Changed files may need new checks or corrections before the assignment can continue.

If you do not know which role is next, ask the agent to explain the saved state first. Navigator can help you understand the project, but cannot advance the workflow. Use an independent assessment chat for Tester or Reviewer; each can resume its own eligible chat.

Developer keeps the saved collaboration mode and user style. An unchanged approved plan does not need another approval; a material revision does. The resume guide explains which roles reload a saved user style and when to name it again.

At sign-off, review the current work and choose whether to accept it, request changes, or cancel. A shorter standard cycle can also return to the full workflow. After sign-off or retained cancellation, a new request starts a new cycle instead of reopening the old one. If you changed branches or computers, bring the saved files and project changes with you; see working on more than one branch.

End a cycle and start another

You can accept work when it is ready for sign-off, or ask to cancel an active cycle. Cancellation does not undo project changes. The next request starts a new cycle; it does not reopen the old one.

End the active cycle

Ready for sign-off

Accept the work

You ask to sign off

↓

1. Recheck that completion evidence still applies
2. Cycle signed off · Record kept

Make your sign-off decision

Existing implementation

Cancel and keep the record

For an existing project, or a new project that has gained implementation.

You ask to cancel

↓

Cycle cancelled · Record kept

Project changes remain in place.

Cancel an active cycle

A different cancellation route when greenfield work has no implementation

Greenfield · No implementation created

Preview and approve a reset

After your cancellation request, the agent checks that no implementation exists and previews the reset, including which workflow records it deletes.

↓

You approve the exact reset command

↓

The reset succeeds · Fresh greenfield state, with STANDARDS still installed

Until approval and a successful reset, cancellation is not complete.

Review the reset and what it removes

↓ After sign-off, retained cancellation, or a successful reset

Give your next request

↓ Check the project mode and any work left by cancelled cycles

Cancelled work remains or is uncertain

Start with Auditor

Standard or eligible documentation work

Auditor establishes which changes belong in the project's baseline. Earlier unresolved cancellations still count.

Start after a retained cancellation

No unresolved cancelled work

Use the eligible starting role

For standard work, Scoper starts a new project; Auditor starts work in an existing project. Developer starts an eligible expedited change. A standalone Documenter assignment starts the documentation route with Auditor.

Choose how to start the next cycle

↓ Once the request and mode are allowed

The agent starts a new cycle with a new ID and the policy for this request

Give the new request to its starting role; the agent checks eligibility and sets up the cycle. If the chosen mode cannot handle it, the agent saves the request and asks you to resolve the choice before starting.

Sign-off checks the current mode and completion policy. If the evidence no longer applies, the work follows recovery before it can be accepted. Asking for changes at sign-off is rework within the active cycle, rather than a request to start another.

A greenfield reset removes the saved workflow state, Auditor context, and all cycle records under .standards/docs/. It leaves no cancelled cycle record. Project files outside .standards/, installed skills, hooks, client settings, and user styles remain. Asking to cancel alone does not approve this reset. If you decline or the reset fails, the cycle has not ended. See the cancellation guide for the full procedure.

Each new standard cycle defaults to the full workflow. To use the shorter finish, include that choice in the new request. The earlier cycle’s policy does not carry over. After a successful greenfield reset, the next request starts the first cycle from the fresh state.