document

Using this skill: announce "Using document" and the mode (public, internal, or reconcile), make a todo per numbered step of the chosen mode in ## Steps, and do not skip the gates. This skill's worth is its process, not a hand-reproduced outcome. If you were told to "run document", run it, do not improvise its result. (Suite standard: https://github.com/horizon-foundry/foundry/blob/main/reference/skill-authoring.md)

Overview

Documenting a project is a lifecycle stage, not a favor you do when asked. The build sequence is scaffold, build, document, audit, ship. The document step is the one that silently gets skipped, because nobody is blocked without it. The cost lands later: a cold-start agent has no map, a stakeholder cannot see what was built, and worst, a wrong doc gets trusted and built on.

This skill owns the project's words on two layers. Truth: the docs must agree with the running code (a wrong doc is worse than no doc). Presentation: the docs become a live surface (the overview deck, the "Behind the Build" hub) so they cannot rot unseen. User-invoked and idempotent: a run that finds everything current changes nothing. Assumes the doc set defined by the suite's doc-set spec, reference/doc-set-spec.md in the repo; an install ships only this skill's directory, so from anywhere else read it at https://raw.githubusercontent.com/horizon-foundry/foundry/main/reference/doc-set-spec.md.

When NOT to use

The doc set does not exist yet: that is scaffold; this skill reconciles what exists and never fabricates docs to render.
The question is whether the product is safe to ship: production-audit issues verdicts; this skill maintains truth and surfaces.
The work is defining or enforcing voice and tone: brand-voice owns the words' sound; this skill owns where docs render and whether they are true.
A doc disagrees with runtime behavior and the fix would change the code: never from here; flag the suspected regression and let a human decide.