tech-docslisted

# Tech Docs Make documentation a trustworthy interface to the software. Help the intended reader complete a real task, understand the relevant contract, and recover from likely failures without inventing behavior or imposing a foreign docs system. ## Workflow 1. Discover the repository before choosing a document shape. Read scoped agent instructions, existing READMEs and docs, navigation and generator config, contribution guidance, terminology, language, implementation, tests, and repository-native validation commands relevant to the requested surface. 2. Define the documentation job: audience, task or decision, entry point, prerequisites, expected result, likely failure paths, and the interface or behavior that is the source of truth. Ask only for gaps that cannot be resolved from the repository. 3. Choose the narrowest owning surface and read its reference: - README, setup, task, conceptual, or contributor guide: read [Guides and READMEs](references/guides-and-readmes.md). - API, CLI, configuration, or migration documentation: read [Interfaces and Migrations](references/interfaces-and-migrations.md). - JSDoc, TSDoc, rustdoc, docstrings, or explanatory comments: read [Code Documentation](references/code-documentation.md). - Any task with commands, code samples, generated references, links, or docs tooling: read [Examples and Verification](references/examples-and-verification.md). 4. Write at the closest stable source of tr