| 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.
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:
- Update status:
vault_update_frontmatter({ path: task_path, fields: { status: "done" } })
- 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" })
- 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: "..." }] })
- Confirm to the user: one sentence — what was done and what tier it was.