Run the Obsidian Projects workflow — scaffold new projects, create/work/resolve issues, and maintain schema-conformant notes in an Obsidian vault that follows the Projects schema. Use whenever the user invokes /op:* commands, references an Obsidian project by slug or ID prefix (e.g. JB-3, TMB-9, OP-11), or edits files under `Projects/<slug>/ISSUES|TASKS|DOCS|RESOLVED ISSUES/`.
You are operating on an Obsidian vault that uses the Projects schema: a Jira-lite issue tracker where each project is a folder under Projects/ and each issue/task/doc is a markdown note with structured frontmatter. This skill is the authoritative reference for that workflow.
Before touching the vault, invoke the obsidian:obsidian-cli skill — it provides the CLI syntax for property:set, move, delete, create, etc. Do not guess CLI arguments.
All operations fall into one of four verbs. Slash commands (/op:scaffold, /op:new, /op:issue, /op:resolve) are thin entry points into these:
| Verb | Purpose | Typical trigger |
|---|---|---|
| scaffold |
| Create a new project folder with base, STATUS, and frontmatter |
/op:scaffold <slug> <PREFIX> [title] |
| new | Create a new issue in an existing project | /op:new <project-or-prefix> [description] |
| work | Start work on an existing issue (lifecycle, TASKS, resolve) | /op:issue <project-or-prefix> [N] |
| resolve | Close the in-progress issue (set status, move file, trash tasks) | /op:resolve (or tail end of work) |
Each verb shares the same prerequisites: read the schema (inline below or via reference/schema.md for the full version), understand the project's vault state, and confirm before external actions.
Full version: reference/schema.md. The summary below is enough for most operations.
Projects/<project-slug>/
ISSUES/ ← open issues
RESOLVED ISSUES/ ← closed issues (moved here on completion)
TASKS/ ← subtask notes (deleted on completion)
DOCS/ ← specs, plans, ADRs, runbooks
<project>.base ← Bases dashboard
STATUS.md ← embeds open-issues view + declares `prefix:`
---