القائمة
Use when starting work on a specific vault task, when a task title or path is mentioned, or when coming from triage output.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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: "..." }] })