create-task

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:

## 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)