ultrakit:audit:docs
Audit Docs
Orchestrate a documentation audit by dispatching parallel agents in two directions: ultrakit:audit:doc-worker agents verify docs against code (docs → code), and ultrakit:audit:code-worker agents scan code for undocumented features (code → docs). Then dispatch ultrakit:audit:doc-fixer agents to apply changes.
This skill is separate from the engineering delivery workflow. It runs ad-hoc or on a schedule to keep documentation current.
Documentation Surfaces
Projects typically have up to three documentation surfaces, each with its own audience and change bar:
| Surface | Audience | Describes | Change bar |
|---|---|---|---|
| Developer docs | Engineers building the system | Architecture, contracts, data flows, design rationale | Would a new team member get a wrong mental model? |
| User-facing docs | People using the product/platform | How to use it, configuration, expected behavior | Would a user have wrong expectations? |
| Agent skills | AI agents assisting with the project | Workflows, commands, patterns, reference material | Would an agent give wrong guidance? |
Not every project has all three. Identify which surfaces exist and where they live before starting the audit.
Developer docs are for architecture, not implementation details. They describe system structure, component boundaries, inter-component contracts, and key design decisions. They do NOT describe class names, method signatures, internal code organization, or implementation patterns within a component. The test: if a change is reverted, does the system's architecture diagram or contract specification change? If no, developer docs do not need updating.