Help us improve
Share bugs, ideas, or general feedback.
From vault-pkm
Manages vault tasks: resolves by path/title, assesses complexity tier (trivial/standard/significant), explores context, executes workflow, and closes properly. Use on task mentions or triage output.
npx claudepluginhub adrianv101/obsidian-pkm-plugin --plugin obsidian-pkmHow this skill is triggered — by the user, by Claude, or both
Slash command
/vault-pkm:tackle-taskThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Open a task, understand what it requires, execute it at the right level of rigor, and close it properly.
Surfaces open vault tasks (active/pending) for current project or all projects with git commits and activity hints, enabling interactive batch status updates.
Looks up tasks by ID or name, marks them in-progress, starts worklogs if enabled, executes using tools like EnterPlanMode and Bash, then completes via /complete-task. Use to pick up and execute tasks.
Looks up task by ID or name with taskmd, reads details, marks in-progress, starts worklog if enabled, executes using tools like EnterPlanMode, and completes it. Use to pick up and run predefined tasks.
Share bugs, ideas, or general feedback.
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" })
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" } }).
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: "..." }] })