Bookmarking
Append a new entry to the active scope's bookmark store — capture-only. All
triage, pruning, and graduation live in /hygiene-check, so this skill stays lean
enough to auto-fire safely.
When to use
- The user says "bookmark this," "park this for later," "backburner this," "park for someday," "revisit this soon," or similar.
- Something comes up mid-conversation worth revisiting but that would derail the current thread.
- A future improvement is identified that the user wants to defer.
Where it goes — scope-aware capture
Determine the active scope from context (the repo/layer this session is working in) and append to that scope's store rather than a hardcoded path:
- Yggdrasil work →
bookmarks.mdat the Yggdrasil repo root (C:\Projects\yggdrasil\bookmarks.md). - A personal-layer item →
claude-personal/bookmarks.md. - An adopted / puppet project → that project's own bookmark store.
Use Glob to locate the store if its path isn't obvious; if the scope is genuinely ambiguous, ask one quick question rather than guessing. Grep the target store before appending so you don't write a near-duplicate of an existing entry.
Active vs. backburner
- Active bookmark (default) → the scope's
bookmarks.md. Things to revisit reasonably soon; the session bookends surface their count and age. An urgency cue ("soon," "priority") can be marked inline with a[soon]/[priority]tag, matching the store's existing convention. - Backburner → when the user says "backburner this" / "park for someday" (cold,
no-near-term-intent), append to
backburner.mdat the scope root instead. Backburner entries carry nosoontag — they're explicitly someday/maybe.
Format
Each entry is a single Markdown list item with a date prefix:
- **2026-05-27** — Short description of the thing to revisit.
If the target store doesn't exist, create it with its standard header (copy the header
from an existing bookmarks.md / backburner.md) and append the new entry under it.
What goes in an entry
The user's words, lightly cleaned up if needed. Preserve their intent and phrasing — these are notes-to-self, not formal documentation. If the input is very short or ambiguous, ask one quick clarifying question before writing.
Capture enough context to make the entry actionable later — especially the why and any alternatives considered, if it records a decision. A future session won't have this conversation; an entry that says "do X (option 2)" without recording what the options were can't be acted on cleanly. Err toward one extra sentence of context.
What does NOT go in an entry
- Anything the user has already acted on or resolved.
- Sensitive credentials, secrets, or personal data.
- Long-form notes — those belong in dedicated documents.
- Maintenance actions — pruning, archiving, graduating, or triaging existing
entries. Those belong to
/hygiene-check; this skill only captures.