plan

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.

Drive a top-2%-quality DevStride plan into existence under a parent item (any grouping level of the organization's hierarchy; this org's Module/Capability/Epic) through an interactive discovery loop with the user — NOT a one-shot autogenerated document. Ends with a full grouping-item → release-unit → leaf hierarchy (this org: Capability→Epic→Story), every level specced to the depth ultracode-build can execute from unattended, and every leaf wired into a real blocked_by/blocks dependency chain so /devstride:build-item can walk the whole plan from its first root story with minimal back-and-forth.

Argument — a parent item number to plan under (any grouping level of your organization's hierarchy, e.g. this org's Module/Capability/Epic; I20100), optionally followed by a short description of what's being planned, and optionally one delivery profile — the bare word prototype, standard or enterprise anywhere in the arguments (/devstride:plan I20100 prototype; step 0 resolves it, and it shapes leaf grain and spec depth per ${CLAUDE_PLUGIN_ROOT}/skills/plan/references/delivery-profiles.md); empty → ask which parent item to plan under: $ARGUMENTS

User-facing vocabulary. Container is internal shorthand in this file for a non-executable hierarchy item that can own child items. Never use it as the noun in a user-facing question, confirmation or report: developers reasonably read “container” as Docker. Say parent item when referring to the supplied I#####, grouping item when the exact type is not yet known, or — best of all — use the organization’s actual work type name (Capability, Epic, Initiative, and so on) once step 0 resolves it. Internal algorithms may continue to use container/leaf classification.

IMPORTANT — the DevStride MCP targets PRODUCTION (api.devstride.com). Every create_item, update_item, add_relationship, and bulk_update_items call this skill makes writes real, live data into the org's roadmap immediately — there is no draft/sandbox mode. Get explicit sign-off before creating anything.

IMPORTANT — this is fundamentally an INTERACTIVE, LOOP-BASED skill, not a document generator. The core value is the qualifying-question loop with the user: scope boundaries, sequencing tradeoffs, deviations from any existing design doc, what's V1 vs deferred, what parallelizes vs what's a hard gate. Do not skip ahead to mass item-creation before the human has actually made those calls. If you find yourself about to invent an architecture decision the user hasn't weighed in on, STOP and ask.

IMPORTANT — keep interactive scope and architecture decisions in the main conversation: a Workflow cannot ask the human mid-run. Use Workflow only after the hierarchy is approved, with parallel() for independent release units and pipeline() for dependent stages. Its agents draft only; they never call MCP write tools. Return proposals to the user before any live write.

Engineering economy and agent routing. Read ${CLAUDE_PLUGIN_ROOT}/skills/ultracode-build/references/engineering-economy.md before choosing a custom approach or opening Workflow. It is the canonical DRY/YAGNI, reuse, parallelism, and model/effort contract; this skill applies its task-sized routes rather than running every drafting task on the most expensive model.

0. Orientation — resolve the root and learn this org's shape

• Resolve the parent item number from $ARGUMENTS (or ask which parent item to plan under — do not guess).
• get_item(view: 'full') / resolve_item on the parent to confirm its work type — this determines what level you're planning at. Read the FULL view here: the profile resolution below needs the parent's description, which the default projection omits.
• Resolve the delivery profile and say so. The canonical contract — table, resolution order, root-marker format — is ${CLAUDE_PLUGIN_ROOT}/skills/plan/references/delivery-profiles.md; this skill honours its grain and specDepth rows and writes its root marker. Resolve per that order, with three plan-specific rules: the marker step walks upward — read the parent's own full description, and if it carries none, walk hierarchy up with get_item(view: 'full') per ancestor until one does (a parent is often a release unit BELOW a marked root; stopping early silently re-gates the subtree), noting whether the marker was the parent's own or inherited (the step-2 sign-off writes a marker only when the parent has none and the profile came from elsewhere than an ancestor's marker); profileOverrides.grain / profileOverrides.specDepth (when the repo is known — planning never REQUIRES the config) each name another profile's column for that one knob (an absent key changes nothing; an unknown VALUE is reported and ignored, never guessed at); and an argument that disagrees with an existing marker is a QUESTION, never an override — the marker is a recorded decision; ask which profile this pass plans under (a "change it" answer means rebalance first, per step 2). A descendant container may carry its own marker — it wins for its subtree; shape leaves beneath it to that profile. State the result, its source, and any override in the orientation message.
• get_work_type_hierarchy and get_workspace_context to learn this org's REAL work type names, lanes, and priorities. This runtime resolution is THE normative mechanism for the vocabulary this skill reasons in: every role used below — plan-root and intermediate containers, the release-unit container (the level whose completion cuts a release — this org's Epic type), and the executable leaf types (this org's Story/Defect) — binds to the type names resolved HERE. Do not assume canonical naming — some orgs have typos or custom hierarchies (e.g. a real org's Capability-level work type is literally spelled Capabilty). Plan against what the org actually has. The release-unit level you shape here MUST be the same level the delivery loop branches and releases at: when the org has multiple container levels and the release boundary is ambiguous from structure alone, check the repo's .claude/ds-config.json hierarchyRoles.releaseUnit as the tie-breaker if the repo is known (planning never REQUIRES that file), and otherwise ASK the user which level is the release unit — then suggest recording the answer in hierarchyRoles so planning and delivery can never diverge (Feature-sized plans against Epic-sized releases undermine the production-safety boundary).