メニュー
End-to-end workflow to fix a GitHub issue — collect context, analyze, implement on a branch, open a PR, then hand off to /pr-watch-fix until CI is green.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/oxsecurity/megalinter --skill fix-issueコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Guided workflow for adding a new linter to MegaLinter. Use when a contributor needs to add support for a new linting tool.
Fix the errors reported by MegaLinter. Use after megalinter-check found errors, or when the user pastes MegaLinter/CI lint errors and wants them fixed. Applies safe fixes automatically (auto-fix linters first, then guided manual fixes using per-linter fix guides), asks the user when fixing is ambiguous, and can disable rules or linters with user confirmation. Never pushes to the default branch.
Collect MegaLinter lint errors for the current repository. Use when the user wants to know if the code passes linting, why the MegaLinter CI job fails, or before/after fixing lint errors. Two modes - watch a CI job (GitHub Actions, GitLab CI, Azure Pipelines, Bitbucket Pipelines) and parse its logs, or run MegaLinter locally with Docker (full run or fast parallel standalone linter runs).
SOC 職業分類に基づく
| name | fix-issue |
| description | End-to-end workflow to fix a GitHub issue — collect context, analyze, implement on a branch, open a PR, then hand off to /pr-watch-fix until CI is green. |
| allowed-tools | Bash Read Grep Glob Edit Write AskUserQuestion WebFetch WebSearch |
| argument-hint | [github issue URL or #number] |
| user-invocable | true |
| model | opus |
| metadata | {"internal":true} |
Resolve the GitHub issue $ARGUMENTS end-to-end.
Delegation hints (token / model optimisation):
- Build step: delegate
make megalinter-buildruns to thebuild-runneragent (haiku).- Version pin edits: delegate to
version-bumper(haiku).- CI watching after PR open: hand off to the
pr-watch-fixskill (sonnet), which itself delegates polling topr-monitor(haiku).- Security-related issues: delegate CVE analysis to
security-analyst(opus) — but you're already on opus, so do it inline if cheaper.
Global git/PR rules (no AI attribution, commit-as-user, no pushes to main, no --force, stage by path) live in CLAUDE.md → Git & PR Conventions. Follow them — do not restate them here.
Parse $ARGUMENTS (accept 123, #123, owner/repo#123, full URL). If empty, ask the user.
gh issue view <ref> --json number,title,body,labels,state,url,author,comments
Read body and all comments in full — context often lives in a comment. If the issue is closed, ask before proceeding.
gh issue view <n> --json closedByPullRequestsReferences,timelineItemsmegalinter/descriptors/), subclass (megalinter/linters/), reporter (megalinter/reporters/), or fixtures (.automation/test/)Form a concrete hypothesis. Ask via AskUserQuestion when any of these are true:
Present: failing behavior, hypothesis, 2–3 options, recommendation. Include a "stop and let me investigate" option when the cause is unclear.
Skip the question only when the fix is local and obvious.
CURRENT_BRANCH="$(git branch --show-current)"
DEFAULT_BRANCH="$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)"
If CURRENT_BRANCH equals the default branch (main/master/etc.), create fix/issue-<NUMBER>-<short-slug> off it. Otherwise keep working on the current branch.
If git status --short shows unrelated uncommitted changes, stop and ask.
make megalinter-build (NEVER make megalinter-build-with-doc).claude/rules/python-style.md@generated by .automation/build.py — change the source and rebuildCHANGELOG.md for CVE ignores or version bumps; for genuine user-facing fixes, add one line under Fixes in the beta section, written for end users per .claude/rules/changelog.md (what changes for them — no implementation details)python -m py_compile, etc.) — Docker-only checks are left to CIMatch the repo's commit style (git log --oneline -10). Format:
<type>: <imperative one-line summary> (#<ISSUE_NUMBER>)
<optional body, 1–3 lines>
Fixes #<ISSUE_NUMBER>
Use a HEREDOC:
git commit -m "$(cat <<'EOF'
fix: <summary> (#<N>)
<body>
Fixes #<N>
EOF
)"
HEAD_BRANCH="$(git branch --show-current)"
BASE_BRANCH="$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)"
git push -u origin "$HEAD_BRANCH"
Pass --base and --head explicitly so gh never prompts and never picks the wrong target (especially with forks):
gh pr create --base "$BASE_BRANCH" --head "$HEAD_BRANCH" --title "<title>" --body "$(cat <<'EOF'
## Summary
<2–4 sentences: root cause and how this PR fixes it>
## Changes
- <bullet per meaningful change>
## Test plan
- [ ] <how to verify>
- [ ] <edge cases>
Fixes <ISSUE_URL>
EOF
)"
Capture the PR number and URL.
Invoke /pr-watch-fix. It owns the 5-minute polling loop, log inspection, fix-commit-push cycle, bot-rebase handling, and stop conditions.
One nuance to apply before invoking: CI-fix commits should use Refs #<N> (not Fixes #<N>) so a later squash-merge of a follow-up doesn't prematurely close the issue.
When /pr-watch-fix returns, report one line:
PR #<N> is green: <url>Stuck on <check>: <root cause>. PR: <url>. Need your input.