// Fix a single GitHub issue end-to-end: triage, research, write the fix, review, and create a PR. Use when asked to fix an issue: "fix issue 1234", "resolve #500", "create a PR for issue 200".
| name | fix-issue |
| description | Fix a single GitHub issue end-to-end: triage, research, write the fix, review, and create a PR. Use when asked to fix an issue: "fix issue 1234", "resolve #500", "create a PR for issue 200". |
| argument-hint | <issue-number> |
Given GitHub issue $ARGUMENTS, decide what to do with it and either close it or fix it. This skill orchestrates the composable skills — it owns the decision tree, not the individual steps.
Invoke /triage-issue $ARGUMENTS to understand the issue and decide what
to do. This runs in a forked subagent and returns a verdict.
If triage says close it — comment with the reason and close:
gh issue close $ARGUMENTS --repo docker/docs \
--comment "<one sentence explaining why>
Generated by <active coding agent name>"
Done.
If triage says escalate upstream — comment noting the repo and stop:
gh issue comment $ARGUMENTS --repo docker/docs \
--body "This needs to be fixed in <upstream-repo>.
Generated by <active coding agent name>"
Done.
If triage says leave it open — comment explaining what was checked and what's unclear. Do not close. Done.
End every issue comment with an accurate agent-disclosure footer that names
the active coding agent, for example Generated by Codex or Generated by Claude Code.
If triage says fix it — proceed to step 3.
Invoke /research to locate affected files, verify facts, and identify
the fix. The issue context carries over from triage. This runs inline —
findings stay in conversation context for the write step.
If research reveals the issue is upstream or cannot be fixed (e.g. unverifiable URLs), comment on the issue and stop.
Invoke /write to create a branch, make the change, format, self-review,
and commit.
Invoke /review-changes to check the diff for correctness, coherence, and
mechanical compliance. This runs in a forked subagent with fresh context.
If issues are found, fix them and re-review until clean.
Invoke /create-pr to push the branch and open a pull request.
git checkout main
Summarize what happened: the issue number, what was done (closed, escalated, fixed with a PR link), and why — in a sentence or two.
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".
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".
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".