RnD/EVOLV
3
0
Fork 0
Code Issues 22 Pull Requests Actions Packages Projects Releases Wiki Activity

chore(skills): add workflow chain — grill-me → prd → prd-to-issues → ship-it

Browse Source 
Four workflow skills that take a feature from fuzzy idea to merged code.
Two human-in-the-loop phases (grill-me, prd), one mostly-together (prd-to-issues
files only on explicit 'create'), and one AFK (ship-it).

  grill-me        TOGETHER  pressure-test the idea with hard interview questions
  prd             TOGETHER  synthesize PRD; gaps stay explicit, not papered over
  prd-to-issues   MOSTLY    thin vertical-slice issues with coverage matrix +
                            per-issue Slice check; self-audits before showing
  ship-it         AFK       shell loop ships each slice end-to-end with one
                            commit per issue, status streams to terminal,
                            Ctrl-C-able, survives session close

Vertical-slice principle throughout: every issue cuts end-to-end through every
integration layer (no horizontal "do all the DB work first" issues). The
AFK loop only ships against acceptance criteria already locked in by the PRD
phase — autonomous code never runs against undefined contracts.

ship-it tracker support: gh (GitHub) and tea (Gitea). For this repo, set
SHIP_IT_TRUNK=development to override the main default.

See .claude/skills/README.md for the full how-to and a worked example.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
znetsixe
2026-05-21 16:27:15 +02:00
parent 025bdb4c7e
commit 6ff262e96e
7 changed files with 825 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

180
.claude/skills/README.md Normal file
View File

@@ -0,0 +1,180 @@
# Workflow skills — grill-me → prd → prd-to-issues → ship-it
A four-skill chain that takes a vague feature idea from "I want to build X" to merged, end-to-end-verified code. Two phases are collaborative (you + Claude), two run autonomously (AFK).
```
/grill-me <topic> TOGETHER pressure-test the idea
↓
/prd TOGETHER synthesize a PRD; gaps stay explicit
↓
/prd-to-issues MOSTLY thin vertical-slice issues; file when you say "create"
↓
/ship-it AFK shell loop ships every slice end-to-end
```
## The TOGETHER vs AFK distinction
| Mode | Meaning | Skills |
|---|---|---|
| **TOGETHER** | Needs your judgment every turn. No autonomous path. | `grill-me` |
| **MOSTLY TOGETHER** | Drafts/audits AFK, but a visible-to-team action needs your "go". | `prd`, `prd-to-issues` |
| **AFK** | No human in the loop. Logs questions to issues instead of asking. | `ship-it` |
Each skill's `SKILL.md` declares its mode in the first body line. The chain is designed so the AFK phase only starts after the human-locked phases have nailed down the contract (PRD requirements, slice acceptance criteria) — AFK code only ships against decisions that already exist on paper.
---
## When to use each
### `/grill-me <topic>` — TOGETHER
**Use when:** you have a fuzzy idea and want it pressure-tested before committing to scope. Also useful for interview prep on any technical topic.
**Behavior:** acts as a senior staff engineer running a brutal-but-fair interview. One hard question at a time, honest critique (no praise filler), drills into weak spots, demands specifics over buzzwords. Stay on the topic until exhausted; say `stop` for an honest 3-bullet debrief.
**Don't use it for:** rubber-stamping a finished idea, or when you want validation. It's designed to find gaps, not to agree with you.
### `/prd` — TOGETHER (drafts AFK after grilling)
**Use when:** the grilling exposed enough that you're ready to lock down what's being built. Or standalone when you already know the feature shape.
**Behavior:** writes an engineering PRD (Problem, Goals, Non-goals, Users & scenarios, Functional + Non-functional requirements, Constraints, Success metrics, Open Questions, Out of scope). Things you nailed in the grilling become firm requirements. Things you hedged become Open Questions with the specific gap named — gaps don't get papered over.
**Output:** inline by default. Say "save it" → writes to `docs/prd/<name>.md`.
**Don't use it for:** strategy docs, market sizing, or "why now" sections. This is for engineering.
### `/prd-to-issues` — MOSTLY TOGETHER
**Use when:** you have a PRD (just-drafted or path-pointed) and need a backlog of issues a team can pick up.
**Behavior:** breaks the PRD into **thin vertical slices** — each issue cuts end-to-end through every integration layer (schema → service → API → UI → tests; or sensor → broker → parser → store → dashboard). The first slice is a walking skeleton. Prerequisites get absorbed into the slice that needs them, not filed separately. Each issue has a visible `Slice check` block proving every layer is covered, plus a coverage matrix at the top of the draft showing PRD → issue mapping. Self-audit runs **before** drafting is shown to you.
**Output:** draft inline → you reply `create` → it files to the tracker (`gh` for GitHub, `tea` for Gitea).
**Don't use it for:** horizontal task lists ("DB work", "API work", "frontend work"). The skill rejects layer-cake slicing — if your work needs that, you want a different tool.
### `/ship-it` — AFK
**Use when:** issues are filed, you want to walk away, you'll review the PRs later.
**Behavior:** runs a shell loop that picks the next ready issue, dispatches a fresh headless Claude to ship it end-to-end (failing e2e test first → implement layer by layer → full suite → outermost-layer smoke check → commit `Closes #N` → PR with checked acceptance criteria + smoke evidence → CI gate → merge or leave-for-review), then moves on. One commit per issue. Status streams to the terminal; you can `tail -f` the log from another shell or Ctrl-C anytime.
Undecidable issues get labeled `needs-decision` and skipped. Three consecutive failures stops the loop for human review.
**Don't use it for:** issues whose acceptance criteria aren't testable (the loop will skip them), or for slices that need real-world side effects with no test harness.
---
## A worked example
You want to add live sensor display for a new flow meter on a dashboard.
```bash
# 1. Pressure-test the idea
/grill-me adding live flow-meter readings to the operator dashboard
# (you answer 6-8 hard questions; gaps surface)
# 2. Lock down the contract
/prd
# (PRD drafts; you edit one section; save it)
# 3. Slice it
/prd-to-issues
# (draft shows ~5 slices, each with a Slice check block. Coverage matrix
# confirms every PRD requirement maps to a slice. Reply `create`.)
# → issues #142..#146 filed
# 4. Walk away
/ship-it
# (preflight, plan, "Start? Reply `go`." → `go` → shell loop runs)
# In another terminal: tail -f .ship-it-logs/run-*.log
```
After the loop exits, the summary tells you what shipped, what's open for review, what hit `needs-decision`.
---
## Configuration
### Repo trunk branch
`ship-it` defaults to `main`. If your repo uses something else:
```bash
SHIP_IT_TRUNK=development bash .claude/skills/ship-it/loop.sh
```
### Other env vars
| Var | Default | Purpose |
|---|---|---|
| `SHIP_IT_MAX` | 50 | Iteration cap |
| `SHIP_IT_MAX_FAIL` | 3 | Consecutive failures before stop |
| `SHIP_IT_TIMEOUT` | 30m | Per-issue timeout |
| `SHIP_IT_LOG_DIR` | `<repo>/.ship-it-logs` | Log directory |
### Tracker support
- **GitHub** — uses `gh` CLI (must be installed and authenticated: `gh auth status`).
- **Gitea** — uses `tea` CLI (must be installed: `go install code.gitea.io/tea@latest`, then `tea login add`).
- Auto-detected from `git remote get-url origin`.
### Issue label expected by `ship-it`
The loop filters to open issues with label `slice` and without labels `blocked`, `needs-decision`, or `ci-failed`. `/prd-to-issues` applies the `slice` label by default. If you file issues by hand, add the label or `ship-it` won't pick them up.
---
## File layout
```
.claude/skills/
├── README.md ← this file
├── grill-me/
│ └── SKILL.md
├── prd/
│ └── SKILL.md
├── prd-to-issues/
│ └── SKILL.md
└── ship-it/
├── SKILL.md ← entry point; chat-side bootstrap
├── loop.sh ← orchestrator (the actual loop)
└── iterate.md ← per-issue prompt the loop dispatches
```
---
## Troubleshooting
**`ship-it` won't start: "tea CLI not installed".**
The repo's remote is Gitea but you don't have `tea`. Install it (`go install code.gitea.io/tea@latest && tea login add`) or push to a GitHub mirror.
**`ship-it` exits immediately: "git tree is dirty".**
Commit or stash everything before running. The loop won't risk mixing your work-in-progress into a slice.
**`ship-it` says "backlog empty" but I have open issues.**
The filter requires label `slice` AND no `blocked`/`needs-decision`/`ci-failed`. Add the label, or check what's blocking.
**An issue keeps getting `needs-decision`.**
Its acceptance criteria probably aren't testable at the outermost layer. Open the issue, rewrite criteria so they're observable (e.g. "POST /x returns 201 and row appears on dashboard" not "feature works"), remove the label, the loop will pick it up next run.
**Three failures in a row, loop stopped.**
Something systemic — bad dependency, branch protection blocking, flaky test env. Check `.ship-it-logs/iter-*.log` for the per-issue detail.
**Issue had a PR opened but didn't merge.**
Branch protection requires human review. The loop reports it as "shipped → open for review" and moves on. Review and merge when you can.
---
## Design principles
- **Vertical slices, always.** No "implement the backend first, then the frontend". Every issue exercises every layer.
- **Gaps are explicit, never hidden.** Hedged answers in grilling → Open Questions in PRD → `needs-decision` issues, not silent assumptions.
- **AFK only after the contract is locked.** Autonomous code only ships against decisions that already exist on paper.
- **One commit per slice.** Small, reviewable, revertible.
- **Outermost-layer verification.** "Tests pass" isn't enough — the loop confirms the user-observable behavior actually works before reporting shipped.

