pipeline

Pipeline: The Full AFK Run

Overview

This is the meta-skill. It chains the other afk skills into one run:

0. Backpressure gate   ── check  ──  .afk/config.json exists and is green
1. Align on spec       ── HITL  ──  afk:spec (skipped if approved PRD provided)
2. Slice the ticket    ── HITL gate ─ afk:slice, user approves the cut
3. Implement per slice ── AFK   ──  afk:ralph (TDD loops + spec review)
4. Refactor pass       ── AFK   ──  afk:refactor-pass
5. Agentic QA          ── AFK   ──  afk:qa
6. Review              ── AFK   ──  afk:review
7. PR + handoff        ── HITL  ──  human reviews, business does UAT

After the slice approval in phase 2, the user should not need to answer anything until the PR is open. Front-load every question into phases 1–2.

Invoke each phase's skill via the Skill tool and follow it — this skill defines the order and the gates, not the phase internals.

Phase Gates

Phase 0 — Backpressure. Read .afk/config.json. Missing or red → run afk:setup first. Then re-run the test, typecheck, and lint commands now — the recorded status is from whenever setup last ran, and documented ≠ working. A recorded green that doesn't reproduce is red. HARD GATE: never go AFK in a project where nothing fails loudly — no tests, or tests that don't run, means no backpressure. yellow → tell the user what's weak and let them decide.

If the config declares pipeline.hooks, also verify now that every referenced skill resolves (it appears in your available skills). An unresolvable hook is a config error: stop and tell the user — never silently skip a hook mid-run.

Phase 1 — Spec. If the user provided a spec/PRD: read it critically against the afk:spec template. Gaps in acceptance criteria, error states, or out-of-scope → ask now (this is the last conversation). No spec → run the afk:spec interview. Either way: explicit user approval of the PRD.

Phase 2 — Slice. Run afk:slice. Present the slice list. This approval is the point of no return — say so. Also confirm now: PR target branch, and anything destructive-adjacent (migrations, deletions) the slices imply.

After approval, create a dedicated git worktree for the run (git worktree add ../<repo>-afk-<slug> -b <branch>) and do all AFK work there — the user's checkout stays free while they're away. Record the worktree path in the state file. Skip only if the user says to work in place.

Phases 3–6 — AFK. Run afk:ralph → afk:refactor-pass → afk:qa → afk:review in order. Failure routing:

• QA failures → fix tasks back to afk:ralph, then re-run QA. Cap: 2 cycles, then pause and report.
• Review criticals → fixes via afk:ralph, then re-review. Cap: 2 cycles.
• A slice BLOCKED on requirements → skip it, continue the others (vertical slices survive their siblings), report it in the handoff. Never invent requirements to keep moving.

Phase 7 — Handoff. Push the branch, open a PR. Body: what shipped (per slice), the QA verdict with its per-case PASS/FAIL table inlined, the review verdict with its findings inlined, skipped/blocked items, and where the human should focus. Inline the verdicts, don't link them — qa/ and .afk/pipeline/ are gitignored by default (afk:setup's policy), so the PR body is where the evidence summary lives. Then suggest afk:reflect.

Team Hooks: Repo-Local Phase Extensions

Teams wire their own project skills (e.g. a figma-sync skill living in the repo's .claude/skills/) into the run via .afk/config.json:

{
  "pipeline": {
    "hooks": {
      "after-slice": [{ "skill": "figma-sync", "blocking": true }],
      "after-review": [{ "skill": "notify-slack" }]
    }
  }
}

Boundaries: after-spec, after-slice, after-implement, after-refactor, after-qa, after-review, before-pr. After completing each phase, check for hooks at that boundary and invoke each via the Skill tool, in order. Log every hook run (and its outcome) in the state file.

• blocking: true — anything other than confirmed success pauses the run and reports, exactly like a failed phase: the hook reporting a problem, but also erroring out or not completing. A blocking hook never fails open. Default is non-blocking: log the failure, continue, and list it in the PR handoff.
• Hooks from after-implement onward must run without user input — they fire after the point of no return. A hook that needs answers belongs at after-spec or after-slice; refuse the config otherwise and say why.

State: Resumable by Design

Maintain .afk/pipeline/<slug>.md from phase 0:

# Pipeline: <feature>   branch: <name>   base: <ref>   worktree: <path>
- [x] 0 backpressure: green
- [x] 1 spec: docs/specs/prd-<slug>.md (approved)
- [x] 2 slices: 4 tickets (approved)
- [ ] 3 implement: 2/4 slices done
- [ ] 4 refactor  - [ ] 5 qa  - [ ] 6 review  - [ ] 7 pr
## Log
<one line per significant event: blocked slices, fix cycles, decisions>

Update it after every phase transition. If a session dies mid-run, the next session reads this file plus the ticket checkboxes and resumes exactly where it stopped. Progress lives on disk, never only in conversation memory.

Compaction is survival, not failure: after the conversation gets compacted mid-run, re-read .afk/pipeline/<slug>.md AND re-invoke the current phase's skill before continuing — the summarized version of a skill is not the skill.

Red Flags

Thought	Reality
"The spec phase is done enough, start slicing"	Every ambiguity you carry past phase 2 becomes a wrong guess made at 3 a.m. with nobody to ask.
"Slice 2 is blocked, I'll interpret the requirement myself"	Skip it, ship the rest, report it. Invented requirements are how AFK gets banned at companies.
"QA failed twice, third fix cycle will do it"	Two cycles, then stop and report. Loops that don't converge need a human, not persistence.
"I'll keep the pipeline state in my head"	The session WILL die at slice 3 of 4. Disk or it didn't happen.
"Skip review, QA already passed"	QA proves the user can finish the flow. Review catches the injection in the endpoint QA happily used.
"That team hook failed, but it's not a core phase — move on quietly"	Non-blocking ≠ invisible. Every hook outcome goes in the state-file log and the PR handoff.

Integration

• Chains: afk:setup → afk:spec → afk:slice → afk:ralph → afk:refactor-pass → afk:qa → afk:review.
• Team hooks (repo-local skills at phase boundaries) come from pipeline.hooks in .afk/config.json — declared by the team, documented in afk:setup Part 4.
• After the PR: afk:reflect to bank what the run taught.
• Small tickets don't belong here — the sizing gate in using-afk decides.