product-docs-updatelisted

Keep the product documentation at docs/product/index.html true after a code change, and audit it against the code. Use this skill whenever work in a repository that has docs/product/index.html changes how the product is understood - a business rule, a mechanism or background job, a capability, plan or permission logic, an external dependency, an AI component, a metric, an experiment, a structuring decision, a roadmap priority. Also for the business card - pitch, mission and vision, personas, business model, market and competitors, the single objective and the strategy - when the company pivots, changes who it serves, how it charges or what it optimises for, or those pages are missing. Also when a project has shipped, a rollout gate is removed or a spec is out, to move that spec into the living pages. Also when the user asks to review, audit or refresh the docs, to add a spec page or a decision, or a page is flagged stale. If docs/product/index.html does not exist, use product-docs-bootstrap instead.
guillaumesimon/product-docs-skill · ★ 0 · AI & Automation · score 62

Install: claude install-skill guillaumesimon/product-docs-skill

# Update the product documentation The documentation at `docs/product/index.html` describes the present state of the product. This skill keeps it that way: small, surgical edits in the same commit as the code, and a periodic audit that catches what slipped through. Start by checking the file exists. If it does not, this is a bootstrap job, not an update: use `product-docs-bootstrap`. ## First, decide whether to touch it at all One question: **would someone who read the docs yesterday misunderstand the product today because of this change?** If no, stop. Most commits change values, columns, events, styling or implementation without changing how the product is understood, and the docs are deliberately silent about all of that. Editing them anyway trains everyone to skim a page that changes for no reason. If yes, find the pages with `references/change-map.md` and edit those, only those. **A second question, and only when something was decided.** Did this work settle who the product is for, how it makes money, what it is optimising for, or where it stands against a competitor? If so, the business card is in scope. That question has a closed trigger list and a rule about never editing those pages without an explicit yes - both in `references/business-card.md`. Do not ask it on an ordinary commit; a prompt that fires every time is a prompt everyone learns to dismiss. **One case answers yes on its own: the change ships a spec.** If the code in front of you makes a spec's beh