[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JSKWMQ143RVEQPDCXYM7C":3,"skill-same:01M71JSKWMQ143RVEQPDCXYM7C":66},{"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":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M71JSKWMQ143RVEQPDCXYM7C","plan-work",null,"PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed implementation tasks into the active epic capsule (specs\u002Fepics\u002FeNN-slug\u002F). Produces countable-story-format .md specs and runnable -tasks.yaml files. Use after slice-tasks (step 2). Not a substitute for scope-work (step 1) or slice-tasks (step 2).","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.qwen\u002Fskills\u002Fplan-work\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"plan","plan work","work","Story","implementation","yaml","format","EPIC","use","slice","for","planning","opus","write","active","spine","tasks","files","scope","2026-11-10 10:12:30",false,"---\nname: plan-work\nmodel: opus\ndescription: \"PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed implementation tasks into the active epic capsule (specs\u002Fepics\u002FeNN-slug\u002F). Produces countable-story-format .md specs and runnable -tasks.yaml files. Use after slice-tasks (step 2). Not a substitute for scope-work (step 1) or slice-tasks (step 2).\"\n---\n\n\u003C!-- story: e45s29 -->\n\n# Plan Work\n\n> **Spine position:** Step 3 — scope-work → slice-tasks → plan-work.\n\nProduce a detailed, verifiable implementation plan in the **active epic capsule directory** (`specs\u002Fepics\u002FeNN-slug\u002F`). Output: a story spec `.md` file (countable-story-format) and a decoupled `eNNsYY-tasks.yaml` with runnable verify commands. \"I think it works\" is not a step.\n\n> **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, convert the task into \"step → verify: `\u003Ccmd>`\" pairs here before writing tasks — every task ships a runnable `verify:` or the plan is not done.\n>\n> **RECURSIVE DISCIPLINE** — This lifecycle applies to EVERY task, including updating these skills. Never skip planning because a task is \"meta\" or \"just documentation.\"\n\n## Pre-flight\n\nRead: `release-plan.yaml`, `product\u002FSCOPE_LATEST.yaml`, active `epics\u002F\u003Ccapsule>\u002Fepic.yaml`, `tech-architecture\u002Ftech-stack.md`, `product\u002FGLOSSARY_LATEST.yaml`.\n\n> **ZOOM-OUT MANDATE** (v1.17.0) — If modifying an existing module: (1) State the module's **purpose**. (2) Name its **callers**. (3) List its **contracts**. Cannot answer all three? Stop — scope is misunderstood.\n\nIf this plan touches an existing module, run `assess-impact` first to understand blast radius.\n\n> **DISCOVERY MANDATE** (v1.18.0) — For external API integration, verify the API signature via local docs or search and quote at least one technical detail in the step's context.\n\n> **MULTIPLE INTERPRETATIONS (HARD GATE)** — If the task admits ≥2 valid interpretations, list them and get a user decision before drafting any steps.\n\n> **COMPLEXITY PUSHBACK (HARD GATE)** — Every new abstraction MUST include a one-sentence \"Reason for Depth.\" If it can't be filled non-trivially, the abstraction is premature — use inline code instead.\n\n> **SLOPCHECK (HARD GATE)** — For every external package, tag it `[OK]`, `[SUS]`, or `[SLOP]`. `[SUS]`\u002F`[SLOP]` require human approval before execution.\n\n## Invocation modes\n\n- Default: full plan with zoom-out mandate, impact assessment, slopcheck\n- `--fast`: Skip zoom-out and impact assessment. Use for tasks under 3 BCPs with no module interface changes.\n\n## Process\n\n> **Timing:** `bash scripts\u002Fbp-timing.sh start plan-work` at invocation; `bash scripts\u002Fbp-timing.sh end plan-work` before handoff.\n\n1. **Explore** — Use `Explore` subagent to understand affected modules, existing test patterns, similar prior art, and dependencies.\n\n2. **Draft steps** — Break implementation into the smallest possible steps where each step leaves the codebase working, has one observable outcome, and can be verified with a single command. Red-flag check: name any rationalization you caught before moving to step 3.\n\n3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs\u002Ftech-architecture\u002FeNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0\u002FP1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` \u002F `low` \u002F `medium` \u002F `high`) sourced from the epic's `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include \"no new security findings in affected paths\" in their verify steps. Each task should also include an `allure:` block to drive test reporting: `severity:` maps risk to Allure severity (`P0→critical`, `P1→high`, `P2→normal`, `P3→minor`), and `categories:` is a list of relevant tags like `\"Security Review\"`, wave names, or test categories (see REFERENCE.md for the full template).\n\n   **Requirement delta tags (e45s29):** When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before\u002Fafter content:\n\n   | Tag | When | Required content |\n   |-----|------|------------------|\n   | `ADDED` | New requirement | Full requirement text |\n   | `MODIFIED` | Changed behavior | **Before:** prior behavior · **After:** new behavior |\n   | `REMOVED` | Retired requirement | **Before:** what existed · **After:** (removed) + rationale |\n   | `RENAMED` | ID or title change only | **Before:** old ID\u002Ftitle · **After:** new ID\u002Ftitle |\n\n   Net-new stories (greenfield) use `ADDED` only. `MODIFIED`\u002F`REMOVED`\u002F`RENAMED` without before\u002Fafter blocks fail the plan-work gate.\n\n4. **Verify step format** — Every step MUST follow: `N. \u003CWhat to do> → verify: \u003Crunnable command>`. See [REFERENCE.md](REFERENCE.md) for good\u002Fbad examples.\n\n4a. **Cross-artifact consistency pass (HARD GATE — e45s04)** — Before handoff, run:\n\n```bash\nbash scripts\u002Flib\u002Fplan-consistency-check.sh specs\u002Fepics\u002F\u003Ccapsule>\u002F\n```\n\nPrint CRITICAL \u002F HIGH \u002F MED findings. **CRITICAL or HIGH blocks code generation** — fix capsule artifacts first. MED requires explicit user acknowledgment.\n\n4b. **tasks.yaml failing ledger (e45s06)** — Every new task entry starts with `status: failing`. Only flip to `status: passing` after its `verify:` command exits 0 during `develop-tdd` or `verify-work`. Never pre-mark passing at plan time.\n\n5. **Review with user** — Confirm step order, granularity, and that verify commands are runnable in this project.\n\n## Lifecycle Gates (e45s09)\n\n| Gate | When | Pass condition |\n|------|------|----------------|\n| **Pre-Implementation** | Before `kickoff-branch` \u002F first RED commit | Root-cause stated for bugs; `assess-impact` done for module changes; plan-consistency-check PASS |\n| **Validation** | Story marked done | All tasks `status: passing`; verify evidence in `specs\u002Fverifications\u002F` |\n| **Reopen-don't-refile** | Regression on shipped story | Reopen existing story\u002Fbug — do not create duplicate capsule entries |\n\nAfter writing capsule tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.\n\n## Verify\n\n→ verify: `test -f scripts\u002Flib\u002Fplan-consistency-check.sh && TASKS=$(grep -l '^spec:' specs\u002Fepics\u002F*\u002F*-tasks.yaml 2>\u002Fdev\u002Fnull | sort | head -1) && test -n \"$TASKS\" && bash scripts\u002Flib\u002Fplan-consistency-check.sh \"$(dirname \"$TASKS\")\" >\u002Fdev\u002Fnull 2>&1`\n\n\n\n## Handoff\n\nGate: READY -> next: kickoff-branch\nWrites: state.yaml handoff.next_skill = kickoff-branch\n\n\n\u003C!-- story: e01s01 -->\n\u003C!-- story: e02s02 -->\n\u003C!-- story: e06s01 -->\n\u003C!-- story: e06s02 -->\n\n---\n\n# Plan Work — Reference\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 3–25 | Navigation |\n| 26–27 | Output file formats |\n| 28–31 | Story spec: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-\u003Cslug>.md` |\n| 32–61 | Task checklist: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-tasks.yaml` |\n| 62–64 | Plan template |\n| 65–71 | Story [X.Y]: [title] — Implementation Steps |\n| 72–77 | Steps |\n| 78–85 | Verification Script (Step-by-Step) |\n| 86–89 | Out of scope |\n| 90–94 | Risks |\n| 95–114 | Verify step format rules |\n| 115–116 | Sub-operations |\n| 117–127 | Risk Assignment Heuristics |\n| 128–143 | Requirement delta tags (e45s29) |\n| 144–152 | Define Success |\n| 153–161 | Zoom-Out Check |\n| 162–169 | Slopcheck |\n\n## Output file formats\n\n### Story spec: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-\u003Cslug>.md`\n\nPopulated countable-story-format with all 20 sections. Minimum maturity: 3 (Countable). Acceptance criteria in §17.\n\n### Task checklist: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-tasks.yaml`\n\n```yaml\nstory_id: e01s01\ntitle: Login\nstatus: failing\nbcps: 3\ntasks:\n  - id: 1\n    description: \"Add login form component tests\"\n    verify: \"npm test -- login-form.test.tsx\"\n    risk: P1\n    status: failing   # flip to passing only after verify exits 0 (e45s06)\n    allure:\n      severity: high              # P0→critical, P1→high, P2→normal, P3→minor\n      categories:\n        - \"Auth\"\n        - \"Security Review\"\n```\n\n**Allure severity mapping:**\n- `P0` → `critical`\n- `P1` → `high`\n- `P2` → `normal`\n- `P3` → `minor`\n\n`categories` is a list of relevant tags — wave names, test categories (e.g. `\"unit\"`, `\"integration\"`), or thematic groupings (e.g. `\"Security Review\"`).\n\nUpdate `specs\u002Fepics\u002F\u003Ccapsule>\u002Fepic.yaml` manifest to list the story and its BCPs. Run `bash scripts\u002Fsync-status-from-epics.sh` after structural changes.\n\n## Plan template\n\n```\n### Story [X.Y]: [title] — Implementation Steps\n\n**type:** feat | fix | refactor\n**risk:** P0 | P1 | P2 | P3\n**context:** domain | infra\n**Context**: [One paragraph: what this story implements and why]\n\n## Steps\n\n1. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `\u003Crunnable command>`\n2. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `\u003Crunnable command>`\n...\n\n## Verification Script (Step-by-Step)\n\n[A human-readable, step-by-step script for the user to verify the story's outcome.]\n\n1. [Action 1: e.g. Start the server]\n2. [Action 2: e.g. Open browser to http:\u002F\u002Flocalhost:3000]\n3. [Observation: e.g. Verify that the login modal appears]\n\n## Out of scope\n\n- [Explicit exclusions]\n\n## Risks\n\n- [Anything that could go wrong and how to detect it early]\n```\n\n## Verify step format rules\n\nEvery step MUST follow this exact format:\n```\nN. \u003CWhat to do> → verify: \u003Crunnable command that proves it worked>\n```\n\n**Good examples:**\n```\n1. Add User model with email and name fields → verify: npm test -- user.test.ts\n2. Add POST \u002Fusers endpoint → verify: curl -s -X POST http:\u002F\u002Flocalhost:3000\u002Fusers -d '{\"email\":\"a@b.com\"}' | jq .id\n3. Add email uniqueness constraint → verify: npm test -- user-uniqueness.test.ts\n```\n\n**Bad examples (no verify command):**\n```\n1. Implement the user creation flow\n2. Write tests for the API\n```\n\n## Sub-operations\n\n### Risk Assignment Heuristics\n\nEvery task and story MUST be assigned a `risk:` level (P0, P1, P2, P3). When `specs\u002Ftech-architecture\u002FeNN-TEST_PLAN_LATEST.md` exists for the epic, defer to its scenario risk mapping (`SC-eNNsYY-P0-NN`). Otherwise, apply these heuristics based on BCP and story type:\n\n- **P0**: Critical path, data loss risk, auth\u002Fsecurity boundary, external integration, or high BCP (≥ 5).\n- **P1**: Core feature logic, state mutations, standard business value (BCP 3-4).\n- **P2**: Utility functions, UI layout changes, display-only data, low risk (BCP 2).\n- **P3**: Documentation, cosmetic tweaks, CSS variables, zero behavioral change (BCP 1).\n\n`verify-work` scales its UAT depth based on this field.\n\n### Requirement delta tags (e45s29)\n\nWhen modifying existing behavior in story spec § Requirements:\n\n```markdown\n#### MODIFIED: User can reset password via email link\n**Before:** Password reset required admin approval.\n**After:** Self-service reset via signed email link (expires 1h).\n\n#### REMOVED: Legacy OAuth1 login\n**Before:** OAuth1 provider supported for enterprise SSO.\n**After:** (removed) — provider deprecated; OAuth2 only.\n```\n\nTags: `ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`. `MODIFIED`\u002F`REMOVED`\u002F`RENAMED` without before\u002Fafter → plan-work gate FAIL.\n\n### Define Success\n\nBefore planning, convert task statements into observable \"step → verify: \u003Ccmd>\" pairs:\n- Break the task into observable outcomes (behaviors) rather than implementation steps\n- Write pairs in the format: `[What must be true] → verify: \u003Crunnable command>`\n- Challenge completeness: are all required behaviors covered?\n- Get user confirmation: \"Does this capture everything the task requires?\"\n- Once confirmed, these pairs become the skeleton for plan-work steps\n\n### Zoom-Out Check\n\nWhen modifying an existing module, confirm scope is understood:\n- State the module's **purpose** — what is it responsible for?\n- Name the **callers** — who depends on it?\n- List the **contracts** — what invariants or interfaces must be preserved?\n\nIf you cannot answer all three without deep code archaeology, scope is misunderstood. Clarify with the user before writing steps.\n\n### Slopcheck\n\nFor every external package proposed in the plan, tag each with one of:\n- `[OK]` — package is mature, actively maintained, appropriate scope\n- `[SUS]` — suspiciously broad, has maintenance concerns, or unclear fit\n- `[SLOP]` — unmaintained, known security issues, or out of scope\n\n`[SUS]` and `[SLOP]` require explicit human approval before the step may execute. Document tags inline next to the package name.\n","\u003C!-- story: e45s29 -->\n\n# Plan Work\n\n> **Spine position:** Step 3 — scope-work → slice-tasks → plan-work.\n\nProduce a detailed, verifiable implementation plan in the **active epic capsule directory** (`specs\u002Fepics\u002FeNN-slug\u002F`). Output: a story spec `.md` file (countable-story-format) and a decoupled `eNNsYY-tasks.yaml` with runnable verify commands. \"I think it works\" is not a step.\n\n> **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, convert the task into \"step → verify: `\u003Ccmd>`\" pairs here before writing tasks — every task ships a runnable `verify:` or the plan is not done.\n>\n> **RECURSIVE DISCIPLINE** — This lifecycle applies to EVERY task, including updating these skills. Never skip planning because a task is \"meta\" or \"just documentation.\"\n\n## Pre-flight\n\nRead: `release-plan.yaml`, `product\u002FSCOPE_LATEST.yaml`, active `epics\u002F\u003Ccapsule>\u002Fepic.yaml`, `tech-architecture\u002Ftech-stack.md`, `product\u002FGLOSSARY_LATEST.yaml`.\n\n> **ZOOM-OUT MANDATE** (v1.17.0) — If modifying an existing module: (1) State the module's **purpose**. (2) Name its **callers**. (3) List its **contracts**. Cannot answer all three? Stop — scope is misunderstood.\n\nIf this plan touches an existing module, run `assess-impact` first to understand blast radius.\n\n> **DISCOVERY MANDATE** (v1.18.0) — For external API integration, verify the API signature via local docs or search and quote at least one technical detail in the step's context.\n\n> **MULTIPLE INTERPRETATIONS (HARD GATE)** — If the task admits ≥2 valid interpretations, list them and get a user decision before drafting any steps.\n\n> **COMPLEXITY PUSHBACK (HARD GATE)** — Every new abstraction MUST include a one-sentence \"Reason for Depth.\" If it can't be filled non-trivially, the abstraction is premature — use inline code instead.\n\n> **SLOPCHECK (HARD GATE)** — For every external package, tag it `[OK]`, `[SUS]`, or `[SLOP]`. `[SUS]`\u002F`[SLOP]` require human approval before execution.\n\n## Invocation modes\n\n- Default: full plan with zoom-out mandate, impact assessment, slopcheck\n- `--fast`: Skip zoom-out and impact assessment. Use for tasks under 3 BCPs with no module interface changes.\n\n## Process\n\n> **Timing:** `bash scripts\u002Fbp-timing.sh start plan-work` at invocation; `bash scripts\u002Fbp-timing.sh end plan-work` before handoff.\n\n1. **Explore** — Use `Explore` subagent to understand affected modules, existing test patterns, similar prior art, and dependencies.\n\n2. **Draft steps** — Break implementation into the smallest possible steps where each step leaves the codebase working, has one observable outcome, and can be verified with a single command. Red-flag check: name any rationalization you caught before moving to step 3.\n\n3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs\u002Ftech-architecture\u002FeNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0\u002FP1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` \u002F `low` \u002F `medium` \u002F `high`) sourced from the epic's `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include \"no new security findings in affected paths\" in their verify steps. Each task should also include an `allure:` block to drive test reporting: `severity:` maps risk to Allure severity (`P0→critical`, `P1→high`, `P2→normal`, `P3→minor`), and `categories:` is a list of relevant tags like `\"Security Review\"`, wave names, or test categories (see REFERENCE.md for the full template).\n\n   **Requirement delta tags (e45s29):** When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before\u002Fafter content:\n\n   | Tag | When | Required content |\n   |-----|------|------------------|\n   | `ADDED` | New requirement | Full requirement text |\n   | `MODIFIED` | Changed behavior | **Before:** prior behavior · **After:** new behavior |\n   | `REMOVED` | Retired requirement | **Before:** what existed · **After:** (removed) + rationale |\n   | `RENAMED` | ID or title change only | **Before:** old ID\u002Ftitle · **After:** new ID\u002Ftitle |\n\n   Net-new stories (greenfield) use `ADDED` only. `MODIFIED`\u002F`REMOVED`\u002F`RENAMED` without before\u002Fafter blocks fail the plan-work gate.\n\n4. **Verify step format** — Every step MUST follow: `N. \u003CWhat to do> → verify: \u003Crunnable command>`. See [REFERENCE.md](REFERENCE.md) for good\u002Fbad examples.\n\n4a. **Cross-artifact consistency pass (HARD GATE — e45s04)** — Before handoff, run:\n\n```bash\nbash scripts\u002Flib\u002Fplan-consistency-check.sh specs\u002Fepics\u002F\u003Ccapsule>\u002F\n```\n\nPrint CRITICAL \u002F HIGH \u002F MED findings. **CRITICAL or HIGH blocks code generation** — fix capsule artifacts first. MED requires explicit user acknowledgment.\n\n4b. **tasks.yaml failing ledger (e45s06)** — Every new task entry starts with `status: failing`. Only flip to `status: passing` after its `verify:` command exits 0 during `develop-tdd` or `verify-work`. Never pre-mark passing at plan time.\n\n5. **Review with user** — Confirm step order, granularity, and that verify commands are runnable in this project.\n\n## Lifecycle Gates (e45s09)\n\n| Gate | When | Pass condition |\n|------|------|----------------|\n| **Pre-Implementation** | Before `kickoff-branch` \u002F first RED commit | Root-cause stated for bugs; `assess-impact` done for module changes; plan-consistency-check PASS |\n| **Validation** | Story marked done | All tasks `status: passing`; verify evidence in `specs\u002Fverifications\u002F` |\n| **Reopen-don't-refile** | Regression on shipped story | Reopen existing story\u002Fbug — do not create duplicate capsule entries |\n\nAfter writing capsule tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.\n\n## Verify\n\n→ verify: `test -f scripts\u002Flib\u002Fplan-consistency-check.sh && TASKS=$(grep -l '^spec:' specs\u002Fepics\u002F*\u002F*-tasks.yaml 2>\u002Fdev\u002Fnull | sort | head -1) && test -n \"$TASKS\" && bash scripts\u002Flib\u002Fplan-consistency-check.sh \"$(dirname \"$TASKS\")\" >\u002Fdev\u002Fnull 2>&1`\n\n\n\n## Handoff\n\nGate: READY -> next: kickoff-branch\nWrites: state.yaml handoff.next_skill = kickoff-branch\n\n\n\u003C!-- story: e01s01 -->\n\u003C!-- story: e02s02 -->\n\u003C!-- story: e06s01 -->\n\u003C!-- story: e06s02 -->\n\n---\n\n# Plan Work — Reference\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 3–25 | Navigation |\n| 26–27 | Output file formats |\n| 28–31 | Story spec: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-\u003Cslug>.md` |\n| 32–61 | Task checklist: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-tasks.yaml` |\n| 62–64 | Plan template |\n| 65–71 | Story [X.Y]: [title] — Implementation Steps |\n| 72–77 | Steps |\n| 78–85 | Verification Script (Step-by-Step) |\n| 86–89 | Out of scope |\n| 90–94 | Risks |\n| 95–114 | Verify step format rules |\n| 115–116 | Sub-operations |\n| 117–127 | Risk Assignment Heuristics |\n| 128–143 | Requirement delta tags (e45s29) |\n| 144–152 | Define Success |\n| 153–161 | Zoom-Out Check |\n| 162–169 | Slopcheck |\n\n## Output file formats\n\n### Story spec: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-\u003Cslug>.md`\n\nPopulated countable-story-format with all 20 sections. Minimum maturity: 3 (Countable). Acceptance criteria in §17.\n\n### Task checklist: `specs\u002Fepics\u002F\u003Ccapsule>\u002FeNNsYY-tasks.yaml`\n\n```yaml\nstory_id: e01s01\ntitle: Login\nstatus: failing\nbcps: 3\ntasks:\n  - id: 1\n    description: \"Add login form component tests\"\n    verify: \"npm test -- login-form.test.tsx\"\n    risk: P1\n    status: failing   # flip to passing only after verify exits 0 (e45s06)\n    allure:\n      severity: high              # P0→critical, P1→high, P2→normal, P3→minor\n      categories:\n        - \"Auth\"\n        - \"Security Review\"\n```\n\n**Allure severity mapping:**\n- `P0` → `critical`\n- `P1` → `high`\n- `P2` → `normal`\n- `P3` → `minor`\n\n`categories` is a list of relevant tags — wave names, test categories (e.g. `\"unit\"`, `\"integration\"`), or thematic groupings (e.g. `\"Security Review\"`).\n\nUpdate `specs\u002Fepics\u002F\u003Ccapsule>\u002Fepic.yaml` manifest to list the story and its BCPs. Run `bash scripts\u002Fsync-status-from-epics.sh` after structural changes.\n\n## Plan template\n\n```\n### Story [X.Y]: [title] — Implementation Steps\n\n**type:** feat | fix | refactor\n**risk:** P0 | P1 | P2 | P3\n**context:** domain | infra\n**Context**: [One paragraph: what this story implements and why]\n\n## Steps\n\n1. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `\u003Crunnable command>`\n2. [Step description] (ref: ADR-NNNN or commit SHA) → verify: `\u003Crunnable command>`\n...\n\n## Verification Script (Step-by-Step)\n\n[A human-readable, step-by-step script for the user to verify the story's outcome.]\n\n1. [Action 1: e.g. Start the server]\n2. [Action 2: e.g. Open browser to http:\u002F\u002Flocalhost:3000]\n3. [Observation: e.g. Verify that the login modal appears]\n\n## Out of scope\n\n- [Explicit exclusions]\n\n## Risks\n\n- [Anything that could go wrong and how to detect it early]\n```\n\n## Verify step format rules\n\nEvery step MUST follow this exact format:\n```\nN. \u003CWhat to do> → verify: \u003Crunnable command that proves it worked>\n```\n\n**Good examples:**\n```\n1. Add User model with email and name fields → verify: npm test -- user.test.ts\n2. Add POST \u002Fusers endpoint → verify: curl -s -X POST http:\u002F\u002Flocalhost:3000\u002Fusers -d '{\"email\":\"a@b.com\"}' | jq .id\n3. Add email uniqueness constraint → verify: npm test -- user-uniqueness.test.ts\n```\n\n**Bad examples (no verify command):**\n```\n1. Implement the user creation flow\n2. Write tests for the API\n```\n\n## Sub-operations\n\n### Risk Assignment Heuristics\n\nEvery task and story MUST be assigned a `risk:` level (P0, P1, P2, P3). When `specs\u002Ftech-architecture\u002FeNN-TEST_PLAN_LATEST.md` exists for the epic, defer to its scenario risk mapping (`SC-eNNsYY-P0-NN`). Otherwise, apply these heuristics based on BCP and story type:\n\n- **P0**: Critical path, data loss risk, auth\u002Fsecurity boundary, external integration, or high BCP (≥ 5).\n- **P1**: Core feature logic, state mutations, standard business value (BCP 3-4).\n- **P2**: Utility functions, UI layout changes, display-only data, low risk (BCP 2).\n- **P3**: Documentation, cosmetic tweaks, CSS variables, zero behavioral change (BCP 1).\n\n`verify-work` scales its UAT depth based on this field.\n\n### Requirement delta tags (e45s29)\n\nWhen modifying existing behavior in story spec § Requirements:\n\n```markdown\n#### MODIFIED: User can reset password via email link\n**Before:** Password reset required admin approval.\n**After:** Self-service reset via signed email link (expires 1h).\n\n#### REMOVED: Legacy OAuth1 login\n**Before:** OAuth1 provider supported for enterprise SSO.\n**After:** (removed) — provider deprecated; OAuth2 only.\n```\n\nTags: `ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`. `MODIFIED`\u002F`REMOVED`\u002F`RENAMED` without before\u002Fafter → plan-work gate FAIL.\n\n### Define Success\n\nBefore planning, convert task statements into observable \"step → verify: \u003Ccmd>\" pairs:\n- Break the task into observable outcomes (behaviors) rather than implementation steps\n- Write pairs in the format: `[What must be true] → verify: \u003Crunnable command>`\n- Challenge completeness: are all required behaviors covered?\n- Get user confirmation: \"Does this capture everything the task requires?\"\n- Once confirmed, these pairs become the skeleton for plan-work steps\n\n### Zoom-Out Check\n\nWhen modifying an existing module, confirm scope is understood:\n- State the module's **purpose** — what is it responsible for?\n- Name the **callers** — who depends on it?\n- List the **contracts** — what invariants or interfaces must be preserved?\n\nIf you cannot answer all three without deep code archaeology, scope is misunderstood. Clarify with the user before writing steps.\n\n### Slopcheck\n\nFor every external package proposed in the plan, tag each with one of:\n- `[OK]` — package is mature, actively maintained, appropriate scope\n- `[SUS]` — suspiciously broad, has maintenance concerns, or unclear fit\n- `[SLOP]` — unmaintained, known security issues, or out of scope\n\n`[SUS]` and `[SLOP]` require explicit human approval before the step may execute. Document tags inline next to the package name.\n",{"name":5,"model":31,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".qwen\u002Fskills\u002Fplan-work",23,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add danielvm-git\u002Fbigpowers --skill plan-work",{"tool":58,"command":59},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill plan-work",{"tool":61,"command":62},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill plan-work","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.qwen\u002Fskills\u002Fplan-work\u002FSKILL.md",true,[],[67,87,94,122,145,166],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":38},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[79,80,81,82,83,84,85,29,86],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","never",{"skillNo":88,"name":89,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":38},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[93,84],"negative path",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":103,"publishedAt":38},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000002","文档处理",[32,104,105,106,107,108,109,110,111,112,27,113,114,115,116,117,118,119,120,121],"write document","document","documents","actionable","technical","methodology","high","bmad","standard","when","minimal","bold","sonnet","integrity","organize","sync","directory","guides",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":38},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[129,130,131,112,132,27,133,134,135,136,116,137,138,139,140,141,142,113,143,144],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":38},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[152,153,154,155,156,157,158,159,160,161,162,112,163,29,129,116,164,165],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":183,"publishedAt":38},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[172,175,180],{"categoryNo":173,"categoryName":174,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":181,"categoryName":182,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000033","数据分析师",[184,185,186,187,188,189,190,30,191,116,192,193,194,19,195,196,197,143,198,199],"dashboard","visual","visual dashboard","status","artifacts","http","plans","panel","start","release","opencode","browser","api","architecture","project status","http api"]