---
# Generated by minsky compile. Do not edit directly.
name: create-task
description: >-
  Create a new task with a properly structured spec. Takes task intent and
  generates a spec with required sections (Summary, Success Criteria, Scope,
  Acceptance Tests, Context) before calling tasks_create.
user-invocable: true
---

# Create Task

Create a new Minsky task with a properly structured specification. This skill ensures every task has measurable success criteria and acceptance tests.

## Arguments

Required: A description of what the task should accomplish. Can be a brief intent ("add retry logic to session start") or a detailed requirement.

Optional flags (included in the description):

- `--parent <taskId>` — set a parent task for subtask relationships
- `--tags <tag1,tag2>` — add tags for thematic batching
- `--backend <backend>` — specify task backend (default: minsky)

## Process

### 1. Analyze the intent

Read the user's description and identify:

- **What** needs to be done (the deliverable)
- **Why** it matters (the motivation — a bug, a missing feature, tech debt)
- **Where** in the codebase it applies (if known)

If the intent is vague, ask one clarifying question before proceeding.

### 2. Research the codebase

Before writing the spec, search the codebase to ground the spec in reality:

- Find the files/modules that will be affected
- Check for existing related work (similar tasks, prior attempts)
- Identify dependencies or blockers

This prevents specs that reference non-existent files or miss existing infrastructure.

### 2a. Verify load-bearing dependency claims (mt#3050)

If the drafted spec asserts that an EXISTING component, tool, or seam **supplies a
capability the task will consume** — a claim shaped like "X is sourced from /
supplied by / comes from the Y seam" — that assertion is load-bearing: downstream
work gets sequenced on the assumption it's true. Before Step 3 finalizes the spec,
each such claim must satisfy ONE of:

- **Cited** — name the FILE the component lives in AND the specific symbol/shape
  (function, type, exported member) that actually provides the capability. This
  is a mechanical presence check on the spec text itself: a file path and a named
  symbol, not a description of research activity.