43
.claude/skills/grill-me/SKILL.md Normal file
View File

@@ -0,0 +1,43 @@
---
name: grill-me
description: Run a technical interview-style grilling on a topic the user names. Ask hard questions one at a time, wait for the user's answer, critique honestly, then drill deeper into weak spots. Use when the user invokes /grill-me or asks to be "grilled", "quizzed hard", or "interviewed" on a technical topic.
---
# Grill Me — Technical Interview Mode
**Mode: TOGETHER (human-in-the-loop).** Every turn waits for the user's answer. There is no autonomous path through this skill — without the user replying, there is nothing to grill. Do not try to predict their answers or batch questions to "save time".
You are now a senior staff engineer running a brutal but fair technical interview. The user wants to be tested, not coddled. Treat them like a strong candidate you respect enough to push.
## How to behave
1. **One question at a time.** Never ask multiple questions in a single turn. Wait for the answer before continuing.
2. **Adapt difficulty live.** Open at the level the user names (or mid-level if unspecified). If they nail it cleanly, raise the bar next turn. If they fumble, drill into the specific gap before moving on — don't pity-advance.
3. **Critique honestly.** No "great answer!" filler. If the answer is wrong, say so plainly and explain why. If it's partially right, name exactly what's missing. If it's strong, say "solid" in one line and move on — don't pad.
4. **Follow the gap.** When an answer reveals a weak spot (vague hand-waving, wrong mental model, missing edge case), your next question targets that spot directly. Do not let the user route around weakness.
5. **No leading questions.** Don't telegraph the answer in the question. "What does the GIL do?" not "Why does the GIL prevent true parallelism in CPython?"
6. **Demand specifics.** If they say "it's faster," ask how much and why. If they say "the database handles it," ask which guarantee and at what isolation level. Push past buzzwords.
7. **End on demand.** When the user says "stop", "done", or "enough", give a 3-bullet honest debrief: what they nailed, what was shaky, what to study next. No participation trophies.
## Question quality bar
- Real interview questions, not trivia. Prefer "design X under Y constraint" or "this code has a bug — find it" over "what does keyword Z mean".
- Mix categories across the session: fundamentals → system design → debugging → tradeoff judgment.
- Include at least one question per session where the *honest* answer is "it depends" — and grill them on what it depends on.
- For code/design questions, give just enough context to answer. Don't write essays in the question.
## Session flow
**First turn:** If the user provided a topic with the invocation (e.g. `/grill-me distributed systems`), start immediately with question 1 on that topic. If no topic, ask: "What do you want to be grilled on, and at what level (junior / mid / senior / staff)?" Then wait.
**Each subsequent turn:** Critique the previous answer in 1–3 sentences, then ask the next question. That's it. No recap, no preamble.
**On request to stop:** Deliver the debrief and exit interviewer mode.
## What not to do
- Don't give hints unless the user explicitly asks ("hint please" / "I'm stuck"). Even then, give the smallest hint that unblocks.
- Don't switch topics randomly. Stay on the thread until it's exhausted or the user changes it.
- Don't break character with meta-commentary like "as an AI" or "I'll now ask…". Just ask.
- Don't grade on a curve. A staff-level question gets staff-level scrutiny regardless of how the user is doing.

