[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3E6PEXBXYY2K8TSRTN1JT":3,"skill-same:01M6K3E6PEXBXYY2K8TSRTN1JT":70},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":69},"01M6K3E6PEXBXYY2K8TSRTN1JT","stories",null,"Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.","jstoup111\u002Fai-conductor","jstoup111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1585332?v=4","01M6K374Y0VEFPVCT2KPBAN4HC","James Stoup","01M6K3751X0GFKNBD0198F50XN",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"artifact","when","invoke","gating","conduct","for","claims","true","requests","requirements","active","architecture","do","general","implementation","engineer","only","use","decide","verify","examples","acceptance","2026-11-10 10:12:30",false,"---\nname: stories\nimplicit_invocation: required\ndescription: \"Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.\"\nenforcement: gating\nphase: decide\nstandalone: true\nrequires: [verify-claims]\n---\n\n## Purpose\n\nGenerates granular stories with happy and negative path scenarios, and is the **always-present\nacceptance-criteria artifact** for both tracks:\n- **Product track** — extract stories from the approved PRD's enumerated functional requirements\n  (`FR-N`); each FR is a unit.\n- **Technical track** — no PRD; write *technical stories* (Given\u002FWhen\u002FThen against the technical\n  change) from the technical intent + the approved architecture.\n\nStories run **after** architecture-review (the design is known), so they describe **behavior\n(WHAT)** grounded in the agreed design — but they state observable behavior\u002Facceptance, NOT the\nmechanism (architecture *informs which scenarios exist*; it is not copied as mechanism into story\ntext — the *how* is the plan's job). Negative paths are mandatory — they feed TDD RED phases.\n\nRead the `Scope boundary:` from `.docs\u002Ftrack\u002F\u003Cslug>.md` as binding; preserve the confirmed narrow\u002Fcomprehensive breadth outcome; do not permit a materially broader expansion beyond it unless the operator confirms before it enters the artifact.\n\n**Correctness gate:** acceptance criteria become the definition of done. Apply the `\u002Fverify-claims`\nprotocol — if a scenario encodes an assumption about expected behavior that was never confirmed\n(against the FR, the ADR, or the operator), flag it with its confidence and HARD-BLOCK for approval\n(HALT if autonomous) rather than baking the guess into a Given\u002FWhen\u002FThen.\n\n**Architecture-induced negatives (do not miss these):** because stories follow architecture, every\nfailure mode a design decision introduces (an external call that times out, a queue that drops\u002Fdupes,\na lock that contends) MUST appear as a negative-path story. These are exactly the cases that were\nmissed when stories preceded the design.\n\nIf writing stories reveals a genuine *structural* gap the design lacks (a missing component\u002Fseam), do\nnot paper over it in story text — kick back to `architecture` (which re-opens in amendment mode).\n\n### Documentation boundary\n\nDo not create stories, requirements, acceptance criteria, Done-When items, or notes for writing or\nupdating ordinary project documentation. When the request is documentation-only, route it to\n`\u002Fexplore` for direct documentation delivery. When documentation accompanies functional work, omit\nthe documentation portion entirely and write stories only for the functional behavior.\n\n## Practices\n\n### 1. Load Input\n\n- **Product track:** read the approved PRD from `.docs\u002Fspecs\u002F`; work through its **Functional\n  Requirements (`FR-N`)** — each FR is the unit you extract stories from. **Technical track** (no\n  PRD): derive acceptance criteria from the technical intent + the approved architecture\u002FADRs.\n- Reference tech-context from session if loaded (e.g., Rails-specific negative paths)\n- Review existing stories in `.docs\u002Fstories\u002F` for this feature area (avoid duplicates)\n- **Check for DRAFT stories from `\u002Fbootstrap`** — if stories have `Status: DRAFT`, review and\n  complete them rather than generating from scratch. Fill in `TODO` negative paths, verify happy\n  paths match actual behavior, and change `**Status:** DRAFT` to `**Status:** Accepted` when done.\n- Recall relevant `.memory\u002F` entries\n\n### 2. Generate Stories\n\nWork through the PRD's functional requirements in order. For **each `FR-N`**, write **one or\nmore granular stories** — split a requirement into multiple stories when it spans distinct\nbehaviors, so each story stays small and independently verifiable. Tag every story with the\n`FR-N` it came from (traceability: PRD → story → plan task). Every `FR-N` must be covered by\nat least one story.\n\nFor removal-shaped stories, follow `\u002Fcode-removal`: acceptance criteria describe surviving\nobservable behavior, never that code, files, or symbols no longer exist.\n\n**Every story heading MUST carry an id**, in the form `## Story \u003Cid>: \u003Ctitle>` (`## Story 1: …`,\n`## Story 2.1: …`). The id is machine-parsed, not decorative: the engine splits a stories file into\nper-story blocks by matching `## Story` followed by **whitespace** and an id of `[A-Za-z0-9.-]`.\nA heading with no id — `## Story: Title` — does not match, so the whole file collapses into a single\nunnamed block and three gates silently degrade:\n\n- the mandatory happy-path\u002Fnegative-path check runs once over the **whole file** instead of per\n  story, so a story missing a negative path passes whenever any *other* story in the file has one;\n- per-story plan coverage falls back to a single file-derived id, so a plan covering one story\n  satisfies coverage for all of them;\n- every `story-\u003Cid>` citation in a coherence mapping resolves to nothing and is rejected as a\n  fabricated id — the first loud symptom, and it appears only at land, long after the real mistake.\n\nSeparators other than whitespace after the id are free (`## Story 1: Title` and `## Story 1 — Title`\nboth parse). What is not optional is the id itself.\n\n```markdown\n**Status:** Accepted\n\n## Story 1: [Descriptive Title]\n\n**Requirement:** FR-N\n\nAs a [role], I want [action] so that [outcome].\n\n### Acceptance Criteria\n\n#### Happy Path\n- Given [specific precondition], when [specific action], then [specific expected result]\n- Given [specific precondition], when [specific action], then [specific expected result]\n\n#### Negative Paths\n- Given [precondition], when [invalid input submitted], then [specific error handling]\n- Given [precondition], when [unauthorized access attempted], then [specific rejection]\n- Given [precondition], when [dependency times out], then [specific graceful degradation]\n- Given [precondition], when [concurrent modification occurs], then [specific conflict resolution]\n\nDo not prefix criteria with ids. The engine derives them positionally as\n`S\u003Cstory-heading-id>.\u003Cn>`, numbering happy paths then negative paths in one run — so the\nfirst negative path of Story 1 is `S1.3`, never `S1.N1`. An authored id the engine does\nnot derive is unkeyable and halts `prd_audit`.\n\n### Done When\n- [ ] [Concrete, verifiable output — e.g., POST \u002Fcontacts returns 201 with contact JSON including `id`, `name`, `email`]\n- [ ] [Persistent side effect confirmed — e.g., contact row exists in database with correct attributes]\n- [ ] [Contract\u002Fformat verified — e.g., response envelope matches API contract]\n```\n\n> **\"Done When\" is the primary success gate.** Acceptance criteria describe *behavior*; \"Done When\"\n> defines the measurable outputs `build_review`, `prd_audit`, or `\u002Fcode-review` checks to confirm the story is complete. Every story\n> MUST have a \"Done When\" section. Checkboxes must be concrete and independently verifiable — not\n> restatements of acceptance criteria.\n\n### 3. Mandatory Negative Path Categories\n\nEvery story MUST consider these categories. Not all apply to every story — but each must be\nexplicitly evaluated and included when relevant:\n\n| Category | Applies When | Example |\n|----------|-------------|---------|\n| **Invalid input** | User-facing endpoints, form submissions | Malformed email, empty required fields, SQL injection attempts |\n| **Auth\u002Fpermission failures** | Protected resources | Unauthenticated access, wrong role, expired token |\n| **Timeouts & network errors** | External API calls, DB queries | API unreachable, connection pool exhausted |\n| **Concurrent access** | Shared mutable state | Two users editing same record, race conditions |\n| **Resource exhaustion** | File uploads, batch processing | Disk full, memory limit, connection pool depleted |\n| **Partial failure & rollback** | Multi-step operations | Step 3 of 5 fails — are steps 1-2 rolled back? |\n| **Dependency unavailability** | DB, cache, queue, external APIs | Redis down, database unreachable, S3 outage |\n| **Data integrity** | Writes, updates, deletes | Orphaned records, constraint violations, cascade effects |\n| **Cascade deletion effects** | Entity has dependents (direct or transitive) | User deleted → what happens to their assigned cards, authored comments, owned teams? Test at every FK reference, not just direct parent |\n| **Model-level immutability** | Record should be read-only after creation | Audit log entry, completed transaction — enforce at model layer (readonly!, validation), not just by omitting API endpoints |\n| **Exception class hierarchy** | Code rescues\u002Fcatches specific exception types | Verify rescue clauses match the actual exception tree — e.g., `Stripe::AuthenticationError` is NOT a subclass of `Stripe::CardError`. Test that the right exception type is caught, not a parent or sibling. |\n| **Dedup\u002Fidempotency key analysis** | Any idempotency or deduplication criterion | Verify the dedup key correctly identifies duplicates without false positives (blocking legitimate operations) or false negatives (allowing true duplicates through). Test with edits that should NOT trigger dedup. |\n| **Invariant side-effect on alternate branches** | A happy path delegates a critical side effect (record\u002Fledger write, cleanup, metric, cache invalidation) to a helper, and an alternate branch (error path, no-remote\u002Foffline, degraded mode, early return) can bypass that helper | A no-remote authoring path returns before the helper that writes the authored-ledger entry → the ledger silently misses the key. Write a negative-path scenario asserting the side effect STILL occurs on each alternate branch — do not assume the happy-path test covers it. |\n\n**If tech-context is loaded**, also include stack-specific categories. For Rails:\n- N+1 queries on list endpoints\n- Unsafe migrations on large tables\n- Mass assignment via unexpected params\n- Missing database indexes\n- Background job failure and retry behavior\n\n**Complexity-Aware Depth:** When the feature is classified as **Small** by `\u002Fconduct`'s\ncomplexity assessment, negative paths are required per STORY (at least 1 per story), not per\ncriterion. Focus on the highest-risk negative path for each story (typically validation\u002Fauth).\nFor **Medium** and **Large** features, the full per-criterion rule applies.\n\n### 4. Quality Gates\n\n**GATE: No story is accepted without at least one negative path per acceptance criterion.**\n\nEach negative path MUST be:\n- **Concrete** — \"Given a user with expired JWT, when they request \u002Fapi\u002Forders, then they receive 401 with error body `{error: 'token_expired'}`\"\n- **NOT vague** — Reject: \"handle errors gracefully\" \u002F \"return appropriate error\" \u002F \"fail safely\"\n- **Testable** — Each Given\u002FWhen\u002FThen maps directly to a test assertion\n\n### 5. Save Stories\n\nSave to `.docs\u002Fstories\u002F\u003Cfeature-name>.md` (one file per feature area).\n\nIf stories already exist for this feature area, append new stories to the existing file.\nWhen a DECIDE correction supersedes or modifies an assertion in an accepted story, replace the\nsuperseded story content in place during that DECIDE pass; never defer the correction to a later\nBUILD phase. The story carries no amendment record of any kind. Git history and the spec PR carry\nthe correction's provenance. The corrected artifact becomes part of the spec-branch baseline before\nBUILD begins.\n\nWhen a DECIDE pass amends a story file with pre-existing amendment blocks, resolve every amendment\nblock in that file by folding its determined behavior into the current behavioral text during the\nsame DECIDE pass. If a block's prose cannot determine current behavior, raise it through the\ncorrectness-and-assumption gate rather than deleting it.\n\n**Stamp the canonical approval marker.** Every stories file MUST begin with a `**Status:**`\nline. Once the operator approves the stories, the file carries `**Status:** Accepted` — this is\nthe single canonical approval token the downstream gates require. A file still pending review\ncarries `**Status:** DRAFT`. This is non-negotiable: the engineer land gate\n(`landSpec`\u002F`runAuthoring`) rejects stories lacking `Status: Accepted`, and the daemon backlog\n**skips a merged spec forever** unless its stories declare `Status: Accepted` (no DRAFT). A\nmissing status line is treated as **not approved** — never leave it off.\n\n### 6. Suggest Next Step\n\nAfter stories are written, suggest invoking the `conflict-check` skill to verify no conflicts\nwith existing stories.\n\n## Verification\n\n- [ ] Every story heading carries a machine-parseable id (`## Story \u003Cid>: \u003Ctitle>`) — an\n      id-less heading silently collapses the file into one block and degrades three gates\n- [ ] Every requirement in the design doc has at least one story\n- [ ] Every story has both happy AND negative paths\n- [ ] At least one negative path per acceptance criterion\n- [ ] All negative paths are concrete Given\u002FWhen\u002FThen (not vague)\n- [ ] Every story has a \"Done When\" section with concrete, verifiable output checkboxes\n- [ ] Stack-specific negative paths included if tech-context loaded\n- [ ] Stories saved to `.docs\u002Fstories\u002F\u003Cfeature-name>.md`\n- [ ] No duplicate stories with existing content\n- [ ] Stories file carries the canonical `**Status:** Accepted` marker on approval (not DRAFT, not missing)\n","## Purpose\n\nGenerates granular stories with happy and negative path scenarios, and is the **always-present\nacceptance-criteria artifact** for both tracks:\n- **Product track** — extract stories from the approved PRD's enumerated functional requirements\n  (`FR-N`); each FR is a unit.\n- **Technical track** — no PRD; write *technical stories* (Given\u002FWhen\u002FThen against the technical\n  change) from the technical intent + the approved architecture.\n\nStories run **after** architecture-review (the design is known), so they describe **behavior\n(WHAT)** grounded in the agreed design — but they state observable behavior\u002Facceptance, NOT the\nmechanism (architecture *informs which scenarios exist*; it is not copied as mechanism into story\ntext — the *how* is the plan's job). Negative paths are mandatory — they feed TDD RED phases.\n\nRead the `Scope boundary:` from `.docs\u002Ftrack\u002F\u003Cslug>.md` as binding; preserve the confirmed narrow\u002Fcomprehensive breadth outcome; do not permit a materially broader expansion beyond it unless the operator confirms before it enters the artifact.\n\n**Correctness gate:** acceptance criteria become the definition of done. Apply the `\u002Fverify-claims`\nprotocol — if a scenario encodes an assumption about expected behavior that was never confirmed\n(against the FR, the ADR, or the operator), flag it with its confidence and HARD-BLOCK for approval\n(HALT if autonomous) rather than baking the guess into a Given\u002FWhen\u002FThen.\n\n**Architecture-induced negatives (do not miss these):** because stories follow architecture, every\nfailure mode a design decision introduces (an external call that times out, a queue that drops\u002Fdupes,\na lock that contends) MUST appear as a negative-path story. These are exactly the cases that were\nmissed when stories preceded the design.\n\nIf writing stories reveals a genuine *structural* gap the design lacks (a missing component\u002Fseam), do\nnot paper over it in story text — kick back to `architecture` (which re-opens in amendment mode).\n\n### Documentation boundary\n\nDo not create stories, requirements, acceptance criteria, Done-When items, or notes for writing or\nupdating ordinary project documentation. When the request is documentation-only, route it to\n`\u002Fexplore` for direct documentation delivery. When documentation accompanies functional work, omit\nthe documentation portion entirely and write stories only for the functional behavior.\n\n## Practices\n\n### 1. Load Input\n\n- **Product track:** read the approved PRD from `.docs\u002Fspecs\u002F`; work through its **Functional\n  Requirements (`FR-N`)** — each FR is the unit you extract stories from. **Technical track** (no\n  PRD): derive acceptance criteria from the technical intent + the approved architecture\u002FADRs.\n- Reference tech-context from session if loaded (e.g., Rails-specific negative paths)\n- Review existing stories in `.docs\u002Fstories\u002F` for this feature area (avoid duplicates)\n- **Check for DRAFT stories from `\u002Fbootstrap`** — if stories have `Status: DRAFT`, review and\n  complete them rather than generating from scratch. Fill in `TODO` negative paths, verify happy\n  paths match actual behavior, and change `**Status:** DRAFT` to `**Status:** Accepted` when done.\n- Recall relevant `.memory\u002F` entries\n\n### 2. Generate Stories\n\nWork through the PRD's functional requirements in order. For **each `FR-N`**, write **one or\nmore granular stories** — split a requirement into multiple stories when it spans distinct\nbehaviors, so each story stays small and independently verifiable. Tag every story with the\n`FR-N` it came from (traceability: PRD → story → plan task). Every `FR-N` must be covered by\nat least one story.\n\nFor removal-shaped stories, follow `\u002Fcode-removal`: acceptance criteria describe surviving\nobservable behavior, never that code, files, or symbols no longer exist.\n\n**Every story heading MUST carry an id**, in the form `## Story \u003Cid>: \u003Ctitle>` (`## Story 1: …`,\n`## Story 2.1: …`). The id is machine-parsed, not decorative: the engine splits a stories file into\nper-story blocks by matching `## Story` followed by **whitespace** and an id of `[A-Za-z0-9.-]`.\nA heading with no id — `## Story: Title` — does not match, so the whole file collapses into a single\nunnamed block and three gates silently degrade:\n\n- the mandatory happy-path\u002Fnegative-path check runs once over the **whole file** instead of per\n  story, so a story missing a negative path passes whenever any *other* story in the file has one;\n- per-story plan coverage falls back to a single file-derived id, so a plan covering one story\n  satisfies coverage for all of them;\n- every `story-\u003Cid>` citation in a coherence mapping resolves to nothing and is rejected as a\n  fabricated id — the first loud symptom, and it appears only at land, long after the real mistake.\n\nSeparators other than whitespace after the id are free (`## Story 1: Title` and `## Story 1 — Title`\nboth parse). What is not optional is the id itself.\n\n```markdown\n**Status:** Accepted\n\n## Story 1: [Descriptive Title]\n\n**Requirement:** FR-N\n\nAs a [role], I want [action] so that [outcome].\n\n### Acceptance Criteria\n\n#### Happy Path\n- Given [specific precondition], when [specific action], then [specific expected result]\n- Given [specific precondition], when [specific action], then [specific expected result]\n\n#### Negative Paths\n- Given [precondition], when [invalid input submitted], then [specific error handling]\n- Given [precondition], when [unauthorized access attempted], then [specific rejection]\n- Given [precondition], when [dependency times out], then [specific graceful degradation]\n- Given [precondition], when [concurrent modification occurs], then [specific conflict resolution]\n\nDo not prefix criteria with ids. The engine derives them positionally as\n`S\u003Cstory-heading-id>.\u003Cn>`, numbering happy paths then negative paths in one run — so the\nfirst negative path of Story 1 is `S1.3`, never `S1.N1`. An authored id the engine does\nnot derive is unkeyable and halts `prd_audit`.\n\n### Done When\n- [ ] [Concrete, verifiable output — e.g., POST \u002Fcontacts returns 201 with contact JSON including `id`, `name`, `email`]\n- [ ] [Persistent side effect confirmed — e.g., contact row exists in database with correct attributes]\n- [ ] [Contract\u002Fformat verified — e.g., response envelope matches API contract]\n```\n\n> **\"Done When\" is the primary success gate.** Acceptance criteria describe *behavior*; \"Done When\"\n> defines the measurable outputs `build_review`, `prd_audit`, or `\u002Fcode-review` checks to confirm the story is complete. Every story\n> MUST have a \"Done When\" section. Checkboxes must be concrete and independently verifiable — not\n> restatements of acceptance criteria.\n\n### 3. Mandatory Negative Path Categories\n\nEvery story MUST consider these categories. Not all apply to every story — but each must be\nexplicitly evaluated and included when relevant:\n\n| Category | Applies When | Example |\n|----------|-------------|---------|\n| **Invalid input** | User-facing endpoints, form submissions | Malformed email, empty required fields, SQL injection attempts |\n| **Auth\u002Fpermission failures** | Protected resources | Unauthenticated access, wrong role, expired token |\n| **Timeouts & network errors** | External API calls, DB queries | API unreachable, connection pool exhausted |\n| **Concurrent access** | Shared mutable state | Two users editing same record, race conditions |\n| **Resource exhaustion** | File uploads, batch processing | Disk full, memory limit, connection pool depleted |\n| **Partial failure & rollback** | Multi-step operations | Step 3 of 5 fails — are steps 1-2 rolled back? |\n| **Dependency unavailability** | DB, cache, queue, external APIs | Redis down, database unreachable, S3 outage |\n| **Data integrity** | Writes, updates, deletes | Orphaned records, constraint violations, cascade effects |\n| **Cascade deletion effects** | Entity has dependents (direct or transitive) | User deleted → what happens to their assigned cards, authored comments, owned teams? Test at every FK reference, not just direct parent |\n| **Model-level immutability** | Record should be read-only after creation | Audit log entry, completed transaction — enforce at model layer (readonly!, validation), not just by omitting API endpoints |\n| **Exception class hierarchy** | Code rescues\u002Fcatches specific exception types | Verify rescue clauses match the actual exception tree — e.g., `Stripe::AuthenticationError` is NOT a subclass of `Stripe::CardError`. Test that the right exception type is caught, not a parent or sibling. |\n| **Dedup\u002Fidempotency key analysis** | Any idempotency or deduplication criterion | Verify the dedup key correctly identifies duplicates without false positives (blocking legitimate operations) or false negatives (allowing true duplicates through). Test with edits that should NOT trigger dedup. |\n| **Invariant side-effect on alternate branches** | A happy path delegates a critical side effect (record\u002Fledger write, cleanup, metric, cache invalidation) to a helper, and an alternate branch (error path, no-remote\u002Foffline, degraded mode, early return) can bypass that helper | A no-remote authoring path returns before the helper that writes the authored-ledger entry → the ledger silently misses the key. Write a negative-path scenario asserting the side effect STILL occurs on each alternate branch — do not assume the happy-path test covers it. |\n\n**If tech-context is loaded**, also include stack-specific categories. For Rails:\n- N+1 queries on list endpoints\n- Unsafe migrations on large tables\n- Mass assignment via unexpected params\n- Missing database indexes\n- Background job failure and retry behavior\n\n**Complexity-Aware Depth:** When the feature is classified as **Small** by `\u002Fconduct`'s\ncomplexity assessment, negative paths are required per STORY (at least 1 per story), not per\ncriterion. Focus on the highest-risk negative path for each story (typically validation\u002Fauth).\nFor **Medium** and **Large** features, the full per-criterion rule applies.\n\n### 4. Quality Gates\n\n**GATE: No story is accepted without at least one negative path per acceptance criterion.**\n\nEach negative path MUST be:\n- **Concrete** — \"Given a user with expired JWT, when they request \u002Fapi\u002Forders, then they receive 401 with error body `{error: 'token_expired'}`\"\n- **NOT vague** — Reject: \"handle errors gracefully\" \u002F \"return appropriate error\" \u002F \"fail safely\"\n- **Testable** — Each Given\u002FWhen\u002FThen maps directly to a test assertion\n\n### 5. Save Stories\n\nSave to `.docs\u002Fstories\u002F\u003Cfeature-name>.md` (one file per feature area).\n\nIf stories already exist for this feature area, append new stories to the existing file.\nWhen a DECIDE correction supersedes or modifies an assertion in an accepted story, replace the\nsuperseded story content in place during that DECIDE pass; never defer the correction to a later\nBUILD phase. The story carries no amendment record of any kind. Git history and the spec PR carry\nthe correction's provenance. The corrected artifact becomes part of the spec-branch baseline before\nBUILD begins.\n\nWhen a DECIDE pass amends a story file with pre-existing amendment blocks, resolve every amendment\nblock in that file by folding its determined behavior into the current behavioral text during the\nsame DECIDE pass. If a block's prose cannot determine current behavior, raise it through the\ncorrectness-and-assumption gate rather than deleting it.\n\n**Stamp the canonical approval marker.** Every stories file MUST begin with a `**Status:**`\nline. Once the operator approves the stories, the file carries `**Status:** Accepted` — this is\nthe single canonical approval token the downstream gates require. A file still pending review\ncarries `**Status:** DRAFT`. This is non-negotiable: the engineer land gate\n(`landSpec`\u002F`runAuthoring`) rejects stories lacking `Status: Accepted`, and the daemon backlog\n**skips a merged spec forever** unless its stories declare `Status: Accepted` (no DRAFT). A\nmissing status line is treated as **not approved** — never leave it off.\n\n### 6. Suggest Next Step\n\nAfter stories are written, suggest invoking the `conflict-check` skill to verify no conflicts\nwith existing stories.\n\n## Verification\n\n- [ ] Every story heading carries a machine-parseable id (`## Story \u003Cid>: \u003Ctitle>`) — an\n      id-less heading silently collapses the file into one block and degrades three gates\n- [ ] Every requirement in the design doc has at least one story\n- [ ] Every story has both happy AND negative paths\n- [ ] At least one negative path per acceptance criterion\n- [ ] All negative paths are concrete Given\u002FWhen\u002FThen (not vague)\n- [ ] Every story has a \"Done When\" section with concrete, verifiable output checkboxes\n- [ ] Stack-specific negative paths included if tech-context loaded\n- [ ] Stories saved to `.docs\u002Fstories\u002F\u003Cfeature-name>.md`\n- [ ] No duplicate stories with existing content\n- [ ] Stories file carries the canonical `**Status:** Accepted` marker on approval (not DRAFT, not missing)\n",{"name":5,"phase":37,"requires":46,"standalone":48,"description":7,"enforcement":22,"implicit_invocation":49},[47],"verify-claims",true,"required","main","136b34ec6792f53d0beba330dfa2dffad6c93484","skills\u002Fstories",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":48},[59,62,65],{"tool":60,"command":61},"npx","npx skills add jstoup111\u002Fai-conductor --skill stories",{"tool":63,"command":64},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill stories",{"tool":66,"command":67},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill stories","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[71,89,126,144,163,184],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":41},"01M70YKSA2H7Q9WSRD1ECEGY20","build-review-dependency-hygiene","Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-review-dependency-hygiene\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,26,88,22],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":108,"publishedAt":41},"01M6K3EQQ6ADH3G2RMYK6XE26E","writing-system-tests","Use BEFORE implementing any feature that has stories in .docs\u002Fstories\u002F — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP\u002Frequest-level acceptance tests for headless\u002FAPI projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-tests\u002FSKILL.md",[95,100,103],{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":101,"categoryName":102,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[109,110,111,112,113,114,115,116,117,118,40,119,25,120,121,122,123,22,124,125],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","api","directory","ui","framework","failing","phase","request",{"skillNo":127,"name":47,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":41},"01M6K3EHR0QQ1QY1S9RC6D1WTD","Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fverify-claims\u002FSKILL.md",[],[132,25,38,31,133,24,134,135,26,136,35,36,137,138,139,140,29,141,142,143,21,22,20],"verify claims","adr","decision","claim","mechanics","workflow","code","reports","plan","questions","about","spec",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":41},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd","Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[146,151,152,153,117,154,83,155,156,157,158,84,159,26,36,160,161,162,20,124],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":41},"01M6K3E1HE7267YKFJQ3YFCGW5","stack-land","Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstack-land\u002FSKILL.md",[],[170,171,172,160,25,173,174,175,38,84,176,177,178,179,180,26,181,35,36,182,20,183],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":193,"publishedAt":41},"01M6K3DX3DTQ5MY3XDKDQ8K4JE","simplify","Use only at an active pipeline batch boundary after code has changed. Reviews current-batch duplication, complexity, over-engineering, and domain-modelling defects; do not invoke for ordinary refactors, code review, or requests that merely ask for simpler prose or code.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fsimplify\u002FSKILL.md",[190],{"categoryNo":191,"categoryName":192,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000007","代码审查",[186,194,31,195,158,24,196,197,198,35,36,199,200,138,201,83,202,27,21,22],"complexity","reviews","pipeline","defects","code review","false","ask","batch","boundary"]