Create clear feature documentation for non-professional developers. Use PROACTIVELY when documenting new features, significant code changes, creating technical specifications, or when a feature isn't covered in the original project spec. Triggers on requests like "document this feature", "create feature docs", "write technical specification", "document these changes", or any request to explain what code does for future reference. Invoke with: /document-feature, /document-feature-simple, /document-feature-full, or say "use the feature-documenter skill to..."
Create comprehensive feature documentation that helps non-professional developers understand and maintain code.
Every line of documentation is a gift to your future self. Six months from now, you will not remember why you structured the API that way or what edge case the validation handles. Documentation is not overhead; it is insurance against amnesia.
This skill creates documentation for "non-professional developers" — people who can code but may not have deep context on the codebase. This means:
Feature documentation is not a monument. It is a map. Maps get updated when the territory changes. If the code changes and the documentation doesn't, the documentation becomes a lie.
Start with what people need most. Overview first, then details. A reader should be able to understand the feature at three levels:
Symptom: Documentation that just repeats what the code already says.
Problem: // increments counter is not documentation. It is a waste of bytes.
Solution: Explain WHY the counter is incremented, WHEN it matters, and WHAT breaks if it doesn't.
Symptom: "The middleware intercepts the flux capacitor to hydrate the Redux store." Problem: This helps no one who doesn't already understand. Documentation is for learners. Solution: Start with plain language. Introduce jargon only when necessary, with definitions.
Symptom: Documentation describing a feature that was refactored six months ago. Problem: Wrong documentation is worse than no documentation. It actively misleads. Solution: Include a "Last Verified" date. Set calendar reminders to review.
Symptom: Complete API documentation but zero explanation of how to USE the API. Problem: Readers can see WHAT functions exist. They can't see HOW to combine them. Solution: Include at least one complete example showing a real use case end-to-end.
Symptom: Documentation that exists but nobody can find it. Problem: Undiscoverable documentation might as well not exist. Solution: Link from code comments. Add to README. Include in onboarding.
Choose based on audience and purpose:
Determine template complexity
references/template-simple.md)references/template-comprehensive.md)Gather context before documenting
./docs/system-design/ for existing specificationsCreate documentation
/docs or .claude/docs directoryUse simplified template when:
Use comprehensive template when:
You are not writing documentation. You are building a bridge between the developer who wrote the code and the developer who will maintain it. Often, these are the same person separated by time.
Every feature you document is a conversation with the future. Make it worth having.