create-story

Human output. Read ${CLAUDE_PLUGIN_ROOT}/skills/build-item/references/plain-language-output.md once per top-level run; composed skills reuse it. Apply it to every message.

Create a NEW one-off Story (the one-day leaf role — this org's Story type) — an inbound request or ad-hoc piece of work that is NOT part of a sequenced /devstride:plan roadmap — file it where you want in the DevStride map, put it on a board, assign it to the current user, then deliver it end-to-end with the SAME build loop /devstride:build-item runs, exactly ONCE (no plan walk, no next-story selection, no dependency chain). Use /devstride:insert-story instead when the work belongs in an existing sequenced plan's dependency chain — that one splices + numbers + lets the loop pick it up in order; this one is a standalone create + single build.

Argument — free text describing the story, optionally prefixed/suffixed with a parent item or workstream number (e.g. I20100 add rate limiting to webhook intake, F42 ..., or just add rate limiting to webhook intake): $ARGUMENTS

IMPORTANT — the DevStride MCP targets PRODUCTION (api.devstride.com). Every create/update here is a real, user-visible change to the live workspace — there is no draft/sandbox mode.

This skill has two phases: (A) CREATE + PLACE the item interactively (steps 0–1), then (B) DELIVER it by invoking build-item in its one-off mode (step 2). Phase B is the EXACT same branch → build → review → PR → merge → completion ritual the plan loop uses — the only difference is it runs once and is not part of a sequenced plan.

0. Gather placement + assignment — ask at the OUTSET, do not guess

• First, require enough to act on. If $ARGUMENTS is empty, or too thin to write an honest one-paragraph spec from (a bare invocation, or a vague fragment like "fix the thing"), STOP and ask the user what the work actually is — the request and the outcome they want — before creating or resolving anything. Do NOT invent a ticket or proceed on a guess.

Once you have a real description, pin these down (inbound work has no natural home in the graph, so ask — don't guess):

• Where in the map? Ask which parent item to file under — an item at any grouping level of your org's hierarchy (this org: Module / Capability / Epic; I#####) or a workstream/folder (F####). If $ARGUMENTS already carries one, confirm it rather than re-asking; otherwise ask. Resolve with resolve_item / find_parent_candidates (the org's story-flavored leaf type via get_work_type_hierarchy; this org: Story) and NEVER guess a parent — the backend rejects illegal parent/type pairings anyway.
• Which board? Ask which DevStride board it should live on (a triage/kanban board, or a current cycle/sprint). List the candidates with list_boards; resolve the chosen board's id and its default not-started lane with get_board. A one-off ticket should be VISIBLE on a board — unlike sequenced-plan items, which live on the Gantt.
• Assignee = the current user by default. Resolve the caller via whoami (identity → username) and assign the item to that user (assigneeUsername). State who that resolved to and allow the user to name a different assignee before creating.
• Resolve the org's priority order (get_workspace_context, same non-canonical-config caveat as plan step 0) so you can set a sensible priorityId — default the org's normal/medium priority unless the user flags it urgent.