Menü
Save documents to the .hive/ context directory (symlinked into Obsidian). Use when the user asks to save, write, or put a document into their notebook.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | obsidian |
| description | Save documents to the .hive/ context directory (symlinked into Obsidian). Use when the user asks to save, write, or put a document into their notebook. |
| allowed-tools | Bash(mkdir:*),Bash(hive:*),Bash(git:*),Bash(date:*),Write,Read |
Save structured documents into the .hive/ context directory. This directory is symlinked into the user's Obsidian vault, so anything written here appears in Obsidian automatically.
IMPORTANT: .hive must be a symlink, not a directory. If it doesn't exist, run
hive ctx init to create it — NEVER use mkdir for .hive itself.
| Type | Path | Filename Pattern |
|---|---|---|
| research | .hive/research/ | YYYY-MM-DD-<slug>.md |
| design-doc | .hive/design-docs/ | YYYY-MM-DD-<slug>.md |
| plan | .hive/plans/ | YYYY-MM-DD-<slug>.md |
For research documents, use the research skill. For design docs, use the design-doc skill. For plans, use the plan-write skill. This skill handles ad-hoc documents or types not covered by a dedicated skill.
.hive/ exists — if not, run hive ctx initmkdir -p .hive/<subdirectory>
git branch --show-current
git rev-parse --short HEAD
date +"%Y-%m-%d"
gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null || echo "unknown"
YYYY-MM-DD-<slugified-title>.md using today's dateEvery document must start with YAML frontmatter:
---
type: "<document-type>"
date: YYYY-MM-DD
repository: owner/repo
branch: [current branch]
commit: [short commit hash]
status: draft
topic: "[Document title]"
---
Use standard markdown. When targeting Obsidian rendering, these features are available:
> [!TYPE] Optional Title
> Content here.
| Callout | When to use |
|---|---|
[!IMPORTANT] | Must-read constraints or requirements |
[!WARNING] | Risks, gotchas, or things likely to go wrong |
[!QUESTION] | Open questions needing resolution |
[!DECISION] | A decision and its rationale |
[!TRADEOFF] | Trade-off comparison between approaches |
Include diagrams when describing systems with multiple components or data flows:
```mermaid
flowchart LR
A[Input] --> B{Decision} --> C[Result]
```
Convert the title to a filename-safe slug:
Example: Auth Service Redesign -> auth-service-redesign
Best practices for working with Go codebases. Use when writing, debugging, or exploring Go code, including reading dependency sources and documentation.
Autonomous orchestration loop for hive hc tasks. The high-capability manager model reads pending tasks, delegates implementation to cheaper worker sub-agents, critically reviews their output, and commits only code that passes quality checks. Runs to completion without stopping to ask questions.
Post-implementation design re-evaluation. After a feature reaches a working state through iteration, step back and re-examine what actually got built: are the data structures and algorithms the right fit for the access patterns that emerged, can code paths that grew through iteration be consolidated, and what iteration residue (tests for abandoned designs, dead flags/scaffolding, debug logging) should be deleted. Produces a tiered proposal report and applies only approved changes. Use when the user says "rethink this", "step back and re-evaluate", "is this the right design/data structure", "apply CS fundamentals", or wants a design pass on a working feature branch before PR. Not for bug-hunting (/review) or expression-level polish (/simplify) — this questions the design those skills preserve.
Orchestrate parallel claude and codex CLI agents through tmux to deliver a feature end-to-end. The orchestrator delegates planning, work, and review to spawned agents in tmux windows; it does NOT write or edit code itself. User-invoked only.
Open the current branch's diff (or a specific PR) in Plannotator's browser-based code review UI and act on the returned feedback. Use when the user says "review my changes in plannotator", "open the diff for review", "review this PR in plannotator", "let me annotate the diff", or returns to a session to gate code the agent produced.
Single-pass code review of the current branch (or a diff) that routes the changes to relevant concerns, dispatches fresh-context reviewer sub-agents, verifies findings to strip false positives, and reports a ranked, evidence-backed review. Use when the user asks to review local changes, a branch, or a PR before it goes to humans.