archflow-mode · git:20260911.a26fb9f · 2026-09-11 · sha256 a2385b10aab0678a
archflow-mode git:20260911.a26fb9fA
Immutable. This exact content is served forever at /api/v1/blob/a2385b10aab0678a.
---
name: archflow-mode
description: "Use ONLY when the user asks for /archflow-mode or \"archflow mode\". Show or switch ceremony mode: quick (solo, light gates) or full (team, strict gates)"
---
> Arguments are the text after the skill name.
# /archflow-mode — Show or switch the ceremony mode (quick | full)
Argument (`the text the user wrote after the skill name`): optional target mode `quick` or `full`. Empty → show the current mode.
`mode` is a profile over the SAME v2.0 schema, not a fork. It governs how much ceremony is enforced.
Switching is an in-place change — no data rewrite, because the schema is identical in both modes.
## Usage
```
/archflow-mode → show the current mode + what it means
/archflow-mode full → switch to full
/archflow-mode quick → switch to quick
```
## The two modes
| Concern | `quick` (small / solo) | `full` (team / scale) |
|---|---|---|
| Releases | one implicit release; no create/ship ceremony until asked | explicit release pipeline + ship ritual |
| Backlog | stories may live directly in the release | backlog stubs → promote → detailed |
| Readiness gates | **auto-satisfied** (exist but don't block) | enforced **advisory-recorded** (`started_ungated` on override) |
| Approval gates | proceed unless the user stops you | explicit per-phase approval |
| Roles | one lane (solo) | PM / designer / architect / engineer / QA lanes |
## Show current mode (no argument)
Read `mode` from `.archflow/roadmap.yaml` (source of truth; mirrored in `current-phase.yaml`). Print
it and a one-line description. If absent, treat as `quick` and offer to record it.
## Switch mode
1. Set `mode` in `.archflow/roadmap.yaml` AND `.archflow/current-phase.yaml`.
2. **quick → full** (materialize ceremony in place, no data loss):
- If a single implicit release holds everything, keep it as the active release; ensure its file
exists under `.archflow/releases/` and it's registered in `roadmap.yaml → releases`.
- Ensure `backlog.yaml` exists (may be empty); future scope becomes stubs.
- Turn readiness gates ON (advisory-recorded from here on).
3. **full → quick** (collapse ceremony):
- Gates become advisory-off (auto-satisfied). Existing release files and history are left intact.
- Use for a project that over-scoped itself; nothing is deleted.
4. Commit:
```bash
git add .archflow/roadmap.yaml .archflow/current-phase.yaml
git commit -m "chore: switch archflow mode to {quick|full}"
```
## Smart graduation prompt (offered by the framework, never forced)
When a `quick` project shows growth signals, OFFER (do not auto-switch) a move to `full`:
- the user asks for a **second release**, or
- a **second contributor** appears, or
- the project **crosses a size threshold** (story count / file count / repo age).
Prompt: "This project looks like it's outgrowing quick mode (<reason>). Switch to full mode? It adds
explicit releases and role-based design/spec gates. `/archflow-mode full` — or keep going as is."
Remember a decline so it doesn't nag every session.
## Optional agents follow the mode
`optional_agents` in `project-settings.yaml` was pre-selected by the mode at setup: `quick` starts with
nothing automatic, `full` with code review on every story and accessibility review on a project with
a UI.
Switching the mode does NOT rewrite that block silently — it is a user decision, and quietly adding a
step to every story is exactly the kind of surprise that makes people distrust a tool. Offer it:
```
Switching to {mode}. Optional review steps are currently:
{each agent: name -> hook points, or "not automatic"}
{full}: Turn on code review for every story? Accessibility review too?
{quick}: Keep them, or turn them off to keep the loop short?
[Update / Leave as they are]
```