@pavp/storywright 1.14.0 → 1.16.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "storywright",
-  "version": "1.14.0",
+  "version": "1.16.0",
   "description": "PM skills for Claude Code — turn ambiguous inputs (prompts, screenshots, Figma links) into Jira-ready user stories.",
   "author": "pavp",
   "license": "MIT",
@@ -21,7 +21,7 @@
     "skills/_components/edge-cases",
     "skills/_components/analytics-events",
     "skills/_components/risks-and-dependencies",
-    "skills/_components/jira-wiki-formatter"
+    "skills/_components/story-formatter"
   ],
   "commands": [
     "commands/story-generate.md",

package/README.md

@@ -57,7 +57,7 @@ this story is too big, split it:
 <paste a story that visibly mixes flows>
 ```
 
-Outputs always include both `story.jira-wiki.md` (Jira wiki markup) and `story.standard.md` (CommonMark).
+Outputs always include `story.standard.md` (PM-facing CommonMark) and `story.dev.md` (dev-facing CommonMark).
 
 ## Skills
 
@@ -78,7 +78,7 @@ Outputs always include both `story.jira-wiki.md` (Jira wiki markup) and `story.s
 - `edge-cases` — boundary/network/concurrency/permission/state
 - `analytics-events` — funnel events with payload taxonomy
 - `risks-and-dependencies` — risks + blocking deps
-- `jira-wiki-formatter` — dual-format renderer
+- `story-formatter` — portable Markdown renderer
 
 ## Multimodal
 

package/commands/story-batch.md

@@ -12,7 +12,7 @@ Follow the skill's procedure:
 1. Phase 0 — parse the input structurally (numbered → bullets → blank-line blocks). Guard: if no items found, stop with guidance. If exactly 1 item, abort and redirect to `/storywright-story-generate`. Present parsed boundaries and wait for user confirmation.
 2. Phase 1 — run the cohesion gate: extract persona and feature-area nouns per item, build the sharing graph, compute the largest-connected-component percentage. Announce verdict inline as `⚠️ Assumed:` blockquote. Honor PM overrides.
 3. Phase 2 — cohesive batch: one shared clarification round (≤4 questions) over the union of items. Disparate batch: per-item clarifications deferred to base step 5.
-4. Phase 3 — per-item pipeline: run base Application steps 3–11 for each confirmed item. Items with pre-split count ≥2 → SPLIT RECOMMENDED (no trio, flag in summary, continue). Items with INVEST V = FAIL → NOT A STORY (no trio, flag, continue). All other items emit the full `story-N.{standard,jira-wiki,dev}.md` trio.
+4. Phase 3 — per-item pipeline: run base Application steps 3–11 for each confirmed item. Items with pre-split count ≥2 → SPLIT RECOMMENDED (no files, flag in summary, continue). Items with INVEST V = FAIL → NOT A STORY (no files, flag, continue). All other items emit both files `story-N.{standard,dev}.md`.
 5. Phase 4 — cross-item analysis over DRAFTED items only: mechanical NxN dependency matrix, per-story V audit, topological build order.
 6. Phase 5 — emit `backlog-summary.md` (cohesion verdict, INVEST table, dep matrix, V audit, build order, SPLIT RECOMMENDED notes) + `.storywright-context.json`. All files in flat folder `docs/storywright/YYYY-MM-DD-HHmm-batch-<slug>/`.
 

package/commands/story-from-figma.md

@@ -14,6 +14,6 @@ Follow the skill's procedure:
 3. Phase 1 — inventory pages and frames; group by prototype links into flows.
 4. Phase 2 — per flow: identify goal, entry point, states, components. Score per-inference confidence (HIGH/MEDIUM/LOW). Mark MEDIUM/LOW with `> ⚠️ Assumed:` blockquotes.
 5. Phase 3 — for any flow that fails INVEST (Small) OR whose deterministic pre-split count ≥2, STOP that flow's draft, route to `/story-split`, and mark it `SPLIT RECOMMENDED` in `flow-summary.md`. Continue with the other flows.
-6. Phase 4 — invoke `story-generate` per drafted flow. Emit the full 3-file trio per story (`story-<N>.standard.md` + `story-<N>.jira-wiki.md` + `story-<N>.dev.md`) + `flow-summary.md` mapping stories → frames for traceability.
+6. Phase 4 — invoke `story-generate` per drafted flow. Emit both files per story (`story-<N>.standard.md` + `story-<N>.dev.md`) + `flow-summary.md` mapping stories → frames for traceability.
 
 Output in the input language (text language wins if mixed inputs).

package/commands/story-generate.md

@@ -15,12 +15,11 @@ Follow the skill's full procedure:
 4. Fill the CORE sections (Title, Summary, User Story, Acceptance Criteria, Definition of Done).
 5. Fill optional sections only if they have real content (drop empty ones).
 6. Run INVEST pre-split test. If count ≥2, show candidate children + ask via `AskUserQuestion` with options: "Yes, split" / "Continue without split" / "No, keep as-is". Never auto-split silently. For other verdicts (NOT A STORY / NEEDS REFINEMENT / RUN A SPIKE) — STOP and hand off accordingly.
-7. Render three outputs via `jira-wiki-formatter` to `docs/storywright/YYYY-MM-DD-HHmm-<title-slug>/` (current local time, title kebab-case max 5 words). Use the `Write` tool for all files — never ask:
-   - `story.standard.md` — PM-facing CommonMark: observable behavior only, no file paths/imports/component names/CLI commands
-   - `story.jira-wiki.md` — PM-facing Jira wiki markup: same content as standard
-   - `story.dev.md` — dev-facing CommonMark: full technical detail (file paths, imports, Technical Considerations, technical edge cases, DoD with `npm run` commands)
+7. Render two outputs via `story-formatter` to `docs/storywright/YYYY-MM-DD-HHmm-<title-slug>/` (current local time, title kebab-case max 5 words). Use the `Write` tool for all files — never ask:
+   - `story.standard.md` — PM-facing CommonMark: observable behavior only, no file paths/imports/component names/CLI commands; DoD uses plain `- ` bullets (no checkboxes); no pipe tables
+   - `story.dev.md` — dev-facing CommonMark: full technical detail (file paths, imports, Technical Considerations, technical edge cases, DoD with `npm run` commands and `- [ ]` checkboxes)
    - `.storywright-context.json` — resolved session answers: `{"language":"...","persona":"...","naming_pattern":null,"output_folder":"...","resolved_questions":[],"sibling_refs":[]}`
-   Emit `story.standard.md` and `story.jira-wiki.md` as fenced code blocks in chat. Do NOT emit `story.dev.md` in chat.
+   Emit `story.standard.md` as a fenced code block in chat. Do NOT emit `story.dev.md` in chat.
 8. Non-blocking assumptions remain? Mark inline with `⚠️ Assumed:`. Do NOT emit clarifications.md.
 
 Output in the input language (preserve es/en).

package/commands/story-refine.md

@@ -16,10 +16,9 @@ Follow the skill's procedure:
 4. Fill missing/weak sections via component skills. Preserve original wording where good.
 5. Append a "Refinement log" at the end listing what changed.
 6. Run INVEST pre-split test. If count ≥2, show candidate children + ask via `AskUserQuestion` with options: "Yes, split" / "Continue without split" / "No, keep as-is". Never auto-split silently.
-7. Render three outputs via `jira-wiki-formatter` to `docs/storywright/YYYY-MM-DD-HHmm-<title-slug>/` (current local time, title kebab-case max 5 words). Use the `Write` tool for all files — never ask:
-   - `story.standard.md` — PM-facing CommonMark: observable behavior only, no file paths/imports/component names/CLI commands
-   - `story.jira-wiki.md` — PM-facing Jira wiki markup: same content as standard
-   - `story.dev.md` — dev-facing CommonMark: full technical detail (file paths, imports, Technical Considerations, technical edge cases, DoD with `npm run` commands)
+7. Render two outputs via `story-formatter` to `docs/storywright/YYYY-MM-DD-HHmm-<title-slug>/` (current local time, title kebab-case max 5 words). Use the `Write` tool for all files — never ask:
+   - `story.standard.md` — PM-facing CommonMark: observable behavior only, no file paths/imports/component names/CLI commands; DoD uses plain `- ` bullets (no checkboxes); no pipe tables
+   - `story.dev.md` — dev-facing CommonMark: full technical detail (file paths, imports, Technical Considerations, technical edge cases, DoD with `npm run` commands and `- [ ]` checkboxes)
    - `.storywright-context.json` — resolved session answers: `{"language":"...","persona":"...","naming_pattern":null,"output_folder":"...","resolved_questions":[],"sibling_refs":[]}`
-   Emit `story.standard.md` and `story.jira-wiki.md` as fenced code blocks in chat. Do NOT emit `story.dev.md` in chat.
+   Emit `story.standard.md` as a fenced code block in chat. Do NOT emit `story.dev.md` in chat.
 8. Non-blocking assumptions remain? Mark inline with `⚠️ Assumed:`. Do NOT emit clarifications.md.

package/commands/story-split.md

@@ -20,6 +20,6 @@ Follow the skill's procedure:
 4. Draft a split plan as a Markdown table with rationale, pattern, and proposed children.
 5. Run the strategic evaluation: does the split reveal low-value work? Are children equal-sized?
 6. STOP and ask the user to approve / adjust / cancel. Never auto-split.
-7. After approval: write `epic.md` (single file — epic metadata, holds the decision trail; NO `split-plan.md`) + the full 3-file trio per child (`story-<N>.standard.md` + `story-<N>.jira-wiki.md` + `story-<N>.dev.md`).
+7. After approval: write `epic.md` (single file — epic metadata, holds the decision trail; NO `split-plan.md`) + both files per child (`story-<N>.standard.md` + `story-<N>.dev.md`).
 8. Coherence check + recursive re-split for children still >1 sprint.
 9. Save artifacts under the canonical output folder `docs/storywright/YYYY-MM-DD-HHmm-<epic-slug>/`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pavp/storywright",
-  "version": "1.14.0",
+  "version": "1.16.0",
   "description": "PM Skills pack for Claude Code — turn ambiguous inputs (prompts, screenshots, Figma links) into Jira-ready user stories.",
   "keywords": [
     "claude",

package/skills/_components/acceptance-criteria/SKILL.md

@@ -39,7 +39,7 @@ Invoked by `story-generate` and `story-refine` after the body of the story is dr
    - And <secondary observable outcome>  (optional)
    ```
 6. Number ACs `AC-1`, `AC-2`, …. This is the ONLY allowed scheme, in every language — never `CA-01`, `Criterio 1`, `Escenario 1`, or any localized variant. The `AC` label is fixed; translate only the scenario title after it. Stable numbering — never renumber when adding new ones in iterations.
-7. Emit only the AC block. Do NOT include explanations, a section heading above the ACs, or surrounding prose. The host renderer (`[[jira-wiki-formatter]]`) owns the `## Acceptance Criteria` heading.
+7. Emit only the AC block. Do NOT include explanations, a section heading above the ACs, or surrounding prose. The host renderer (`[[story-formatter]]`) owns the `## Acceptance Criteria` heading.
 
 ## Examples
 

package/skills/_components/business-rules/SKILL.md

@@ -17,7 +17,7 @@ Business rules are **policy invariants** the story must respect. They survive ac
 
 ## When to use
 
-After the story body is drafted, before ACs are finalized — so ACs can reference relevant rules. Business Rules are an **optional PM section** (see `[[jira-wiki-formatter]]` — emit in `story.standard.md` / `story.jira-wiki.md` only when non-empty) AND are mirrored in `story.dev.md`. They are policy invariants, not technical detail, so unlike edge-cases they are not dev-only.
+After the story body is drafted, before ACs are finalized — so ACs can reference relevant rules. Business Rules are an **optional PM section** (see `[[story-formatter]]` — emit in `story.standard.md` only when non-empty) AND are also rendered in `story.dev.md`. They are policy invariants, not technical detail, so unlike edge-cases they are not dev-only.
 
 ## Inputs & interpretation
 

package/skills/_components/definition-of-done/SKILL.md

@@ -17,7 +17,7 @@ A Definition of Done is the contract for "shippable". It must be **checkable, ob
 
 ## When to use
 
-Invoked after acceptance criteria and technical considerations are drafted. DoD is **dual-rendered** (see `[[jira-wiki-formatter]]`): the PM-facing files (`story.standard.md` / `story.jira-wiki.md`) carry the **acceptance-only** DoD (no CLI commands, no file-level criteria); `story.dev.md` carries the **full** DoD including CLI commands (`npm run test`) and file-level lines. Produce both projections from the baseline below: PM projection = drop command/file lines; dev projection = keep everything.
+Invoked after acceptance criteria and technical considerations are drafted. DoD is **dual-rendered** (see `[[story-formatter]]`): `story.standard.md` carries the **acceptance-only** DoD projection (no CLI commands, no file-level criteria, plain `- ` bullets — no `- [ ]` checkboxes); `story.dev.md` carries the **full** DoD including CLI commands (`npm run test`), file-level lines, and `- [ ]` checkboxes. Produce both projections from the baseline below: PM projection = drop command/file lines AND strip `[ ]` to plain `- `; dev projection = keep everything including `- [ ]`.
 
 ## Inputs & interpretation
 
@@ -29,7 +29,7 @@ Invoked after acceptance criteria and technical considerations are drafted. DoD
 1. Start from the baseline list below.
 2. Drop lines that don't apply (e.g., no analytics if the story is purely internal).
 3. Add story-specific lines from technical considerations (e.g., "Database migration runs cleanly on staging").
-4. Use checkbox markdown (`- [ ]`) so reviewers can tick during review.
+4. Use checkbox markdown (`- [ ]`) so reviewers can tick during review. **PM projection exception:** when rendering the DoD for `story.standard.md`, replace `- [ ]` with plain `- ` bullets — Jira Cloud does not autoformat task-list syntax. `story.dev.md` keeps `- [ ]` unchanged.
 
 ### Baseline DoD
 

package/skills/_components/edge-cases/SKILL.md

@@ -16,7 +16,7 @@ Edge cases are how engineers find latent risk. Generate them **before** acceptan
 
 ## When to use
 
-**Dev-file only.** Invoked while rendering `story.dev.md` (the dev-facing file), never the PM-facing `story.standard.md` / `story.jira-wiki.md`. `[[storywright-base]]` rule 3 forbids an Edge Cases section in the PM story body — this output lands exclusively in `story.dev.md`. It still informs AC failure paths (`[[acceptance-criteria]]`): the AC covers the observable behavior in the PM files; the enumerated technical edge detail lives in dev.md.
+**Dev-file only.** Invoked while rendering `story.dev.md` (the dev-facing file), never the PM-facing `story.standard.md`. `[[storywright-base]]` rule 3 forbids an Edge Cases section in the PM story body — this output lands exclusively in `story.dev.md`. It still informs AC failure paths (`[[acceptance-criteria]]`): the AC covers the observable behavior in the PM file; the enumerated technical edge detail lives in dev.md.
 
 ## Inputs & interpretation
 

package/skills/_components/{jira-wiki-formatter → story-formatter}/SKILL.md

@@ -1,20 +1,19 @@
 ---
-name: jira-wiki-formatter
-description: Render a story into three files: story.standard.md and story.jira-wiki.md (PM-facing, no technical detail) plus story.dev.md (dev-facing, full technical detail).
+name: story-formatter
+description: Render a story into two files: story.standard.md (PM-facing CommonMark, no technical detail) and story.dev.md (dev-facing CommonMark, full technical detail).
 trigger: "internal use by story-* skills"
-intent: Component skill that takes a structured story and produces three output files following the templates in story-generate/templates.
-version: 2.2.0
+intent: Component skill that takes a structured story and produces two output files following the templates in story-generate/templates.
+version: 3.0.0
 inputs:
   - structured-story
 outputs:
   - story.standard.md
-  - story.jira-wiki.md
   - story.dev.md
 ---
 
 ## Purpose
 
-Stories need to live in Jira AND in any other markdown surface (Notion, Linear, GitHub Issues, internal wikis). Generate both representations from the same source.
+Stories need to live in Jira Cloud, Notion, Linear, GitHub Issues, and any other Markdown surface. Generate a portable CommonMark PM file and a full developer-facing file from the same source.
 
 ## When to use
 
@@ -26,12 +25,11 @@ Final step in `story-generate` and `story-refine`. Always last.
 
 ## Application (step-by-step)
 
-## Audience separation — THREE files
+## Audience separation — TWO files
 
 | File | Audience | Technical detail |
 |---|---|---|
 | `story.standard.md` | PM, stakeholders | ❌ None — no file paths, no imports, no component names, no `npm run X` in DoD |
-| `story.jira-wiki.md` | PM → Jira paste | ❌ None — same content as standard, Jira markup |
 | `story.dev.md` | Developer | ✅ Full — file paths, imports, Technical Considerations, technical edge cases, full DoD with commands |
 
 **What is "technical":** file paths, import statements, component/hook names, API method names, CLI commands (`npm run test`), null/undefined checks, browser API constraints (HTTPS, permissions), specific library flags.
@@ -42,75 +40,43 @@ Final step in `story-generate` and `story-refine`. Always last.
 
 **Pre-emit heading guard (apply before writing any section to any file):**
 - `story.standard.md` and `story.dev.md`: title line must use `#`; every section heading must use `##`. If received content uses `###` or `####` for a section, demote it to `##` before emitting.
-- `story.jira-wiki.md`: title line must use `h2.`; every section heading must use `h3.`. If `h1.` or `h2.` appears on any line after the first heading, correct it to `h3.` before emitting.
 
 Apply silently — no log entry needed for heading-level corrections.
 
-1. Render `story.jira-wiki.md` (PM-facing) using Jira's wiki markup:
-   - Headings: `h1. `, `h2. `, `h3. `
-   - Bold: `*text*`
-   - Italic: `_text_`
-   - Code: `{{code}}` inline, `{code}…{code}` block
-   - Lists: `* item`, `# item` (numbered)
-   - Tables: `||header||header||` then `|cell|cell|`
-   - Panels for callouts: `{panel:title=⚠️ Assumed}…{panel}`
-   - Strip all technical detail (see audience table above)
-2. Render `story.standard.md` (PM-facing) using CommonMark:
+1. Render `story.standard.md` (PM-facing) using CommonMark:
    - Headings: `##`, `###`
    - Bold: `**text**`
    - Italic: `*text*`
    - Code: `` `inline` ``, ```` ``` ```` blocks
    - Lists: `- item`, `1. item`
-   - Tables: standard pipe tables
    - Callouts: `> ⚠️ **Assumed:** …`
    - Strip all technical detail (see audience table above)
-3. Render `story.dev.md` (dev-facing) using CommonMark:
+   - **No pipe tables.** PM files MUST NOT contain pipe-table Markdown (`| col | col |` rows). Render any tabular content as lists instead — Jira Cloud does not autoformat Markdown tables on paste.
+   - **DoD projection:** when rendering the Definition of Done block in `story.standard.md`, strip `[ ]` from each item — emit `- ` plain bullets, not `- [ ]` checkboxes. Jira Cloud does not autoformat task-list syntax into interactive checkboxes; plain bullets paste cleanly. The dev file keeps `- [ ]` unchanged.
+2. Render `story.dev.md` (dev-facing) using CommonMark:
    - Same structure as `story.standard.md` PLUS:
    - Technical Considerations section (file paths, imports, API calls)
    - Edge Cases section (null checks, error states, browser constraints)
-   - DoD includes CLI commands and file-level criteria
+   - DoD includes CLI commands and file-level criteria; uses `- [ ]` checkboxes
    - Refinement log includes technical changes
-4. Section model for PM files = **core + optional (non-technical)**.
+3. Section model for PM files = **core + optional (non-technical)**.
 
    **Core (always emit, in this order):**
    1. Title
    2. User Story (As a / I want to / so that)
    3. Acceptance Criteria (observable behavior only)
-   4. Definition of Done (acceptance criteria only, no commands)
+   4. Definition of Done (acceptance-only projection, plain `- ` bullets — no commands, no `- [ ]`)
 
    **Optional PM sections (emit only if non-empty):**
    5. Business Goal
    6. Scope / Out of Scope
    7. Business Rules
 
-5. **Drop any section with no real content.** An empty heading is noise.
-6. Emit `story.standard.md` and `story.jira-wiki.md` as fenced code blocks in chat (PM-facing). Do NOT emit `story.dev.md` in chat — write to disk only. File persistence is handled by the calling skill via the `Write` tool.
+4. **Drop any section with no real content.** An empty heading is noise.
+5. Emit `story.standard.md` as a fenced code block in chat (PM-facing). Do NOT emit `story.dev.md` in chat — write to disk only. File persistence is handled by the calling skill via the `Write` tool.
 
 ## Examples
 
-### Good — Jira wiki
-
-```
-h2. Login con Google
-
-Permitir a usuarios autenticarse mediante OAuth con Google.
-
-h3. User Story
-*As a* visitante nuevo
-*I want* iniciar sesión con mi cuenta de Google
-*So that* puedo evitar crear una nueva contraseña.
-
-h3. Criterios de Aceptación
-*AC-1: Login exitoso*
-* Given el usuario está en la pantalla de login
-* When toca "Continuar con Google" y autoriza una cuenta válida
-* Then es redirigido al dashboard en <3s
-
-h3. Definition of Done
-* (/) Code merged behind feature flag
-* (/) ACs pass in QA
-```
-
 ### Good — CommonMark
 
 ```
@@ -130,17 +96,16 @@ Permitir a usuarios autenticarse mediante OAuth con Google.
 - Then es redirigido al dashboard en <3s
 
 ## Definition of Done
-- [ ] Code merged behind feature flag
-- [ ] ACs pass in QA
+- Code merged behind feature flag
+- ACs pass in QA
 ```
 
 ## Common Pitfalls
 
-- Mixing Jira and CommonMark in the same file. Pick one per file.
-- Forgetting that Jira's `{code}` block doesn't support all languages — fall back to `{noformat}` for plain text.
-- Emoji in Jira: works in cloud, often mangled in older self-hosted. Keep emojis to non-critical decoration.
+- Emitting `- [ ]` checkboxes in PM-file DoD — use plain `- ` bullets in `story.standard.md`; keep `- [ ]` only in `story.dev.md`.
+- Including pipe tables in PM files — render tabular content as lists instead.
 - Empty headings. Drop.
-- Wrong heading levels: CommonMark output uses `#` (H1) for title, `##` (H2) for sections. Jira uses `h2.` for title, `h3.` for sections. The canonical block in `[[storywright-base]]` uses `###`/`####` as taxonomy shorthand only — do not copy those levels into the rendered artifact.
+- Wrong heading levels: CommonMark output uses `#` (H1) for title, `##` (H2) for sections. The canonical block in `[[storywright-base]]` uses `###`/`####` as taxonomy shorthand only — do not copy those levels into the rendered artifact.
 - Emitting INVEST as a section: INVEST is a process step. Its verdict belongs in the log line only (`INVEST Verdict: READY`), never as a standalone section in the output file.
 
 ## References
@@ -148,5 +113,5 @@ Permitir a usuarios autenticarse mediante OAuth con Google.
 - [[story-generate]] (templates live under `story-generate/templates/`)
 
 <claude-specific>
-Cache both syntax tables (Jira wiki and CommonMark) — they're stable.
+Cache the CommonMark syntax table — it's stable. Remember: PM file DoD uses plain `- ` bullets; dev file DoD uses `- [ ]` checkboxes. PM files must not contain pipe tables.
 </claude-specific>

package/skills/_components/storywright-base/SKILL.md

@@ -31,14 +31,14 @@ If you are reading this through a top-level skill, treat every rule below as non
    - ONE AC Scenario (one Given chain + one `When` + one `Then`).
    If the input naturally needs >1 `When`/`Then`, the skill MUST stop the single-story path and route to `[[story-split]]`.
 
-3. **No mini-PRDs in the PM story body.** PROHIBITED in `story.standard.md` / `story.jira-wiki.md`:
+3. **No mini-PRDs in the PM story body.** PROHIBITED in `story.standard.md`:
    - Non-Functional Requirements blocks (a11y/i18n/perf/tokens) — DoD only.
    - Edge Cases enumerated as their own section — fold into AC failure paths.
    - Dependencies as prose — Jira ticket links only.
    - Per-claim visual specs (pixel measurements, hex inferences) inline — use single banner (rule 5).
    - Logs >3 lines (>5 if SPLIT verdict).
 
-3a. **Technical detail lives in `story.dev.md`.** The content rule 3 bans from the PM body is NOT discarded — it is rendered in the dev-facing file. Edge cases, analytics events, risks/dependencies, technical considerations, and the command-level DoD belong in `story.dev.md`, populated by the enrichment components (Application step 8b). The PM↔dev split is the home for this content; rule 3 governs the PM files, `story.dev.md` carries the technical detail. See `[[jira-wiki-formatter]]` for the audience table.
+3a. **Technical detail lives in `story.dev.md`.** The content rule 3 bans from the PM body is NOT discarded — it is rendered in the dev-facing file. Edge cases, analytics events, risks/dependencies, technical considerations, and the command-level DoD belong in `story.dev.md`, populated by the enrichment components (Application step 8b). The PM↔dev split is the home for this content; rule 3 governs the PM file, `story.dev.md` carries the technical detail. See `[[story-formatter]]` for the audience table.
 
 4. **Output language matches the user's chat language**, not the input's. Auto-detect first via rule 4a; only ask via `AskUserQuestion` if signals split.
 
@@ -96,7 +96,7 @@ If you are reading this through a top-level skill, treat every rule below as non
 
 12. **Passive-goal downstream prompt (rule G).** If the story's `I want to` verb is observational (`view, see, read, browse, look at, inspect, monitor`) AND the `so that` does not name a follow-up user action — ask once via `AskUserQuestion`: "What does the user do with this?". Strengthen the `so that` accordingly. Skip if `so that` already names a downstream action.
 
-13. **PM section whitelist (rule H).** Only these section names may appear in `story.standard.md` and `story.jira-wiki.md`:
+13. **PM section whitelist (rule H).** Only these section names may appear in `story.standard.md`:
 
     **ALLOWED:** User Story, Acceptance Criteria, Definition of Done, Contexto, Business Goal, Scope, Out of Scope, Business Rules. (`**Summary:**` is inline text, not a section heading — it is not subject to this list.)
 
@@ -171,7 +171,7 @@ Mechanical counter. Apply the table — do NOT eyeball:
 
 ## Canonical output shape (this is the WHOLE story — no exceptions)
 
-> **Note:** This block shows the *section taxonomy and rules* — not heading levels or exact markup. The rendered artifact must follow the `story-generate/templates/` files exactly: `#` for title, `##` for sections (CommonMark) or `h2.`/`h3.` (Jira wiki). INVEST is a **process step** — it informs the Verdict line in the log but is NOT emitted as a section in the output artifact.
+> **Note:** This block shows the *section taxonomy and rules* — not heading levels or exact markup. The rendered artifact must follow the `story-generate/templates/` files exactly: `#` for title, `##` for sections (CommonMark). INVEST is a **process step** — it informs the Verdict line in the log but is NOT emitted as a section in the output artifact.
 
 ```markdown
 ### [Title]
@@ -232,15 +232,15 @@ NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No
    - Count ≤1 → continue to step 8 (single-story path).
    - Count ≥2 → execute the **host skill's split behavior** (see Source-specific differential in each top-level skill).
 
-8. **Fill the canonical block** (Use Case + AC + Design Ref + INVEST). Preserve original wording where it was already good. NEVER invent NFR/edge-case/deps sections **in the PM story body** — rule 3 still holds for `story.standard.md` / `story.jira-wiki.md`.
+8. **Fill the canonical block** (Use Case + AC + Design Ref + INVEST). Preserve original wording where it was already good. NEVER invent NFR/edge-case/deps sections **in the PM story body** — rule 3 still holds for `story.standard.md`.
 
-   **Summary line (mandatory).** Generate `**Summary:**` immediately after the title — one sentence, value-focused, no heading. This line is MANDATORY in all three output files. Format: `**Summary:** <sentence>` in CommonMark files, `*Summary:* <sentence>` in the Jira wiki file. Never omit it.
+   **Summary line (mandatory).** Generate `**Summary:**` immediately after the title — one sentence, value-focused, no heading. This line is MANDATORY in both output files. Format: `**Summary:** <sentence>`. Never omit it.
 
    The Summary MUST open with WHAT the deliverable is and WHICH problem it solves, in business language. The rule 3 / rule H ban on technical detail (file paths, imports, component/CLI names) does NOT exempt you from explaining the purpose — "no technical names" means no jargon, NOT "no explanation of what it does." Strip the jargon, keep the purpose.
 
    **For enabling / infra / platform stories this is mandatory and load-bearing.** When the deliverable is plumbing (publishing packages, provisioning a registry, setting up a pipeline, wiring shared config), describing only the process (publish / setup / install) is INSUFFICIENT — a PM reading it must understand what each artifact is FOR and what breaks downstream without it. State the consumer value, not the mechanics. Example: "publish 2 shared packages to a private registry" → the Summary explains what each package does and what stops working if it is missing, never just the publish/install cycle.
 
-8.5. **PM section self-audit (rule H).** Before calling [[jira-wiki-formatter]], enumerate every section drafted for the PM files. For each section name:
+8.5. **PM section self-audit (rule H).** Before calling [[story-formatter]], enumerate every section drafted for the PM file. For each section name:
      - In Rule H ALLOWED list → keep.
      - In Rule H BANNED list → move its content to `story.dev.md`.
      - Not in either list → treat as BANNED, move to `story.dev.md`.
@@ -252,8 +252,8 @@ NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No
    - `[[risks-and-dependencies]]` → `### Dependencias` + `### Riesgos`
    - `[[analytics-events]]` → `### Analytics / Eventos`
    - `[[definition-of-done]]` → full DoD with CLI commands (PM files get the acceptance-only projection)
-   - `[[business-rules]]` → policy invariants (also an *optional* PM section per `[[jira-wiki-formatter]]` when non-empty)
-   None of these may appear in the PM story body except the optional Business Rules section (see Rule H for the full PM section whitelist). Skip any component whose output is empty (drop empty sections — rule 3 / jira-wiki-formatter).
+   - `[[business-rules]]` → policy invariants (also an *optional* PM section per `[[story-formatter]]` when non-empty)
+   None of these may appear in the PM story body except the optional Business Rules section (see Rule H for the full PM section whitelist). Skip any component whose output is empty (drop empty sections — rule 3).
 
 9. **Run INVEST** via `[[invest-checklist]]`.
    - `READY` → render.
@@ -261,15 +261,14 @@ NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No
    - `NEEDS REFINEMENT` → iterate failing dimension, max 1 cycle, then STOP.
    - `NOT A STORY` → tell user it's a tech task and stop.
 
-10. **Render** via `[[jira-wiki-formatter]]`.
+10. **Render** via `[[story-formatter]]`.
     - Derive the output folder: `docs/storywright/YYYY-MM-DD-HHmm-<title-slug>/` where `YYYY-MM-DD-HHmm` is the current local date+time and `<title-slug>` is the story title in kebab-case (max 5 words, drop articles/prepositions).
-    - Use the `Write` tool to persist three files to that folder (create it if it does not exist):
+    - Use the `Write` tool to persist both files to that folder (create it if it does not exist):
       - `story.standard.md` — PM-facing CommonMark, no technical detail
-      - `story.jira-wiki.md` — PM-facing Jira wiki markup, no technical detail
       - `story.dev.md` — dev-facing CommonMark, full technical detail (file paths, imports, technical edge cases, full DoD with commands)
-    - Emit `story.standard.md` and `story.jira-wiki.md` as fenced code blocks in chat. Do NOT emit `story.dev.md` in chat.
+    - Emit `story.standard.md` as a fenced code block in chat. Do NOT emit `story.dev.md` in chat.
     - Write `.storywright-context.json` to the same folder.
-    - Never ask whether to save — always write all four files.
+    - Never ask whether to save — always write both story files and the context JSON.
 
 11. **Log** ≤3 bullets (≤5 if SPLIT) appended at story end. Log type label is host-specific (Generation / Refinement / Split).
 
@@ -307,7 +306,7 @@ Everything else is identical and lives in this base.
 - [[invest-checklist]]
 - [[acceptance-criteria]]
 - [[clarification-questions]]
-- [[jira-wiki-formatter]]
+- [[story-formatter]]
 - [[story-generate]]
 - [[story-refine]]
 - [[story-split]]

package/skills/story-batch/SKILL.md

@@ -8,7 +8,6 @@ inputs:
   - backlog-text
 outputs:
   - story-1.standard.md
-  - story-1.jira-wiki.md
   - story-1.dev.md
   - backlog-summary.md
   - .storywright-context.json
@@ -22,12 +21,12 @@ composes:
   - _components/risks-and-dependencies
   - _components/definition-of-done
   - _components/invest-checklist
-  - _components/jira-wiki-formatter
+  - _components/story-formatter
 ---
 
 ## Purpose
 
-A backlog input usually contains N discrete items — different features, improvements, or requirements listed together. This skill maps that multi-item input into Cohn+Gherkin stories — **one story per item, processed in a single invocation**.
+A backlog input usually contains N discrete items — different features, improvements, or requirements listed together. This skill maps that multi-item input into Cohn+Gherkin stories — **one story per item, processed in a single invocation**. Each story emits two files: `story-N.standard.md` (PM-facing) + `story-N.dev.md` (dev-facing).
 
 **All hard rules, canonical output shape, language detection, terminal-only Q, mechanical NxN dep matrix, per-child V audit, context persistence, and INVEST handling live in `[[storywright-base]]`. Read that first. Anything in this file is a SOURCE-SPECIFIC or SPLIT-BEHAVIOR delta only.**
 
@@ -54,7 +53,7 @@ This skill produces **multiple stories in one invocation** (one per confirmed it
 
 For any item whose deterministic pre-split count ≥2 → STOP that item's draft, mark it `SPLIT RECOMMENDED` in `backlog-summary.md`, and continue with the remaining items. NEVER auto-invoke `[[story-split]]`.
 
-For any item whose INVEST V dimension FAILS → mark it `NOT A STORY` in `backlog-summary.md`, emit no trio, and continue. NEVER stop the batch.
+For any item whose INVEST V dimension FAILS → mark it `NOT A STORY` in `backlog-summary.md`, emit no files, and continue. NEVER stop the batch.
 
 If N=1 after boundary confirmation → abort and instruct the user to use `/storywright-story-generate` instead.
 
@@ -106,11 +105,11 @@ If the PM replies with an override, honor it and re-announce the new mode before
 
 For each confirmed item (1-based index N):
 
-1. Run base Application steps 3–11 verbatim (persona, passive-goal check, gap-check, pre-split count, canonical block, rule H audit, dev enrichment, INVEST, render trio, log).
+1. Run base Application steps 3–11 verbatim (persona, passive-goal check, gap-check, pre-split count, canonical block, rule H audit, dev enrichment, INVEST, render duo, log).
 2. Use filename prefix `story-<N>.` (all items share one flat batch folder).
-3. **Pre-split ≥2:** mark item as `SPLIT RECOMMENDED`, skip drafting the canonical block, emit no trio. Continue to the next item.
-4. **INVEST V = FAIL:** mark item as `NOT A STORY`, emit no trio. Continue to the next item.
-5. **INVEST other failures (T, N, E, I, S):** flag inline with `⚠️` in `backlog-summary.md` but still emit the trio (base behavior).
+3. **Pre-split ≥2:** mark item as `SPLIT RECOMMENDED`, skip drafting the canonical block, emit no files. Continue to the next item.
+4. **INVEST V = FAIL:** mark item as `NOT A STORY`, emit no files. Continue to the next item.
+5. **INVEST other failures (T, N, E, I, S):** flag inline with `⚠️` in `backlog-summary.md` but still emit both files (base behavior).
 
 Only items in `DRAFTED` status (step 10 logged) proceed to the Phase 4 matrix.
 
@@ -124,7 +123,7 @@ Scope: only items that reached `DRAFTED` in Phase 3 participate in the matrix an
 
 ### Phase 5 — Output
 
-Trios are already written by Phase 3 step 10. Emit:
+Story pairs are already written by Phase 3 step 10. Emit:
 
 1. **`backlog-summary.md`** at the batch folder root when N>1 OR any item is SPLIT RECOMMENDED or NOT A STORY:
 
@@ -133,8 +132,8 @@ Trios are already written by Phase 3 step 10. Emit:
 
    Generated: YYYY-MM-DD HH:mm
    Items: N
-   Drafted: D (story trios emitted)
-   Split recommended: S (no trio — run /storywright-story-split per item)
+   Drafted: D (story pairs emitted)
+   Split recommended: S (no story files — run /storywright-story-split per item)
 
    **Cohesion:** COHESIVE | DISPARATE (<cohesion%>, threshold 60%, driver: persona/area/both)
 
@@ -172,7 +171,7 @@ NO `clarifications.md`. NO Edge Cases / NFR sections **in PM files** (they live
 Input: numbered list of 3 checkout-related items.
 - Phase 0 finds 3 items structurally.
 - Phase 1: cohesion% = 100% → COHESIVE, one shared clarification round.
-- Phase 3: items 1 and 2 pass INVEST → trios emitted; item 3 has pre-split ≥2 → SPLIT RECOMMENDED, no trio.
+- Phase 3: items 1 and 2 pass INVEST → story pairs emitted; item 3 has pre-split ≥2 → SPLIT RECOMMENDED, no files.
 - Phase 5: `backlog-summary.md` with 3-row table (2 DRAFTED, 1 SPLIT RECOMMENDED), 2×2 dep matrix over items 1–2.
 
 ### Good — disparate batch

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

@@ -8,7 +8,6 @@ inputs:
   - figma-link
 outputs:
   - story-1.standard.md
-  - story-1.jira-wiki.md
   - story-1.dev.md
   - flow-summary.md
   - .storywright-context.json
@@ -22,7 +21,7 @@ composes:
   - _components/risks-and-dependencies
   - _components/definition-of-done
   - _components/invest-checklist
-  - _components/jira-wiki-formatter
+  - _components/story-formatter
 ---
 
 ## Purpose
@@ -91,8 +90,8 @@ Use the base canonical output shape. Design Reference banner per source-specific
 
 ### Phase 5 — Output
 
-Per drafted flow, render the full trio via `[[jira-wiki-formatter]]` (same 3-file contract as `story-generate` / `story-refine`):
-- `story-<N>.standard.md` + `story-<N>.jira-wiki.md` (PM-facing) + `story-<N>.dev.md` (dev-facing).
+Per drafted flow, render both files via `[[story-formatter]]` (same 2-file contract as `story-generate` / `story-refine`):
+- `story-<N>.standard.md` (PM-facing) + `story-<N>.dev.md` (dev-facing).
 
 If N>1 OR any flow was routed to split:
 - `flow-summary.md` with the matrix, V audit, build order, and SPLIT-RECOMMENDED markers.

package/skills/story-generate/SKILL.md

@@ -10,7 +10,6 @@ inputs:
   - figma-link
 outputs:
   - story.standard.md
-  - story.jira-wiki.md
   - story.dev.md
   - .storywright-context.json
 composes:
@@ -23,12 +22,12 @@ composes:
   - _components/risks-and-dependencies
   - _components/definition-of-done
   - _components/invest-checklist
-  - _components/jira-wiki-formatter
+  - _components/story-formatter
 ---
 
 ## Purpose
 
-Take whatever the PM has — a one-liner, a half-baked story, a screenshot, a Figma link — and produce a Cohn+Gherkin story an engineer can pick up and ship without follow-up questions.
+Take whatever the PM has — a one-liner, a half-baked story, a screenshot, a Figma link — and produce a Cohn+Gherkin story an engineer can pick up and ship without follow-up questions. Emits two files: `story.standard.md` (PM-facing) + `story.dev.md` (dev-facing).
 
 **All hard rules, canonical output shape, language detection, mechanical pre-split test, context persistence, terminal-only Q, and INVEST handling live in `[[storywright-base]]`. Read that first. Anything in this file is a SOURCE-SPECIFIC or SPLIT-BEHAVIOR delta only.**
 
@@ -56,7 +55,7 @@ If the base **deterministic pre-split test** returns count ≥2:
 - Show candidate children + dep notes + V audit.
 - Ask via `AskUserQuestion`: "This story has [N] independent flows. Run split now?" with options:
   - "Yes, split" → execute `[[story-split]]` inline (epic + children + .storywright-context.json).
-  - "Continue without split" → proceed with single-story path (fill canonical block → INVEST → render the 3-file trio).
+  - "Continue without split" → proceed with single-story path (fill canonical block → INVEST → render both files).
   - "No, keep as-is" → stop. No output written.
 - Do NOT silently auto-split without the AskUserQuestion confirmation.
 

package/skills/story-refine/SKILL.md

@@ -10,7 +10,6 @@ inputs:
   - figma-link
 outputs:
   - story.standard.md
-  - story.jira-wiki.md
   - story.dev.md
   - .storywright-context.json
 composes:
@@ -23,12 +22,12 @@ composes:
   - _components/risks-and-dependencies
   - _components/definition-of-done
   - _components/invest-checklist
-  - _components/jira-wiki-formatter
+  - _components/story-formatter
 ---
 
 ## Purpose
 
-Bring an existing user story up to standard *without* turning it into a feature spec.
+Bring an existing user story up to standard *without* turning it into a feature spec. Emits two files: `story.standard.md` (PM-facing) + `story.dev.md` (dev-facing).
 
 **All hard rules, canonical output shape, language detection, mechanical pre-split test, context persistence, terminal-only Q, mechanical NxN dep matrix, per-child V audit, and INVEST handling live in `[[storywright-base]]`. Read that first. Anything in this file is a SOURCE-SPECIFIC or SPLIT-BEHAVIOR delta only.**
 
@@ -48,7 +47,7 @@ If the base **deterministic pre-split test** returns count ≥2:
 - Show candidate children + per-pair dep notes (base rule 10) + V audit (base rule 11).
 - Ask via `AskUserQuestion`: "This story has [N] independent flows. Run split now?" with options:
   - "Yes, split" → execute `[[story-split]]` inline (epic + children + .storywright-context.json).
-  - "Continue without split" → proceed with single-story path (fill canonical block → INVEST → render the 3-file trio).
+  - "Continue without split" → proceed with single-story path (fill canonical block → INVEST → render both files).
   - "No, keep as-is" → stop. No output written.
 - Do NOT silently auto-split without the AskUserQuestion confirmation.
 

package/skills/story-split/SKILL.md

@@ -11,10 +11,8 @@ inputs:
 outputs:
   - epic.md
   - story-1.standard.md
-  - story-1.jira-wiki.md
   - story-1.dev.md
   - story-2.standard.md
-  - story-2.jira-wiki.md
   - story-2.dev.md
   - .storywright-context.json
 composes:
@@ -27,7 +25,7 @@ composes:
   - _components/analytics-events
   - _components/risks-and-dependencies
   - _components/definition-of-done
-  - _components/jira-wiki-formatter
+  - _components/story-formatter
 ---
 
 ## Purpose
@@ -45,7 +43,7 @@ When a story is an epic in disguise, splitting badly is worse than not splitting
 
 This skill IS the split behavior. It always emits multiple files:
 - `epic.md` — title, why-split, INVEST failure reasons, mechanical NxN matrix, build order, V audit per child, list of children. Single file (epic metadata, not a user story).
-- Per child: the full 3-file trio `story-<N>.standard.md` + `story-<N>.jira-wiki.md` + `story-<N>.dev.md`, rendered via `[[jira-wiki-formatter]]` — same contract as every other story-producing skill. Each child is a canonical user story (per base shape).
+- Per child: both files `story-<N>.standard.md` + `story-<N>.dev.md`, rendered via `[[story-formatter]]` — same contract as every other story-producing skill. Each child is a canonical user story (per base shape).
 - `.storywright-context.json` — persisted answers.
 
 NO `split-plan.md`. The plan lives inside `epic.md`.
@@ -116,7 +114,7 @@ Follow the **base Application** skeleton for the front-end behaviors (context lo
 
 5. **STOP and ask the user to approve via `AskUserQuestion`.**
 
-6. **For each approved child, write the base canonical block, then render via `[[jira-wiki-formatter]]` to the 3-file trio** (`story-<N>.standard.md` + `story-<N>.jira-wiki.md` + `story-<N>.dev.md`). The child's enrichment (edge cases, risks, analytics) populates its `story-<N>.dev.md` per base step 8b.
+6. **For each approved child, write the base canonical block, then render via `[[story-formatter]]` to both files** (`story-<N>.standard.md` + `story-<N>.dev.md`). The child's enrichment (edge cases, risks, analytics) populates its `story-<N>.dev.md` per base step 8b.
 
 7. **Build dependency matrix mechanically (base rule 10).** Render in `epic.md`.
 

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

@@ -1,40 +0,0 @@
-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}}
-
-----
-
-{panel:title=PM-facing — no technical detail}
-Technical Considerations, Edge Cases, Analytics, Risks & Dependencies live in story.dev.md (rule 3). Optional sections below — keep only those with content.
-{panel}
-
-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}}