Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/njbrake/dotpi --skill fix-github-issueLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Basé sur la classification professionnelle SOC
Affichage de SKILL.md
| name | fix-github-issue |
| description | Fix a github issue and create a PR |
Fix a GitHub issue by creating a branch, implementing the fix, and opening a PR.
/fix-github-issue
Fetch the issue — Use gh issue view <number> --json title,body,labels,comments to get full context. Assign the ticket to yourself so that people know you're working on it. (If it's already assigned to someone, you should raise this back to me, don't take the ticket from them)
Read project instructions — Read AGENTS.md (and any subdirectory AGENTS.md referenced) to understand build commands, conventions, and Definition of Done checks.
Understand the code — Read all files referenced in the issue. If the issue describes a pattern that should already exist elsewhere (e.g. "ChatPanel does X correctly"), read that file too to understand the target pattern.
Create a branch — Branch from main with a descriptive name: fix/<short-slug> for bugs, feat/<short-slug> for features. You'll want to make sure you fetch the latest on main first so that you branch off the newest commit.
Implement the fix — Make the minimal change that addresses the issue. Follow existing patterns in the codebase. Don't refactor surrounding code.
Write a test — Bug fixes must include a test that reproduces the bug and verifies the fix. If an existing test file covers the component/module, add the test there; otherwise create a new test file matching existing test patterns. The test should fail without the fix and pass with it.
Run all Definition of Done checks — Run every check listed in under "Definition of Done".
AGENTS.mdCommit — Write a clear commit message: imperative subject line, body explaining why, include Fixes #<number>. Add the Co-Authored-By: DeepSeek V4 Flash <noreply@deepseek.com> trailer.
Confirm with user — Before pushing, present the user with a summary of the changes: files modified, what was changed and why, and test results. Wait for explicit user approval before proceeding. Do not push or create a PR until the user confirms.
Push and open PR — Push with -u, create PR via gh pr create.
.github/pull_request_template.md, .github/PULL_REQUEST_TEMPLATE.md, or a .github/PULL_REQUEST_TEMPLATE/ directory. Use ls .github/ to find it.## Summary (bullet points of what changed), ## Test plan (checklist of verification steps).Fixes #<number> in the body to auto-close the issue./self-review-pr — Invoke that skill on the PR you just opened. It enforces the breadth check (does the same bug exist in other call sites?) and the test-coverage check (sibling test files for every modified source file) that are easy to miss when reviewing only the diff. Push a fixup commit for any high-confidence finding, then iterate until checks pass.