Generate @moduledoc/@doc for tested Elixir features; may update their README section or ADR. Not for docs lookup, documentation audits/reviews, or capturing standalone decisions.
SkillScore77Maintained
Automatic
◆Doc Ops pack
Last verified 9/2/2026
What it changes
Passed 15 of 19 test cases with the skill, and 11 of 19 without it.
Without skill59%
With skill77%
Checks it passed that the model alone missed
Omits @doc annotations for functions that do not have confirming tests
Refuses to add @doc to untested code until test coverage is established
Reports that no new modules were added and documentation coverage is unchanged
and 4 more in the full report
6 fixed11 passed either way3 still failing2 broke
Pass-rate lift
+18 pp
Tokens
+3%
Agent turns
0%
Response time
-30%
Model gemini-3.6-flashMeasured 9/2/2026v517 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
Where should the final documentation review report file be saved for a feature named 'user-invites' under the plan slug 'team-management'?
What was checked, without and with the skill
Checked
Without skill
With skill
Outputs the report path as .claude/plans/team-management/reviews/user-invites-docs.md
Missed
Passed
case-13 · gemini-3.6-flash · 9/2/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md72 lines5 files
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
Never remove existing documentation — Existing docs may reflect design intent that isn't obvious from code alone; update rather than replace
@moduledoc on every public module — Undocumented modules accumulate quickly and create onboarding friction for new team members
ADRs capture the "why", not the "what" — Code shows what was built; ADRs explain why this approach was chosen over alternatives
Match @doc to function's public API — Document parameters, return values, and edge cases; callers shouldn't need to read the implementation
DO NOT add @doc to untested code — documentation implies a stable contract; document only after tests confirm the function behaves as described
What Gets Documented
Output
Description
@moduledoc
For new modules missing documentation
@doc
For public functions without docs
README section
For user-facing features
ADR
For significant architectural decisions
Workflow
Step 0: Pre-check (avoid no-op runs)
Run git diff --name-only HEAD~5 | grep '\.ex$' | head -20 to check for new .ex files.
If NO new .ex files were added (only modifications), skip the full
audit and report: "No new modules — documentation coverage unchanged."
This prevents 35-message analysis sessions that conclude "PASS" with
zero output (confirmed: session bb0a0454 wasted ~2K tokens on no-op).
Choose Phoenix review, plan, debug, or test command. Use when user asks which phx-* command or plugin skill handles a task; do not route only to a domain skill. NEVER for bare /help; NOT for ambiguous requests (use intent-detection) or a plugin tour.