// Write a documentation fix on a branch. Makes the minimal change, formats, self-reviews, and commits. Use after research has identified what to change. "write the fix", "make the changes", "implement the fix for #1234".
| name | write |
| description | Write a documentation fix on a branch. Makes the minimal change, formats, self-reviews, and commits. Use after research has identified what to change. "write the fix", "make the changes", "implement the fix for #1234". |
| hooks | {"PostToolUse":[{"matcher":"Edit|Write","hooks":[{"type":"command","command":"bash ${CLAUDE_SKILL_DIR}/scripts/post-edit.sh"}]}]} |
Make the minimal change that resolves the issue. Research has already identified what to change — this skill handles the edit, formatting, self-review, and commit.
git checkout -b fix/issue-<number>-<short-desc> main
Use a short kebab-case description derived from the issue title (3-5 words).
Always read each file before modifying it. Make the minimal change that fixes the issue. Do not improve surrounding content, add comments, or address adjacent problems.
Follow the writing guidelines in CLAUDE.md, STYLE.md, and COMPONENTS.md.
Every content page requires title, description, and keywords in its
front matter. If any are missing from a file you touch, add them.
Prettier runs automatically after each edit via the PostToolUse hook. Run lint manually after all edits are complete:
scripts/lint.sh <changed-files>
The lint script runs markdownlint and vale on only the files you pass it, so the output is scoped to your changes. Fix any errors it reports.
Re-read each changed file: right file, right lines, change is complete,
front matter is present. Run git diff and verify only intended changes
are present.
Stage only the changed files:
git add <files>
git diff --cached --name-only # verify — no package-lock.json or other noise
git commit -m "$(cat <<'EOF'
docs: <short description under 72 chars> (fixes #NNNN)
<What was wrong: one sentence citing the specific problem.>
<What was changed: one sentence describing the exact edit.>
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
The commit body is mandatory. A reviewer reading only the commit should understand the problem and the fix without opening the issue.
_vendor/ or data/cli/ — these are vendoredgit log --all --full-history -- "**/filename.md"Push the current branch and create a pull request against docker/docs. Use after changes are committed and reviewed. "create a PR", "submit the fix", "open a pull request for this".
Clone a dockersamples Labspace repo, extract learning objectives and module structure from labspace.yaml, and produce a Hugo guide page under content/guides/ with correct frontmatter, labspace-launch shortcode, and Docker docs style compliance. Use when asked to create a lab guide, write a Labspace page, add a Docker lab tutorial, migrate a lab to docs, or document a hands-on lab.
Analyze a single GitHub issue for docker/docs — check whether the problem still exists, determine a verdict, and report findings. Use when asked to triage, assess, or review an issue, even if the user doesn't say "triage" explicitly: "triage issue 1234", "is issue 500 still valid", "should we close #200", "look at this issue", "what's going on with #200".
Handle Hugo docs information-architecture moves: discover old vs new URLs, add front matter aliases (Phase 1), update in-repo links (Phase 2), interactive List 2 resolution and fragment validation (Phase 3; no guessing). Supports PR-scoped mapping plus whole-content sweeps for inbound links to that mapping, or a full-site follow-up. Triggers on: "IA migration", "redirects for moved pages", "fix links after content move", "PR-scoped link/anchor pass", "aliases for old URLs". After branch work, chain the review-changes skill (main...HEAD) before a PR. Agents must run the in-file required procedure and definition of done, not the phases alone in isolation.
Audit a documentation site for agent-friendliness: discovery, markdown delivery, crawlability, semantic structure, machine-readable surfaces, and content legibility. Use when asked to assess docs.docker.com or any docs site for AI/agent readiness, produce a scored report, compare with external scanners, or generate a remediation list. Triggers on: "audit docs for agent readiness", "how agent-friendly is docs.docker.com", "score our docs for AI agents", "review llms.txt / markdown / crawlability", "create an agent-readiness remediation plan".
Check a single PR's CI status, review comments, and requested changes. Fix actionable failures and address feedback. "check PR 1234", "what's the status of my PR", "address review comments on #500".