메뉴
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에서 현재 제공할 수 있는 파일을 다운로드하세요.
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.