{"id":14666,"plugin_id":"plugin_asdk_app_6a563d3bd288819196199d33db4cfc55","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:09:58.081Z","digest":"6f73a188f6bbf42f79ab850caefe7aa7bfbcabfac61f29134ef6ab0eaacd526d","against":null,"payload":{"name":"create-fix-pr","description":"Investigates a root cause and files a minimal fix PR for a reported bug or observability finding.","included_files":[{"relative_path":"pr-conventions.md","size_in_bytes":2946}],"skill_md_contents":"---\nname: create-fix-pr\ndescription: \"Investigates a root cause and files a minimal fix PR for a reported bug or observability finding.\"\nlicense: Apache-2.0\ncompatibility: Requires git and the GitHub CLI (gh); pairs with the investigate skill\nmetadata:\n  author: launchdarkly\n  version: \"0.1.0\"\n---\n\n# Create a fix PR\n\n## Overview\n\nYou 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.\n\nUse the `gh` CLI for all GitHub operations (auth comes from your `gh` login) and standard `Bash` / `Edit` / `Read` / `Grep` for everything else.\n\n## Workflow\n\n1. **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.\n2. **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.\n3. **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.\n4. **Get the repo.** Clone it if you don't already have it locally — `gh repo clone <owner>/<repo>`.\n5. **Check for repo conventions.** Read `agents.md` or `CLAUDE.md` at the repo root — these describe repo-specific rules your fix needs to respect.\n6. **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.\n7. **Set git identity** before committing — see `pr-conventions.md`.\n8. **Commit, push, and file the PR.** See `pr-conventions.md` for branch naming and PR body rules.\n\n## What's a good fix\n\n- Changes the smallest possible number of lines\n- Preserves current production behavior unless the bug IS the current behavior\n- Doesn't depend on assumptions you can't verify from the evidence\n- Would pass a `code-review` skill's check if one existed\n\n## What isn't\n\n- Sweeping refactors unrelated to the reported problem\n- Speculative null checks or error handling added \"while you're in there\"\n- Changes to tests that hide the underlying bug\n- Bumping dependency versions to fix a symptom\n\n## Restricted tools\n\nIf `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.\n\n## Never include in a PR\n\n- GitHub access tokens or any other secrets or credentials.\n- Debugging logs or print statements you added during investigation.\n\nFollow the repo's own commit and PR conventions for everything else.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}