/autoworker

name: autoworker
description: >
  Auto-loop execution workflow with quality gates. Use when starting any non-trivial
  implementation task. Provides automatic task decomposition, code implementation,
  testing (L1-L4), and iterative quality gates until completion. Invoke with /autoworker.
user-invocable: true
version: "1.0.0"
author: "phj128"
license: "MIT"
tags: workflow, automation, quality-gates, testing
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, AskUserQuestion, Skill
hooks:
  Stop:
    - hooks:
        - type: command
          command: "sh \"${CLAUDE_SKILL_DIR}/../../scripts/state-persist.sh\""
          timeout: 5
  SessionStart:
    - matcher: "clear"
      hooks:
        - type: command
          command: "sh \"${CLAUDE_SKILL_DIR}/../../scripts/state-recover.sh\""
          timeout: 5

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`