Auto mode

Auto Mode

In auto mode the user has delegated the plan. The cost of interrupting per-step is high; the cost of barreling through a wrong assumption is also high. The skill is knowing which is which.

Engineering workflows: addyosmani/agent-skills — 24 lifecycle skills installed at ~/.cursor/skills/. Full integration map: reference.md.

Core behavior

1. Work the board top-to-bottom. One in_progress task at a time. Finish (verify, not just "done writing") before advancing.
2. Advance, don't ask. When a task has a clear path, take it. Don't pause for "should I use option A or B" when one is clearly adequate and reversible.
3. Only stop for one of these:
   • Decision the user must make — a real fork with non-reversible consequences, or a product/voice/spec choice that's theirs, not yours.
   • Blocker you can't resolve — env down, missing secret, a dependency that won't install, a test that fails for reasons outside the change.
   • Budget signal — a step has taken unexpectedly long (see cost-transparency); pause to confirm before sinking more.
   • Done with the board — report the final state.
4. Show the board on each turn so the user has ambient progress (see progress-board). The board replaces "asking for permission".

Per-task execution (agent-skills)

For each board item, read and follow the matching addyosmani skill before acting:

1. Route — use using-agent-skills discovery (see reference.md) to pick the workflow.
2. Execute — follow that skill's process steps in order; do not skip verification.
3. Overlay Cam discipline — match-conventions, validate-gate, respect-the-guard, pre-commit-hygiene as applicable.
4. Mark done — only when acceptance criteria + Definition of Done (~/.cursor/skills-references/addyosmani/references/definition-of-done.md) + cheapest validate gate all pass.

Default implementation loop per task (from incremental-implementation + test-driven-development):

acceptance criteria → RED → GREEN → regression → build → commit (scoped) → mark done

Session open (once)

Before the first board item:

0. Agent skills refresh (15-day timer) — read agent-skills-last-refresh in this file's frontmatter. If missing or ≥ agent-skills-refresh-interval-days old, run:

powershell -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\auto-mode\scripts\check-and-refresh.ps1"

On REFRESH_OK, the script updates agent-skills-last-refresh and agent-skills-count in this file. On NOT_DUE, continue silently. On REFRESH_FAILED, surface the error; timestamp is unchanged so the next session retries. Force: add -Force.

1. session-orient — env, disk, blockers
2. correct-assumptions — trust live evidence
3. Spec gate (full-plan auto only) — require SPEC.md, docs/SPEC.md, or spec/*. Missing → spec-driven-development or stop.
4. Clean baseline — git status --porcelain; uncommitted non-planning work → stop unless user confirms.
5. Plan gate — no task list → planning-and-task-breakdown → commit tasks/plan.md + tasks/todo.md.
6. Single approval (if plan was just generated) — unambiguous yes only; then autonomous.

Stop hard on

• Test can't pass / build breaks without obvious fix → debugging-and-error-recovery
• Spec ambiguous or task needs uncovered decision
• High-risk / irreversible: auth, migrations, payments, deletes, deploys, secrets → doubt-driven-development + explicit sign-off

Resume after resolution from the next pending board item.

What is NOT a stopping reason

• "I'm not 100% sure which of two equivalent approaches." — pick one, note it in the board, move on.
• "The user might prefer a different name." — use a reasonable name; rename is cheap.
• "There might be a better library." — use the adequate one; switch later if needed.
• "I should re-confirm the plan." — the plan is the board you were given.

When to exit auto mode early

• You discover the board itself is wrong (a task is impossible, or a missing task blocks everything). Stop, propose the board change, get the user's nod, resume.
• Two tasks contradict each other. Stop, surface the conflict.
• A task requires a spec that doesn't exist. Stop, ask for the spec or propose one.

A classifier gates guarded actions

Auto mode isn't unconditional. A classifier approves or blocks guarded actions — a monitor starting, a deploy, a destructive op. "Allowed by auto mode classifier" is the gate passing; a blocked action is either surfaced to the user or routed to the legitimate path (see respect-the-guard). The classifier is what makes autonomy safe at the action level: the board says what to do, the classifier says whether a given action is safe to do autonomously.

Close-out

When the board is empty:

1. code-review-and-quality on the full change set (or per-task if already done)
2. readiness-report — decisions, verify commands, commit SHAs
3. close-the-loop — arc recap, next action

Pair with

Orchestration (Cam): progress-board, cost-transparency, session-orient, validate-gate, respect-the-guard, readiness-report, close-the-loop

Engineering (agent-skills): using-agent-skills (router), planning-and-task-breakdown, incremental-implementation, test-driven-development, debugging-and-error-recovery, doubt-driven-development

Full routing table: reference.md