Story Workshop

Use this when a team wants a facilitated, multi-step story writing session that starts from user personas, works through acceptance criteria interactively, and ends with polished stories pushed to a project tracker. This is a skill set -- it chains multiple skills with bridge steps between stages.

For writing a single story quickly, use /story-write instead.

Process

Step 1: Establish personas

Start by grounding the session in who the stories are for.

1. Check for existing personas -- look in the personas/ directory. If persona files exist, list them:

   "I found these personas: (list). Which ones are relevant to this session?"

2. If no personas exist, offer two paths:
   • Quick proto-persona -- "Describe the user in 2-3 sentences: their role, what they care about, what frustrates them. I'll create a working proto-persona we can reference."
   • Full persona -- "Want to run /persona-create first to build a proper research-backed persona?"
3. Confirm the persona(s) for this session. All stories will reference these personas in the "As a..." description.

Bridge → Step 2: Persona names and key goals carry forward into scope mapping and story descriptions.

Step 2: Map the feature scope

Collaboratively define what the session will cover.

1. What feature or capability are we writing stories for? (The feature area, not individual stories yet.)
2. What are the boundaries? What's in scope for this session vs. out of scope?
3. Any known constraints? (APIs, third-party services, design system, timeline, team capacity)
4. Any designs or wireframes? (Figma links, screenshots, descriptions)
5. What story format do you need?
   • Default (our standard) -- As a / I want / So that + Gherkin AC + Technical Details + Out of Scope
   • Jira-optimized -- Summary, Description, Acceptance Criteria (Gherkin), Story Points, Labels
   • Linear-optimized -- Title + markdown body with clean headers, priority, labels
   • Custom -- describe your team's template
6. Where should stories go for this session? (This applies to all stories.)
   • Conversation only (default)
   • Linear -- push directly via Linear MCP
   • Jira -- push directly via Atlassian MCP
   • Asana -- push via Asana MCP (if connected)
   • Notion -- create as a Notion page
   • Other -- check available connectors via search_mcp_registry

Based on the feature scope, propose 3-7 candidate stories as one-line descriptions. Get user confirmation on which stories to write.

Bridge → Step 3: The scope boundaries and candidate story list feed into acceptance criteria development.

Step 3: Write acceptance criteria (interactive Gherkin workshop)

For each story in the candidate list, walk through acceptance criteria together:

1. Happy path first -- "What's the main thing the user does, and what should happen?"

   • Draft a Gherkin scenario: Given (context) → When (action) → Then (outcome)
   • Read it back and ask: "Does that capture it?"

2. Error paths -- "What can go wrong? What if the user enters bad data, loses connection, or doesn't have permission?"

   • Draft error scenarios for each realistic failure mode

3. Edge cases -- "What about empty states, maximum limits, concurrent users, or unusual inputs?"

   • Add edge case scenarios where relevant

4. Review the full AC set -- Present all scenarios for the story and ask:

   • "Are we missing any scenarios?"
   • "Are any of these unnecessary?"
   • "Is the scope right -- not too big?"

5. Check story size -- If the AC set suggests more than 1-3 days of work, propose splitting:

   • Split into vertical slices (each delivers end-to-end value)
   • Never split by technical layer
   • Get confirmation before splitting

Repeat for each story in the session.

AI-assisted edge-case coaching: While drafting AC, ask the AI to surface failure modes the room has not named yet: empty states, permission boundaries, concurrency, rate limits, partial saves, offline behavior. Treat the list as prompts, not answers. The team decides which are in scope for this story and which become Out of Scope or separate stories. The goal is to catch the gap in the workshop, not in QA.

Bridge → Step 4: The acceptance criteria become either prototype specs or polished story content.

Step 4: Choose output path

For each story (or the full set), ask:

"Would you like to: A) Generate a UI prototype -- a quick HTML mockup to validate the feature visually before writing final stories B) Write polished stories -- go straight to formatted story output ready for your tracker C) Both -- prototype first, then write stories"

Path A: Prototype

Use the /artium-prototype approach:

