/create-task

name: create-task
description: This skill should be used when creating a task in the active tracker - "create task", "create issue", "bd create", "new task", "add task", "add issue". Ensures all required fields are provided, enforces English-only task content, and suggests epic labels. Triggers on any task creation in any context - commands, planning, or direct conversation.

Create Task

Standardized task creation that enforces required fields and suggests labels. Fires in any context where a task is being created - inside commands, during planning, or in direct conversation.

> **IMPORTANT:** If the spec below invokes any deferred tool (e.g. `AskUserQuestion`), you MUST load and call it as specified. Never skip the call, never substitute a default answer of your own — the tool invocation is part of the contract. This is critical.

IMPORTANT: Language

**All task content MUST be in English regardless of conversation language.** If the user is speaking another language, translate to English before creating the task.

Applies to every field:

• `title`
• `description` (problem statement, acceptance criteria, examples)
• `labels`
• Any subsequent `comment-add` / `set-field` on this task

**Why:** tasks are searched, filtered, and cross-referenced across the team and external systems (GitHub, Linear). Mixed-language tasks break tracker `search` and confuse non-native-language readers.

Why This Exists

Tasks created without labels, priority, or description become orphaned and hard to find. This skill ensures every task has full metadata from the start.

Required Fields

Every task `create` MUST include every field the active adapter's `create` declares in `accepts:` - and nothing else:

| Field | Required | Rules | |------|----------|-------| | `title` | Always | Imperative mood, clear action. Under 80 chars | | `type` | If declared | One of: `task`, `bug`, `feature`, `epic` | | `priority` | If declared | 0-4 (0=critical, 1=high, 2=medium, 3=low, 4=backlog) | | `description` | Always | Why this task exists + acceptance criteria | | `labels` | If declared | At least one `epic:<name>` label for grouping |

**"If declared" means:** read the active adapter's `create` binding cell. Ask for a field only when its `accepts:` list carries it. When it does not, either use the rename the adapter declares (`priority→severity` means ask for priority, send severity) or say in one line that this tracker has no such field, and move on. Never collect a value and drop it - the user has no way to tell that happened.

Label Selection

**Run this whole section only if the adapter's `create` declares `labels` in `accepts:`.** The `label` verb being supported is a different question - a tracker can carry labels on a task and still not take them at creation time, and walking the user through discovery and a pick only to drop the answer is the exact failure this skill's Required Fields section forbids.

Labels are project-specific. ALWAYS discover them dynamically - never hardcode.

Step L1: Discover Existing Labels

**Tracker protocol:** `Skill(skill: "lets:protocol-tracker")` before this and any later `lets-tracker` block here, unless its text is in your current context.

label   # list all labels; filter the result for `epic:*`. On a tracker that marks `label` absent, skip label discovery (no epic suggestions - propose a label by hand).

If no labels found, also scan recent tasks for `epic:*` naming conventions via `list-by-status`.

Step L2: Present Labels to User

Show discovered labels and ask which fits:

> Found these epic labels in the project: > - `epic:features` - (N open tasks) > - `epic:quality` - (N open tasks) > - ... > > Which label fits? Or suggest a new one.

Step L3: New Label Flow

If no existing label fits: 1. Propose a new `epic:<name>` label with a short explanation of the grouping 2. Decide whether an epic task fits this theme (the `create` verb, `type=epic`, `labels="epic:<name>"`) 3. `{LETS_GATES}` is `strict` -> ask whether to create the epic, and wait for user approval before creating either the label or the epic; otherwise -> use the proposed label (and create the epic when one fits, through this skill's flow) and name both in the final report

Creation Flow

Step 1: Gather Information

If the user provides a clear description (title + context), proceed directly. Otherwise ask concisely:

> What's the task? (title, what problem it solves)

Do NOT ask for each field separately - infer type, priority, and labels from context.

Step 2: Compose Fields

From the user's input, derive only the fields the adapter's `create` declares in `accepts:` - skip the rest without asking:

1. **Title** - imperative mood, specific action (e.g., "Add retry logic to API client") 2. **Type** - infer from context: bug (something broken), feature (new capability), task (chore/refactor), epic (theme) 3. **Priority** - infer from urgency. Default to P2 unless context suggests otherwise 4. **Description** - why + acceptance criteria. Write as markdown with clear structure 5. **Labels** - run Label Selection flow (above). Present discovered labels, let user choose or create new

Step 2.5: Duplicate check

Runs at every level. **Tracker protocol:** `Skill(skill: "lets:protocol-tracker")` first, unless its text is in your current context.

search query="<distinctive title keywords>"   # OPTIONAL verb; returns matching tasks

Judge each result from its title + description: a likely duplicate is the same problem or the same deliverable.

• Likely duplicate -> show it as **Title** (`id`) and ask (at EVERY level - a real choice):

AskUserQuestion(
  questions=[{
    question: "A likely duplicate exists. Create this task anyway?",
    header: "Duplicate",
    options: [
      { label: "Use the existing one", description: "Don't create; continue with the existing task" },
      { label: "Create anyway", description: "Create the new t