$npx -y skills add launchdarkly/ai-tooling --skill create-fix-prInvestigates a root cause and files a minimal fix PR for a reported bug or observability finding.
| 1 | # Create a fix PR |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | You are investigating a problem and filing a pull request that resolves it. This builds on the `investigate` skill — do the investigation properly first, don't jump to a fix without evidence. |
| 6 | |
| 7 | Use the `gh` CLI for all GitHub operations (auth comes from your `gh` login) and standard `Bash` / `Edit` / `Read` / `Grep` for everything else. |
| 8 | |
| 9 | ## Workflow |
| 10 | |
| 11 | 1. **Investigate.** Use the `investigate` skill to find the root cause. Cite the exact trace ID, log line, error group, and code location that pins the problem. |
| 12 | 2. **Confirm there isn't already a PR open.** Before filing anything, search GitHub for an existing open PR addressing the same issue — `gh pr list --search "<keywords>" --state open`. If one exists, direct the user to it — do not create a duplicate. |
| 13 | 3. **Judge whether a PR is the right tool.** If the fix requires a config change, a flag flip, or a change outside the code you can access, describe the solution instead of filing a PR. |
| 14 | 4. **Get the repo.** Clone it if you don't already have it locally — `gh repo clone <owner>/<repo>`. |
| 15 | 5. **Check for repo conventions.** Read `agents.md` or `CLAUDE.md` at the repo root — these describe repo-specific rules your fix needs to respect. |
| 16 | 6. **Make the change.** Minimal diff. Don't refactor surrounding code, don't add features, don't fix unrelated bugs you happen to notice. One PR, one fix. |
| 17 | 7. **Set git identity** before committing — see `pr-conventions.md`. |
| 18 | 8. **Commit, push, and file the PR.** See `pr-conventions.md` for branch naming and PR body rules. |
| 19 | |
| 20 | ## What's a good fix |
| 21 | |
| 22 | - Changes the smallest possible number of lines |
| 23 | - Preserves current production behavior unless the bug IS the current behavior |
| 24 | - Doesn't depend on assumptions you can't verify from the evidence |
| 25 | - Would pass a `code-review` skill's check if one existed |
| 26 | |
| 27 | ## What isn't |
| 28 | |
| 29 | - Sweeping refactors unrelated to the reported problem |
| 30 | - Speculative null checks or error handling added "while you're in there" |
| 31 | - Changes to tests that hide the underlying bug |
| 32 | - Bumping dependency versions to fix a symptom |
| 33 | |
| 34 | ## Restricted tools |
| 35 | |
| 36 | If `gh` isn't installed or `gh auth status` shows no auth, surface the error to the user and stop — don't try alternative auth schemes. |
| 37 | |
| 38 | ## Never include in a PR |
| 39 | |
| 40 | - GitHub access tokens or any other secrets or credentials. |
| 41 | - Debugging logs or print statements you added during investigation. |
| 42 | |
| 43 | Follow the repo's own commit and PR conventions for everything else. |