go

name	go
description	Full autonomous RIPER cycle in one command. Runs RESEARCH → PLAN → REVIEW → EXECUTE → REVIEW with auto-advance on REVIEW PASS. Stops only on REVIEW FAIL, user-required decisions, or safety guards.
user-invocable	true

/go — Autonomous Full-Cycle Execution

Execute a complete RIPER cycle from a single command. The agent handles research, planning, review, execution, and validation — stopping only when human judgment is required.

Usage

/go <task description>

Examples:

• /go Fix the mobile padding on the pricing page
• /go Add a loading spinner to the essay submission button
• /go Add weekly study streak tracking to the dashboard

Safety Guards

These are hard stops that cannot be bypassed:

Guard	Threshold	What happens
REVIEW FAIL	Any critical/high finding	Stops, reports findings, waits for user direction
Cumulative lines changed	500+ lines modified across all files	Stops, reports scope, waits for user to approve continuing
Scope escalation	During RESEARCH, task is clearly multi-day or architectural	Stops after RESEARCH, reports findings, asks user to confirm scope
User input needed	Implementation requires a decision only the user can make	Stops, asks the specific question, resumes after answer
Commit	Never auto-commits or auto-pushes	Reports completion, waits for Enter C

Execution Protocol

Phase 1: RESEARCH

[MODE: RESEARCH]

1. Read all files relevant to the task description
2. Understand current state, patterns, dependencies
3. Log findings to the board via board_log_activity
4. Scope check: If the task is clearly larger than expected (3+ files, architectural decisions, multi-day), STOP and report:

   "This task is larger than a /go cycle. It touches [X, Y, Z] and requires [architectural decision]. Recommend entering PLAN mode manually. Continue anyway?"

5. If scope is reasonable, auto-advance to PLAN

Phase 2: PLAN

[MODE: PLAN]

1. Create board tasks with assigned_agent and acceptance criteria (per /plan skill protocol)
2. Include a test-runner task and code-reviewer task in the plan
3. Output the implementation checklist
4. Auto-advance to REVIEW (existing behavior)

Phase 3: POST-PLAN REVIEW

[MODE: REVIEW]

1. Invoke /review skill (post-plan validation)
2. If PASS: Auto-advance to EXECUTE (no user approval needed)
3. If NEEDS REVISION: Fix the issues automatically if possible (missing agent, wrong dependency). If the fix requires user judgment, STOP and ask.

Phase 4: EXECUTE

[MODE: EXECUTE]

1. Delegate each task to its assigned_agent per the plan
2. Track cumulative lines changed across all files
3. Line guard: If cumulative lines > 500, STOP:

   "500-line safety cap reached ([N] lines across [M] files). Review changes so far before continuing?"

4. On completion, auto-advance to REVIEW (existing behavior)

Phase 5: POST-EXECUTE REVIEW

[MODE: REVIEW]

1. Invoke /review skill (post-execute validation)
2. If PASS: Report completion summary. Wait for Enter C.

   "/go complete. [summary of what was built]. All reviews passed. Ready for commit (Enter C)."

3. If FAIL: Report findings. Attempt auto-fix for low/medium issues. For critical issues, STOP and ask user.

Task Queue Mode

When used with multiple tasks (future: task chaining from board queue):

/go --queue <project_id>

Pulls READY tasks from the board queue in priority order. After completing each task:

1. Run the full /go cycle above
2. Ping Discord with completion status
3. Pull next task
4. Queue guards: Stop after 15 tasks OR 4 hours OR 500 cumulative lines (whichever first)

What /go Does NOT Do

• Never pushes to main — autonomous execution ONLY commits/pushes to dev. If on main, switch to dev first. This is a hard safety rule for both interactive and Docker worker modes.
• Never commits or pushes without authorization — in interactive mode, waits for explicit Enter C. In worker/Docker mode, auto-commits to dev only.
• Never skips REVIEW gates — both post-plan and post-execute reviews run every time
• Never makes architectural decisions — if the task requires choosing between approaches, it stops and asks
• Never modifies scope — if it discovers related issues, it logs them as separate board tasks but doesn't fix them in this cycle
• Never runs without a board task — creates one immediately at cycle start for tracking

Relationship to RIPER Modes

/go is not a new mode — it's an orchestrator that drives through existing modes automatically. Each phase respects all existing mode rules. The only behavioral change is auto-advance on REVIEW PASS, which eliminates the need for explicit "Enter E" after a passing plan review.

When /go is active, the mode header still shows the current mode (e.g., [MODE: RESEARCH]). The /go context is noted in the board session.