@pavp/storywright 1.0.0

package/skills/_components/risks-and-dependencies/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: risks-and-dependencies
+description: Surface technical, product, and organizational risks plus blocking dependencies for a story. Each item has owner, likelihood, mitigation. Returns only the risks+deps block.
+trigger: "internal use by story-* skills"
+intent: Component skill that turns hidden assumptions into tracked risks and dependencies so PMs and tech leads can act on them.
+version: 1.0.0
+inputs:
+  - story-context
+  - business-rules
+  - technical-considerations
+outputs:
+  - risks-and-dependencies-block
+---
+
+## Purpose
+
+Risks and dependencies that aren't written down end up as outages or missed launches. Make them visible at story time.
+
+## When to use
+
+Late in `story-generate`, after business rules and technical considerations are drafted — those inform what's risky.
+
+## Inputs & interpretation
+
+- **story-context** — surface, novelty
+- **business-rules** — compliance/policy items often imply risks
+- **technical-considerations** — new SDKs, new infra, new patterns imply risk
+
+## Application (step-by-step)
+
+1. Enumerate **dependencies** (blocking other work):
+   - Other stories / teams
+   - External APIs (auth providers, payment, analytics)
+   - Infra changes (new env var, new DB column)
+   - Designs / copy / legal sign-off
+2. For each dependency: `<what> · owner · status (READY / IN-PROGRESS / NOT-STARTED) · blocking?`
+3. Enumerate **risks** across 4 categories:
+   - **Technical** (latency, scale, integration brittleness)
+   - **Product** (adoption assumption, UX confusion)
+   - **Security / privacy** (PII exposure, attack surface)
+   - **Operational** (oncall toil, monitoring gap)
+4. For each risk: `<risk> · likelihood (L/M/H) · impact (L/M/H) · mitigation`
+5. If a risk is high-impact AND high-likelihood, flag it `🚨` so it gets attention in review.
+6. Emit under two subheadings: `### Dependencias` and `### Riesgos` (or English).
+
+Example:
+
+```
+### Dependencias
+| Dependencia | Owner | Estado | Bloquea? |
+|---|---|---|---|
+| Google OAuth credentials in staging | Platform team | READY | No |
+| Account-linking design (final) | Design — @maria | IN-PROGRESS | Sí |
+| Legal review of consent copy | Legal — @sam | NOT-STARTED | Sí |
+
+### Riesgos
+| Riesgo | Likelihood | Impact | Mitigación |
+|---|---|---|---|
+| 🚨 Account-linking edge cases not fully scoped | H | H | Spike before pickup; document edge matrix |
+| Workspace domain restriction config drift | M | M | Read domain list from config service, not env var |
+| OAuth callback latency on slow networks | M | L | Add timeout + retry; pre-existing pattern from sign-up |
+```
+
+## Examples
+
+### Good
+
+See above — owners named, statuses observable, mitigations actionable.
+
+### Bad
+
+`- Could be risky.` (no axis, no owner, no mitigation)
+
+## Common Pitfalls
+
+- Listing "the user might not like it" as a risk. Tie to a measurable adoption signal.
+- Owners as "the team". Assign a person or named role.
+- Mitigations as "be careful". Mitigations are actions.
+
+## References
+
+- [[business-rules]]
+- [[invest-checklist]] (Independent check often surfaces dependencies)
+
+<claude-specific>
+Use extended thinking. Risks cluster — surfacing one often reveals others in the same category.
+</claude-specific>

