From obsidian-grill
Grilling session that stress-tests your plan against your Obsidian vault's established knowledge — terminology, prior decisions, and open questions — then writes crystallised glossary terms and decision notes back into the vault as linked Obsidian notes. Use when the user wants to challenge a plan against what their knowledge base already says, in the language of their vault, and capture the outcome in Obsidian. The vault is the source of truth and the destination; the codebase is cross-referenced too.
How this skill is triggered — by the user, by Claude, or both
Slash command
/obsidian-grill:grill-with-obsidianThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<what-to-do>
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time, waiting for feedback on each question before continuing.
If a question can be answered by exploring the Obsidian vault or the codebase, explore them instead of asking.
This skill combines three installed skills:
grill-with-docs (mattpocock) — the grilling methodology, glossary discipline, and ADR criteria. This skill adapts it.wiki-query — how to read/search the vault for domain awareness during the interview.wiki-update — how to write distilled knowledge back into the vault.~/.obsidian-wiki/config to get OBSIDIAN_VAULT_PATH (the vault) and
OBSIDIAN_WIKI_REPO. If the file doesn't exist, tell the user to run
bash setup.sh from their obsidian-wiki repo, and stop.$OBSIDIAN_VAULT_PATH/index.md (and overview.md if present) to learn
the vault's scope and conventions.wiki-update does) and target projects/<project-name>/. If
the topic doesn't map cleanly to an existing project, ask which project (or
propose creating a new one).Before asking a question, see whether the vault already answers it or whether
the plan contradicts what's recorded. Search like wiki-query:
**/*.md over $OBSIDIAN_VAULT_PATH for matching titles, then Grep content.[[wikilinks]] from hits to related notes; check frontmatter tags.projects/<project>/ first (its glossary.md, decisions/, concepts),
then the wider vault (concepts/, entities/).Also cross-reference the codebase when the user states how something works.
When a term conflicts with how the vault already defines it, call it out immediately:
"Your vault's glossary defines cancellation as X (see [[cancellation]]), but you
seem to mean Y — which is it?"
When a term is vague or overloaded, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things." Prefer terms already canonical in the vault.
Invent specific scenarios that probe edge cases and force precise boundaries between concepts.
If the vault, the code, and the user disagree, surface the contradiction:
"[[order-cancellation]] says orders cancel whole; your code cancels line items;
you just said partial — which is right?"
Capture decisions as they crystallise, in Obsidian-native form. All writes go
under projects/<project-name>/. Create files lazily — only when you have
something to write.
projects/<project>/glossary.mdWhen a term is resolved, update the project glossary right there. Use the format
in GLOSSARY-FORMAT.md: frontmatter tags, bold term
names, [[wikilinks]] to related notes, aliases to avoid. The glossary is a
glossary only — no implementation details, no spec, no scratch pad.
Cross-link terms to existing vault notes where they already exist.
projects/<project>/decisions/NNNN-slug.mdOffer a decision note only when all three are true:
If any is missing, skip it. Use the format in DECISION-FORMAT.md:
frontmatter (status, date, tags), 1–3 sentences, [[wikilinks]] to the
terms and notes it touches. Number by scanning projects/<project>/decisions/
for the highest existing NNNN and incrementing.
When a grilling branch can't be settled now, record it under an ## Open
Questions section in the relevant note (glossary, decision, or the project
overview). This keeps the gap visible and lets wiki-query surface it later.
[[wikilinks]], not bare text, when referencing other notes/terms.tags consistent with the vault's existing taxonomy (peek at
Tags/ or neighbouring notes).projects/<project>/<project>.md (the project overview) exists, link new
glossary/decision notes from it; if it doesn't and you've created notes, add a
short overview that links them.Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub 0xkatze/obsidian-grill --plugin obsidian-grill