task-create

task-create

Author a single Backlog.md task with the structure that turns it into a usable design document.

When This Skill Runs

Trigger phrases:

• "create a backlog task for X"
• "add a TASK for X"
• "file this in the backlog"
• "write up X as a task"

If the user has not yet decided whether the work belongs in backlog/tasks/ at all, route through the conventions skill first — it owns the create-vs-skip decision.

Prerequisites

• Backlog.md is installed (see setup skill).
• The user has at least a one-line intent for the task. If they have nothing, ask one round of clarifying questions before proceeding — do not invent scope.

Allowed Tools

Read, Write, Edit, Bash (for backlog CLI), Grep, Glob.

Input

Parameter	Source	Required
short-title	Skill argument	No — if absent, derive from the user's prompt

Why this skill exists

A bare backlog task create "title" produces a stub with no Description, no AC, no Plan. That stub is often left as a one-liner and the task fails to function as the design document it is supposed to be. This skill writes the body in one shot so the task is useful from the moment it is committed.

Execution Steps

Step 1 — Gather inputs

Ask only for what is missing. Do not over-question — typical defaults:

Field	Default if user is silent
priority	medium
labels	infer from the user's description (one domain + one kind)
dependencies	[]
assignee	[]

Required from the user (or the conversation context):

• A clear problem statement
• A rough acceptance criterion or two

Step 2 — Create the file

Use the backlog CLI so frontmatter and filename conventions stay correct:

mise x -- backlog task create "<title>" \
  --priority <high|medium|low> \
  --labels <domain>,<kind>

This produces backlog/tasks/task-N - <slug>.md with empty body sections. Read its path back from the CLI output.

If the CLI is not available (rare — usually setup is incomplete), fall back to writing the file directly using ${CLAUDE_PLUGIN_ROOT}/assets/task-template.md and the next free TASK-N (count existing files in backlog/tasks/ + 1).

Step 3 — Fill the body

Open the file and replace the empty sections with real content. Use the structure below verbatim — it is what makes the task usable as a design document.

## Description

<2-4 paragraphs. State the problem first, then the constraints driving the solution.
Cite file paths and (where stable) line numbers. Do not say "the file we discussed" —
the next agent will not have that context.>

**Current state**

- <bullet on relevant existing code or config — file path + what it does>
- <bullet on what is missing or wrong>

**Candidate approaches** (only if the choice is non-obvious)

| Option | Pros | Cons |
|---|---|---|
| A | ... | ... |
| B | ... | ... |

## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 <verifiable, action-oriented bullet>
- [ ] #2 <...>
- [ ] #3 <...>
<!-- AC:END -->

## Implementation Plan

1. (PR-A) <step — concrete file path or component>
2. (PR-B) <step>
3. (PR-C) <step>

## Implementation Notes

- Estimated difficulty: <S | M | L>
- Dependencies: <TASK-N if any>
- <Open question — prefix with "OPEN:" so a grep finds it>

Notes on the structure:

• The <!-- AC:BEGIN --> ... <!-- AC:END --> markers are how Backlog.md parses checkbox state. Keep them.
• Acceptance Criteria items are numbered (#1, #2) so they can be referenced from PRs and Implementation Notes.
• The Implementation Plan typically maps 1:1 to PRs. If the work is a single PR, use a flat list instead.
• Implementation Notes is the only section that may be edited after the task is Done. Use it to record divergence from plan.

Step 4 — Wire dependencies

If the new task depends on others, add their IDs:

mise x -- backlog task edit TASK-N --dep TASK-M --dep TASK-K

If another task should depend on this one, edit that task instead — the dependency arrow points from blocked to blocker.

Step 5 — Show the user

Print the final path and a backlog task list slice so they see the task in context. Suggest the next action — usually:

• "Mark In Progress when you start, with: mise x -- backlog task edit TASK-N --status 'In Progress'"
• "Or move to backlog/drafts/ if you are not ready to schedule it yet."

Output

A single new file at backlog/tasks/task-N - <slug>.md, fully populated with the sections above, and (where applicable) updated dependency edges on related tasks.

Error Handling

• backlog task create fails because the CLI is missing: tell the user to run the setup skill first, or fall back to the template (see Step 2 fallback).
• No clear problem statement after one round of questions: stop and tell the user the task is too vague to be useful as a design document. Suggest moving it to backlog/drafts/ instead.
• A near-duplicate task already exists: surface the existing TASK-N and ask whether to extend its Implementation Plan instead of creating a new task (matches the conventions skill rule against fragmentation).

Constraints

• Never write a task with an empty Description or empty AC. If those cannot be filled, the task is a draft.
• Never auto-assign dependencies: without naming them in chat first — they create scheduling constraints the user may not want.
• Never set status: Done at creation time. New tasks start at To Do.