Menú
Use when starting work on a specific vault task, when a task title or path is mentioned, or when coming from triage output.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Use when researching what the vault knows about a topic — performs graph + semantic exploration with gap analysis to map existing knowledge and find missing connections. Primarily used via the vault-explorer agent. Not for routine session-start context loading (hooks handle that).
Use when wrapping up a work session — creates devlog entry, captures undocumented decisions/research/debugging, audits link health of session work, and updates project index. Primarily used via the pkm-capture agent.
Use when writing to the vault — creating new notes (vault_write), editing existing notes (vault_edit, vault_append, vault_update_frontmatter). Handles duplicate checking, link discovery, annotations, and index updates for new notes. Provides guidelines for modifications.
Use when you want to quickly capture a new task in the vault from a title, with optional priority and due date.
Use when you want to review and batch-update open vault task statuses for the current project or across all projects.
| 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. |
Open a task, understand what it requires, execute it at the right level of rigor, and close it properly.
From the user's message, extract either a task path or a task title/name.
vault_read(path) directlyvault_query({ type: "task", status: "pending" })
vault_query({ type: "task", status: "active" })
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" } }).
Read the full task note. Extract:
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.
vault_neighborhood(task_path, depth: 2) — find related ADRs, research notes, prior decisions linked from the taskvault_activity({ path: project_folder, limit: 20 }) — see recent related work to avoid duplicating effortFor Significant tasks: after exploring, invoke superpowers:brainstorming to clarify intent and requirements before writing any code. The brainstorming output should inform the plan.
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.
After the work is complete and verified:
vault_update_frontmatter({ path: task_path, fields: { status: "done" } })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" })vault_add_links({ path: task_path, links: [{ target: "...", annotation: "..." }] })