package/skills/story-from-figma/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: story-from-figma
+description: Generate user stories from a Figma file or frame URL. Uses an MCP Figma server to enumerate frames, components, navigation, and states; falls back to asking for screenshots if MCP is unavailable.
+trigger: "story from figma | generate from figma | analizar figma | https://www.figma.com/"
+intent: Multimodal entrypoint skill. Inspects a Figma design, infers user flows and screens, and produces one or more stories via story-generate.
+version: 1.0.0
+inputs:
+  - figma-link
+outputs:
+  - story.jira-wiki.md (per generated story)
+  - story.standard.md (per generated story)
+  - clarifications.md
+composes:
+  - _components/clarification-questions
+  - _components/acceptance-criteria
+  - _components/invest-checklist
+  - _components/definition-of-done
+  - _components/business-rules
+  - _components/edge-cases
+  - _components/analytics-events
+  - _components/risks-and-dependencies
+  - _components/jira-wiki-formatter
+---
+
+## Purpose
+
+A Figma file usually represents N screens / N flows. This skill maps that visual structure into stories — one story per logical user goal, not one per frame.
+
+## When to use
+
+- User pastes a Figma link.
+- User says "generate stories from this design".
+
+## Inputs & interpretation
+
+- **figma-link** — file URL, page URL, or specific frame URL. Detect the scope:
+  - File URL → consider the whole file; ask which page or flow to focus on
+  - Page URL → enumerate frames in that page
+  - Frame URL → single-screen analysis (usually one story)
+
+## Application (step-by-step)
+
+### Phase 0 — MCP availability check
+
+1. Verify an MCP Figma server is connected to Claude Code. See `mcp-figma-notes.md` in this skill folder for setup options.
+2. If MCP is unavailable:
+   - Ask the user to either (a) install an MCP Figma server, (b) export the relevant frames as PNGs and drop them in chat, or (c) paste a textual description of the flows.
+   - Continue under the chosen fallback. The rest of the skill works with screenshots via Claude vision.
+
+### Phase 1 — Inventory
+
+1. List pages in the file (if MCP allows).
+2. For the target page, list frames with:
+   - Frame name
+   - Frame type (entry, modal, error state, empty state, success state, loading, etc.)
+   - Outgoing prototype links (which other frame each interactive element points to)
+3. Identify the **flows** by grouping frames connected by prototype links. One flow = one candidate story (or epic if large).
+
+### Phase 2 — Per-flow inference
+
+For each flow:
+
+1. Identify the **goal** (what user outcome does this flow achieve?).
+2. Identify the **entry point** (where does the user start?).
+3. Enumerate **states**: empty, loading, success, error, edge.
+4. Identify **components** (forms, lists, modals) and their **inputs/outputs**.
+5. Score confidence per inference: HIGH (visible in design), MEDIUM (implied), LOW (assumed). Anything below HIGH gets `> ⚠️ Assumed:` in the output.
+6. Pass the structured inference to `[[story-generate]]` to produce the full story.
+
+### Phase 3 — Splitting check
+
+If a single flow has too many states or branches, run `[[invest-checklist]]` first. If it returns `SPLIT RECOMMENDED`, hand off to `[[story-split]]` before generating.
+
+### Phase 4 — Output
+
+For each story:
+- Emit `story.jira-wiki.md` + `story.standard.md` per the formatter.
+- Emit a single `flow-summary.md` listing all stories produced and the frames they map to, so reviewers can audit traceability.
+
+If any inference is LOW confidence, add to `clarifications.md`.
+
+## Examples
+
+### Good
+
+Input: Figma file URL with 3 flows on the "Auth" page (login, signup, password reset).
+
+Output:
+- 3 stories (one per flow).
+- Each story references the frames it derived from: `Maps to frames: AUTH-001, AUTH-002, AUTH-003`.
+- Account-recovery flow flagged for `[[story-split]]` because it had 12 frames covering multiple recovery methods.
+
+### Bad
+
+One story per frame. Frames are screens; stories are user goals. A single goal may span 5 frames.
+
+## Common Pitfalls
+
+- Treating each frame as a story.
+- Skipping prototype-link analysis — without flow structure, inferred user goals are guesses.
+- Ignoring empty/error/loading states. Designers usually include them; PMs often miss them.
+- Trusting MEDIUM/LOW inferences silently. Always surface them.
+- Generating stories without verifying that the design covers all error paths (often the design only shows the happy path).
+
+## References
+
+- [[story-generate]]
+- [[story-split]]
+- [[clarification-questions]]
+- `./mcp-figma-notes.md` (setup of MCP server)
+
+<claude-specific>
+- Use Claude's native vision when MCP is unavailable and the user drops PNGs.
+- Use extended thinking for flow grouping — prototype links can be ambiguous.
+- Cache the Phase 2 inference checklist across calls.
+- When MCP Figma is available, batch frame metadata fetches into one round trip to minimize tool round-trips.
+</claude-specific>

package/skills/story-from-figma/mcp-figma-notes.md

