| name | steer |
| description | Create or open an Obsidian note, attach hidden writing context, and focus the note for the user through the Steer CLI. |
Steer handoff
Use this skill when the user wants to continue writing in Obsidian with context
from the current coding or investigation session.
Requirements
- Obsidian Desktop 1.12.2 or later is open.
- The Obsidian CLI is installed.
- Steer is installed and enabled in the target vault.
Never edit the plugin's data.json directly. The running plugin owns its
in-memory settings and persists context through the CLI operation.
Resolve the vault
Use the active vault instead of searching the filesystem:
vault="$(obsidian vault info=name | tail -n 1)"
If that produces no vault name, run obsidian vaults verbose. Use the only
listed vault automatically. Ask the user which vault to use only when multiple
vaults are listed and the intended one is ambiguous. Do not scan the home
directory or application bundle for the CLI or vault. Use obsidian help, not
obsidian --help, when command discovery is necessary.
Create the handoff
Choose a vault-relative Markdown path. Create a private temporary request file
containing:
{
"version": 1,
"path": "Messages/Feature announcement.md",
"content": "# Feature announcement\n\n",
"context": "The release promotes a tested immutable snapshot without rebuilding images. Publishing creates the named Helm chart, Git tag, GitHub Release, and changelog notes."
}
path is required and must end in .md.
content creates the note and is optional.
context becomes hidden Steer context and is optional.
- Include at least one of
content or context.
- For an existing note, omit
content. The command never overwrites a note.
- An empty
context clears context from an existing note.
context contains reference material about the subject being written about.
Include relevant facts, decisions, rationale, implementation details,
tradeoffs, current status, unresolved questions, terminology, and useful
links.
- Never put writing instructions in
context. Exclude the requested document
type, audience, tone, style, length, structure, emphasis, ordering,
formatting, calls to action, and instructions such as what to lead with,
mention, avoid, preserve, or clarify.
- Keep factual wording requirements only as subject facts. For example, record
"10 of 17 stable team agents have migrated" without adding an instruction to
use that sentence as the headline.
- When the user supplies a writing request, use it only to decide which subject
facts are relevant. Do not copy or paraphrase the request itself into
context.
- Synthesize the subject matter instead of copying a raw transcript. Exclude
thinking traces, repetitive exchanges, secrets, irrelevant tool output, and
details unrelated to the subject.
A safe shell pattern is:
request="$(mktemp)"
trap 'rm -f "$request"' EXIT
chmod 600 "$request"
cat >"$request" <<'JSON'
{
"version": 1,
"path": "Messages/Feature announcement.md",
"content": "# Feature announcement\n\n",
"context": "The feature is complete. It replaces mutable main-snapshot deployment pins with repository-owned named release pins."
}
JSON
obsidian vault="$vault" steer:handoff request="$request"
Put vault="..." before the command name. Parameters use name=value syntax.
Verify the result
Parse the returned JSON. Success has this shape:
{ "ok": true, "path": "Messages/Feature announcement.md", "created": true }
Treat {"ok":false,"error":"..."} as a failure and report the error. On
success, Obsidian opens the note, reveals its Steer view, and focuses the
editor.