Obsidian feature

Skill rubber-ducks-syndicate/obsidian-documentation-skill/skills/obsidian-feature

A modular orchestrator + specialists ecosystem for Claude Code that turns code changes and conversations into structured, linked Obsidian documentation.

Install

npx -y skills add rubber-ducks-syndicate/obsidian-documentation-skill --skill obsidian-feature

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Specialist skill for documenting features (backend + frontend) in an Obsidian vault. Normally invoked by the obsidian-documentation orchestrator, but also use it directly when the user asks to document a feature, a new capability, an endpoint, a UI flow, or "what I just built" — including from a git diff or PR. Produces feature notes under Features/ with backend/frontend sub-notes, ready for the tagging and linking pass.

SKILL.md

4.0 KB, as published. Nobody here has run it

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

Check for an existing note. Search Features/ (and Backend/, Frontend/) for this feature. If found, update it instead of creating a new one.
Determine scope. Small feature → one note. Larger feature with distinct backend and frontend work → main note + Backend.md + Frontend.md sub-notes in the feature folder.
Write the main note using the template below.
Flag diagram opportunities to the orchestrator (e.g., a request flow worth drawing) — do NOT create diagrams yourself; that is obsidian-excalidraw's job.
Propose tags and links in frontmatter/Related sections, but final consistency is enforced by obsidian-tagging and obsidian-linking.

Main feature note template

---
created: <date>
updated: <date>
type: feature
status: active
tags: [feature, <domain tags>]
related: ["[[<related notes>]]"]
---

# <Feature Name>

<2–3 plain-language sentences: what this feature does and why it exists. A non-developer should understand this paragraph.>

## Why we built it

<Business/user problem it solves. The "why".>

## How it works

<Plain-language walkthrough of the flow, end to end. Mention key components
by name and link them: [[Backend/Payment Service]].>

## Backend

<Summary + link to [[Backend]] sub-note if one exists. Endpoints, data
model changes, jobs — explained simply.>

## Frontend

<Summary + link to [[Frontend]] sub-note if one exists. Screens,
components, state — explained simply.>

## Example

<A concrete scenario: "When a customer clicks Pay, …">

## Related

- [[Features MOC]]
- <other related notes>

Sub-notes (Backend.md, Frontend.md) follow the same shape, scoped down, and always link back to the main note.

Example

Input: git diff adds POST /refunds endpoint, a RefundButton React component, and a refunds table.

Output:

Features/Refunds/Refunds.md — main note: why refunds were needed, how a refund flows from button click to payout
Features/Refunds/Backend.md — endpoint, table, refund job (tags: feature, backend, backend/api)
Features/Refunds/Frontend.md — RefundButton, confirmation modal (tags: feature, frontend/react)
Flag to orchestrator: "refund flow is a good sequence-diagram candidate"