@@ -0,0 +1,54 @@
+# Setting up a Figma MCP server
+
+`story-from-figma` works best when Claude Code can call a Figma MCP server. This file documents the options known to work; we do **not** ship our own server.
+
+## Option A — Official Figma Dev Mode MCP (recommended)
+
+Figma's Dev Mode MCP exposes file/frame metadata directly to AI agents. Setup:
+
+1. Open Figma → enable Dev Mode on your file/team plan.
+2. From the Dev Mode panel, copy the MCP server URL or token.
+3. In your Claude Code MCP config (`~/.claude/mcp.json` or project `.mcp.json`):
+   ```json
+   {
+     "mcpServers": {
+       "figma": {
+         "type": "http",
+         "url": "https://mcp.figma.com/sse",
+         "headers": {
+           "Authorization": "Bearer ${FIGMA_TOKEN}"
+         }
+       }
+     }
+   }
+   ```
+4. Set `FIGMA_TOKEN` in your shell environment.
+5. Restart Claude Code.
+
+Check availability inside Claude Code: ask "what MCP tools are available for figma?" — expect tools like `figma_get_file`, `figma_get_frame`, `figma_list_frames`.
+
+## Option B — Community Figma MCP
+
+Several community implementations exist (search GitHub for `figma-mcp` or `figma-context-mcp`). Setup is similar but tool names differ. The skill is written to be tool-name-agnostic — it asks Claude to "list pages", "list frames", "fetch frame metadata" using whichever tools the server provides.
+
+## Option C — No MCP (screenshot fallback)
+
+If you cannot set up MCP:
+
+1. In Figma, select the frames you care about.
+2. `Export` → PNG @ 2x.
+3. Drop the PNGs into Claude Code chat alongside the prompt.
+4. The skill will use Claude vision and degrade gracefully — flow structure must be described by the user.
+
+## Permissions reminder
+
+A Figma token gives read access to your designs. Use a **scoped token** with read-only access to the specific team/project. Never commit the token to git.
+
+## Troubleshooting
+
+| Symptom | Likely cause | Fix |
+|---|---|---|
+| "Tool not found" in chat | MCP not connected | Restart Claude Code; verify `~/.claude/mcp.json` |
+| 401 / 403 | Token missing or revoked | Re-issue scoped token |
+| Empty frame list | Figma file is private to another team | Switch token / share file with token's account |
+| Slow responses | Large file | Pass a page URL instead of the whole file URL |

