メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
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 職業分類に基づく
SKILL.md を表示中
| 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.