From statsclaw
Offers lightweight pipeline for small routine changes (≤3 files, low-risk, e.g., typos, version bumps, lint fixes) via leader-builder-tester-ship, skipping full workflow.
npx claudepluginhub statsclaw/statsclaw --plugin statsclawThis skill uses the workspace's default tool permissions.
A lightweight workflow for small, well-understood changes where the full two-pipeline architecture adds overhead without proportional safety benefit.
Executes ad-hoc tasks like one-file bug fixes, config changes, small refactors, docs updates, and dependency management via direct edits, atomic git commits. Use for 'quick fix', 'ad-hoc task', or /octo:quick.
Executes quick-iteration workflow for small/medium code changes: plan phase, build implementation, optional review, git commit/push. Supports AFK mode and plan confirmation.
Executes trivial one-sentence tasks inline without subagents or planning. For quick fixes like typos, config changes, small refactors under 2 minutes.
Share bugs, ideas, or general feedback.
A lightweight workflow for small, well-understood changes where the full two-pipeline architecture adds overhead without proportional safety benefit.
Leader MUST evaluate every incoming request against these smallness criteria before committing to a full workflow. If ALL of the following are true, leader SHOULD offer the simplified workflow:
| Criterion | Test |
|---|---|
| Few files | Change touches ≤3 files (estimated during planning) |
| Low risk | No algorithmic changes, no numerical methods, no public API changes |
| Clear scope | Request is unambiguous — no uploaded files, no papers, no formulas |
| Well-understood | The fix/change pattern is routine (typo, config tweak, simple bug fix, dependency bump, adding a parameter, formatting) |
| No theoretical work | No mathematical derivation, no statistical methodology, no specification needed |
@export tag.Rbuildignore entriesWhen leader detects a small request, it MUST ask the user before proceeding:
Leader uses AskUserQuestion with:
question: "This looks like a small change (≤3 files, routine pattern). Use simplified workflow?"
options:
- label: "Simplified (faster)"
description: "Skip planner/scriber. Direct: plan → build → validate → ship."
- label: "Full workflow"
description: "Run the complete two-pipeline architecture with all teammates."
If the user chooses "Full workflow" or provides a custom answer suggesting thoroughness, leader proceeds with the standard workflow (1–9).
If the user chooses "Simplified", leader uses Workflow 10.
If leader is uncertain whether the request is small, it MUST ask. The default is always to offer the choice — never silently downgrade to simplified.
leader → builder → tester → shipper?
No planner, no scriber, no reviewer. Leader writes a lightweight spec directly in request.md (extended with acceptance criteria).
CREDENTIALS_VERIFIED → PLANNED → PIPELINES_COMPLETE → REVIEW_PASSED → DONE
Skipped states: SPEC_READY, DOCUMENTED. No comprehension.md, spec.md, test-spec.md, ARCHITECTURE.md, docs.md, or review.md from reviewer.
request.md with:
impact.md as in the full workflow. Status → PLANNED.isolation: "worktree". Builder receives request.md as its spec (no separate spec.md). Builder implements and writes implementation.md. Status → PIPELINES_COMPLETE.request.md. Tester writes audit.md. If BLOCK → respawn builder (max 3). Tester acts as the quality gate (replaces reviewer for simplified workflow).
REVIEW_PASSED.DONE.| Target State | Precondition |
|---|---|
PLANNED | request.md with acceptance criteria AND impact.md exist |
PIPELINES_COMPLETE | implementation.md exists |
REVIEW_PASSED | audit.md exists with verdict PASS |
DONE | shipper.md exists (if ship requested) |
| Component | Reason |
|---|---|
| planner | No theoretical analysis needed for routine changes |
| scriber | No architecture/process-record needed for small changes |
| reviewer | Tester provides sufficient quality gate |
spec.md / test-spec.md | Builder uses request.md directly; tester validates against acceptance criteria |
comprehension.md | No uploaded material to comprehend |
ARCHITECTURE.md | Small change doesn't warrant architecture documentation |
| Log entry | No process record for routine changes |
If at any point during the simplified workflow:
Leader MUST escalate to the full workflow. This means:
SPEC_READY onward using the full pipelinestatus.md to reflect the escalation┌─────────────────────────────────────────────────────────────────────┐
│ StatsClaw Progress (simplified) [2/4] │
│ │
│ [✔] Plan ── [▶] Implement ── [ ] Validate ── [ ] Ship │
│ │
│ ▶ Active: builder implementing changes... │
└─────────────────────────────────────────────────────────────────────┘
See skills/progress-bar/SKILL.md for full progress bar specification.