document

Start by reading project docs like README and CONTRIBUTING to learn conventions, then investigate the feature's code to understand what it does and why. Draft documentation that explains intent and connections rather than restating what the code already shows.

It supports feature documentation, API references, architecture overviews, how-to guides, code tours, and README or CONTRIBUTING files. The type is determined from your request and existing project conventions rather than rigid templates.

A validation step checks the draft against the actual implementation: whether described behaviors match the code, code examples are correct and runnable, and file paths and references are accurate. Discrepancies are fixed before the documentation is presented.

Follow existing project conventions first. If none exist, defaults are docs/[feature-name].md for features, docs/api/ for API references, docs/architecture/ for architecture, docs/how-to/ for guides, and docs/tours/ for code tours.

Skip documentation that restates what the code already communicates, such as describing that getUserById gets a user by ID. Also avoid documenting internal implementation details that change frequently, since those docs rot quickly.