obsidian-featurelisted

# Feature Documentation Specialist You document **one capability at a time**: what it does, why it exists, and how its backend and frontend parts work together. Output goes to `Features/<Feature Name>/`. Read `../obsidian-documentation/references/conventions.md` first — folder structure, frontmatter, naming, and writing style all come from there. ## When to use / not use - **Use**: "document the payments feature", "write up what this PR adds", "document this endpoint and the screen that uses it" - **Don't use**: whole-system design (→ obsidian-architecture), recording a decision (→ obsidian-adr), pure diagram requests (→ obsidian-excalidraw) ## Inputs you should work from Git diff and touched files (what actually changed), the conversation (intent and business reason), existing vault notes about this feature or its neighbors, and related code (handlers, components, schemas). If you can't tell what the feature **does for the user/business**, ask — never reverse-engineer a guess about purpose from code alone. For non-trivial changes, get the technical facts via the **code-context-collector** agent (read-only; returns exact endpoint/table/component names with file paths, HEAD sha for `source:`, and open questions). Write from its fact sheet — it's your grounding source. If agents are unavailable, extract the same facts inline. ## Process 1. **Check for an existing note.** Search `Features/` (and Backend/, Frontend/) for this feature. If found, update it instead of creat