| name | doc |
| description | Generate or update documentation for hlstatsnext.com — package READMEs, ARCHITECTURE.md, JSDoc on exported surfaces, CHANGELOG entries. Use when code needs docs or existing docs are outdated. |
| argument-hint | <target file, package, or feature> |
| model | opus |
| effort | medium |
Documenter
Generate and update documentation for hlstatsnext.com.
Documentation types
- Package README (
packages/<name>/README.md, apps/<name>/README.md): purpose, public API surface, install/use snippet, env vars consumed, related packages
- Top-level project docs under
docs/ (ALL_CAPS naming — ARCHITECTURE.md, BEST_PRACTICES.md, PRODUCTION_DEPLOYMENT.md, DOCKER_NETWORKING_SETUP.md, etc.): keep in sync when patterns change; if a new subsystem deep-dive is needed, add a new docs/<TOPIC>.md matching that style
- JSDoc on exported functions/classes — only for non-obvious surfaces (Pothos resolvers, RCON protocol handlers, validators, RabbitMQ adapters). Skip getters and trivial passthroughs.
CHANGELOG.md (if used): Keep a Changelog format — [Unreleased] → Added / Changed / Fixed / Removed
Process
- Read the code being documented
- Read existing docs in the same area to match tone and format
- Identify whether existing docs are stale (reference renamed files, removed functions, old patterns)
- Write or update — additive by default, only remove things that are factually wrong
- Verify code examples compile (mentally type-check the snippet against the current API)
- Check for stale cross-references (links to moved files, removed functions, deprecated env vars)
Guidelines
- Accuracy over comprehensiveness. Wrong docs are worse than no docs.
- Code examples must be copy-pasteable with the right imports — use the
@repo/* aliases.
- Package READMEs are 60-second briefings, not exhaustive references. Lead with the purpose and a single usage snippet.
- Don't document internal implementation in user-facing docs. Internal patterns go in JSDoc, or in a new top-level
docs/<TOPIC>.md for cross-cutting subsystems.
- Use the project's terminology consistently: daemon, ingester, ingress, orchestrator, coordinator, repository, GraphQL resolver, RCON command — match how the codebase names things.
- For JSDoc: explain WHY when not obvious. Don't restate the signature. The CLAUDE.md rule about comments applies here too.
- For ARCHITECTURE updates: include a one-line diff in the doc itself ("Updated 2026-MM-DD to reflect X") when the change is significant.
- For schema docs: don't duplicate the Prisma schema in prose. Link to it.
Target: $ARGUMENTS
