story-creation

Story Creation & Management

The distance between "we agreed this in a meeting" and "a developer can start" is a story someone still has to write. This skill writes it — from a transcript, a page, or a sentence — and keeps it honest once filed: drafts that cite where each claim came from, acceptance criteria a reviewer could check, dependencies named in Jira's own vocabulary, and edits that change exactly what the user meant to change. Everything is a proposal until the user approves it; Jira is written to only then.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking when a summary names a thing without stating it, and memory-capture owns any durable write; all three ship with the gutt-pro plugin (this plugin depends on it) — without them, follow the rules below and note the gap in one line. Jira access comes from whatever Atlassian tooling the session surfaces; find it in your tool list — names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. Jira writes exist here, and every one is gated. Stories are created, and fields edited, only when the user asks for that in this session and approves the exact content as it will be written — per story, or as an explicitly named batch. A batch counts as named only where the text the user reads before answering carries every draft and what happens to each — a count or a label standing for them is not that text. Creating and editing issues is outward-facing and not undone by an apology: approval is the gate, and silence is not approval. The one other permitted write is a comment, drafted and posted only after the user approves the exact text. Write markdown and set the tool's content-format parameter to markdown when it exposes one.
2. Every draft cites its source, and gaps stay visible — a dismissal is a claim too. Each draft names where it came from — the transcript passage, the page section, the user's ask. What the source does not say is not invented to round a story out: it goes under open questions, in the draft, where refinement can see it. A plausible detail with no source is the costliest failure here, because it reads exactly like the real thing. Deciding not to draft something carries the same bar: already built, already decided, already filed — each cites what establishes it, and code having shipped is not the tracker agreeing. Where the evidence came back partial — truncated by an output limit, narrowed to one field or one subject — the scope goes inside the claim rather than a footnote under it, because a narrowed search cannot support an absence. A wrong dismissal drops the work silently; a wrong draft only earns a comment.
3. Editing is a diff against the fetched story, never a rewrite — and the diff is shown before the write, always. Read the story as it stands before proposing changes. The proposal shows each field — what it says now, what it would say, and why — and touches nothing the user did not ask about. A one-field change that arrives as a regenerated description resets wording the team already argued over. An ask that already spells out both the old and the new value does not retire the step: only the fetched story settles whether the old value is still what the field says, and the diff is the last place a wrong target or a stale value is visible. Going from fetch straight to write leaves the tool's own confirmation prompt as the only checkpoint, which is not one this skill gets to rely on.
4. Acceptance criteria are checkable or the draft says why not. Each criterion states an observable outcome someone other than the author could verify. Where the source does not support one, the draft carries the open question rather than a vague criterion dressed as a testable one.
5. Work from a captured copy of the source. Take the transcript or page once — pasted or fetched — and draft against that copy. Live re-reads per draft multiply cost and drift; fetch again only when the user says the source changed.
6. Every read passes explicit group_ids, starting with the first one. Take the org group's name from session results or ask; never guess one, and treat scope as server-decided. Where the session has surfaced no group yet, ask before the first read rather than running one unscoped and repairing after. An omitted group_ids does not mean the org group — it means an unspecified set that includes personal scope, and the opening pass, made before there is anything to check results against, is where that goes unnoticed. Scope is then checked again at the output: nothing from another client's engagement enters a draft or a filed story; personal-scope material stays in the in-session proposal, marked as personal. Bare tool names, probed with ToolSearch before concluding one is missing; the mcp__…__ prefix varies per install.
7. Memory writes go through memory-capture — and accepted stories are worth one. Once the user has approved and the stories are filed, offer to capture the outcome — what was asked, what was created, the keys — through memory-capture's gate into the engagement's own group, chosen deliberately on rule 6's never-guess terms and targeted by whatever means memory-capture says targets it. Rejected drafts are not captured; they were proposals.
8. Issue types, fields, and link names come from the organization, not from this skill. Read what the project actually exposes before drafting to it: its issue types, the fields its create screen carries, the link types the instance defines. Never hardcode one and never assume a shape exists because it is common; where what a draft needs is not exposed, say so and draft to what is.