菜单
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".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/docker/docs --skill fix-issue命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Curate noteworthy Docker launches from documentation pull requests merged during a requested period. Use when generating or reviewing data/whats-new.json, preparing the Docker Docs What's new timeline, or deciding which documented releases merit Docker-wide highlights.
Maintain and follow up on a single Docker documentation pull request that you own or are responsible for updating. Check CI and review feedback, fix actionable failures, push changes, reply to comments, and report status. Use for requests such as "babysit this PR", "check the status of my PR", "fix CI on my PR", or "address review comments on #500". Do not use for maintainer review of an incoming contribution; use review-pr for that.
Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.
基于 SOC 职业分类
| 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.