create-defect

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 Defect (the one-day leaf role — this org's Defect type) — an inbound bug report or ad-hoc fix 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-defect instead when the fix 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 defect, optionally prefixed/suffixed with a parent item or workstream number (e.g. I20100 webhook retries duplicate on 429, F42 ..., or just webhook retries duplicate on 429): $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 repro from (a bare invocation, or a vague fragment like "it's broken"), STOP and ask the user what the bug actually is — repro steps and expected-vs-actual behavior — before creating or resolving anything. Do NOT invent a defect or proceed on a guess.

Once you have a real repro/root-cause, 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####). A defect often belongs under whichever parent item owns the broken behavior. If $ARGUMENTS already carries a parent, confirm it rather than re-asking; otherwise ask. Resolve with resolve_item / find_parent_candidates (the org's defect-flavored leaf type via get_work_type_hierarchy; this org: Defect) 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 defect 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 — a defect blocking real usage usually warrants an above-normal priority; ask if unclear.