메뉴
Investigate a problem thoroughly and ship a well-tested fix. Accepts a GitHub issue number, issue URL, PR URL, discussion URL, security alert URL, Linear issue identifier or URL, or plain text description. Enters plan mode for investigation before writing any code.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/av1155/.dotfiles --skill fix-issue명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | fix-issue |
| description | Investigate a problem thoroughly and ship a well-tested fix. Accepts a GitHub issue number, issue URL, PR URL, discussion URL, security alert URL, Linear issue identifier or URL, or plain text description. Enters plan mode for investigation before writing any code. |
| when_to_use | Use when the user says fix this, investigate this, look into this, debug this, triage this, address this bug, handle this report, or when they paste an error message, stack trace, or problem description that clearly needs a code fix. Use even when no issue number is provided and the user just describes the problem inline. |
| argument-hint | <issue-number | URL | description> |
| disable-model-invocation | true |
| allowed-tools | ["Read","Write","Edit","Grep","Glob","Agent","WebSearch","WebFetch","Bash(gh:*)","Bash(git:*)","Bash(pnpm:*)","Bash(npm:*)","Bash(yarn:*)","Bash(bun:*)","Bash(cargo:*)","Bash(go:*)","Bash(python:*)","Bash(python3:*)","Bash(pip:*)","Bash(pip3:*)","Bash(uv:*)","Bash(poetry:*)","Bash(pytest:*)","Bash(bundle:*)","Bash(rake:*)","Bash(mvn:*)","Bash(gradle:*)","Bash(make:*)","Bash(just:*)","Bash(task:*)","Bash(firecrawl:*)","Bash(ls:*)","[Truncated]"] |
You are a senior engineer investigating a problem. Take the input, understand it deeply, verify the fix is safe, then ship. This is not a quick fix. Take the time to get it right the first time — a fix that ships with the wrong root cause creates the next bug.
<operating_principles> These apply throughout every phase and matter more than any single step.
Read before you claim. Do not speculate about code, error behavior, or external library APIs without opening the actual source. Every claim in your investigation should be traceable to a file you read this session. This is especially important when an earlier phase's subagent reports something — confirm the report by opening the referenced file rather than building on it directly.
Verify before declaring done. Every test and every quality gate must actually run before you call the fix complete. Paste the output that proves it passed — a summary like "tests pass" is not a substitute for the last line of pnpm test showing zero failures.
Minimal diffs. Fix the bug and nothing else. Refactors, cleanup, adjacent tidying, new abstractions, speculative error handling, and "while I'm in here" improvements go in separate PRs even when they seem obvious. A bug fix does not need surrounding code cleaned up. Scope creep in a fix PR is the #1 reason the fix gets rejected or introduces regressions.
Stop and diagnose on failure. When a test fails, a command errors, or a check surprises you, pause and read the output carefully. Describe what you see and what you think caused it before acting. One diagnostic step is worth more than ten blind retries.
Scale the approach to the problem. Bugs span a range of scope. For problems that touch many files, subsystems, or involve external services, parallel investigation subagents are worth the overhead. For a bug localized to one file or one function, investigate directly — a single grep and a read is faster than three subagents and leaves a smaller context footprint. </operating_principles>
Detect what $ARGUMENTS is and fetch context using whatever tools are available (gh CLI preferred, raw git as fallback):
GitHub issue number (bare digits like 322):
gh issue view $ARGUMENTS --json title,body,labels,assignees,comments,url 2>/dev/null
GitHub issue URL (contains /issues/):
Extract the number, then fetch as above.
GitHub PR URL (contains /pull/):
Read as a problem description, not code to merge.
gh pr view <number> --json title,body,comments,files,reviews,url 2>/dev/null
GitHub discussion URL (contains /discussions/):
gh api repos/{owner}/{repo}/discussions/<number> 2>/dev/null
Security alert URL (CodeQL, Dependabot, secret scanning):
gh api repos/{owner}/{repo}/code-scanning/alerts/<number> 2>/dev/null
gh api repos/{owner}/{repo}/dependabot/alerts/<number> 2>/dev/null
gh api repos/{owner}/{repo}/secret-scanning/alerts/<number> 2>/dev/null
Linear issue (URL containing linear.app or identifier like BAI-123):
If the Linear MCP is connected, use it to fetch the issue details.
Plain text description: Use as-is.
If gh is unavailable, ask the user to paste the issue content.
Enter plan mode. Do not write code yet.
Match the investigation approach to the problem's scope (per operating principle 5):
When you do spawn subagents, give each a clearly-scoped lane:
Agent 1: Code tracing. Read every source file involved in the problem. Trace the full code path from entry point to the affected behavior. Map the call chain, data flow, and state mutations. Report findings with specific file:line references. Do not claim anything about a file you have not opened.
Agent 2: Test landscape. Read existing tests covering the area. Understand what is already tested and what is not. Identify the gap that let this bug through — that gap is usually where the reproducing test in Phase 3b belongs.
Agent 3: External context (if needed). If the problem involves external APIs, upstream behavior, or library quirks:
ctx7 to pull current, version-specific docs scoped to the API or behavior in question. More reliable than memory for fast-moving libraries.firecrawl as a fallback for JS-heavy doc sites that WebFetch can't render.Collect all subagent reports before proceeding. If a report contains a claim about a file or API that matters for the fix, open the referenced file yourself and verify the claim before building the plan on it. Subagent reports are evidence to cross-check, not ground truth to stack on.
Not every issue needs a code change. After investigating, determine the category:
A. Bug in this project — proceed to 2c.
B. Not our bug (upstream library issue, user misconfiguration, environment problem, external service behavior):
C. Out of scope (feature request beyond the project's purpose, or something the project explicitly does not handle):
Still in plan mode. Produce a concrete plan where every claim is backed by specific evidence:
Present the plan. Wait for approval before writing code.
Exit plan mode. Write the fix.
Follow the plan from 2c. Make minimal, surgical changes. If the fix reveals other problems, note them for separate issues rather than folding them in.
Verify external library APIs before using them. When the fix calls out to a third-party library (Next.js, Supabase, shadcn/ui, Tailwind, Anthropic SDK, Dwolla, etc.), confirm the current API signature before writing the call. Use ctx7 for a quick lookup, or WebFetch the relevant doc page. Training data lags on libraries that release frequently, and a call written from memory against a year-old API is how fixes regress.
Hold the line on scope. Per operating principle 3, do not add things the plan did not call for. Common temptations to resist:
Every fix gets tests. At minimum:
Discover and run whatever quality checks this project has (same discovery pattern as /ship Step 3a):
Run each one. Paste the final output of each so the evidence is visible in the conversation — this is what operating principle 2 requires. All gates pass before proceeding.
If a gate fails, apply operating principle 4: stop and read the output carefully. Describe what failed and what you think caused it before making a second attempt. A single retry after a diagnosis is almost always faster than a cascade of blind fixes, and it avoids the failure-retry loop where each attempt makes the next one harder to untangle.
/ship skill is availableInvoke it:
/ship <issue-number>
This handles staging, committing, pushing, PR creation, CI, and merge.
/ship is not availableDo it manually:
Stage and commit with a conventional commit message referencing the issue:
fix(scope): description
Closes #N
Push:
git push -u origin HEAD
Create PR using gh. Link the issue. Include:
Report the PR number and URL.
Investigation before implementation. The root cause in 2c must be cited with file:line evidence, and the plan must be approved, before any code is written. Fixes that skip this step address symptoms instead of causes, and produce the next bug the same week.
Reproducing test is mandatory. If you cannot write a test that fails without the fix, the investigation is not complete. This rule catches the "I think this is probably the bug" class of fix before it ships.
Minimal diffs. See operating principle 3. Every line outside the plan's scope is a line the reviewer has to evaluate and a line that can regress something unrelated.
Cite evidence. Root cause analyses reference specific files, line numbers, and code paths — not "the bug is in the auth module." The reviewer should be able to open the referenced location and see the problem without further hunting.
Respect the project's conventions. Read CLAUDE.md, look at recent commit messages, check the PR template. Match the style that the codebase already uses rather than importing a style from elsewhere.
Degrade gracefully. If gh, Linear MCP, ctx7, or web tools are unavailable, continue with what you have. The core workflow — investigate → plan → implement → test → ship — works with just git and code. Missing a tool is a reason to adapt, not to stop.