@pavp/storywright 1.13.0 → 1.13.2

package/commands/story-from-figma.md

@@ -13,7 +13,7 @@ Follow the skill's procedure:
 2. Phase 0.5 — detect companion text / screenshots. Use text as canonical for `User Story / Scope / Business Goal`; Figma as canonical for `Components / States / Flows`. Surface conflicts as BLOCKING clarifications. Never silently pick a winner.
 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), hand off to `/story-split` before generating.
-6. Phase 4 — invoke `story-generate` per flow. Emit dual outputs + `flow-summary.md` mapping stories → frames for traceability.
+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.
 
 Output in the input language (text language wins if mixed inputs).

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` + one stub per child + `split-plan.md` decision trail.
+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`).
 8. Coherence check + recursive re-split for children still >1 sprint.
-9. Save artifacts under `./stories/<epic-slug>/`.
+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.13.0",
+  "version": "1.13.2",
   "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

@@ -3,7 +3,7 @@ name: acceptance-criteria
 description: Write acceptance criteria for a user story in Given/When/Then style. Covers happy path, edge cases, and explicit non-goals. Returns only the AC block, never a full story.
 trigger: "internal use by story-* skills"
 intent: Component skill that produces a complete, testable acceptance-criteria block. Pure renderer — does not ask the user questions; relies on context already gathered upstream.
-version: 1.0.0
+version: 1.1.0
 inputs:
   - story-context
   - edge-cases-block
@@ -38,8 +38,8 @@ Invoked by `story-generate` and `story-refine` after the body of the story is dr
    - Then <observable outcome>
    - And <secondary observable outcome>  (optional)
    ```
-6. Number ACs `AC-1`, `AC-2`, …. Stable numbering — never renumber when adding new ones in iterations.
-7. Emit only the AC block. Do NOT include explanations, headers above `## Criterios de Aceptación`, or surrounding prose.
+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.
 
 ## Examples
 

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

@@ -3,7 +3,7 @@ name: storywright-base
 description: Shared base behavior for all storywright top-level skills. Hard rules, canonical output, terminal-only Q, context schema, mechanical deps, V audit, language detect.
 trigger: "internal use by story-* skills"
 intent: Component skill that holds the v2.2 baseline. Top-level skills (story-generate, story-refine, story-split, story-from-figma) compose this and add only their source-specific behavior on top.
-version: 2.4.0
+version: 2.5.0
 inputs:
   - none
 outputs:
@@ -188,7 +188,7 @@ Mechanical counter. Apply the table — do NOT eyeball:
 - ...
 
 #### Acceptance Criteria
-- **Scenario:** [single-outcome scenario name]
+**AC-1: [single-outcome scenario name]**
 - **Given:** [context — surface nouns here drive dep matrix per rule 10]
 - **and Given:** [context]
 - **When:** [single trigger]
@@ -206,6 +206,10 @@ Mechanical counter. Apply the table — do NOT eyeball:
 
 NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No Assumptions block (assumptions get `⚠️ Assumed` inline or are resolved via `AskUserQuestion`). No standalone INVEST section — verdict belongs in the log only.
 
+**Title — no story-number prefix.** The title is the bare story name. NEVER prefix it with a story/sequence number (`Historia 00 —`, `Story 3:`, `HU-01 -`, or any equivalent). Sequence belongs in the ticket ID / filename, not the heading. One title heading, one scheme, every file.
+
+**AC numbering — one scheme only: `AC-N`.** Every acceptance criterion is labelled `**AC-1:**`, `**AC-2:**`, … in ALL output files and ALL languages — never `CA-01`, `Criterio 1`, `Escenario 1`, or any localized variant. The label `AC` is fixed; only the scenario title after it is translated. Numbering is stable: append, never renumber existing ACs across iterations (see `[[acceptance-criteria]]`).
+
 ## Application (step-by-step — every skill follows this skeleton)
 
 0. **Detect companion sources** (image, figma-link, accompanying text). Run conflict detection against the primary input. Run chrome detection using rule 7. Surface conflicts as BLOCKING `AskUserQuestion`.
@@ -232,6 +236,10 @@ NOTHING else. No NFR block. No Edge Cases enumeration. No Dependencies prose. No
 
    **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.
 
+   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:
      - In Rule H ALLOWED list → keep.
      - In Rule H BANNED list → move its content to `story.dev.md`.

package/skills/story-generate/SKILL.md

@@ -56,7 +56,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 dual outputs).
+  - "Continue without split" → proceed with single-story path (fill canonical block → INVEST → render the 3-file trio).
   - "No, keep as-is" → stop. No output written.
 - Do NOT silently auto-split without the AskUserQuestion confirmation.
 

package/skills/story-refine/SKILL.md

@@ -48,7 +48,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 dual outputs).
+  - "Continue without split" → proceed with single-story path (fill canonical block → INVEST → render the 3-file trio).
   - "No, keep as-is" → stop. No output written.
 - Do NOT silently auto-split without the AskUserQuestion confirmation.