package/skills/story-generate/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: story-generate
+description: Transform an ambiguous prompt, half-baked story, screenshot, or Figma link into a Jira-ready user story with acceptance criteria, DoD, edge cases, and risks. Ask only critical clarifying questions.
+trigger: "generate a user story | write a user story | turn this into a story | crear historia de usuario"
+intent: Top-level orchestrator skill that drives the full story generation flow by composing component skills.
+version: 1.0.0
+inputs:
+  - text
+  - image
+  - figma-link
+outputs:
+  - story.jira-wiki.md
+  - story.standard.md
+  - clarifications.md
+composes:
+  - _components/clarification-questions
+  - _components/acceptance-criteria
+  - _components/invest-checklist
+  - _components/definition-of-done
+  - _components/business-rules
+  - _components/edge-cases
+  - _components/analytics-events
+  - _components/risks-and-dependencies
+  - _components/jira-wiki-formatter
+---
+
+## Purpose
+
+Take whatever the PM has — a one-liner, a half-baked story, a screenshot, a Figma link — and produce a story that an engineer can pick up and ship without follow-up questions. Always output two artifacts (Jira wiki + CommonMark).
+
+## When to use
+
+- The user has a goal but not a story (e.g., "Permitir login con Google").
+- The user pastes a vague story and wants it production-ready.
+- The user drops an image/Figma link and asks for stories.
+
+## Inputs & how to interpret each
+
+### Text prompts
+Anything from a single phrase to a paragraph. If the prompt names only a feature, infer the implicit user goal.
+
+### Local images (PNG/JPG)
+Use vision. Extract:
+- UI elements (buttons, fields, navigation)
+- Visible states (loading, error, success)
+- Inferred flow (what does each element trigger?)
+- Confidence per inference (high / medium / low). Anything below high → add `> ⚠️ Assumed:` blockquote in the output and surface in clarifications.
+
+### Figma links
+If MCP Figma is available (see `[[story-from-figma]]`), use it to enumerate frames, components, navigation. If not, fall back to asking the user to drop screenshots.
+
+## Application (step-by-step)
+
+1. **Detect input type** (text | image | figma-link | mixed). Branch accordingly.
+2. **Intake gap check** — invoke `[[clarification-questions]]`. If it returns BLOCKING questions, **ask first** before drafting.
+3. **Detect language** of input (es | en | other). Output in the input language.
+4. **Draft skeleton** of the structured story (all 15 sections from the template).
+5. **Fill the CORE first** (always required, in order):
+   1. **Title** — concise, ≤8 words.
+   2. **Summary** — single value-focused sentence ("Enable Google login for trial users to reduce signup friction"), NOT a feature label ("Add Google button"). Elevator pitch.
+   3. **User Story** (As a / I want to / so that).
+      - **Persona check:** if role is "user" or "customer", push for sharper ("trial user", "Workspace admin"). Generic personas hide motivation.
+      - **"So that" check:** outcome must be distinct from action. "So I can save my work" = restating; "So I don't lose progress if tab crashes" = real motivation.
+   4. **Acceptance Criteria** via `[[acceptance-criteria]]` — at minimum the happy path + one failure mode.
+   5. **Definition of Done** via `[[definition-of-done]]`.
+
+6. **Fill OPTIONAL sections only if they have real content.** Drop any that would be empty or boilerplate:
+   - Contexto / Business goal — include when there's a stated trigger or KPI
+   - Scope / Out of scope — include when boundaries are non-obvious
+   - `[[business-rules]]` — include when invariants exist beyond the ACs
+   - Technical considerations — include when surface/SDK/flag matters
+   - `[[edge-cases]]` — include when ≥3 high-impact edges exist
+   - `[[analytics-events]]` — include when story has measurable funnel
+   - `[[risks-and-dependencies]]` — include when there are real blockers or unknowns
+
+   The bias is **less is more**. A clean 4-section story beats a 15-section one full of `N/A`.
+6. **Run INVEST self-check** via `[[invest-checklist]]`:
+   - `READY` → continue.
+   - `NOT A STORY` (V failed) → STOP. Tell the user this is a tech task, not a user story. Suggest reframing or combining with user-facing work.
+   - `NEEDS REFINEMENT` (T or N failed) → revise the failing sections in place.
+   - `RUN A SPIKE` (E failed on unknowns) → recommend a 1–2 day investigation; do not split or generate yet.
+   - `SPLIT RECOMMENDED` (I, E, or S failed) → STOP. Hand off to `[[story-split]]`. **Never auto-split.**
+7. **Render outputs** via `[[jira-wiki-formatter]]`:
+   - `story.jira-wiki.md` — Jira wiki markup
+   - `story.standard.md` — CommonMark
+8. **If clarifications remain unresolved** (user skipped them, or low-confidence visual inferences exist):
+   - Emit `clarifications.md` with the outstanding questions
+   - Mark the story output with a `DRAFT` banner at the top
+   - Tell the user explicitly what would unblock promoting from DRAFT to READY
+9. **Present both artifacts** as fenced code blocks. Ask the user whether to save to disk (offer paths under `./stories/<slug>/`).
+
+## Examples
+
+### Good — text prompt
+Input: *"Permitir login con Google"*
+
+Flow:
+1. Run gap check → 3 BLOCKING questions: scope of accounts, account linking, surface (web/mobile/both).
+2. Ask the 3 questions, wait for answers.
+3. Draft + fill all 15 sections.
+4. INVEST → `READY`.
+5. Render both outputs.
+6. Done.
+
+### Good — image input
+Input: screenshot of a dashboard with a filter sidebar.
+
+Flow:
+1. Vision: extract filter categories, infer apply/reset actions.
+2. Confidence on "filters persist across navigation" → MEDIUM → mark as `⚠️ Assumed` and surface in clarifications.
+3. Run gap check → 1 BLOCKING (does this replace or augment current filters?).
+4. Ask, draft, fill, INVEST, render.
+
+### Bad
+
+Input: *"Build the new dashboard"*
+
+Don't draft. The scope is too broad. Run gap check → propose splitting into smaller stories at the **clarification step**, before the story is drafted. (Effectively delegates to `[[story-split]]` upfront.)
+
+## Common Pitfalls
+
+- Drafting before asking the critical questions. Always run intake first.
+- Ignoring confidence in image inferences. If you guessed, say so.
+- Auto-splitting. Never. Propose, wait, then split.
+- Mixing English and Spanish in the output. Pick the input language.
+- Skipping the `clarifications.md` file when assumptions remain.
+
+## References
+
+- [[story-refine]] (use when input is an existing story to improve)
+- [[story-split]] (use when INVEST fails on Independent/Estimable/Small)
+- [[story-from-figma]] (use when input is a Figma link)
+- [[clarification-questions]]
+
+## Output templates
+
+See `templates/story.jira-wiki.md` and `templates/story.standard.md` in this skill's folder for the canonical section ordering and formatting.
+
+<claude-specific>
+- Use extended thinking for INVEST check and for vision confidence scoring.
+- Cache the 15-section taxonomy and component invocation order across calls.
+- When input includes images, attach them to the same message as the prompt to use Claude's native vision (do not describe-then-reason in two steps).
+- Use prompt caching on the component skill bodies (they're long and reused).
+</claude-specific>

package/skills/story-generate/templates/story.jira-wiki.md

@@ -0,0 +1,54 @@
+h2. {{Title}}
+
+*Summary:* {{value-focused one-liner}}
+
+h3. User Story
+* *As a* {{persona}}
+* *I want to* {{action}}
+* *so that* {{outcome}}
+
+h3. Acceptance Criteria
+
+*AC-1: {{scenario title}}*
+* *Given* {{precondition}}
+* *When* {{trigger}}
+* *Then* {{observable outcome}}
+
+h3. Definition of Done
+* (/) {{line 1}}
+* (/) {{line 2}}
+
+----
+
+h3. Contexto
+{{trigger: feedback / OKR / incident / competitor}}
+
+h3. Business Goal
+{{metric or hypothesis this moves}}
+
+h3. Scope
+* {{in 1}}
+
+h3. Out of Scope
+* {{out 1}}
+
+h3. Business Rules
+# {{rule 1}}
+
+h3. Technical Considerations
+* {{api / sdk / flag / data model}}
+
+h3. Dependencies
+||What||Owner||Status||Blocks?||
+|{{dep}}|{{owner}}|{{READY/IN-PROGRESS}}|{{Yes/No}}|
+
+h3. Risks
+||Risk||L||I||Mitigation||
+|{{risk}}|{{L/M/H}}|{{L/M/H}}|{{action}}|
+
+h3. Analytics
+||Event||Trigger||Payload||
+|{{event_name}}|{{when}}|{{fields}}|
+
+h3. Edge Cases
+* *{{axis}}:* {{behavior}}

package/skills/story-generate/templates/story.standard.md

@@ -0,0 +1,59 @@
+# {{Title}}
+
+**Summary:** {{value-focused one-liner}}
+
+## User Story
+- **As a** {{persona}}
+- **I want to** {{action}}
+- **so that** {{outcome}}
+
+## Acceptance Criteria
+
+**AC-1: {{scenario title}}**
+- **Given** {{precondition}}
+- **When** {{trigger}}
+- **Then** {{observable outcome}}
+
+## Definition of Done
+- [ ] {{line 1}}
+- [ ] {{line 2}}
+
+---
+
+<!-- Optional sections — keep only those with content. Delete the rest. -->
+
+## Contexto
+{{trigger: feedback / OKR / incident / competitor}}
+
+## Business Goal
+{{metric or hypothesis this moves}}
+
+## Scope
+- {{in 1}}
+
+## Out of Scope
+- {{out 1}}
+
+## Business Rules
+1. {{rule 1}}
+
+## Technical Considerations
+- {{api / sdk / flag / data model}}
+
+## Dependencies
+| What | Owner | Status | Blocks? |
+|---|---|---|---|
+| {{dep}} | {{owner}} | {{READY/IN-PROGRESS}} | {{Yes/No}} |
+
+## Risks
+| Risk | L | I | Mitigation |
+|---|---|---|---|
+| {{risk}} | {{L/M/H}} | {{L/M/H}} | {{action}} |
+
+## Analytics
+| Event | Trigger | Payload |
+|---|---|---|
+| `{{event_name}}` | {{when}} | {{fields}} |
+
+## Edge Cases
+- **{{axis}}:** {{behavior}}

package/skills/story-refine/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: story-refine
+description: Audit an existing user story for gaps and fill them in place. Surfaces missing AC, DoD, edge cases, risks; asks clarifications only for blocking unknowns. Returns dual-format refined story.
+trigger: "refine this story | improve this story | refinar historia | this story is incomplete"
+intent: Refinement skill for stories that already exist but are incomplete or weakly specified. Composes the same component skills as story-generate but skips the drafting step.
+version: 1.0.0
+inputs:
+  - text
+outputs:
+  - story.jira-wiki.md
+  - story.standard.md
+  - clarifications.md
+composes:
+  - _components/clarification-questions
+  - _components/acceptance-criteria
+  - _components/invest-checklist
+  - _components/definition-of-done
+  - _components/business-rules
+  - _components/edge-cases
+  - _components/analytics-events
+  - _components/risks-and-dependencies
+  - _components/jira-wiki-formatter
+---
+
+## Purpose
+
+When the PM already has a story written but it's missing sections, has hand-wavy ACs, or never went through INVEST, this skill brings it up to standard without rewriting it from scratch.
+
+## When to use
+
+- User pastes an existing story (text) and asks to make it Jira-ready.
+- A story has ACs but no DoD, or vice versa.
+- INVEST gate fails on `Testable` or `Negotiable` — fixable in place (not splittable).
+
+For oversized stories that fail `Independent / Estimable / Small`, hand off to `[[story-split]]` instead.
+
+## Inputs & interpretation
+
+- **text** — existing story. Detect which sections are present, which are missing, which are weak.
+
+## Application (step-by-step)
+
+1. **Parse the existing story.** Map content into the 15-section taxonomy. Note: present / missing / weak.
+2. **Gap-check the weak sections** via `[[clarification-questions]]`. If gaps are inferrable, mark `⚠️ Assumed` and proceed. Only ask BLOCKING questions.
+3. **Detect language** of the existing story; preserve it in the output.
+4. **Fill missing/weak sections** in dependency order:
+   - Reglas de negocio → `[[business-rules]]`
+   - Consideraciones técnicas → inline
+   - Edge cases → `[[edge-cases]]`
+   - Criterios de aceptación → `[[acceptance-criteria]]`
+   - Analytics → `[[analytics-events]]`
+   - Riesgos + dependencias → `[[risks-and-dependencies]]`
+   - DoD → `[[definition-of-done]]`
+5. **Preserve original wording** where it was already good. Mark changed sections with a comment trail at the end of the story:
+   ```
+   ---
+   Refinement log:
+   - Added Edge Cases (8 cases)
+   - Strengthened AC-2 (was untestable: "should work properly")
+   - Added analytics block
+   ```
+6. **Run INVEST** via `[[invest-checklist]]`.
+   - `READY` → render outputs.
+   - `NEEDS REFINEMENT` → iterate on the failing dimension.
+   - `SPLIT RECOMMENDED` → STOP. Tell the user the story should go through `[[story-split]]` instead.
+7. **Render** both outputs via `[[jira-wiki-formatter]]`.
+8. **Emit `clarifications.md`** if assumptions remain unresolved.
+
+## Examples
+
+### Good
+
+Input: a story with title + User Story + 2 vague ACs ("It should be fast", "User can log in").
+
+Output:
+- Original title/user story preserved.
+- AC-1 rewritten to Given/When/Then with observable outcomes.
+- AC-2 split into AC-2 (happy path) and AC-3 (failure path).
+- Added Edge Cases section (5 cases).
+- Added DoD section.
+- Refinement log appended.
+
+### Bad
+
+Rewriting the whole story when only 2 sections were weak. Preserve good content.
+
+## Common Pitfalls
+
+- Treating refine like generate. If the PM already wrote the user goal, don't restate it.
+- Renumbering ACs the team may already reference externally. Append new ACs at the end.
+- Skipping the refinement log. Reviewers need to see what changed.
+
+## References
+
+- [[story-generate]]
+- [[story-split]]
+- [[invest-checklist]]
+
+<claude-specific>
+- Diff the original sections against the refined ones in your reasoning; only emit changes that materially improve the story.
+- Cache the 15-section taxonomy.
+</claude-specific>