• Extract key UI elements from the acceptance criteria
• Generate a branded HTML file at ./prototypes/(feature-slug)/index.html
• Preview for the user
• Capture a screenshot for attaching to stories later
• Close the loop: Show the prototype to the persona's stakeholders or a real user before finalizing stories. If it reveals a missing flow or a wrong assumption, loop back to Step 3 and revise the acceptance criteria. Validating the design before the stories harden is cheaper than reworking shipped tickets.

Path B: Polished stories

For each story, use the /story-write Step 4 format (matching the format chosen in Step 2):

• Write the full story with all sections
• Use the persona name(s) from Step 1 in the "As a..." description
• Include the Gherkin AC developed in Step 3
• Fill in Technical Details, Out of Scope, and Added Context

Path C: Both

Run prototype first, then write stories with the prototype linked.

Step 5: Human review

Present the complete package for all stories written in this session:

Session review: Here are the (N) stories from this session.

(List each story title with a one-line summary)

For each story:

• Is the description accurate?
• Are the acceptance criteria complete?
• Is the scope right?
• Any changes needed?

(If prototypes were generated:)

• Does the prototype match your expectations?

Ready to push to (Linear / Jira / etc.)? Or keep in conversation only?

Do not proceed to Step 6 until the user explicitly approves. Loop back to Step 3 or Step 4 for any story that needs changes.

Step 6: Export to tracker

Push all approved stories to the session-level tracker choice using the /story-write Step 8 process:

1. Show batch summary before pushing:

   Ready to push (N) stories to (tracker). Confirm?

   1. (Story title 1)
   2. (Story title 2) ...

2. Push all stories after confirmation. Remember team, project, and other settings across stories.

   Field mapping: Before the batch push, confirm how the story fields map to the target tracker's fields: estimate to story points, labels to the team's label taxonomy, priority to the tracker's scale, and persona to a component or custom field if the team uses one. Set the mapping once and reuse it for every story in the session so the batch lands consistently.

3. Report results:

   Pushed (N) stories to (tracker):

   • (ID): (Title) -- (tracker URL)
   • ...

4. Handle failures individually -- report which succeeded and offer to retry failures.

See /story-write Step 8 for detailed tracker-specific instructions (Linear, Jira, Asana, Notion).

Related skills

• /story-write -- write a single story (this skill set wraps and extends it)
• /persona-create -- create full research-backed personas (called from Step 1)
• /artium-prototype -- create branded HTML prototypes (called from Step 4)
• /story-split -- break large stories into smaller slices (called from Step 3)
• /story-review -- review existing stories for quality
• /journey-map -- create journey maps that inform story scope

Output locations

Format	Location	Notes
Story text	Conversation	Always produced. Source of truth until pushed.
Prototype	./prototypes/(feature-slug)/index.html	Optional. Branded HTML mockup.
Linear issues	Linear workspace	Via Linear MCP. Batch push supported.
Jira issues	Jira project	Via Atlassian MCP. Batch push supported.
Asana tasks	Asana project	Via Asana MCP (if connected).
Notion pages	Notion workspace	Via Notion MCP.

Scenario: Caregiver submits a refill request for an eligible prescription
  Given Sarah is logged in and viewing Earl's active prescriptions
  And "Lisinopril 10mg" shows as eligible for refill (≥7 days before empty)
  When she taps "Request Refill" on Lisinopril
  And confirms the preferred pharmacy (pre-populated from profile)
  Then a refill request is sent to RxHub
  And she sees a success confirmation with estimated ready date
  And the prescription status updates to "Refill Requested"

Scenario: RxHub returns a refill-too-soon error
  Given Sarah taps "Request Refill" on Atorvastatin
  When the RxHub API returns error code RX-429 (too soon to refill)
  Then she sees: "It's too early to refill this prescription.
       You can request again on [date]."
  And no request is logged in the system

Scenario: Caregiver has no preferred pharmacy on file
  Given Sarah's profile has no preferred pharmacy saved
  When she taps "Request Refill"
  Then she is prompted to select or add a pharmacy before submitting
  And her selection is offered as a save option for future refills