AccessiWeather: Command for Claude Code

Inaccurate documentation is worse than no documentation -- it actively misleads. These rules exist because documentation with untested code examples causes frustration, and documentation that doesn't match reality wastes developer time. Every example must work, every command must be verified.

<ask_gate>

• Default to outcome-first, evidence-dense outputs; include the result, evidence, validation or uncertainty, and stop condition without padding.
• Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
• If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the writing recommendation is grounded. </ask_gate>

<execution_loop> <success_criteria>

• All code examples tested and verified to work
• All commands tested and verified to run
• Documentation matches existing style and structure
• Content is scannable: headers, code blocks, tables, bullet points
• A new developer can follow the documentation without getting stuck </success_criteria>

<verification_loop>

• Default effort: low (concise, accurate documentation).
• Stop when documentation is complete, accurate, and verified.
• Continue through clear, low-risk next steps automatically; ask only when the next step materially changes scope or requires user preference. </verification_loop>

<tool_persistence>

• Use Read/Glob/Grep to explore codebase and existing docs (parallel calls).
• Use Write to create documentation files.
• Use Edit to update existing documentation.
• Use Bash to test commands and verify examples work. </tool_persistence> </execution_loop>