[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CP3CHHC5S3FG5DS38W6PP8":3,"skill-same:01M6CP3CHHC5S3FG5DS38W6PP8":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6CP3CHHC5S3FG5DS38W6PP8","work",null,"Runs the story worker loop in a story-workflow project — claim ready stories, implement each in its own worktree, close through verification gates, repeat until the goal is met or the loop stalls. Use when asked to \"work the board\", \"complete all stories\", \"work on epic st-XXXX\", \"pick up the next story\", \"start a worker\", or to resume or continue a story run — and when a loop re-prompt names the next story in a session that started the loop. DO NOT TRIGGER without .agents\u002Fshousper-stories\u002Fconfig.json (use stories:setup first), for decomposing a spec into stories (stories:plan), or to stop a run (stories:cancel).","shousper\u002Fclanker-kit","shousper","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1144345?v=4","01M6CP153W30NV9J1XT8K98G4J","Corey McGregor","01M6CP157WFP2WEFX4TJH7JVPG",5,"MIT","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fwork\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"next","workflow","claim","do","stop","goal","up","ready","session","verification gates","pick","work on","plan","loop","start","worktree","verification","run","config","2026-11-10 10:12:30",false,"---\nname: work\ndescription: Runs the story worker loop in a story-workflow project — claim ready stories, implement each in its own worktree, close through verification gates, repeat until the goal is met or the loop stalls. Use when asked to \"work the board\", \"complete all stories\", \"work on epic st-XXXX\", \"pick up the next story\", \"start a worker\", or to resume or continue a story run — and when a loop re-prompt names the next story in a session that started the loop. DO NOT TRIGGER without .agents\u002Fshousper-stories\u002Fconfig.json (use stories:setup first), for decomposing a spec into stories (stories:plan), or to stop a run (stories:cancel).\n---\n\n# Story Worker\n\nYou are one worker in a possibly-parallel pool. The `story` CLI arbitrates everything shared — claims, locks, gates, integration. Your job is judgment and implementation.\n\n**Core principle:** the loop is encoded — the CLI and your harness's turn-end hook drive continuation. You execute one story per iteration well; you never improvise orchestration.\n\n## HARD GATE: the CLI is the only writer\n\nNever edit or write files under the configured `storiesDir` (default `stories\u002F`) or under `.agents\u002Fshousper-stories\u002Flocal\u002F` (state, loop files, learnings, evidence). Every board mutation is a `story` command. A hook denies direct writes — treat a denial as a redirect and run the CLI command it names. Do not route around it with the shell (`sed -i`, `echo >>`, heredocs): unlocked writes corrupt the board for every parallel worker.\n\n## Starting a run\n\n1. Parse the goal scope from the ask: whole board (\"complete all stories\"), an epic (`epic:st-9c01`), an explicit list of ids, or a single story.\n2. Multi-story goal → `story loop start --goal \"\u003Cscope>\"`. The CLI binds the loop to YOUR session (your harness adapter supplies the session id as `STORY_SESSION_ID`) — only this session receives its re-prompts, and other sessions' loops never address you. From now on the loop re-prompts you with the next story at each turn end — never \"keep going\" on your own initiative, and never touch the loop state files. The loop is the only continuation mechanism: do not also run it under a harness goal\u002Fautonomy mode (OMP's `\u002Fgoal`, for example) — two drivers fight over when to stop, and the loop's stop is the one the board records.\n3. Single-story ask → skip the loop; run one iteration of the procedure below.\n\nWhile a loop is bound to your session, the guard also denies the ask-the-user tool: a run is unattended by definition. A question only a human can answer is a park (step 6), never a prompt.\n\n## Iteration procedure\n\nOne story per iteration, in this order:\n\n### 1. Pick\n\n`story ready --json`. Feedback items rank first — take the top entry. Empty set → summarize why via `story board` (everything done, blocked, or in-review) and end your turn; the loop tick decides whether the goal is met.\n\n### 2. Claim\n\n`story claim \u003Cid>` — verifies readiness under lock, writes your lease, creates `.worktrees\u002Fst-\u003Cid>` on branch `story\u002Fst-\u003Cid>`. Lost the race (claim error) → re-run `story ready` and take the next. Never work on a story you have not claimed.\n\n### 3. Plan via the bundled planner runner — never inline, never model-choosing\n\nEvery claimed story gets an execution-time plan from the bundled planner runner beside this file — even when the story already carries one (prerequisites may have merged since it was written; the planner validates and refreshes against the code as it is NOW). The runner pins the planner tier from story `complexity` in code (routine, hard, frontier — `frontier` is your human partner's explicit opt-in, made at board approval; complexity is locked while the story is in-progress). You never pick, retry at a different tier, or substitute a planner — that decision does not exist in this session.\n\nLaunch it exactly as `launch.md` in this skill's directory describes for your harness: it names the runner file, shows the launch call, and says how the result comes back. Pass one entry per claimed story — `{ id, complexity (from story show --json; absent = routine), worktree (absolute path), storyBody (the full body, pasted; the planner must not re-read the board) }`. Claimed several stories? Pass them all in one call; they plan in parallel. Never poll a running planner; `launch.md` says how its completion reaches you.\n\nThe result is `{ status, planned, unimplementable, failed }`. Per story:\n\n- `planned` → `story update \u003Cid> --plan-file \u003Cfile>` with its `plan`, and hold its `batches` for step 4. `launch.md` says where your harness delivers them: a file the runner already wrote, or the result itself. Never retype either from a truncated snapshot.\n- `unimplementable` → `story park \u003Cid> --question \"\u003Cits question>\"` and move on.\n- `failed` → `story park \u003Cid> --question \"planner failed: \u003Cerror>\"` and move on. A planner failure is never a tier-selection problem — there is no alternative-tier path, and complexity cannot change while the story is in-progress.\n\n### 4. Implement via kit:build-flow — inside the worktree\n\nAll implementation happens in `.worktrees\u002Fst-\u003Cid>`. Three hard rules, each from a real incident:\n\n- **cd into the worktree in your session shell IMMEDIATELY before invoking kit:build-flow, verify with `pwd`, and pass the worktree path as build-flow's `args.worktree`.** The workflow's agents inherit the shell's cwd, not the path named in their prompts — launching from the main repo split-brains the run (agents edit main's tree, reviewers report \"no implementation\", fixes land in the wrong copy). After the workflow returns, `git -C \u003Crepo-root> status --porcelain` must show only board files; anything else is a split brain — port stray changes into the worktree, then restore main.\n- **Launch build-flow, then end your turn — continuation is event-driven.** build-flow's completion re-invokes you with its result (its own `launch.md` says exactly how on your harness); gating, committing, and closing happen in that re-invocation. The loop tick holds quietly while this session's claim is in flight, so ending the turn is safe. Never poll a running workflow — polling burns context.\n- build-flow's worktree requirement is already satisfied by the story worktree; do NOT create another.\n\nInvoke kit:build-flow with the planner's `\u003Cbatches>` as `args.batches` — never the raw story as a single fat task. The story body stays the spec; the planner output is the plan.\n\n**Committing — MANDATORY before closing:** `story done` merges the story BRANCH, not the working tree. build-flow leaves its work uncommitted by design, so commit it to the story branch first (message `st-\u003Cid>: \u003Cwhat changed>`) — the CLI refuses a dirty worktree or a zero-commit branch (use `--allow-empty` only for a genuinely codeless story). Stage code only, never `stories\u002F**`: board files are CLI-managed — restore them with `git checkout -- stories` instead of committing them. The goal loop is your human partner's standing consent to commit on `story\u002Fst-\u003Cid>` branches — never to main; integration belongs to the CLI.\n\n### 5. Discovered work\n\nOut-of-scope work you uncover → file it, don't do it. Write the whole spec at filing time — the CLI refuses a story without a description and at least one acceptance criterion, and the next claimant plans from nothing else:\n\n```bash\nstory create --title \"…\" --type bug --discovered-from \u003Cid> \\\n  --description \"What is wrong, where, and why it is out of scope here\" \\\n  --ac \"Mechanically checkable outcome\" --ac \"Another one\" [--touches …]\n```\n\nThen return to the claimed story. Scope creep breaks the sizing contract.\n\n### 6. Park, don't stall\n\nA decision only a human can make — product choice, contradictory spec, missing access or credentials, destructive\u002Firreversible action:\n\n```bash\nstory park \u003Cid> --question \"Specific, answerable question — include the options you see\"\n```\n\n…then go back to step 1 for the next story. Parked questions surface in the end-of-run summary. Do NOT park for technical difficulty — that is kit:debugging territory.\n\n### 7. Review gates\n\n`story show \u003Cid>` lists the story's gates. For each `kind: review` gate, before closing:\n\n1. Run its `capture` command from the worktree; note the artifact paths.\n2. Dispatch the gate's persona as a subagent (see Personas) with the whole evidence bundle: story file path, artifact paths, the worktree path, and build-flow's verification summary path. The persona judges every acceptance criterion against that bundle, so anything you leave out is a fail, not a smaller review.\n3. Persist the returned verdict: `story record \u003Cid> --gate \u003Cname> --verdict pass|fail --evidence \u003Cartifact-path>` — record a `fail` too, before you touch anything.\n4. On `fail` → fix what the persona named (code, capture coverage, or the capture script), re-capture, re-dispatch — within the per-story fix budget.\n\n### 8. Close\n\n`story done \u003Cid>`. The CLI runs every command gate in the worktree (serialized machine-wide), verifies review verdicts, writes the evidence file, reconciles `touches` to the actual diff, then integrates per merge mode:\n\n- `self` — merged to main, worktree torn down. Merge conflict → the story returns to in-progress with an integration-fix note: resolve in the worktree, re-gate, re-run `story done`.\n- `local` \u002F `pr` — the story goes in-review (worktree or PR awaits a human); move on.\n\nA failing gate names itself in the output → fix in the worktree (kit:debugging for surprises), re-run `story done`. Gates run in a clean subprocess from the worktree — a fresh worktree may need the project's own toolchain setup before its gates can pass. Never mark done any other way; never weaken a gate to pass it.\n\n### 9. End the iteration\n\nFinish your message normally. At turn end the loop ticks: it either re-prompts you with the next story or ends the run with a summary. Do not restart a stopped loop or edit budgets — a human decides.\n\n## Feedback items (local \u002F pr mode)\n\n`story ready` ranks arrived review feedback above new stories. Claiming a feedback item attaches you to the story's EXISTING worktree and branch. Before changing code, invoke kit:receiving-review on the reviewer comments — verify each against the codebase, implement what survives scrutiny, then re-run gates and close via `story done` (which re-pushes in pr mode).\n\n## Personas\n\nReview-gate verdicts come from subagents dispatched with a filled template (`launch.md` names the dispatch tool on your harness):\n\n- `references\u002Fpersonas\u002Fqa-reviewer.md` — AC-by-AC verification against evidence.\n- `references\u002Fpersonas\u002Fvisual-reviewer.md` — judgment on visual captures.\n- A gate whose `persona` names a file in `.agents\u002Fshousper-stories\u002Fpersonas\u002F` uses that project-generated persona instead.\n\nFill every placeholder (story file path, worktree, evidence paths — paths, never pasted content), dispatch, and record the single `VERDICT:` line the persona returns. Never record a verdict a persona did not return, and never skip the dispatch because the result \"seems obvious\" — the recorded verdict is the anti-reward-hacking line.\n\n## Learnings\n\nLearned something the other workers need — a build quirk, a flaky suite, a naming decision? Append it: `story loop learn \"\u003Cone-liner>\"`. The tick injects shared learnings into every worker's re-prompt.\n\n## Context discipline\n\nThe board holds ALL state — your session context is disposable, so keep it thin. A worker session that grows to hundreds of turns pays cache reads on its entire context every turn; measured runs show this dwarfs the cost of the actual work.\n\n- The orchestrator touches only: the `story` CLI, skill invocations, and agent dispatches. Probes, gate captures, spike scripts, and verification runs happen inside build-flow or dispatched subagents — never inline in your session.\n- Never read implementation files, diffs, or full test output into your context. The story file, gate evidence, and structured agent returns are the record; build-flow's `verification.summary` is the test evidence.\n- After `story done`, if your context has grown large, compact before claiming the next story — everything needed to continue (board, learnings, loop state) is on disk.\n\n## Budgets and visibility\n\nTwo budgets come from config: the **stall budget** (`budgets.maxStalls`, default 3) ends a run after that many consecutive turn ends with no board progress — a story claimed, closed, parked, or filed resets it, so a run that keeps landing stories never stops; the **per-story fix budget** (`budgets.maxFixRoundsPerStory`, default 3) caps retries on one story. The loop's status line shows `iteration N · stalls a\u002Fb` at each turn end — your human partner watches it. Runs end on: goal complete, board drained or blocked, or a budget exhausted. The final summary MUST surface parked questions verbatim and list in-review stories awaiting humans.\n\n## Red Flags\n\n**Never:**\n\n- Hand-edit `stories\u002F**`, loop state, learnings, or evidence files — CLI only.\n- Implement outside the story's worktree, or without a claim.\n- Run probes, captures, or verification inline in the worker session — dispatch them; read only structured results back.\n- Run `story done` with uncommitted work in the worktree — the CLI refuses, but the commit is your job, not a formality.\n- Poll or block on a running workflow — completion drives continuation; end your turn instead.\n- Claim another story while one is in flight in this session — one story per iteration; the loop resumes when the current one closes.\n- Launch build-flow with the shell cwd outside the story worktree, or without `args.worktree`.\n- Commit `stories\u002F**` board files into a story branch.\n- Close a story any way other than a passing `story done`.\n- Fake, infer, or self-author a review-gate verdict.\n- Expand a story's scope — file discovered work instead.\n- Merge to main yourself — integration is the CLI's.\n- Continue past a stopped loop, restart it, or edit budgets.\n- Ask your human partner a question mid-run — park the story instead.\n- Swallow parked questions from the final summary.\n- Skip the planner runner, plan inline in the worker session, or pass the raw story to build-flow as one fat task.\n- Dispatch a planner yourself as a plain subagent, at a self-chosen tier, or \"fall back\" to a lesser tier on failure — planning goes through the bundled runner only; failures park.\n- Self-assign `frontier` complexity — that escalation belongs to your human partner at approval time.\n- Unpark a story (`--status todo`) then downgrade its `complexity` to reclaim and re-plan at a cheaper tier — the CLI stamps and enforces the parked tier, but the loophole is closed at the board level: only your human partner clears it (`--clear-park-lock`).\n\n## Integration\n\n- kit:build-flow — per-story implementation (TDD + review), run inside the story worktree.\n- kit:receiving-review — before acting on PR or review feedback.\n- kit:debugging — gate failures with a non-obvious cause.\n- stories:plan — files the work this skill drains; stories:cancel — the stop lever.\n- `references\u002Fpersonas\u002F` — bundled persona templates.\n- `launch.md` — harness-specific launch mechanics for the planner runner, build-flow's result delivery, and persona dispatch; read on demand.\n","# Story Worker\n\nYou are one worker in a possibly-parallel pool. The `story` CLI arbitrates everything shared — claims, locks, gates, integration. Your job is judgment and implementation.\n\n**Core principle:** the loop is encoded — the CLI and your harness's turn-end hook drive continuation. You execute one story per iteration well; you never improvise orchestration.\n\n## HARD GATE: the CLI is the only writer\n\nNever edit or write files under the configured `storiesDir` (default `stories\u002F`) or under `.agents\u002Fshousper-stories\u002Flocal\u002F` (state, loop files, learnings, evidence). Every board mutation is a `story` command. A hook denies direct writes — treat a denial as a redirect and run the CLI command it names. Do not route around it with the shell (`sed -i`, `echo >>`, heredocs): unlocked writes corrupt the board for every parallel worker.\n\n## Starting a run\n\n1. Parse the goal scope from the ask: whole board (\"complete all stories\"), an epic (`epic:st-9c01`), an explicit list of ids, or a single story.\n2. Multi-story goal → `story loop start --goal \"\u003Cscope>\"`. The CLI binds the loop to YOUR session (your harness adapter supplies the session id as `STORY_SESSION_ID`) — only this session receives its re-prompts, and other sessions' loops never address you. From now on the loop re-prompts you with the next story at each turn end — never \"keep going\" on your own initiative, and never touch the loop state files. The loop is the only continuation mechanism: do not also run it under a harness goal\u002Fautonomy mode (OMP's `\u002Fgoal`, for example) — two drivers fight over when to stop, and the loop's stop is the one the board records.\n3. Single-story ask → skip the loop; run one iteration of the procedure below.\n\nWhile a loop is bound to your session, the guard also denies the ask-the-user tool: a run is unattended by definition. A question only a human can answer is a park (step 6), never a prompt.\n\n## Iteration procedure\n\nOne story per iteration, in this order:\n\n### 1. Pick\n\n`story ready --json`. Feedback items rank first — take the top entry. Empty set → summarize why via `story board` (everything done, blocked, or in-review) and end your turn; the loop tick decides whether the goal is met.\n\n### 2. Claim\n\n`story claim \u003Cid>` — verifies readiness under lock, writes your lease, creates `.worktrees\u002Fst-\u003Cid>` on branch `story\u002Fst-\u003Cid>`. Lost the race (claim error) → re-run `story ready` and take the next. Never work on a story you have not claimed.\n\n### 3. Plan via the bundled planner runner — never inline, never model-choosing\n\nEvery claimed story gets an execution-time plan from the bundled planner runner beside this file — even when the story already carries one (prerequisites may have merged since it was written; the planner validates and refreshes against the code as it is NOW). The runner pins the planner tier from story `complexity` in code (routine, hard, frontier — `frontier` is your human partner's explicit opt-in, made at board approval; complexity is locked while the story is in-progress). You never pick, retry at a different tier, or substitute a planner — that decision does not exist in this session.\n\nLaunch it exactly as `launch.md` in this skill's directory describes for your harness: it names the runner file, shows the launch call, and says how the result comes back. Pass one entry per claimed story — `{ id, complexity (from story show --json; absent = routine), worktree (absolute path), storyBody (the full body, pasted; the planner must not re-read the board) }`. Claimed several stories? Pass them all in one call; they plan in parallel. Never poll a running planner; `launch.md` says how its completion reaches you.\n\nThe result is `{ status, planned, unimplementable, failed }`. Per story:\n\n- `planned` → `story update \u003Cid> --plan-file \u003Cfile>` with its `plan`, and hold its `batches` for step 4. `launch.md` says where your harness delivers them: a file the runner already wrote, or the result itself. Never retype either from a truncated snapshot.\n- `unimplementable` → `story park \u003Cid> --question \"\u003Cits question>\"` and move on.\n- `failed` → `story park \u003Cid> --question \"planner failed: \u003Cerror>\"` and move on. A planner failure is never a tier-selection problem — there is no alternative-tier path, and complexity cannot change while the story is in-progress.\n\n### 4. Implement via kit:build-flow — inside the worktree\n\nAll implementation happens in `.worktrees\u002Fst-\u003Cid>`. Three hard rules, each from a real incident:\n\n- **cd into the worktree in your session shell IMMEDIATELY before invoking kit:build-flow, verify with `pwd`, and pass the worktree path as build-flow's `args.worktree`.** The workflow's agents inherit the shell's cwd, not the path named in their prompts — launching from the main repo split-brains the run (agents edit main's tree, reviewers report \"no implementation\", fixes land in the wrong copy). After the workflow returns, `git -C \u003Crepo-root> status --porcelain` must show only board files; anything else is a split brain — port stray changes into the worktree, then restore main.\n- **Launch build-flow, then end your turn — continuation is event-driven.** build-flow's completion re-invokes you with its result (its own `launch.md` says exactly how on your harness); gating, committing, and closing happen in that re-invocation. The loop tick holds quietly while this session's claim is in flight, so ending the turn is safe. Never poll a running workflow — polling burns context.\n- build-flow's worktree requirement is already satisfied by the story worktree; do NOT create another.\n\nInvoke kit:build-flow with the planner's `\u003Cbatches>` as `args.batches` — never the raw story as a single fat task. The story body stays the spec; the planner output is the plan.\n\n**Committing — MANDATORY before closing:** `story done` merges the story BRANCH, not the working tree. build-flow leaves its work uncommitted by design, so commit it to the story branch first (message `st-\u003Cid>: \u003Cwhat changed>`) — the CLI refuses a dirty worktree or a zero-commit branch (use `--allow-empty` only for a genuinely codeless story). Stage code only, never `stories\u002F**`: board files are CLI-managed — restore them with `git checkout -- stories` instead of committing them. The goal loop is your human partner's standing consent to commit on `story\u002Fst-\u003Cid>` branches — never to main; integration belongs to the CLI.\n\n### 5. Discovered work\n\nOut-of-scope work you uncover → file it, don't do it. Write the whole spec at filing time — the CLI refuses a story without a description and at least one acceptance criterion, and the next claimant plans from nothing else:\n\n```bash\nstory create --title \"…\" --type bug --discovered-from \u003Cid> \\\n  --description \"What is wrong, where, and why it is out of scope here\" \\\n  --ac \"Mechanically checkable outcome\" --ac \"Another one\" [--touches …]\n```\n\nThen return to the claimed story. Scope creep breaks the sizing contract.\n\n### 6. Park, don't stall\n\nA decision only a human can make — product choice, contradictory spec, missing access or credentials, destructive\u002Firreversible action:\n\n```bash\nstory park \u003Cid> --question \"Specific, answerable question — include the options you see\"\n```\n\n…then go back to step 1 for the next story. Parked questions surface in the end-of-run summary. Do NOT park for technical difficulty — that is kit:debugging territory.\n\n### 7. Review gates\n\n`story show \u003Cid>` lists the story's gates. For each `kind: review` gate, before closing:\n\n1. Run its `capture` command from the worktree; note the artifact paths.\n2. Dispatch the gate's persona as a subagent (see Personas) with the whole evidence bundle: story file path, artifact paths, the worktree path, and build-flow's verification summary path. The persona judges every acceptance criterion against that bundle, so anything you leave out is a fail, not a smaller review.\n3. Persist the returned verdict: `story record \u003Cid> --gate \u003Cname> --verdict pass|fail --evidence \u003Cartifact-path>` — record a `fail` too, before you touch anything.\n4. On `fail` → fix what the persona named (code, capture coverage, or the capture script), re-capture, re-dispatch — within the per-story fix budget.\n\n### 8. Close\n\n`story done \u003Cid>`. The CLI runs every command gate in the worktree (serialized machine-wide), verifies review verdicts, writes the evidence file, reconciles `touches` to the actual diff, then integrates per merge mode:\n\n- `self` — merged to main, worktree torn down. Merge conflict → the story returns to in-progress with an integration-fix note: resolve in the worktree, re-gate, re-run `story done`.\n- `local` \u002F `pr` — the story goes in-review (worktree or PR awaits a human); move on.\n\nA failing gate names itself in the output → fix in the worktree (kit:debugging for surprises), re-run `story done`. Gates run in a clean subprocess from the worktree — a fresh worktree may need the project's own toolchain setup before its gates can pass. Never mark done any other way; never weaken a gate to pass it.\n\n### 9. End the iteration\n\nFinish your message normally. At turn end the loop ticks: it either re-prompts you with the next story or ends the run with a summary. Do not restart a stopped loop or edit budgets — a human decides.\n\n## Feedback items (local \u002F pr mode)\n\n`story ready` ranks arrived review feedback above new stories. Claiming a feedback item attaches you to the story's EXISTING worktree and branch. Before changing code, invoke kit:receiving-review on the reviewer comments — verify each against the codebase, implement what survives scrutiny, then re-run gates and close via `story done` (which re-pushes in pr mode).\n\n## Personas\n\nReview-gate verdicts come from subagents dispatched with a filled template (`launch.md` names the dispatch tool on your harness):\n\n- `references\u002Fpersonas\u002Fqa-reviewer.md` — AC-by-AC verification against evidence.\n- `references\u002Fpersonas\u002Fvisual-reviewer.md` — judgment on visual captures.\n- A gate whose `persona` names a file in `.agents\u002Fshousper-stories\u002Fpersonas\u002F` uses that project-generated persona instead.\n\nFill every placeholder (story file path, worktree, evidence paths — paths, never pasted content), dispatch, and record the single `VERDICT:` line the persona returns. Never record a verdict a persona did not return, and never skip the dispatch because the result \"seems obvious\" — the recorded verdict is the anti-reward-hacking line.\n\n## Learnings\n\nLearned something the other workers need — a build quirk, a flaky suite, a naming decision? Append it: `story loop learn \"\u003Cone-liner>\"`. The tick injects shared learnings into every worker's re-prompt.\n\n## Context discipline\n\nThe board holds ALL state — your session context is disposable, so keep it thin. A worker session that grows to hundreds of turns pays cache reads on its entire context every turn; measured runs show this dwarfs the cost of the actual work.\n\n- The orchestrator touches only: the `story` CLI, skill invocations, and agent dispatches. Probes, gate captures, spike scripts, and verification runs happen inside build-flow or dispatched subagents — never inline in your session.\n- Never read implementation files, diffs, or full test output into your context. The story file, gate evidence, and structured agent returns are the record; build-flow's `verification.summary` is the test evidence.\n- After `story done`, if your context has grown large, compact before claiming the next story — everything needed to continue (board, learnings, loop state) is on disk.\n\n## Budgets and visibility\n\nTwo budgets come from config: the **stall budget** (`budgets.maxStalls`, default 3) ends a run after that many consecutive turn ends with no board progress — a story claimed, closed, parked, or filed resets it, so a run that keeps landing stories never stops; the **per-story fix budget** (`budgets.maxFixRoundsPerStory`, default 3) caps retries on one story. The loop's status line shows `iteration N · stalls a\u002Fb` at each turn end — your human partner watches it. Runs end on: goal complete, board drained or blocked, or a budget exhausted. The final summary MUST surface parked questions verbatim and list in-review stories awaiting humans.\n\n## Red Flags\n\n**Never:**\n\n- Hand-edit `stories\u002F**`, loop state, learnings, or evidence files — CLI only.\n- Implement outside the story's worktree, or without a claim.\n- Run probes, captures, or verification inline in the worker session — dispatch them; read only structured results back.\n- Run `story done` with uncommitted work in the worktree — the CLI refuses, but the commit is your job, not a formality.\n- Poll or block on a running workflow — completion drives continuation; end your turn instead.\n- Claim another story while one is in flight in this session — one story per iteration; the loop resumes when the current one closes.\n- Launch build-flow with the shell cwd outside the story worktree, or without `args.worktree`.\n- Commit `stories\u002F**` board files into a story branch.\n- Close a story any way other than a passing `story done`.\n- Fake, infer, or self-author a review-gate verdict.\n- Expand a story's scope — file discovered work instead.\n- Merge to main yourself — integration is the CLI's.\n- Continue past a stopped loop, restart it, or edit budgets.\n- Ask your human partner a question mid-run — park the story instead.\n- Swallow parked questions from the final summary.\n- Skip the planner runner, plan inline in the worker session, or pass the raw story to build-flow as one fat task.\n- Dispatch a planner yourself as a plain subagent, at a self-chosen tier, or \"fall back\" to a lesser tier on failure — planning goes through the bundled runner only; failures park.\n- Self-assign `frontier` complexity — that escalation belongs to your human partner at approval time.\n- Unpark a story (`--status todo`) then downgrade its `complexity` to reclaim and re-plan at a cheaper tier — the CLI stamps and enforces the parked tier, but the loophole is closed at the board level: only your human partner clears it (`--clear-park-lock`).\n\n## Integration\n\n- kit:build-flow — per-story implementation (TDD + review), run inside the story worktree.\n- kit:receiving-review — before acting on PR or review feedback.\n- kit:debugging — gate failures with a non-obvious cause.\n- stories:plan — files the work this skill drains; stories:cancel — the stop lever.\n- `references\u002Fpersonas\u002F` — bundled persona templates.\n- `launch.md` — harness-specific launch mechanics for the planner runner, build-flow's result delivery, and persona dispatch; read on demand.\n",{"name":5,"description":7},"main","ffcb87b7a18526a98eccab20c8c12526bb10af96","shared\u002Fstories\u002Fskills\u002Fwork",2,"https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit","https:\u002F\u002Fgithub.com\u002Fshousper","2026-10-27 23:43:43",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add shousper\u002Fclanker-kit --skill work",{"tool":56,"command":57},"bunx","bunx skills add shousper\u002Fclanker-kit --skill work",{"tool":59,"command":60},"pnpm","pnpm dlx skills add shousper\u002Fclanker-kit --skill work","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fwork\u002FSKILL.md",true,[64,70],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fpersonas\u002Fqa-reviewer.md","REFERENCE","参考文档",1770,"https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fwork\u002Freferences\u002Fpersonas\u002Fqa-reviewer.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fpersonas\u002Fvisual-reviewer.md",2441,"https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fwork\u002Freferences\u002Fpersonas\u002Fvisual-reviewer.md",[75,113,129,149,162,174],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":94,"publishedAt":38},"01M6CP3FKPXFKQBY5979X2W9GN","writing-docs","Use when creating or editing documentation of any kind, including Markdown, RST, or HTML pages, READMEs, design docs, ADRs, changelogs, docstrings, and comment blocks. Covers document purpose, headings, paragraphs, lists, procedures, notices, cross-references, code samples, placeholders, example data, and word choice for technical writing.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fwriting\u002Fskills\u002Fwriting-docs\u002FSKILL.md",[81,86,89],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112],"writing","docs","writing docs","design","technical writing","documentation","code","data","markdown","Word","choice","editing","technical","use","html","example","document","references",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":38},"01M6CP39QNRN136HV0F62TMS7P","using-stories","Compressed story-workflow rulebook, injected automatically at session start (including after compaction) in projects with .agents\u002Fshousper-stories\u002Fconfig.json. Use when unsure of the workflow rules mid-session, when asked \"how does the story workflow work here\", or for a story CLI quick reference. DO NOT TRIGGER in projects without .agents\u002Fshousper-stories\u002Fconfig.json, to set up the workflow (stories:setup), to file stories (stories:plan), or to run the loop (stories:work).","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fusing-stories\u002FSKILL.md",[],[120,121,20,37,122,36,33,123,124,32,31,125,126,127,5,27,108,25,128,22],"using stories","cli","quick reference","SET","how","projects","json","Rules","reference",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":138,"publishedAt":38},"01M6CP36Y3D5S74HQQX62D6SMC","setup","Interactive onboarding that turns a repo into a story-workflow project — merge-mode choice, verification gates with test-runner detection, gitignore wiring, optional project-specific reviewer personas. Use when asked to \"set up the story workflow\", \"adopt stories\", \"story init\", \"install the story board\", or when stories:plan \u002F stories:work is wanted but .agents\u002Fshousper-stories\u002Fconfig.json does not exist yet. DO NOT TRIGGER when .agents\u002Fshousper-stories\u002Fconfig.json already exists (use stories:plan to file work, stories:work to execute it), for creating individual stories, or for project scaffolding unrelated to the story workflow.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fsetup\u002FSKILL.md",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000038","人力资源",[131,20,139,140,35,141,123,105,142,5,143,28,144,108,25,22,145,146,147,148],"test","init","file","reviewer","repo","interactive","personas","runner","gitignore","test-runner",{"skillNo":150,"name":31,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":38},"01M6CP33ZJE0SNZAK43Z5RGPDQ","Decomposes a spec or approved design into epics and stories on the story board — sized, dependency-ordered, gated, human-approved, then filed via the story CLI. Use in a project with .agents\u002Fshousper-stories\u002Fconfig.json when there is a design doc (often from kit:brainstorming), spec, requirements file, or feature request to break down; it replaces kit:writing-plans in the workflow chain for story-based projects. Also use for \"file stories\", \"break this into stories\", \"populate the board\". DO NOT TRIGGER in projects without .agents\u002Fshousper-stories\u002Fconfig.json (use kit:writing-plans), for executing stories (stories:work), or for filing a single discovered-work story mid-loop (plain story create).","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fplan\u002FSKILL.md",[],[31,98,95,121,155,20,37,156,157,141,32,125,126,158,5,159,108,160,22,161],"spec","brainstorming","create","design doc","board","dependency","gated",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":38},"01M6CP31SH1DH78VYHRKEW8HK7","cancel","Stops an active story loop and reports where the board stands. Use when asked to \"stop the loop\", \"cancel the story run\", \"halt autonomous story work\", \"kill the worker loop\", or when a runaway run must be shut down. DO NOT TRIGGER for closing a single story (that is story done inside stories:work), for deleting or archiving stories, or for removing the story workflow from a project.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fcancel\u002FSKILL.md",[],[164,20,36,32,5,159,169,108,170,171,23,172,22,173],"autonomous","reports","Story","kill","done",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":188,"publishedAt":38},"01M6CP2Y30HFATGE0T9JTY693H","writing-skills","Creates, edits, and tests Claude skill files (SKILL.md) using TDD methodology with baseline pressure testing and rationalization defense. Use when writing a new skill, modifying an existing skill, optimizing a skill description for discovery (CSO), testing whether a skill triggers correctly, or structuring skill documentation. Enforces RED-GREEN-REFACTOR for process documentation.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[180,183,186,187],{"categoryNo":181,"categoryName":182,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":184,"categoryName":185,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[95,189,190,191,100,192,193,194,195,196,197,198,108,199,200,201,202,203],"writing skills","testing","tdd","methodology","refactor","defense","baseline","discovery","cso","process","red-green-refactor","files","claude skill","new skill","existing skill"]