Chapter 22 | Trigger Mode: Semi-manual and Fully Automatic

Chapter 22: Trigger Modes — Semi-Manual + Fully Automatic

Learning Objectives

Enable /dev to flexibly switch between "fully controlled" and "fully hands-off" modes.

Three Levels of Supervision

flowchart TB
    L0["L0: Fully Manual
Ask for every task"] --> Cost0["✓ Extremely High Control
✗ Tedious, Slow"]
    L1["L1: Group-Level Semi-Manual
User specifies group N"] --> Cost1["✓ Critical Checkpoints
✓ MVP-Friendly"]
    L2["L2: Auto-Loop + Notifications
/dev runs fully + Telegram"] --> Cost2["✓ Hands-Off
⚠️ Check notifications for deviations"]
    L3["L3: Cron + Remote
Scheduled runs + Push notifications"] --> Cost3["✓ Fully Autonomous
⚠️ Highest risk of loss of control"]

    style L0 fill:#ffcdd2
    style L1 fill:#fff9c4
    style L2 fill:#c8e6c9
    style L3 fill:#bbdefb

→ Most users switch between L1 and L2. L0 is too tedious, and L3 carries high risks.

Semi-Manual (L1)

You: Implement Group 3
  ↓
main Claude: 
  /dev 3 mode
  Runs the full cycle for Group 3 (DEV → TEST → REVIEW)
  Complete → Waits for you
  
You: Review, OK, do Group 4
  ↓
Loop

Pros: You can intervene to review, adjust, or roll back after each group is completed. Cons: You must be present to monitor.

Fully Automatic (L2)

You: /dev
  ↓
main Claude:
  Starts from the next PENDING group
  Full cycle
  Pass → Next group
  Stuck → Escalate → architect → STUCK.md → Notify + Stop
  
You: (Coffee / Meeting / Sleep)
Your Telegram: ⚠️ Group 7 stuck — see STUCK.md
You: (Back at computer) Read STUCK.md, pick an option, modify, and continue

Pros: Free to do other things. Cons: You won't know if it goes off track — which is why we implemented the ⚠️ marker + Telegram notifications.

Cron Scheduling (L3)

The most aggressive form:

# crontab -e
0 9 * * *   cd /Users/amanda/work/openspec && claude -p "/dev"
0 14 * * *  cd /Users/amanda/work/openspec && claude -p "/dev"
0 21 * * *  cd /Users/amanda/work/openspec && claude -p "/dev"

Automatically runs /dev at 9 AM / 2 PM / 9 PM daily. Combined with a Stop hook pushing to Telegram → you don't need to actively initiate it at all.

Timeline:

sequenceDiagram
    participant Cron as crontab
    participant CC as Claude Code
    participant Agents as Multi-agent
    participant TG as Telegram
    participant You as You

    Note over You: Coffee / Work / Sleep

    loop Daily 09:00
        Cron->>CC: claude -p "/dev"
        CC->>Agents: dispatch a group
        Agents-->>CC: Complete / Stuck
        CC->>TG: ⚠️ marker push
        TG-->>You: 📱 Progress
    end

    loop Daily 14:00
        Cron->>CC: claude -p "/dev"
        Note over Agents: ...continues to progress...
    end

    loop Daily 21:00
        Cron->>CC: claude -p "/dev"
        Note over Agents: ...until all complete or STUCK...
    end

Risk Points:

✗ You discover a crash during the day
✗ Uncontrolled token consumption
✗ Bad code automatically committed

→ L3 must be equipped with: Thresholds (to prevent infinite loops) + Notifications (for timely awareness) + Sandbox (to prevent accidents).

When to Use Which Mode

flowchart TD
    Q1{Project Stage?}
    Q1 -->|MVP / Learning| L1["Semi-Manual"]
    Q1 -->|Stable| Q2{Are you present?}
    Q1 -->|Long-term Maintenance| L3["Cron"]

    Q2 -->|Frequently switching tasks| L2["Fully Automatic + Notifications"]
    Q2 -->|Can monitor| L1

    style L1 fill:#fff9c4
    style L2 fill:#c8e6c9
    style L3 fill:#bbdefb

Switching Techniques

Our /dev command itself supports all modes:

/dev status     # L0: View only, no action
/dev 3          # L1: Run one group, then stop
/dev            # L2: Run until complete or stuck
# (cron) /dev   # L3: Scheduled

→ Same command, same project, switch at will. This is the core design value of dev.md.

How /dev Knows When to Stop in L2

In L2 mode, there must be clear "success / failure" exit conditions:

Success: All groups APPROVED → E2E PASS → "READY TO ARCHIVE" → STOP
Failure: Any group STUCK → architect diagnosed → STOP

→ It won't run indefinitely — this is what dev.md Step 8 "Hard stop conditions" ensures.

Anti-Patterns

❌ Deploying L3 directly for MVP → You won't know if it crashes
❌ L2 without notifications → You won't know if it gets stuck
❌ Sticking to L0 → Loses all advantages of a multi-agent system
❌ Not checking bills after switching to L3 → Surprise at month-end
❌ Different commands for different modes → Cognitive load, not interchangeable

Recommended Path

Week 1 (Learning Phase)       L0 + L1 mixed
                              Manually observe how each group runs
Weeks 2-4 (Stabilization Phase)    L1 primarily
                              Switch to L2 for overnight runs once familiar
Production                    L2, L1 for critical changes
                              L3 reserved for "truly stable, no incidents for 2 months"

What You Can Do Now

• Choose among the 4 supervision levels based on context
• Enable /dev to support multiple trigger modes with a single command
• Understand what "safety features" are essential for L2 / L3