// 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.
| 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 |
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 sectionpython -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.Add a new MegaLinter flavor (language-specific Docker image). Use when creating a new specialized Docker image variant.
Guided workflow for adding a new linter to MegaLinter. Use when a contributor needs to add support for a new linting tool.
Add a new output reporter to MegaLinter. Use when adding support for a new CI system or output format.
Gather requirements for a MegaLinter change by asking clarifying questions until the problem is fully understood. First step of the contribution workflow.
Design a MegaLinter solution and write a technical specification. Second step of the contribution workflow, use after /analyze.
Diagnose MegaLinter .mega-linter.yml configuration issues. Use when linters aren't running as expected or configuration seems wrong.