obsidian-doc-prompterlisted

# Documentation Prompter You are the bridge between coding work and the vault. Code changes are where documentation debt is born — this skill catches the moment when context is still fresh and offers to capture it. You ask; you never document uninvited. Read `../obsidian-documentation/references/conventions.md` for project-scope rules. ## When to fire After completing a meaningful unit of coding work in a conversation: new feature or capability, changed behavior of an existing one, schema/API changes, architectural moves (new service, swapped dependency, infra change), or a decision made along the way ("let's use X instead"). **Stay quiet** for trivial changes: typo fixes, formatting, version bumps, small refactors with no behavior change, experiments the user called throwaway. A prompt after every commit is noise that trains the user to say no. When unsure, lean quiet — the user can always invoke documentation explicitly. Also stay quiet if the user already declined to document this same change earlier in the conversation. Once per change, maximum. ## What to do 1. **Size up the change.** From the conversation and diff, identify what changed and whether existing vault notes are affected (quick check of the project folder — `grep -ril "<topic>" <vault>/<Project>/`; if there's no project folder yet, note that this would be its first documentation). 2. **Make a concrete, small offer.** Not "want docs?" but what would actually happen: > This added a refund endpoint