- **`UNVERIFIED`** — if the file was not actually read this turn, mark the claim
  with the literal word `UNVERIFIED` (e.g., "the router default is UNVERIFIED as
  sourced from `tasks_route`") instead of asserting it as settled fact.

Checkable from the spec text alone: either a path + symbol citation is present
for the claim, or the literal marker `UNVERIFIED` is present. Step 2 ("Research
the codebase") names an activity; this step is the falsifiable gate on that
activity's OUTCOME for dependency claims specifically — advice to "research the
codebase" is not itself verifiable, which is exactly what failed in the
incident below.

**Incident this closes (R13, mt#3043, 2026-07-22):** a spec asserted the
router-suggested default would be "sourced from the existing `tasks_route` /
`tasks_estimate` seam" without reading `task-routing-service.ts`. The named
component actually exposes task-GRAPH routing (`AvailableTask`/`RouteStep`/
`TaskRoute` — readinessScore, blockedBy, dependencies), not model-complexity
routing. One file read falsified the premise — but only AFTER the task was
filed, sequenced behind other work, and presented to the principal as the next
thing to build.

**Proportionality (cf. mt#2309):** this is a narrow presence check on
load-bearing dependency claims, not the full `/plan-task` gate battery
(cite+quote+map+verdict across every claim in a spec). Process weight matches
work weight — a task-creation-time step, not a planning-phase audit.

### 3. Generate the structured spec

Write a spec with ALL required sections:

```markdown
## Summary

<1-3 sentences: what this task does and why>

## Success Criteria

- [ ] <Measurable criterion 1>
- [ ] <Measurable criterion 2>
- [ ] ...

## Scope

**In scope:** <what's included>
**Out of scope:** <what's explicitly excluded>

## Acceptance Tests

- <Concrete test 1: action -> expected result>
- <Concrete test 2: action -> expected result>
- ...

## Context

- <Relevant background, related tasks, prior art>
- <Links to code, issues, or documentation>
```

**Quality rules for each section:**

- **Summary:** Lead with the deliverable, not the problem. Include the "why."
- **Success Criteria:** Each item must be independently verifiable. Use checkboxes. Avoid "should work correctly" — specify what "correctly" means.
- **Scope:** Name specific things that are OUT of scope to prevent scope creep.
- **Acceptance Tests:** Each test is an action+assertion pair. Include happy path AND edge cases.
- **Context:** Link to related tasks, PRs, or code paths. Include grep patterns that should return zero/non-zero results after completion.

### 4. Create the task

Call `mcp__minsky__tasks_create` with:

- `title`: concise task title (under 80 chars)
- `spec`: the full structured spec from step 3

If `--parent`, `--tags`, or `--backend` were specified, include those parameters.

**Gate:** before calling `tasks_create`, confirm every load-bearing dependency
claim in the drafted spec passes Step 2a — cited (file + symbol) or marked
`UNVERIFIED`. Do not call `tasks_create` while an uncited, unmarked dependency
claim remains in the spec.

### 5. Confirm

Report the created task ID and a one-line summary to the user.

### 6. Chain-walk decision (mt#2689)

Task creation is NOT a terminal action by default. After reporting the ID, classify the
just-created task and act on the classification — do not end the turn on the report alone:

- **(a) Incident-response task** — filed for a problem the user reported in the live
  conversation, or one discovered during this conversation's work. **Continue the chain
  now**: invoke `/plan-task <id>` (and, on gate-pass, `/implement-task <id>`) in the same
  turn. A user report of an active operational problem IS a change request for this
  principal; the harness-level "user is describing a problem → report findings and stop"
  exception is overridden by project rules (`Take direct action without asking`, `Do not
defer identified, actionable work`). Filing the task and giving a workaround is not the
  deliverable — the fix is. Per Work Completion: **"Artifact creation is not progress."**
- **(b) Background/tracking task** — filed for later by design (a follow-up the user asked
  to track, a decomposition child, a deferred idea). Stopping here is correct — but say so
  explicitly ("filed for later; not implementing now") so the stop is a visible decision,
  not a silent default.

**Halt conditions** (the only valid reasons to stop after filing an incident-response task):

- The user explicitly deferred ("just file it", "track it for later", "don't fix it yet").
- The task requires decomposition or is blocked on an external/principal-owned decision
  (route that decision through an Ask, per the escalation-packaging discipline).
- A parallel-work probe shows another actor holds the work (surface the collision instead).
- The scope is too large for the current turn — say so and propose the split; do not
  silently stop.

**The tell:** a closing line shaped like "this will keep recurring until mt#X lands" or
"the fix is tracked in mt#X" without doing the work in the same turn is the failure mode
this step exists to prevent (R3 of the stop-at-handoff family, 2026-07-08 — mt#2674 was
filed with a complete root-cause and spec, then the turn ended; the user had to prompt for
the implementation). `/classify-before-deferring` fires on the same shape.

## Example

User: `/create-task add a --dry-run flag to the session delete command`

Result:

```
Title: Add --dry-run flag to session delete command

## Summary

Add a `--dry-run` flag to `minsky session delete` that shows what would be deleted without actually deleting. This prevents accidental session loss.

## Success Criteria

- [ ] `minsky session delete --dry-run <session>` prints session details and "would delete" message without deleting
- [ ] `minsky session delete <session>` (without --dry-run) behavior unchanged
- [ ] Flag registered in CLI help text
- [ ] MCP tool `session_delete` accepts `dryRun` parameter

## Scope

**In scope:** --dry-run flag, CLI + MCP parameter, output formatting
**Out of scope:** Interactive confirmation prompt (separate task), bulk delete

## Acceptance Tests

- Run `minsky session delete --dry-run <existing-session>`: prints details, session still exists after
- Run `minsky session delete --dry-run <nonexistent-session>`: error "session not found"
- Run `minsky session delete <session>`: deletes normally (regression check)

## Context

- Session delete is in `src/adapters/shared/commands/session/lifecycle-commands.ts`
- Related: mt#687 (session lifecycle improvements)
```