Documentation Is the AI Standards User Interface
The AI rules file is the primary interface between the AI standards program and developers. But the rules file alone is not enough: developers need to know how to configure their tools (setup guide), how to use rules effectively (usage guide), how to write and maintain rules (authoring guide), and where to get help (FAQ, support channels). Without surrounding documentation: the rules file is a reference without context.
The documentation hierarchy: the rules file (the primary document — what conventions to follow), the quick start guide (get from zero to productive in 30 minutes), the usage guide (how to work effectively with AI rules day-to-day), the authoring guide (how to write, test, and maintain rules — for tech leads), the FAQ (answers to common questions), and the knowledge base (searchable repository of tips, examples, and case studies). Each document serves a different audience at a different stage.
The documentation principle: the rules file must be self-sufficient (a developer should be able to use rules effectively after reading only the rules file). The surrounding documentation is supplementary — it enhances understanding but is not required for basic operation. AI rule: 'If a developer needs to read the usage guide before the rules file makes sense: the rules file is incomplete. The rules file should be the only required reading.'
Audience-Specific Content
New developer documentation: quick start guide (15 minutes — install AI tool, configure rules, verify with a test prompt), first-day checklist (repos cloned, tools configured, rules loaded, first AI-assisted PR submitted), and common pitfalls (overriding rules too aggressively, accepting AI output without review, not checking for existing components). AI rule: 'New developer documentation is tested by having a new hire follow it on their first day. If they need help beyond the documentation: update the docs immediately.'
Experienced developer documentation: usage guide (effective prompting techniques with rules, when to override, how to provide feedback), advanced patterns (multi-file features, refactoring with rules, debugging unexpected AI output), and contribution guide (how to propose rule changes, the review process, what makes a good rule proposal). AI rule: 'Experienced developer documentation assumes proficiency. It answers: how do I get more from AI rules? Not: what are AI rules?'
Leadership documentation: program overview (what the AI standards program does, how it is governed), metrics dashboard guide (how to read the dashboard, what the metrics mean), and reporting templates (executive summary, quarterly review, annual report). AI rule: 'Leadership documentation answers: is the program working? How do I communicate the program's value? Leaders do not need to understand rules — they need to understand impact.'
The quick start guide says: 'Run pnpm install, then configure your AI tool.' But the setup process changed 2 months ago and no one updated the guide. A new hire follows the guide, hits an error, and spends 2 hours debugging. Fix: every new hire follows the quick start on their first day. If they hit any issue: the guide is updated before the end of the day. User-tested documentation stays accurate because users continuously validate it.
Documentation Maintenance Strategy
The documentation decay problem: documentation is written once and never updated. Within 6 months: the quick start guide references an old tool version, the usage guide describes patterns that have been replaced, and the FAQ answers questions that are no longer asked. Stale documentation is worse than no documentation — it misleads developers and erodes trust. AI rule: 'Documentation has a freshness date. Every document includes: last-reviewed date and the responsible owner. Documents not reviewed in 3 months: flagged for update.'
Review cadence: rules file (updated continuously — every rule change triggers a rules file update), quick start guide (reviewed monthly — setup steps change when tools or infrastructure change), usage guide (reviewed quarterly — patterns evolve as the team gains experience), authoring guide (reviewed semi-annually — rule writing best practices stabilize), FAQ (updated continuously — new questions are added as they arise, outdated answers are removed). AI rule: 'Tie documentation review to the quarterly rule review cycle. The same meeting that reviews rules: also reviews documentation. One process, two outputs.'
Documentation testing: the quick start guide is tested by every new hire (does it work on their first day?). The usage guide is tested by the lunch-and-learn series (does the content match what is presented?). The authoring guide is tested by the champion training (does it teach rule writing effectively?). AI rule: 'Documentation is tested by use. If new hires struggle with the quick start guide: update it based on their experience. User-tested documentation: stays accurate. Untested documentation: drifts from reality.'
No documentation: the developer asks in Slack and gets the correct answer in 10 minutes. Stale documentation: the developer follows outdated instructions for 2 hours, creates a misconfigured environment, and then asks in Slack — wasting 2 hours plus the Slack time. Stale docs mislead with authority. Set a freshness date on every document. Flag documents not reviewed in 3 months. A short, current document: infinitely better than a comprehensive, outdated one.
Making Documentation Discoverable
Documentation that cannot be found does not exist. Discoverability tactics: single entry point (one URL that links to all AI standards documentation — ai-standards.internal.company.com or a Confluence space), search integration (documentation is indexed by the internal search — developers find answers by searching, not by navigating a hierarchy), contextual links (the rules file links to the relevant guide for each section — 'For more on error handling patterns, see: [usage guide link]'), and IDE integration (links to documentation in the rules file comments — developers access docs without leaving the editor).
Documentation as code: store documentation alongside the rules in the same repository. Benefits: documentation is version-controlled (history and rollback), documentation is updated in the same PR as rule changes (they stay in sync), and documentation follows the same review process as code (quality is maintained). AI rule: 'docs/ directory in the rules repository. Rule change PR: includes documentation update if the change affects any documented behavior. Reviewer checklist: documentation updated?'
Self-service first: developers should find answers in documentation before asking questions in Slack or support channels. The FAQ covers: the 20 most common questions (80% of support volume). The knowledge base covers: edge cases and advanced topics. When a developer asks a question in Slack: answer the question AND add it to the FAQ. AI rule: 'Every repeated question is a missing FAQ entry. Track Slack questions. If the same question is asked 3+ times: add it to the FAQ. The FAQ should eliminate recurring support requests.'
Three developers ask the same question in #ai-standards this month: 'How do I override a rule for a specific file?' The answer exists in the usage guide, page 12, paragraph 4. But no one found it. Fix: add to the FAQ with the exact phrasing developers use ('How to override a rule for one file'). The FAQ uses developer language, not documentation language. When repeated questions drop to zero: the FAQ is complete.
Documentation Strategy Summary
Summary of the AI standards documentation strategy.
- Hierarchy: rules file (required reading) → quick start → usage guide → authoring guide → FAQ → knowledge base
- Self-sufficient rules: the rules file alone should enable effective usage. Guides are supplementary
- New devs: quick start (15 min), first-day checklist, common pitfalls. Tested by every new hire
- Experienced devs: advanced patterns, contribution guide. Assumes proficiency
- Leadership: program overview, dashboard guide, reporting templates. Impact-focused
- Freshness: last-reviewed date on every doc. Review cadence tied to quarterly rule review
- Testing: quick start tested by new hires. Usage guide tested by lunch-and-learns
- Discoverability: single entry point, search indexed, contextual links, IDE integration