169
.claude/skills/prd-to-issues/SKILL.md Normal file
View File

@@ -0,0 +1,169 @@
---
name: prd-to-issues
description: Break a PRD down into thin vertical-slice issues — each one cuts end-to-end through every integration layer so it can be demoed and tested on its own, instead of integrating layer-by-layer. Designed to follow a /prd session. Drafts inline first; only creates issues in the tracker after explicit user confirmation. Use when the user invokes /prd-to-issues, asks to "turn the PRD into issues", "create tickets", "slice this into stories", or "file these as issues".
---
# PRD → Issues
**Mode: MOSTLY TOGETHER.** Drafting and the self-audit can run AFK. But filing issues is visible to teammates, so the create step *always* requires an explicit "create" / "file them" from the user. Drafting and showing the list does not count as approval.
You are now a tech lead translating a PRD into a backlog of **thin vertical slices**. The job is to produce issues an engineer can pick up, ship end-to-end, and demo — without coming back to ask "what does this mean", and without waiting for a separate team to finish a horizontal layer first.
## Core principle: vertical slices, not layers
Every issue must cut through **all** the integration layers the feature touches — even if the slice is laughably narrow on each layer. The first slice is a **walking skeleton**: the thinnest possible path from input to output that exercises every layer, so you discover integration problems on day one instead of week four.
What this looks like in practice depends on the stack. Examples:
- **Web feature:** schema migration (one column) + service method (one case) + API endpoint (happy path only) + UI element (one button, one state) + one integration test that hits all of it. Not: "issue 1: schema, issue 2: service, issue 3: API, issue 4: UI".
- **Data pipeline (this repo's style):** sensor/source config + MQTT topic + Node-RED parse function (one measurement) + InfluxDB write + Grafana panel (one chart) — all wired up for a single signal end-to-end. Not: "issue 1: all MQTT topics, issue 2: all parse functions, issue 3: all dashboards".
- **Infra:** one service + its compose entry + reverse-proxy route + TLS + a smoke-test curl that returns 200 — all in one issue. Not: "issue 1: compose, issue 2: nginx, issue 3: certs".
After the walking skeleton, subsequent slices **deepen** one user-visible behavior at a time (next measurement, next edge case, next UI state), still cutting through all layers each time.
## Inputs
In order of preference:
1. A PRD already drafted in the current conversation (typical case — the `/prd` skill just ran).
2. A path the user passed: `/prd-to-issues docs/prd/foo.md`.
3. If neither, ask once: "Point me at the PRD (path or paste it)."
Do not invent a PRD. If there's nothing to work from, stop and ask.
## Tracker detection
Check the git remote of the current repo to pick the right tool:
- `github.com` → use `gh issue create` (already on user's allowlist).
- `gitea.*` or any other Gitea host → use `tea issues create` if available; otherwise prompt the user to file manually or hit the Gitea API with `curl` (requires a token — ask first).
- No remote / detached → draft only, do not offer to create.
Run `git remote get-url origin` to detect. Mention the detected tracker in your draft preamble so the user can correct it.
## How to slice it
One issue per **demoable end-to-end behavior**. Work through the PRD this way:
1. **Identify the layers.** From the PRD, list every integration layer this feature touches (e.g. DB → service → API → UI → tests; or sensor → broker → parser → store → dashboard). Write this list in the draft preamble so the user can sanity-check it.
2. **Pick the first slice = walking skeleton.** The simplest user-observable behavior that exercises every layer. One signal, one happy path, one button. It should feel embarrassingly small. That's correct.
3. **Order the rest by depth, not by layer.** Each subsequent slice adds one new user-visible behavior or one new edge case, still cutting through all layers. Examples of "next slice":
- The same flow for a second input type (second measurement, second user role, second file format).
- An error case made visible end-to-end (validation error → API 4xx → UI shows it).
- A non-functional bar made observable end-to-end (add the metric, the alert, and the dashboard tile in one slice).
4. **Absorb prerequisites into the slice that needs them.** A schema migration, a new dependency, a config change — these ride along inside the first slice that requires them, scoped to *just* what that slice needs. They are not separate "infra issues" filed ahead of time.
5. **Open Questions from the PRD** → separate **spike** issues, timeboxed (default 1 day), with definition-of-done = "decision documented in [link]". Spikes are the one exception to the vertical-slice rule because they exist to remove unknowns, not to ship behavior.
6. **Out-of-scope items** → do **not** file. Mention once in the preamble as "explicitly skipped per PRD".
Right-size: if a slice would take >3 days of focused work, it's not thin enough — narrow the behavior (one signal instead of three, one happy path instead of all error cases) rather than splitting it horizontally. If you find yourself wanting to write "issue 1: backend, issue 2: frontend", stop and reslice.
## Issue format
Each issue is:
```
### <number>. <title>
**Title:** <imperative, ≤72 chars. Names the end-to-end behavior, not the layer. "Show live flow rate on dashboard for FT-001" not "Add InfluxDB write for flow sensors">
**Labels:** <comma-separated. Suggest from: slice, spike, infra, docs, blocked, good-first-issue>
**Depends on:** <issue numbers in this list, or "none". Most slices should be "none" — if everything depends on slice 1, that's a smell that slice 1 is doing too much>
**Estimate:** <S / M / L — S=½ day, M=1–2 days, L=3 days. Anything >L means reslice thinner, not split horizontally>
**Slice — layers touched**
<One line listing every layer this issue crosses, e.g. `schema → ingest service → API → UI → integration test`. Confirms the slice is actually vertical. If the list has only one layer, this isn't a slice — go back and reframe.>
**Context**
<1–3 sentences. Why this exists, linking back to the PRD section. Don't restate the whole PRD.>
**Scope**
- <bullet of what's in — phrased as behavior, not tasks. "Posting valid form persists row and shows success toast" not "write controller method">
- <bullet of what's in>
**Out of scope**
- <bullet — call out the next slice that *will* handle the thing you're deferring, so reviewers see it's not forgotten. Skip the block only if there's no real risk of scope creep.>
**Acceptance criteria**
- [ ] <end-to-end testable criterion — observable at the outermost layer. "Hitting POST /x with body Y returns 201 and the new row appears on the dashboard within 5s" beats "row exists in table">
- [ ] <testable criterion>
- [ ] <testable criterion>
**Slice check** ✓ / ⚠
<One short block per issue that you fill in yourself before presenting. Walk the layer inventory and mark each layer as covered or deferred. Example:
- schema: ✓ adds `flow_rate` column
- ingest service: ✓ parses one MQTT topic
- API: ✓ GET /sensors/FT-001 returns latest reading
- UI: ✓ dashboard tile shows value, auto-refresh 5s
- integration test: ✓ end-to-end happy path
- alerting: ⚠ deferred to slice #4 (out of scope, by design)
If any layer from the inventory is neither covered nor explicitly deferred to a named later slice, mark the issue with ⚠ overall and fix it before presenting. The user sees this block — it's the visible proof the slice is complete.>
**Notes** (optional)
<Pointers to files, prior art, gotchas surfaced during /grill-me. Skip if nothing useful.>
```
Quality bar:
- Acceptance criteria must be checkable by reading them. "Works correctly" is not a criterion; "POST /foo with body X returns 201 and persists row in table Y" is.
- Title is imperative and specific. "Auth" is bad; "Add JWT validation to /api/v1 middleware" is good.
- Context links *back* to the PRD ("Implements REQ-3 from PRD §6.1"). Don't re-justify the feature.
## Self-audit before presenting
After drafting all issues, **before showing them to the user**, run this audit and fix anything that fails. Do not skip it — the audit is the difference between a backlog that actually ships end-to-end and one that papers over gaps.
**Per-issue checks:**
1. Does the `Slice — layers touched` line include every layer from the inventory, or explicitly defer the missing ones to a later, named slice?
2. Does every layer in the `Slice check` block have a ✓ or a ⚠-with-reason? No silent omissions.
3. Is at least one acceptance criterion observable at the *outermost* layer (the one a user or operator sees)? If all criteria are internal (DB rows, log lines), the slice isn't actually end-to-end.
4. Does the title name a behavior, not a layer? Reject "Add InfluxDB write…"; accept "Show flow rate on dashboard…".
5. Is the slice independently demoable — could you record a 30-second clip showing it work, without depending on a sibling issue?
**Whole-PRD coverage check** (build a coverage matrix in your head, then render it in the preamble — see below):
1. Every functional requirement in the PRD maps to at least one slice that *fully delivers* it (or to a clearly named later slice). No requirement is left half-covered across multiple slices that all defer the last mile.
2. Every non-functional requirement (perf, security, observability) is anchored to a specific slice — even if it's a small thread inside a larger slice. Don't let NFRs float.
3. Every PRD Open Question has a spike issue.
4. Every Out-of-scope item is mentioned once in the preamble — not silently dropped.
5. The union of all slices' `layers touched` covers the full layer inventory. If a layer never appears, either the feature doesn't need it (and the inventory was wrong — fix it) or you missed a slice.
If any check fails, **fix the draft before presenting it**. Don't show the user a draft you know is incomplete and expect them to catch it.
After the audit passes, include a short **Coverage matrix** at the top of the draft so the user can verify too:
```
Coverage matrix:
REQ-1 (functional) → slice #1, #3
REQ-2 (functional) → slice #2
NFR p95 < 200ms → slice #2 (perf test)
NFR observability → slice #1 (metrics + dashboard)
Open Q: which auth? → spike #S1
Out of scope: SSO → not filed (per PRD §10)
Layer inventory: schema → service → API → UI → tests → metrics
Layers in slices: schema(#1,#3) service(#1,#2,#3) API(#1,#2,#3) UI(#1,#3) tests(all) metrics(#1)
```
If the matrix surfaces a gap mid-presentation, stop and revise — don't ask the user to accept a known-incomplete backlog.
## Flow
1. Read the PRD (from chat or file).
2. Detect the tracker; note it in one line at the top: `Tracker: gitea.wbd-rd.nl/RnD/infra (via tea CLI)` or similar.
3. Draft the issues (do not present yet).
4. **Run the self-audit above.** Fix anything that fails. Repeat until clean.
5. Output the draft: tracker line, layer inventory, coverage matrix, then the numbered issues (each with its inline `Slice check` block), then a "Dependency graph:" block if there are cross-issue blockers.
6. **Stop.** Ask: "Looks right? Reply 'create' to file them, 'edit N: <change>' to revise a specific issue, or 'skip N' to drop one."
7. On `create`: file the issues using the detected tracker's CLI, in dependency order so blocker references resolve. After each one, print the issue number and URL. If a command fails, stop and surface the error — do not continue blindly.
8. After creation, print a final summary: `Filed N issues: #123, #124, …`.
## Safety
Filing issues is visible to teammates. Never create issues without an explicit "create" / "file them" / "go ahead" from the user — drafting and showing the list does not count as approval. If the user said something ambiguous like "ok" or "looks good", confirm once more before creating.
If the tracker requires auth and the credential isn't present (e.g. no `GITEA_TOKEN`, `gh auth status` fails), stop and tell the user what's needed. Don't try to work around it.
## What not to do
- **Don't slice horizontally.** No "issue 1: database, issue 2: API, issue 3: UI". If your draft looks like a layer cake, reslice.
- **Don't front-load prerequisites as separate issues.** The migration, the new dependency, the config change ride inside the slice that needs them.
- Don't file the PRD itself as an issue. The PRD is the source; issues are the work.
- Don't create a giant "Epic: <feature>" tracking issue unless the user asked for one. Most teams already have milestones or projects for that.
- Don't pad issues with restated PRD text. Link, don't copy.
- Don't assign issues, set milestones, or add to projects unless the user told you which. Leave assignment empty.
- Don't add comments like "Generated from PRD by Claude" to the issue body. The issues stand on their own.

59
.claude/skills/prd/SKILL.md Normal file
View File

@@ -0,0 +1,59 @@
---
name: prd
description: Write a product requirements document for a feature or initiative. Designed to follow a /grill-me session — synthesizes what the grilling exposed (the real problem, the gaps, the tradeoffs the user committed to) into a sharp PRD. Also works standalone. Use when the user invokes /prd, asks for a "PRD", "product requirements", or says something like "now write this up" after a grilling.
---
# PRD — Product Requirements Document
**Mode: TOGETHER (human-in-the-loop).** The PRD encodes decisions and tradeoffs the user owns. Draft from context, but expect the user to review and edit. The skill *can* draft AFK once a grilling has already happened (that's most of the input), but the final document needs the user's eyes before it feeds `/prd-to-issues`.
You are now a senior PM writing a PRD that engineering will actually use. The job is to lock down what's being built, why, and what success looks like — not to sell the idea or pad it with strategy slides.
## Continuity with grill-me
If a `/grill-me` session preceded this in the current conversation, mine it as primary input. The grilling already exposed:
- What the user *actually* knows vs. is hand-waving
- Which constraints they committed to (real) vs. which they ducked (open question)
- Edge cases that came up and how they answered
The PRD should reflect that. Things the user nailed go in as firm requirements. Things they hedged on go in **Open Questions** with the specific gap named — don't paper over them. If a tradeoff was explicitly chosen during the grilling, write it as a decision, not a question.
If there was no preceding grilling, ask one question first: "What's the feature, who's it for, and what's the deadline (or 'none')?" Then proceed.
## Structure
Produce the PRD as a single markdown document. Use exactly these sections, in this order. Skip a section only if it would be empty — never include a section just to write "N/A".
1. **Title & one-line summary** — the feature name and a sentence a stranger could understand.
2. **Problem** — what's broken or missing today, who it hurts, evidence it matters. No solution talk yet.
3. **Goals** — 2–5 bullets, each a concrete outcome (not an activity). "Reduce X by Y" beats "improve X".
4. **Non-goals** — what this explicitly will *not* do. This section is load-bearing; do not skip it. Pull from things the user pushed back on or de-scoped during the grilling.
5. **Users & scenarios** — who uses it, in what situation. 1–3 concrete scenarios written as "When X, the user does Y to achieve Z." No personas with names and hobbies.
6. **Requirements**
- **Functional** — numbered list. Each requirement is testable. "The system shall…" or "Given X, when Y, then Z." If a requirement can't be verified by reading it, rewrite it.
- **Non-functional** — performance budgets, security/privacy, scale, accessibility, observability. Numbers where possible.
7. **Constraints & dependencies** — what's fixed (existing systems, stack choices, deadlines, headcount) and what this depends on shipping first.
8. **Success metrics** — how we'll know it worked, with a target and a measurement source. "Adoption" is not a metric; "≥40% of weekly active X use the feature within 8 weeks, measured via event Y" is.
9. **Open questions** — explicit unknowns with an owner and a deadline-to-resolve where possible. This is where grilling gaps land.
10. **Out of scope** — same energy as Non-goals, but for things that *could* be in a v2. One bullet each, no justification needed.
## Tone & quality bar
- Specific over comprehensive. A 1-page PRD that engineers can build from beats a 6-page one they skim.
- Write to engineers, not execs. Skip the market-sizing, the "why now", the strategy paragraph. The Problem section is enough motivation.
- Every requirement must be testable. If you can't write the test, the requirement is too vague.
- Prefer numbers over adjectives. "Fast" is meaningless; "p95 < 200ms" is a contract.
- Call out the tradeoff the user is making, especially when they made it deliberately during grilling. Make it visible so reviewers can't accidentally undo it.
- Don't invent. If the grilling didn't establish a number, deadline, or stakeholder, leave it as an Open Question — don't fabricate one to look complete.
## Output mode
Default: write the PRD inline in the chat as markdown. If the user said "save it" or "write to file", write it to `docs/prd/<short-kebab-name>.md` (create the directory if missing). Confirm the path after writing.
## What not to do
- No emojis, no excessive bold, no marketing voice. This is an engineering document.
- No "Background" section that retells history. Problem is enough.
- No "Phases" or "Rollout Plan" unless the user asked — that's a separate doc.
- Don't ask clarifying questions mid-draft. If grilling didn't cover it and you can't infer it, it goes in Open Questions.
- Don't grade or comment on the idea. Write the PRD for the feature as briefed.

115
.claude/skills/ship-it/SKILL.md Normal file
View File

@@ -0,0 +1,115 @@
---
name: ship-it
description: AFK autopilot. Drives a shell loop that works through every ready issue in the tracker (GitHub via gh, Gitea via tea), implementing each vertical slice end-to-end and committing per issue. Status streams to the terminal so the human can tail progress locally and Ctrl-C anytime. The shell is the loop; each iteration dispatches one fresh headless Claude run to ship one issue. Use when the user invokes /ship-it, says "go AFK on this", "work the backlog", "ralph the issues", or "ship everything".
---
# Ship It — AFK backlog autopilot
**Mode: AFK.** No human in the loop. Does not ask questions mid-run. If a slice is undecidable, the iteration labels the issue `needs-decision` and the loop moves on. The human gets one summary at the end, not chatter during.
## How this works (read before invoking)
The actual loop runs in a shell script: `.claude/skills/ship-it/loop.sh`. **The shell is the loop**, not you. Each iteration shells out to a fresh, headless `claude -p` invocation that processes exactly one issue using `.claude/skills/ship-it/iterate.md` as its prompt. Three reasons this design beats "LLM keeps going inside one session":
1. **Fresh context per issue.** No drift, no accumulated history bloating the window.
2. **Visible in the terminal.** Progress streams to stdout and tees to a log file. The human can tail it from another shell, see commits land, and Ctrl-C cleanly.
3. **Survives session close.** Closing the interactive Claude window doesn't kill the loop. Re-attach by tailing the log.
## Files
- `loop.sh` — orchestrator. Tracker detection, preflight, dispatch loop, status output, stop conditions, summary.
- `iterate.md` — the prompt passed to each per-issue headless Claude. Read it; it defines what "shipped" means.
- `SKILL.md` — this file. When the user invokes `/ship-it`, you bootstrap and hand off.
## When the user invokes /ship-it
You (the interactive Claude) do the bootstrap, not the work. Concretely:
1. **Preflight in chat** (catches the obvious failures before the script runs):
- `git status --porcelain` empty?
- On `main` (or `$SHIP_IT_TRUNK`)? Up-to-date with origin?
- `gh auth status` (or tea token) returns 0?
- `gh issue list --state open --label slice | wc -l` ≥ 1?
2. **Show the plan** in one short block: tracker host, trunk branch, count of ready issues, the first 3 issue titles, the log path. Nothing more.
3. **Ask one question:** "Start? Reply `go`." This is the *only* human-in-the-loop checkpoint — kicking off AFK work is a real commitment, deserves an explicit ok.
4. **On `go`:** run the loop in the foreground so the user sees live output:
```
bash .claude/skills/ship-it/loop.sh
```
Do not background it. Do not pipe through anything that buffers. The user can Ctrl-C.
5. **While it runs:** stay silent. Don't interject. Don't "monitor" by re-reading logs in chat — the user has the terminal.
6. **When it exits:** read the final `==== ship-it summary ====` block from the log file, present it once with concrete next steps ("2 issues are `needs-decision` — open them to answer their questions?").
## Following progress
The script logs to stdout AND tees to `.ship-it-logs/run-<RUN_ID>.log`. Tail from another terminal:
```bash
tail -f .ship-it-logs/run-*.log
```
Per-issue detail (everything the headless Claude did for that one issue) is in `.ship-it-logs/iter-<RUN_ID>-<ISSUE>.log` — useful for debugging a failed iteration.
Commits land in git as the loop runs. Watch with:
```bash
watch -n 5 'git log --oneline -10 origin/main'
```
## Config (env vars, override before invoking)
| Var | Default | Purpose |
|---|---|---|
| `SHIP_IT_MAX` | 50 | Hard cap on iterations per run |
| `SHIP_IT_MAX_FAIL` | 3 | Consecutive failures before stop |
| `SHIP_IT_TRUNK` | `main` | Trunk branch name |
| `SHIP_IT_TIMEOUT` | `30m` | Per-issue timeout (kills the headless claude) |
| `SHIP_IT_LOG_DIR` | `<repo>/.ship-it-logs` | Where logs go |
## What each iteration does (per `iterate.md`)
For one issue: read it → branch from trunk → write failing e2e test at the outermost layer → implement layer by layer until the test passes → run the full suite → outermost-layer smoke check → commit (one commit, message ends `Closes #N`) → push → open PR with acceptance-criteria checkboxes + smoke evidence → wait for CI → merge if green and branch protection allows, else leave open for review → return to trunk → emit `ITERATION_RESULT:` line for the loop.
**Commit per issue:** yes, exactly. One commit per slice, referenced to the issue, lands on the branch before the PR opens. The slice scope was made small in `/prd-to-issues` precisely so this is one tight commit, not a series.
## Stop conditions (in priority order)
1. **User Ctrl-C** → trap catches SIGINT, current step finishes cleanly, summary prints, exit 130.
2. **Backlog empty** (no ready issues) → exit 0.
3. **Three consecutive hard failures** → exit 1. Something systemic — bad dependency, branch protection blocking, flaky env. Surfaces for human review.
4. **Precondition violated mid-run** → exit non-zero with reason.
## What "ready" means (the loop's filter)
An issue is `ready` iff:
- State is open
- Has label `slice` (filed by `/prd-to-issues`)
- Does NOT have label `blocked`, `needs-decision`, or `ci-failed`
- Is not a spike (spikes deliver decisions, not code — humans handle those)
Issues are processed in number order — walking-skeleton first, as `/prd-to-issues` ordered them.
## Safety boundaries
The headless Claude is launched with a tool allowlist that excludes destructive operations. It cannot:
- Force-push or rewrite shared history
- Bypass branch protection or skip CI hooks (`--no-verify`, `--admin`)
- Auto-merge red or pending PRs (the iterate prompt forbids it, and CI gates back it up)
- Modify CI/CD config or IaC unless the slice's `Slice — layers touched` line explicitly names that layer
- Close issues without the outermost-layer smoke check passing
- Assign people or change milestones/projects
If something tries to push past these in practice (e.g. a slice "needs" a CI change to pass), it should fail the iteration with `needs-decision` and let a human approve the scope expansion.
## What not to do
- **Don't drive the loop yourself by reading issues and implementing them inline.** The shell is the loop. If you're tempted to "just do this one in chat," stop and run the script.
- **Don't background the script** so the user can keep chatting with you. The output IS the value. The user wants to watch it work.
- **Don't summarize between iterations.** Chatter belongs in the final summary, not after each commit.
- **Don't tag the user in PR/issue comments** during the run. They're not in the loop until the script exits.
- **Don't restart a failed iteration manually.** The loop's `needs-decision` and `ci-failed` labels are how failures stay in the tracker for human triage. Manual restart skips that.
## How this fits the chain
`/grill-me <feature>` (together) → `/prd` (together) → `/prd-to-issues` (mostly together, file step needs `create`) → `/ship-it` (AFK). The four-skill arc takes a vague feature idea to merged code with one human checkpoint per phase boundary.

70
.claude/skills/ship-it/iterate.md Normal file
View File

@@ -0,0 +1,70 @@
# ship-it iterate — one issue, end-to-end
You are running ONE iteration of the ship-it AFK loop. Implement, verify, and ship exactly one issue, then exit. The outer shell loop will pick the next one.
**Mode: AFK.** Do not ask questions. If the issue is genuinely undecidable from its body + linked PRD + grilling notes already in the issue or repo, drop a comment on the issue with the specific question, label it `needs-decision`, and exit with status=needs-decision. Do not guess at user intent.
Variables provided below this prompt: `ISSUE_NUMBER`, `TRACKER_CLI` (`gh` or `tea`), `TRUNK_BRANCH`, `REPO_ROOT`.
## Steps
1. **Read the issue.**
- GitHub: `gh issue view $ISSUE_NUMBER --json number,title,body,labels`
- Gitea: `tea issues $ISSUE_NUMBER --output json`
- Parse: `Slice — layers touched`, `Scope`, `Acceptance criteria`, `Slice check`, `Notes`, linked PRD path.
- If `Acceptance criteria` is missing or non-testable → exit status=needs-decision with reason "acceptance criteria not testable".
2. **Branch from latest trunk.**
`git fetch origin && git switch -c "slice/${ISSUE_NUMBER}-<short-kebab-slug>" "origin/$TRUNK_BRANCH"`
3. **Write the failing e2e test first.** Anchored at the OUTERMOST layer named in `Slice — layers touched` (HTTP endpoint, UI smoke, dashboard query, log assertion — whatever the acceptance criterion observes). Run it. Confirm it fails for the right reason. If you can't write an e2e test for this slice, that's a sign the acceptance criterion isn't really observable end-to-end → exit status=needs-decision.
4. **Implement layer by layer.** Walk the `Slice — layers touched` list. Make the minimal change at each layer to satisfy the slice — do not gold-plate, do not refactor adjacent code, do not "improve" things outside scope. Re-run the e2e test after each layer change.
5. **Run the broader test suite.** Catch regressions caused by the slice. Fix any test that was green before and is now red — do not skip or mark tests. If a test was already red before your changes, leave it (note in PR body).
6. **Outermost-layer smoke check.** The 30-second-demo check: hit the endpoint with curl, query the dashboard, tail the log, load the page. Observe what the acceptance criterion observes. Capture the output (curl response body, log snippet, query result) — you'll paste it into the PR body as evidence.
7. **Commit.** One commit per slice (or a tight series — no WIP commits, no fixup commits, no "address review" before review exists). Read the repo's recent `git log` to match commit style. Message ends with `Closes #${ISSUE_NUMBER}`.
8. **Push and open PR.**
- GitHub: `git push -u origin HEAD && gh pr create --fill`
- Gitea: `git push -u origin HEAD && tea pr create --title "..." --description "..."`
- PR body must include:
- Each acceptance criterion as a checked `- [x]` line.
- The smoke-check evidence (curl output / log snippet / screenshot path) in a fenced block.
- `Closes #${ISSUE_NUMBER}` (so the issue auto-closes on merge).
9. **Wait for CI and decide merge.**
- Poll: `gh pr checks --watch` (or `tea pr status`).
- **All green + branch protection allows direct merge** → `gh pr merge --squash --delete-branch`. Verify the merge commit landed on trunk.
- **All green + branch protection requires human review** → leave PR open. Comment `Ready for review — all acceptance criteria verified, smoke check passed.` on the issue. Exit status=shipped with the PR number.
- **Red CI** → one fix-and-push cycle. Read the failing log, fix the actual cause (do not skip the test). If still red after the second attempt: label issue `ci-failed`, comment with the CI excerpt, leave PR open, exit status=failed with reason "ci-red".
10. **Return to trunk.** `git switch $TRUNK_BRANCH && git pull --ff-only`. If the slice was merged, run the smoke check one more time against integrated trunk. If it fails there → revert the merge, label `regression`, exit status=failed with reason "regression-on-trunk".
## Boundaries
- Never force-push, never rewrite shared history, never delete branches you didn't create.
- Never bypass branch protection (`--admin`) or skip CI hooks (`--no-verify`).
- Never auto-merge a PR whose CI is red or pending.
- Never close an issue without the outermost-layer smoke check passing.
- Never modify CI/CD config, IaC, or production data unless the slice's `layers touched` explicitly names that layer.
- Never invent acceptance criteria. If they're vague, label `needs-decision`.
- Never assign issues or change milestones.
## Final output line
The shell loop greps for this exact line to determine outcome. Print it as the LAST line before exiting, on its own line, no decoration:
```
ITERATION_RESULT: status=<shipped|failed|needs-decision> issue=#<N> pr=<#N|none> reason=<short single-line reason>
```
Examples:
```
ITERATION_RESULT: status=shipped issue=#142 pr=#287 reason=merged-to-main
ITERATION_RESULT: status=shipped issue=#143 pr=#288 reason=open-for-review
ITERATION_RESULT: status=failed issue=#144 pr=#289 reason=ci-red-after-retry
ITERATION_RESULT: status=needs-decision issue=#145 pr=none reason=acceptance-criteria-not-testable
```

189
.claude/skills/ship-it/loop.sh Normal file
View File

@@ -0,0 +1,189 @@
#!/usr/bin/env bash
# ship-it AFK loop — works through every ready issue end-to-end.
# See SKILL.md for design. Ctrl-C to stop; partial work is preserved on disk.
set -uo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" || { echo "not in a git repo"; exit 1; }
# ---- config (env-overridable) ----
MAX_ITERATIONS="${SHIP_IT_MAX:-50}"
MAX_CONSECUTIVE_FAILURES="${SHIP_IT_MAX_FAIL:-3}"
TRUNK_BRANCH="${SHIP_IT_TRUNK:-main}"
ITERATION_TIMEOUT="${SHIP_IT_TIMEOUT:-30m}" # per-issue cap
LOG_DIR="${SHIP_IT_LOG_DIR:-$REPO_ROOT/.ship-it-logs}"
mkdir -p "$LOG_DIR"
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
LOG_FILE="$LOG_DIR/run-$RUN_ID.log"
# ---- logging ----
log() {
local ts; ts="$(date -u +%H:%M:%S)"
printf '[%s] %s\n' "$ts" "$*" | tee -a "$LOG_FILE"
}
die() { log "FATAL: $*"; exit 1; }
# ---- graceful interrupt ----
INTERRUPTED=0
on_interrupt() {
INTERRUPTED=1
log ""
log "interrupt received — finishing current step cleanly, then stopping"
}
trap on_interrupt INT
# ---- tracker detection ----
ORIGIN_URL="$(git -C "$REPO_ROOT" remote get-url origin 2>/dev/null || true)"
if [[ "$ORIGIN_URL" == *"github.com"* ]]; then
TRACKER_CLI="gh"
command -v gh >/dev/null || die "gh CLI not installed"
gh auth status >/dev/null 2>&1 || die "gh not authenticated (run: gh auth login)"
list_ready_issues() {
gh issue list --state open --label slice --limit 100 \
--json number,title,labels \
--jq '[.[] | select(.labels | map(.name) | (contains(["blocked"]) or contains(["needs-decision"]) or contains(["ci-failed"])) | not)] | sort_by(.number)'
}
elif [[ "$ORIGIN_URL" == *"gitea"* ]]; then
TRACKER_CLI="tea"
command -v tea >/dev/null || die "tea CLI not installed (Gitea repo detected) — install tea or switch to a GitHub remote"
list_ready_issues() {
tea issues list --state open --output json 2>/dev/null \
| jq '[.[] | select((.labels // []) | map(.name) | (contains(["blocked"]) or contains(["needs-decision"]) or contains(["ci-failed"])) | not) | select((.labels // []) | map(.name) | contains(["slice"]))] | sort_by(.index)'
}
else
die "unknown tracker for origin: '$ORIGIN_URL' (need github.com or gitea.*)"
fi
# ---- preflight ----
cd "$REPO_ROOT"
[[ -z "$(git status --porcelain)" ]] || die "git tree is dirty — commit or stash before starting"
CURRENT_BRANCH="$(git branch --show-current)"
[[ "$CURRENT_BRANCH" == "$TRUNK_BRANCH" ]] || die "not on $TRUNK_BRANCH (on '$CURRENT_BRANCH')"
git fetch origin "$TRUNK_BRANCH" >/dev/null 2>&1 || die "git fetch failed"
LOCAL_SHA="$(git rev-parse HEAD)"
REMOTE_SHA="$(git rev-parse "origin/$TRUNK_BRANCH")"
[[ "$LOCAL_SHA" == "$REMOTE_SHA" ]] || die "$TRUNK_BRANCH not up-to-date with origin (pull first)"
command -v claude >/dev/null || die "claude CLI not on PATH"
# ---- banner ----
log "ship-it run $RUN_ID"
log " tracker: $TRACKER_CLI ($ORIGIN_URL)"
log " trunk: $TRUNK_BRANCH @ ${LOCAL_SHA:0:8}"
log " log: $LOG_FILE"
log " config: max_iter=$MAX_ITERATIONS, max_fail=$MAX_CONSECUTIVE_FAILURES, timeout=$ITERATION_TIMEOUT"
log ""
ITERATE_PROMPT_TEMPLATE="$(cat "$SCRIPT_DIR/iterate.md")"
SHIPPED=()
FAILED=()
NEEDS_DECISION=()
CONSECUTIVE_FAILURES=0
ITERATION=0
# ---- main loop ----
while (( ITERATION < MAX_ITERATIONS )); do
(( INTERRUPTED )) && break
ITERATION=$((ITERATION + 1))
READY_JSON="$(list_ready_issues 2>/dev/null || echo '[]')"
READY_COUNT="$(echo "$READY_JSON" | jq 'length' 2>/dev/null || echo 0)"
if (( READY_COUNT == 0 )); then
log "backlog empty — stopping"
break
fi
ISSUE_NUM="$(echo "$READY_JSON" | jq -r '.[0].number // .[0].index')"
ISSUE_TITLE="$(echo "$READY_JSON" | jq -r '.[0].title')"
log "─────────────────────────────────────────────────────────────"
log "iter $ITERATION | #$ISSUE_NUM \"$ISSUE_TITLE\" ($READY_COUNT ready) → starting"
ITER_LOG="$LOG_DIR/iter-$RUN_ID-$ISSUE_NUM.log"
PROMPT="$ITERATE_PROMPT_TEMPLATE
## Variables for this iteration
- ISSUE_NUMBER=$ISSUE_NUM
- TRACKER_CLI=$TRACKER_CLI
- TRUNK_BRANCH=$TRUNK_BRANCH
- REPO_ROOT=$REPO_ROOT
Begin."
ITER_START="$(date +%s)"
set +e
timeout "$ITERATION_TIMEOUT" claude -p "$PROMPT" \
--allowed-tools "Bash,Edit,Write,Read,Grep,Glob,WebFetch" \
--output-format text \
>"$ITER_LOG" 2>&1
CLAUDE_EXIT=$?
set -e
ITER_END="$(date +%s)"
ITER_DURATION=$((ITER_END - ITER_START))
RESULT_LINE="$(grep -E '^ITERATION_RESULT:' "$ITER_LOG" | tail -1 || true)"
STATUS="$(echo "$RESULT_LINE" | sed -n 's/.*status=\([^ ]*\).*/\1/p')"
PR_FIELD="$(echo "$RESULT_LINE" | sed -n 's/.*pr=\([^ ]*\).*/\1/p')"
REASON="$(echo "$RESULT_LINE" | sed -n 's/.*reason=\(.*\)/\1/p')"
if (( CLAUDE_EXIT == 124 )); then
STATUS="failed"
REASON="timeout after $ITERATION_TIMEOUT"
fi
case "$STATUS" in
shipped)
log "iter $ITERATION | #$ISSUE_NUM ✓ shipped → PR $PR_FIELD (${ITER_DURATION}s)"
SHIPPED+=("#$ISSUE_NUM→$PR_FIELD")
CONSECUTIVE_FAILURES=0
;;
failed)
log "iter $ITERATION | #$ISSUE_NUM ✗ failed: $REASON (${ITER_DURATION}s, see $ITER_LOG)"
FAILED+=("#$ISSUE_NUM ($REASON)")
CONSECUTIVE_FAILURES=$((CONSECUTIVE_FAILURES + 1))
;;
needs-decision)
log "iter $ITERATION | #$ISSUE_NUM ? needs-decision: $REASON (${ITER_DURATION}s)"
NEEDS_DECISION+=("#$ISSUE_NUM ($REASON)")
CONSECUTIVE_FAILURES=0
;;
*)
log "iter $ITERATION | #$ISSUE_NUM ! unknown outcome (claude exit=$CLAUDE_EXIT, ${ITER_DURATION}s) — see $ITER_LOG"
FAILED+=("#$ISSUE_NUM (unknown outcome)")
CONSECUTIVE_FAILURES=$((CONSECUTIVE_FAILURES + 1))
;;
esac
if (( CONSECUTIVE_FAILURES >= MAX_CONSECUTIVE_FAILURES )); then
log "$MAX_CONSECUTIVE_FAILURES consecutive failures — stopping for human review"
break
fi
# back to trunk for next iteration
if [[ "$(git branch --show-current)" != "$TRUNK_BRANCH" ]]; then
git switch "$TRUNK_BRANCH" >/dev/null 2>&1 || log " warn: could not return to $TRUNK_BRANCH"
fi
git pull --ff-only origin "$TRUNK_BRANCH" >/dev/null 2>&1 || log " warn: could not fast-forward $TRUNK_BRANCH"
done
# ---- summary ----
log ""
log "==== ship-it summary ===="
log "iterations: $ITERATION"
log "shipped: ${#SHIPPED[@]} ${SHIPPED[*]:-}"
log "failed: ${#FAILED[@]} ${FAILED[*]:-}"
log "needs-decision: ${#NEEDS_DECISION[@]} ${NEEDS_DECISION[*]:-}"
log "log: $LOG_FILE"
if (( INTERRUPTED )); then
log "stop reason: user-interrupt"
exit 130
elif (( CONSECUTIVE_FAILURES >= MAX_CONSECUTIVE_FAILURES )); then
log "stop reason: consecutive-failures"
exit 1
else
log "stop reason: backlog-empty"
exit 0
fi