docs-and-writing

Maps repository changes to required documentation updates with templates and style rules.

Updated Jul 3, 2026
One-click install
npx skills add https://github.com/MarineTeam/fable-video --skill docs-and-writing-marineteam
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: docs-and-writing
Source: https://github.com/MarineTeam/fable-video/tree/main/.claude/skills/docs-and-writing
Command: npx skills add https://github.com/MarineTeam/fable-video --skill docs-and-writing-marineteam

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a feature ships, a bug is fixed, or an environment variable is added, it is easy to forget which documents must change with it. This Skill answers exactly that: given a change type, it tells you which files and sections of README.md, FEATURES.md, CHANGELOG.md, and the skill library must be updated, and in what format. ## Core Features & Use Cases - Update matrix: Maps change types (new feature, new env var, bug fix, dependency change, release, security fix) to the exact docs and sections to touch. - Ready-to-paste templates: Provides verbatim-format skeletons for CHANGELOG release sections, FEATURES.md bullets, README env-var rows, common-issues entries, and skill Provenance tables. - Style guide enforcement: Codifies the repo's actual writing conventions — bold lead-in with em-dash, known-gaps honesty markers, date-stamped volatile facts, and runnable verify commands. - Use Case: After adding a new environment variable, consult the matrix to learn you must update the correct README env-var table, the environment-and-config skill's inventory, its env.local.template, and possibly the CI build env block. ## Quick Start Ask the AI to use the docs-and-writing skill to determine which documentation files and sections must be updated for the change you just made.

Frequently Asked Questions about docs-and-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I know which docs to update after shipping a feature?

Use the update matrix: find your change type (new feature, env var, bug fix, release) and touch every listed doc and section. A new user-visible feature requires a FEATURES.md bullet, a CHANGELOG.md Added entry, and README updates if it changes what users or admins see.

What is the correct format for a CHANGELOG release section?

Use a versioned header like ## [X.Y.Z] - YYYY-MM-DD, a one-paragraph summary, then ### Added, ### Performance, and ### Known gaps subsections with bold lead-in bullets wrapped at about 78 characters. Fixed, Changed, and Security are valid Keep a Changelog categories when content calls for them.

When should I not use this documentation skill?

Do not use it to decide whether a change is safe (use change-control), to understand architecture rationale (architecture-contract), to triage security alerts (security-response), or to diagnose runtime symptoms (debugging-playbook). It only covers writing the record once you know what changed.

How do I document a new environment variable in a README?

Add one table row in the correct section: Required if the app breaks without it, Optional-email for email knobs, Optional-other for everything else. Also update the environment-and-config skill's inventory and env template, plus the CI build env block if the variable is read during next build.

What version artifacts must agree before publishing a release?

Three artifacts must name the same version: package.json's version field, the top CHANGELOG.md version header, and FEATURES.md's Current as of header. The v1.8.0 release shipped with package.json and the FEATURES header lagging, so verify all three with grep before tagging.