Document

Generate documentation for newly implemented features.

Usage

/phx:document .claude/plans/magic-link-auth/plan.md
/phx:document magic link authentication
/phx:document  # Auto-detect from recent plan

Iron Laws

1. Never remove existing documentation — Existing docs may reflect design intent that isn't obvious from code alone; update rather than replace
2. @moduledoc on every public module — Undocumented modules accumulate quickly and create onboarding friction for new team members
3. ADRs capture the "why", not the "what" — Code shows what was built; ADRs explain why this approach was chosen over alternatives
4. Match @doc to function's public API — Document parameters, return values, and edge cases; callers shouldn't need to read the implementation
5. DO NOT add @doc to untested code — documentation implies a stable contract; document only after tests confirm the function behaves as described