/tackle-task

name: tackle-task
description: Use when starting work on a specific vault task, when a task title or path is mentioned, or when coming from triage output.

Tackle Task

Open a task, understand what it requires, execute it at the right level of rigor, and close it properly.

Step 1: Resolve the task

From the user's message, extract either a task path or a task title/name.

• **Path given**: `vault_read(path)` directly
• **Title/name given**: issue two queries and match by H1 title or basename:

  vault_query({ type: "task", status: "pending" })
  vault_query({ type: "task", status: "active" })

If multiple tasks match, show candidates and ask the user to pick. Fall back to `vault_search(title)` if queries return nothing.

If the task can't be found, tell the user and stop.

Once found, mark it active: `vault_update_frontmatter({ path, fields: { status: "active" } })`.

Step 2: Read and assess

Read the full task note. Extract:

• **Title** and **description**
• **Acceptance criteria** (if present — key signal for scope clarity)
• **Priority** and **due date**
• **Project** context

Step 3: Complexity check

Classify into one tier using these signals. This should take seconds, not minutes — trust your first read.

| Tier | Signals | Route to | |------|---------|----------| | **Trivial** | Single concern, obvious change, clear AC, file/location already known | Step 5 directly (skip Step 4) | | **Standard** | Multi-file change, small feature or bugfix, scope is clear but needs a plan | Step 4 → Explore → Plan → Code → Commit | | **Significant** | New feature, architectural impact, vague requirements, multiple unknowns | Step 4 → `superpowers:brainstorming` → full pipeline |

When uncertain between tiers, go one tier up. A few extra minutes of planning is almost always cheaper than an incomplete or wrong implementation.

Complexity keywords that push up a tier: "design", "architecture", "integrate", "migrate", "refactor across", "not sure how", any missing acceptance criteria.

Step 4: Explore context (Standard and Significant only)

• `vault_neighborhood(task_path, depth: 2)` — find related ADRs, research notes, prior decisions linked from the task
• `vault_activity({ path: project_folder, limit: 20 })` — see recent related work to avoid duplicating effort
• Read any directly relevant linked notes (ADRs, research) before proceeding

For **Significant** tasks: after exploring, invoke `superpowers:brainstorming` to clarify intent and requirements before writing any code. The brainstorming output should inform the plan.

Step 5: Execute

**Trivial**: Read the relevant file(s), make the change, run verification. Commit.

**Standard**: Follow the Small Tasks workflow — Explore, confirm approach with user if non-obvious, Code, verify, Commit.

**Significant**: Follow the Significant Features workflow — brainstorm → worktree → plan → execute → finish branch.

Don't re-summarize what you read in Step 2. Move directly into the work.

Step 6: Close the task

After the work is complete and verified:

1. Update status: `vault_update_frontmatter({ path: task_path, fields: { status: "done" } })` 2. Check for existing completion timestamp: `vault_read(task_path)` — if the note already contains `**Completed**`, skip the append. Otherwise: `vault_append({ path: task_path, content: "\n**Completed**: YYYY-MM-DD\n" })` 3. If the work produced ADRs, research notes, or other vault notes, link them back to the task: `vault_add_links({ path: task_path, links: [{ target: "...", annotation: "..." }] })` 4. Confirm to the user: one sentence — what was done and what tier it was.