Use this skill for one-command Obsidian workflow orchestration across the existing six domain skills. This skill owns named workflow command IDs and preview/apply execution policy, while delegating all direct official CLI command execution to the appropriate domain skill.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add thedixitjain/the-mega-skill-library --skill obsidian-cli-workflows --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Obsidian Cli Workflows?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-obsidian-cli-workflows)More formats (shields.io, HTML) on the badges page.
---
name: obsidian-cli-workflows
description: "Use this skill for one-command Obsidian workflow orchestration across the existing six domain skills. This skill owns named workflow command IDs and preview/apply execution policy, while delegating all direct official CLI command execution to the appropriate domain skill."
category: docs-and-knowledge-mgmt
source_repo: hashgraph-online/awesome-codex-plugins
source_path: "plugins/greg-asher/codex-obsidian/skills/obsidian-cli-workflows/SKILL.md"
source_url: https://github.com/hashgraph-online/awesome-codex-plugins/blob/HEAD/plugins/greg-asher/codex-obsidian/skills/obsidian-cli-workflows/SKILL.md
---
# Obsidian CLI Workflows
Use this skill for orchestration-only one-command workflows that chain the existing official Obsidian CLI domain skills.
## Routing contract
Use this skill when:
- the user asks for a named one-command workflow ID such as `tasks.rollup` or `daily.bootstrap`
- the user wants a preview/apply orchestration plan that may span multiple domain skills
- the user asks to run a multi-step vault workflow with explicit risk classification and side-effect reporting
Do not use this skill when:
- the user asks to run raw direct command families (route to the owning domain skill)
- the request is only note CRUD/tasks/properties/history without workflow orchestration
- the request is only runtime admin/devtools/sync/publish or only workspace/navigation without one-command orchestration
- the request depends on community CLI tooling, `obsidian://` launchers, or Headless Sync
## Public workflow command interface
Workflow invocation must use a named command ID from `references/workflow-registry.md`.
No natural-language-only invocation mode in this release:
- require explicit `workflow_id=<command-id>`
- reject unregistered workflow IDs
Common controls for every workflow:
- `mode=preview|apply` (default: `preview`)
- `vault=<name>` optional pass-through
- `output=inline|note|json` (default: `inline`)
## Core orchestration policy
1. This skill owns orchestration logic only and does not replace direct command ownership contracts of the six domain skills.
2. All workflows default to `mode=preview`.
3. Preview output must include step plan, target summary, risk classification, and required confirmations.
4. Apply output must include executed-step list, skipped-step list, and explicit mutation summaries.
5. Medium/high-risk workflows require explicit apply confirmation before mutating steps.
6. Apply mode may run only user-approved steps that match preview targets.
7. Ambiguous note/base/workspace targets fail closed with a disambiguation requirement.
8. `publish.release_gate` must probe `help publish:status` before any publish command.
9. If publish probe returns unsupported, return explicit blocker and do not attempt `publish:*`.
10. Keep `vault:open` out of executable workflow steps in this release.
11. Preserve existing domain-skill safety boundaries and mutation guardrails.
12. If a request falls outside official desktop CLI workflow surface, say so and stop.
## Codex-safe launcher and escalation policy
This skill delegates execution to the six domain skills.
For delegated command execution, inherit the same sanitized launcher and escalation behavior already defined in those skills.
## Risk model
- `low`: read-only workflows or report-only outcomes
- `medium`: controlled note/bookmark/runtime mutations with bounded scope
- `high`: workspace/layout mutations, direct base-create flows, or publish gating flows that can trigger remote side effects
## Response contract
Always return:
- `workflow_id`
- selected `mode`
- selected `output`
- delegated skill chain
- risk level
- step plan (`preview`) or execution summary (`apply`)
- target summary and ambiguity status
- mutation/side-effect summary when applicable
- blocking reason when capability/target checks fail
## Workflow registry
All workflow definitions and guardrails are in:
- `references/workflow-registry.md`
## References
- `references/playbook.md`
- `references/limitations-and-boundaries.md`
- `references/validation.md`
- `references/source-links.md`
---
**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/greg-asher/codex-obsidian/skills/obsidian-cli-workflows/SKILL.md`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!