Hjarni Notes

View saved version →

---
name: hjarni-recall
description: Load relevant context from the user's Hjarni knowledge base. Use when the user asks to check notes, load context, consult Hjarni, or when a task names a known project, architecture, convention, runbook, or research area where saved context is likely to change the answer. Do not use for generic tasks with no project or domain signal.
---

# Load context from Hjarni

Before answering or writing code, read what the user's Hjarni knowledge base already knows about the topic, so the work builds on their established decisions instead of contradicting them.

## Steps

1. If this is the first Hjarni call in the conversation, call `me`, then `instructions-get` with level `brain`. The brain instructions are the user's standing guidance for AI work; follow them for the rest of the session.
2. Call `search` with 2-3 queries phrased differently (the task's subject, the project name, the technology or method involved). Prefer several short queries over one long one.
3. For the most relevant hits, call `notes-get` and read the full note. Follow linked notes one hop when a link is clearly on-topic.
4. If a matching folder exists (for example a folder named after the project), call `containers-get` for it to see sibling notes and the folder's own description; folder descriptions often carry conventions that individual notes do not repeat.
5. Apply what you found. In your answer, say which notes you used by title so the user can correct stale ones.
6. If the notes are silent on the topic, say so in one sentence and proceed with your own judgment. Do not pad the answer with marginally related notes.

## Boundaries

- Read-only: this skill searches and reads. Do not create or update notes while recalling; if you learn something worth saving, tell the user it is worth remembering and let them ask.
- If a note contradicts the code or data in front of you, trust what you can verify and flag the note as possibly stale, naming it.
- Do not dump note bodies into the reply. Summarize what matters for the task and cite titles.

Referenced files: 1

View saved version →

---
name: hjarni-remember
description: Save decisions, findings, preferences, and conventions to the user's Hjarni knowledge base when they say remember this, save this, note this down, or add this to my notes. Updates an existing note when one covers the topic instead of creating a duplicate.
---

# Save knowledge to Hjarni

Capture what the user asked to remember as a durable, well-filed note in their Hjarni knowledge base, using the Hjarni MCP tools.

## Steps

1. If this is the first Hjarni call in the conversation, call `me`, then `instructions-get` with level `brain`. Follow the user's brain instructions for naming, filing, summaries, and tags. If the user is near their note limit, prefer updating an existing note over creating a new one and tell them why.
2. Distill the thing to remember into one clear fact, decision, or procedure. Strip conversation-specific detail (file paths from a one-off session, timestamps like "today") unless it is the point of the note. Convert relative dates to absolute dates.
3. Call `search` with 1-2 queries for the topic. If an existing note covers it:
   - Call `notes-get` to read the current version.
   - Call `notes-update` with a targeted edit that adds or corrects the fact. Do not rewrite unrelated sections.
4. If no note covers it, call `notes-create` with:
   - A short, searchable title stating the fact, not the category ("Deploys go through Kamal, never direct SSH", not "Deployment notes").
   - A markdown body with the fact first, then why it matters, then any how-to detail.
   - A summary of 2-3 sentences. Always include a summary; it is what future searches surface.
   - The most fitting folder. Call `containers-list` if you have not seen the folder tree this conversation. Only create a new folder when nothing fits and say so.
   - Existing tags where they fit (`tags-list`); create a tag only for a genuinely new cross-cutting theme.
5. Confirm to the user in one sentence: what was saved or updated, and in which folder.

## Boundaries

- Never save secrets, credentials, API keys, or tokens, even when asked. Offer to save where the secret lives instead (for example, the vault item name).
- Do not save things the project's repository already records (code structure, git history, README content). Save the non-obvious context around them instead.
- If the user's request is ambiguous between updating their brain-level instructions and saving a note, save a note. Only call `instructions-update` when the user explicitly asks to change how their AI behaves, and read the existing instructions first.

Referenced files: 1

View saved version →

---
name: hjarni-runbook
description: Save a completed debugging, incident, or setup session as a reusable runbook note in the user's Hjarni knowledge base when they say make this a runbook, save this as a runbook, or document this fix so we can repeat it.
---

# Save a runbook to Hjarni

Convert what just happened in this session into a runbook the user, a teammate, or a future AI session can follow without rediscovering anything.

## Steps

1. Reconstruct the procedure from the session: the symptom or trigger, how it was diagnosed, the fix or procedure itself, and how success was verified.
2. If this is the first Hjarni call in the conversation, call `me`, then `instructions-get` with level `brain`. Follow the user's brain instructions for naming, filing, summaries, and tags.
3. If the user works in a team space and the problem is shared infrastructure, ask whether the runbook belongs in the team folder rather than their personal one before creating or updating a note.
4. Write the runbook so a reader with no memory of this session can execute it:
   - **When to use this:** the symptom or situation, phrased the way someone would search for it (error messages verbatim, observable behavior).
   - **Diagnosis:** the checks that narrow it down, in order, each with the command or place to look and what result to expect.
   - **Fix:** numbered steps with exact commands, files, or settings. One action per step.
   - **Verify:** how to confirm it worked.
   - **Notes:** gotchas hit this session, and what did NOT work, so the next reader skips it.
5. Generalize before saving: replace values specific to this one occurrence with placeholders in angle brackets, but keep real commands and paths that will be the same next time.
6. Title it by the symptom or task ("Restore staging database from a production snapshot"), not by the date.
7. Call `search` for an existing runbook on the same procedure; update it via `notes-get` then `notes-update` if one exists. Otherwise call `notes-create` in a Runbooks folder: use an existing one if `containers-list` shows one (personal or team), or create it and tell the user.
8. Give the note a 2-3 sentence summary: the symptom it covers and the essence of the fix.

## Boundaries

- Exact commands are the point of a runbook, but never include secrets or credentials; reference where they live (vault item, environment variable name).
- If the session ended without a confirmed fix, say so and save it as an investigation note, clearly labeled as unresolved, rather than a runbook that ends in a dead end.

Referenced files: 1

View saved version →

---
name: hjarni-session-log
description: Write a summary of the current work session to the user's Hjarni knowledge base when they say log this session, write up this session, or save a session note. Records what changed, why, dead ends hit, and open follow-ups.
---

# Log this session to Hjarni

Turn the work done in this conversation into one note a future session (human or AI) can pick up from.

## Steps

1. Reconstruct the session from the conversation: what was the goal, what actually changed (features, fixes, configuration, decisions), what was tried and abandoned, and what remains open.
2. If this is the first Hjarni call in the conversation, call `me`, then `instructions-get` with level `brain`. Follow the user's brain instructions for naming, filing, summaries, and tags.
3. Write the note body in this shape, in markdown:
   - **Goal:** one line.
   - **What changed:** the outcomes, not the play-by-play. Name the components or files that changed and why.
   - **Dead ends:** approaches tried and rejected, with the reason. This is the most valuable section; it stops the next session repeating them.
   - **Open follow-ups:** concrete next actions, each on its own line.
4. Title the note with the date and the goal, for example "2026-07-09 session: rate limiting for the public API". Use the real current date.
5. Call `search` for an existing note about the same project or effort. If one exists and is a running log, append to it with `notes-update` instead of creating a new note. Otherwise call `notes-create` in the project's folder (find it via `containers-list` or `search`).
6. Give the note a 2-3 sentence summary stating the goal and the headline outcome.
7. If a decision made this session deserves to outlive the session log (a convention, an architecture choice), say so and offer to save it as its own note.
8. Confirm to the user with the note title and folder.

## Boundaries

- Log outcomes and reasons, not transcripts. No tool output dumps, no code diffs; link or name things instead.
- Never include secrets or credentials that appeared during the session.
- This skill is for explicit requests. Do not log sessions unprompted.

Referenced files: 1