autoworker

Autoworker: Auto-Loop Execution Workflow

Two paths: Plan Mode (discussion) → /clear → Execution (implementation).

/clear is the boundary. Different paths, completely different behaviors.

Core Principles (Apply Throughout)

The hard standard for "tested": Actually execute commands and observe output. The following do NOT count as tested:

• grep confirming content exists — only confirms it was written, not that it works
• bash -n syntax check — only confirms no syntax errors, not that logic is correct
• Read viewing file content — only confirms text is correct, not that execution results are correct

Counter-intuitive principle: The smaller the change, the easier it is to skip verification — but verification cost is equally low, so there's no reason to skip.

Special note: Instruction file refactoring (SKILL.md / prompt template structural changes) is not a "documentation task" — it is the highest-risk change type (silent failure, affects all subsequent sessions) and must be fully verified.

Path A: Plan Mode (Discussion Phase — With Context)

Trigger: Receive a non-trivial task → EnterPlanMode (not typo fixes or single-line additions).

After entering Plan Mode, immediately invoke autoworker:deep-plan.

autoworker:deep-plan ensures discussion depth through 5 structured phases:

| Phase | What | Depth Gate | |-------|------|-----------| | 1. Motivation Exploration | Continuously ask why, challenge "is this really needed" | Motivation expressible in 1-3 clear sentences | | 2. Assumption Challenge | List implicit assumptions, challenge each one | Each assumption has verification method or flagged risk | | 3. Solution Derivation | Derive solution from motivation, compare alternatives, 4-question review | User makes explicit choice with reasoning | | 4. Acceptance Criteria | Discuss quantitative/behavioral metrics separately | Each metric can become an L4 test case | | 5. Plan Output | Consolidate into plan file (fixed format for subtask-init extraction) | 95% confidence self-check passes |

Forbidden: Skipping deep-plan and jumping straight to a solution. Plan depth determines the quality ceiling of the execution chain.

→ After autoworker:deep-plan completes, call ExitPlanMode. Then /clear to enter execution session.

Path B: Execution Session (After /clear — No Context, Only Plan)

Trigger: After /clear or new session, you see the plan produced by Plan Mode (injected via system context).

Key insight: This plan is the product of thorough discussion with the user in the previous session.

Goals, scope, success criteria, and verification methods have already been confirmed.

No need to ask confirmation questions. The first action is to invoke autoworker:subtask-init to create subtask.md from the plan and start the execution chain.

Do not investigate before creating subtask — investigation is part of assumption verification inside autoworker:subtask-init, not a prerequisite.

Verified failure mode: Claude sees plan → wants to "investigate the current state first" → finishes investigating and starts coding directly → subtask.md never created → no execution chain constraints → no gate-check quality gate.

Execution Chain (Skill Auto-Chaining + Self-Iteration Loop)

Core idea: The execution chain is not linear — it's a self-iteration loop. Write code → test → check → find gaps → update plan → write more code → test again... until quality meets the bar, then deliver to user. Each step is enforced by skill chaining, leaving no room to skip steps.

Execution chain pseudo-code:

autoworker:subtask-init
    Pause old active subtask → Write acceptance criteria + status: active
    → autoworker:subtask-plan

autoworker:subtask-plan
    Multi-subtask positioning (active) → silent failure analysis → acceptance coverage check
    → autoworker:dispatch

while autoworker:dispatch (multi-subtask positioning):  # Re-read active subtask each time
    match state:
        has incomplete Phase  → autoworker:code → autoworker:checkpoint → continue
        has untested layer    → autoworker:test → autoworker:checkpoint → continue
        all tests complete    → autoworker:gate-check (acceptance traceability → PASS/FAIL) → continue
        Gate = FAIL           → autoworker:subtask-update → continue
        Gate = PASS           → status: completed → output completion report → break

| Skill | Responsibility | Chains To | |-------|---------------|-----------| | autoworker:subtask-init | Persist goals + acceptance criteria + assumptions, pause old active, run assumption verification | → autoworker:subtask-plan | | autoworker:subtask-plan | Silent failure analysis + traceability table + L1-L4 verification plan + coverage check + solution self-check | → autoworker:dispatch | | autoworker:dispatch | Multi-subtask positioning (active), read checkbox state, route (sole routing point) | → dynamic | | autoworker:code | Implement one Phase of code | → autoworker:checkpoint | | autoworker:test | Execute one test layer | → autoworker:checkpoint | | autoworker:checkpoint | Record keeping (check off Phase / write test results) | → autoworker:dispatch | | autoworker:gate-check | Acceptance criteria traceability + confidence self-assessment + supplementary verification + self-check. Sets completed on PASS | → autoworker:dispatch | | autoworker:subtask-update | Add/correct subtask items | → autoworker:dispatch |

Hard rules:

• The execution chain uses automatic skill chaining — each skill forcibly invokes the next at the end. Manual step-skipping is neither needed nor allowed.
• After each test layer passes, you must invoke autoworker:checkpoint (invoke the skill, do not manually edit subtask).
• Before autoworker:gate-check PASS, you cannot claim "done".
• Complete all self-executable verification autonomously before returning to user. Do not pause mid-chain to report.
• No manual skill substitution: Do not "fill in the verification plan yourself" instead of autoworker:subtask-plan, do not "write test results yourself" instead of autoworker:checkpoint, do not "route yourself" instead of autoworker:dispatch.
• No chain interruption for context concerns: After entering Path B, do not suggest /clear, do not say "context is getting full, suggest breaking up", do not stop the execution chain citing context. The 1M context has automatic compression — context management is the system's job, not yours. Your sole responsibility is to run the execution chain until gate-check PASS. (Note: In interactive discussion, suggesting to split genuinely large tasks is reasonable — this rule only constrains the execution chain.)

Testing: 4 Progressive Layers

| Layer | What It Verifies | Example | |-------|-----------------|---------| | L1 Build | Compilation/type check passes | pnpm build, bash -n *.sh, python -m py_compile | | L2 Unit | Individual function/module logic is correct | Specific function call + expected output | | L3 Chain | Multi-module collaboration, correct data flow | Feed downstream with actual upstream output, no hand-written simplified data | | L4 End-to-End | Complete user path, from input to final effect | Simulate actual user operation path, no skipping steps |

L4 is mandatory. L2/L3 can be skipped but must state justification.

Mid-Course Correction Protocol (When User Gives Feedback During Execution)

Trigger: User says "change to X", "also need to consider Y", "wrong direction", etc.

Do NOT immediately Edit/Write. First confirm:

1. Restate understanding: "You mean change A to B, because C?"
2. Ask scope: "Just this one place or all similar places?"
3. Ask reason (if not obvious): Different reasons may lead to completely different implementations.
4. After confirmation → update subtask.md → then modify code.

High-frequency failure mode: User s