implement-issue
Skill2 starsChanged 3 months agoMITView on GitHub
Validates and implements a GitHub issue against current repository evidence, runs the project's completion gate, reviews the change, and opens a draft pull request. Use when the user runs /implement-issue with an issue number.
We split this skill into the rules it gives an agent
11 rules. 0 are common, 6 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 25 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Read the issue, project instructions, vision, contribution guidance, Definition of Ready, Definition of Done, relevant domain skills, real …
- Distinctive: line 24
Always perform and record web search for current evidence before presenting options.
- Very specific: line 28
When grill-with-docs or grill-me is registered, run its actual user-question loop before presenting options.
- Distinctive: line 40
Keep prototypes local and disposable, retain only reviewable captures and findings, and remove them when the grill concludes.
- Distinctive: line 49
When current evidence conclusively fails a required prototype or readiness threshold, report that stop without asking whether to bypass the …
- Very specific: line 56
Treat the nearest applicable DEFINITION_OF_READY.md and DEFINITION_OF_DONE.md as canonical.
- Distinctive: line 79
If the behavior no longer reproduces, distinguish:
- Very specific: line 88
After selection, reuse or create a focused branch/worktree and apply the git-workflow remote-default synchronization gate before editing.
- Distinctive: line 95
Run targeted checks while developing, then the applicable Definition of Done and repository gate.
- Very specific: line 97
Run one /code-review fix-all pass against the acceptance criteria, Definition of Done, project conventions, branch diff, and reproducible …
- Very specific: line 103
Use /create-pr, include Closes #<issue>, and report only observed completion evidence.
“Common” is measured: kept by at least 6 in 10 of the 25 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Implement issue
Resolve the issue end to end against the current repository, or establish with evidence that no implementation is needed.
Gates
- Read the issue, project instructions, vision, contribution guidance, Definition of Ready, Definition of Done, relevant domain skills, real project commands, affected code paths, tests, and reproduction before deciding.
- Always perform and record web search for current evidence before presenting options. Prefer official and primary sources, reconcile them with the versions in the checkout, and treat remembered links only as search leads. Stop if the search cannot produce current evidence relevant to the decision.
- When
grill-with-docsorgrill-meis registered, run its actual user-question loop before presenting options. Prefergrill-with-docs; if neither exists, note that once and continue. - During the grill, proactively give the user visual or dynamic context selected
by the affected surface:
- for UI/UX, show upfront mockups for every materially different experience;
- for architecture or workflows, show a diagram or flow;
- for interaction-heavy or technical behavior, create a short-lived dynamic prototype for the recommendation or the interaction that cannot be judged statically. Show a shared current-state view when it helps compare options. Clearly label observed facts, proposed behavior, and prototype-only shortcuts.
- Keep prototypes local and disposable, retain only reviewable captures and
findings, and remove them when the grill concludes. Do not deploy or publish
them. Preserve or promote a prototype only with explicit user approval; keep
approved prototype material outside the selected worktree until its
git-workflowsynchronization gate passes. - Present two to four genuinely distinct evidence-backed options, recommend one, and wait for the user's choice unless automatic mode applies. Include a compact evidence digest with links to the most relevant current sources, checked project versions, and any mismatch or remaining uncertainty.
- When current evidence conclusively fails a required prototype or readiness threshold, report that stop without asking whether to bypass the gate.
- For any code or test change, complete the project gate, one bounded
/code-review fix-all, and/create-pr.
Project definitions
Treat the nearest applicable DEFINITION_OF_READY.md and
DEFINITION_OF_DONE.md as canonical. If either is absent after a real search,
state that once, carry the gap into the plan and PR, and use only the workflow's
built-in checks plus commands the repository actually declares.
Automatic mode
Automatic mode applies only when the original prompt says automatic or
explicitly requests it. Complete web research, source and documentation probing,
surface-appropriate artifacts, and every other gate; present the evidence and
options, select the evidence-backed recommendation, and continue. A material
product, architecture, security, scope, or vision decision disables automatic
mode.
Workflow
- Fetch the issue, including comments and labels; verify it is open, implementation-ready, and not a PR, duplicate, blocked, or rejected item.
- Load the applicable project contracts and specialized skills.
- Trace the full behavior from entry point to symptom and run the cited reproduction or artifact when possible. Search callers, siblings, tests, configuration, and history far enough to identify the real layer. Always perform current web search and reconcile its results with the checkout.
- If the behavior no longer reproduces, distinguish:
- already fixed and covered: recommend closing with the fixing code/commit and test evidence;
- fixed without regression coverage: add the missing test only;
- shared-root-cause sibling paths still affected: include only those paths.
- Produce the surface-appropriate artifacts, run the grill gate with that context, validate readiness, confirm any clarified issue scope, then present the options and recommendation. Ground the checkpoint in evidence from this run.
- After selection, reuse or create a focused branch/worktree and apply the
git-workflowremote-default synchronization gate before editing. - Implement the smallest complete change at the correct layer. Update tests and docs required by the issue and project contracts.
- For UI/UX work, render every affected state; capture reviewable before/after evidence; check accessibility, responsive behavior, themes, and design-system consistency; attach the evidence to the PR.
- Run targeted checks while developing, then the applicable Definition of Done and repository gate. Fix failures rather than weakening the gate.
- Run one
/code-review fix-allpass against the acceptance criteria, Definition of Done, project conventions, branch diff, and reproducible behavior. Resolve every validated in-scope finding and rerun affected checks. Stop for a material new decision; do not continue with unresolved Blocking or Important findings. If/code-reviewis unavailable, perform that same bounded review and fix pass directly. - Use
/create-pr, includeCloses #<issue>, and report only observed completion evidence.
Other versions28 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- frostney/knips★ 141% same
Wrote their own version · 27
- dlt-hub/dlt★ 6ksame name
- google/site-kit-wp★ 1.4ksame name
- luainkernel/lunatik★ 608same name
- warpdotdev/oz-for-oss★ 313same name
- codemonkey85/PKMDS-Blazor★ 235same name
- gymcoach-app/gymcoach★ 149same name
- aaddrick/claude-pipeline★ 128same name
- Julien-Au/gymcoach★ 43same name
- dativo-io/talon★ 17same name
- alexjbarnes/cockpit★ 16same name
17 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use review-issue, merge-pr and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ravihammondSkillreview-issue
Review and repair one GitHub issue implementation in the current checkout.
Also in 3 projects that use this
TermiX-officialSkillmerge-pr
Merge a GitHub PR via squash after /preparepr. Use when asked to merge a ready PR. Do not push to main or modify code. Ensure the PR ends in MERGED state and clean up worktrees after success.
Also in 3 projects that use this
OpenAISkillwriting-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Also in 3 projects that use this
Google CloudSkilltriage
Gather context on a change or bug and plan the implementation.
Also in 3 projects that use this
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- codebase-auditSkill
- create-issueSkill
- create-prSkill
- create-releaseSkill
- domain-modelingSkill
- git-workflowSkill
- grillingSkill
- grill-with-docsSkill
- implement-ideaSkill
- improve-codebase-architectureSkill
- native-nostalgia-stackSkill
- project-structureSkill
- review-prSkill
- roadmap-reviewSkill
- run-retroSkill
- software-engineering-excellenceSkill
- update-prSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

