Skip to content
Development
Skill

/story-time

Start the Specify phase of the SPARK loop: the Product Owner interrogates a product idea and turns it into a spec with user stories and testable acceptance criteria. Use when the user brings a new feature idea, product idea or change request that has no spec yet — or wants an

From plugin
aspark
2010 skills7 agents
Install
$ npx -y skills add a-lottes/aSPARK --skill story-time --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/story-time

Context preview

The summary Claude sees to decide when to auto-load this skill.

Start the Specify phase of the SPARK loop: the Product Owner interrogates a product idea and turns it into a spec with user stories and testable acceptance criteria. Use when the user brings a new feature idea, product idea or change request that has no spec yet — or wants an

SKILL.md

story-time.SKILL.md
name: story-time
description: >
  Start the Specify phase of the SPARK loop: the Product Owner interrogates a
  product idea and turns it into a spec with user stories and testable
  acceptance criteria. Use when the user brings a new feature idea, product
  idea or change request that has no spec yet — or wants an existing spec
  challenged and reworked.

/story-time — Specify (Product Owner)

You are running the **Specify** ceremony. The Product Owner challenges the idea; the outcome is a spec — or the insight that the idea shouldn't be built.

Input

The user's feature idea, usually passed as the command argument. If no idea was provided, ask for it before doing anything else.

Steps

1. **Name the feature.** Derive a short kebab-case feature name from the idea (e.g. `weekly-stats-dashboard`). If `.spark/<feature-name>/` already exists, ask the user whether to rework that spec or pick a new name. 2. **Resolve active lenses.** The constitution is the single source of truth. If `.spark/constitution.md` has a *Project Profile & Active Lenses* section, take the active lenses from it and pass their paths in step 3. If there's **no constitution**, do **not** resolve or apply lenses for this run — only give a lightweight **nudge**: glance at the repo (signals in `${CLAUDE_PLUGIN_ROOT}/lenses/README.md`), name the likely type(s) in one line (e.g. "this looks like a public `website` — an `seo` lens would apply"), and point the user to `/charter` to record the profile so the lens activates for every phase. No lens is applied off a fallback guess; nothing is switched on without a constitution entry the user confirmed. 3. **Delegate to the Product Owner.** Invoke the `product-owner` agent with: the user's idea verbatim, the feature name, the path `.spark/<feature-name>/spec.md`, and the spec template from `${CLAUDE_PLUGIN_ROOT}/templates/spec.md`. Point it at `.spark/constitution.md` if that file exists — the spec must live within it. Pass the paths of any active lenses (`${CLAUDE_PLUGIN_ROOT}/lenses/<name>.md`) so the PO captures their concerns as measurable NFRs. 4. **Relay, don't guess.** If the agent returns open questions instead of a spec, put them to the user (use AskUserQuestion where the options are enumerable), then re-invoke the agent with the answers. Repeat until the spec is drafted. 5. **Run the Clarify pass.** Once a draft exists, have the PO scan it for ambiguity against its taxonomy (functional boundaries, data, permissions, error/edge cases, NFRs, integrations, UX states, out-of-scope). Put the returned clarification questions to the user — AskUserQuestion for enumerable choices — and re-invoke the agent to fold each answer into the right section and log it in the spec's *Clarifications* table. Repeat until no high-impact ambiguity is left unresolved or unparked. Don't skip this because the draft "looks complete" — that's exactly when a whole category is silently missing. 6. **Present the result.** Show the user: the sharpened problem statement, the story list with MoSCoW priorities, the non-functional requirements, the named risks/assumptions, what was clarified, and what was cut to Out of Scope. If the PO recommends *not* building the feature, lead with that recommendation and its reasons. 7. **Iterate.** Fold the user's feedback back into the spec via the agent until the user is satisfied. 8. **Walk the gate.** Go through the SPEC GATE checklist at the bottom of the spec together with the user:

  • If the feature is UI-facing, the *Design Review* section is still empty

— the gate stays open. Set status `draft` and hand off to `/look-and-feel`.

  • If design review is N/A (record why), ask the user for approval. Only

on their explicit yes: set status `approved` and check the gate boxes that are genuinely true.

Rules

  • Never set `approved` without the user's explicit approval in this

conversation.

  • The spec contains no solutions — if technical questions come up, park them

for `/sprint-plan`.

Handoff

  • UI-facing feature → **`/look-and-feel`** (Designer checks the spec)
  • Spec approved, no design review needed → **`/sprint-plan`**
  • Idea rejected → archive nothing; leave the spec with status `rejected` as

a documented decision.

Read more
Ships withaspark

A gated agile delivery process for Claude Code: an AI product team (PO, Designer, EM, Reviewer, QA, Release) where every feature must pass a quality gate before it moves on — including real-browser QA.

Get the whole plugin

Other skills on aspark.

charter
Skill

charter

Establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Use once at project start to give the team…

@a-lottes@a-lottesView Skill
demo-day
Skill

demo-day

Hands-on QA in a real browser: the QA Tester clicks through the running app, verifies every acceptance criterion from the spec, explores beyond the happy path…

@a-lottes@a-lottesView Skill
go-live
Skill

go-live

Start the Keep phase of the SPARK loop: the Release Manager runs fresh pre-flight checks, writes the user-facing changelog, prepares tag/PR/ deploy, publishes…

@a-lottes@a-lottesView Skill
increment
Skill

increment

Start the Act phase of the SPARK loop: build the increment strictly following the approved plan, task by task, with progress tracked in the plan. Use after the…

@a-lottes@a-lottesView Skill
next-steps
Skill

next-steps

Have the Product Owner survey the project's current state — shipped features, in-flight work, open findings, standing goals — and propose one concrete next…

@a-lottes@a-lottesView Skill