create-tasks

Skill: create-tasks

Turns product scope into technical cards. Works against any tracker mode (${CLAUDE_PLUGIN_ROOT}/shared/card-format.md): tracker MCP, GitHub Issues via gh, or local Markdown. Respond in the conversation language (docs/agents/language.md; unset → the user's language).

Load before acting: ${CLAUDE_PLUGIN_ROOT}/shared/workflow-context.md (roles + project config), ${CLAUDE_PLUGIN_ROOT}/shared/card-format.md (the card contract this skill produces), and ${CLAUDE_PLUGIN_ROOT}/shared/guardrails.md (this skill mutates trackers — the loading contract applies).

Step 0 — Resolve context and parse the input

Resolve the Tracker role (and Repo, if a codebase is present) per workflow-context — batched question only for what detection can't settle.

Input shapes, checked in order (stop at the first match):

1. Path to a local .md file → product doc; parents come from its scope.
2. Tracker item URL or identifier (ENG-790, #123, TASK-007, item URL) → single parent. A URL pins the tracker (workflow-context rule).
3. Tracker project / milestone / epic URL → collection of parents (tracker modes only).
4. Empty → product-doc discovery order from card-format § Product context input; nothing found → offer to run /create-product right here.

Malformed input → show the accepted shapes with one example each; never guess.

Step 1 — Read the scope

• Single parent: fetch the item + comments. Terminal status (done/canceled) or existing children → ask before proceeding (possible duplicate work).
• Collection: list items; keep only eligible parents — not sub-items, not terminal, no existing children. Record everything else in skipped with a reason. If the collection mixes product and non-product items and docs/agents/tracker.md defines no product_filter, ask once how to identify product items (a team name, a label, or "all items") and write the answer back as product_filter: in tracker.md.
• Product doc: read it; the doc (or each of its major scope items, if clearly separable) is the parent scope. High-level acceptance criteria become the source of each card's ## Test criteria (one it per criterion).
• In all cases, read the project knowledge the cards must respect: the guideline files listed in docs/agents/validation.md and any docs/agents/guardrails.md rules. For each card's target area, the nearest GUIDELINES.md up the tree wins over the codebase-level one (make-guidelines precedence). No guidelines anywhere → offer /make-guidelines (the pipeline self-heals), or proceed with the card sourcing patterns from the code itself.