create-task

Create Task

Usage

/at:create-task [further user instructions]

Goal

Crystallise and scope an ongoing conversation into a well-defined task, capturing user intent at a high level.

Context

This skill is typically run as part of a larger workflow:

create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task

As steps (e.g. clarify, plan, impl, review) typically run in new sessions, it's imperative that the task file plus repo state carry everything the next agent needs.

Task Store and Project Config

Task-store location, task-file naming and numbering, attachments, and config-file precedence are all owned and resolved by /at:config — read settings from the resolved block (see Step 0), not from restated defaults here. The three config layers share one format: shipped defaults (auto-task.config.defaults.md) ← project (.claude/auto-task.config.md, committed) ← local (.claude/auto-task.config.local.md, gitignored, wins on conflict). /at:config § Heading → Setting Map lists the recognised sections.

Guidance (DO NOT IGNORE!)

These rules govern both how you gather intent and write the task. Internalise and follow them throughout.

• The audience is the implementing agent, with full repo access — not a human catching up on the project. Every line must earn its place for that reader.
• Be maximally succinct. Capture the user's intent with the fewest words that remove ambiguity. Task content length obviously follows complexity but don't pad.
• When a task has an authoritative attachment (design brief, spec, report), don't restate its content. Only capture decisions or information that's additional to the attachment.
• Don't spell out what a capable agent infers from the repo - established conventions (e.g. fail-fast), the single obvious mechanism for a change, enum values readable from a table. Test per line: would two reasonable agents build the same thing without it?
• Use plain English. Write like a human agile BA/PM writing a user story, not like a technical writer or AI producing a spec.
• Prefer short sentences and bullet points over paragraphs.
• Minimise use of backticks, emphasis, file paths, symbol names, and code mechanics - exact names and details get resolved in later stages.
• Read code to understand, not to transcribe. Read enough to describe the task accurately.
• Match scope exactly. For example: don't bundle "review X, then fix it". A review task ends at the review report; a fix task ends at the fix.
• Avoid AI-slop at all costs - both verbosity and language like "categorised by theme and priority", "promote into guardrails", "earned their keep".