solve
Skill1 starsChanged 3 months agoMITView on GitHub
Use when given an issue or ticket to resolve (a GitHub issue, Jira ticket, or bug report link or number), especially one written by someone else that contains a diagnosis or a proposed fix, before writing any implementation code for it.
7 other projects use a version of this.
Adopted by
Most recently taken up by
- DaeSeokSong/oh-my-ouroborostheir own version, first seen Nov 1, 2026
- RTGS2017/NagaAgenttheir own version, first seen Oct 8, 2026
- Xxiii8322766509/NagaAgenttheir own version, first seen Oct 8, 2026
- Z3Prover/z3their own version, first seen Oct 8, 2026
- davidsolheim/skillstheir own version, first seen Oct 5, 2026
- sequant-io/sequanttheir own version, first seen Aug 10, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- Z3Prover/z3★ 13ksame name
- Xxiii8322766509/NagaAgent★ 1.5ksame name
- RTGS2017/NagaAgent★ 1.5ksame name
- DaeSeokSong/oh-my-ouroboros★ 3same name
- corygabrielsen/skills★ 1same name
- davidsolheim/skills★ 1same name
- sequant-io/sequant★ 1same name
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.
In this repository5 other files it gives its agents.
- before-and-afterSkill
- brevitySkill
- handoffSkill
- respawnSkill
- step-backSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Read the full ticket: description, comments, linked issues and PRs.
- Distinctive: line 24
Check for staleness: git log / git blame the relevant files.
- Distinctive: line 26
If Not confirmed: the deliverable is a report with evidence (commits, code references, reproduction attempts), recommending the ticket be …
- Distinctive: line 30
Treat the ticket's proposed fix, if present, as candidate #1, not as a directive.
- Distinctive: line 49
If the fix's central claim is a performance improvement, apply the before-and-after skill so the PR carries measured evidence.
“Common” is measured: kept by at least 6 in 10 of the 4 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
Solve
Overview
Turn a ticket into a validated solution, then into code, in that order. A ticket is testimony, not truth: its premise (the claimed problem) and any proposed fix are hypotheses to verify against the current code, written by someone without full context and possibly before the code changed.
Core rule: no implementation code until (1) the premise is validated against the current codebase and (2) the user has approved a solution. Reproduction scripts and failing tests written to verify the premise are allowed and encouraged; the fix itself is not.
The invocation argument is the ticket: a URL, an issue number, or pasted text.
Phase 1: Understand
- Read the full ticket: description, comments, linked issues and PRs.
- Locate the code it concerns and read it as it exists NOW on the default branch, not as the ticket describes it.
Phase 2: Validate the premise
- Confirm the claimed problem exists in the current code: reproduce it (failing test, script, observed behavior) or trace the code path and show exactly where the flaw lives.
- Check for staleness:
git log/git blamethe relevant files. Has the code changed since the ticket was filed? Was it already fixed, partially fixed, or refactored out of existence? - Conclude with one verdict: Confirmed, Partially confirmed (state which part survives), or Not confirmed (already fixed, misdiagnosed, or not reproducible).
- If Not confirmed: the deliverable is a report with evidence (commits, code references, reproduction attempts), recommending the ticket be closed or corrected. Do not implement anything. A PR that fixes a nonexistent problem has negative value.
Phase 3: Evaluate solutions
- Treat the ticket's proposed fix, if present, as candidate #1, not as a directive. It earns implementation by surviving comparison, not by being written down.
- Develop at least one genuine alternative: a different approach a competent reviewer might prefer, not a strawman.
- Compare candidates on: correctness (including edge cases the ticket ignores), blast radius, complexity, performance, and consistency with the codebase's existing conventions.
- Recommend one, with reasoning. Recommending the ticket's own fix is a fine outcome; say why it won.
Phase 4: Checkpoint (hard stop)
Present to the user, compactly:
- Premise verdict and the evidence for it.
- Candidate solutions with tradeoffs, and the recommendation.
- Implementation sketch: files to change, tests to add or adapt.
- Open questions, if any.
Then STOP and wait for approval. Do not start implementing while waiting. If the user replies with a change of direction, update the plan and re-confirm.
Phase 5: Implement (only after approval)
- Implement the approved solution. Where feasible, the Phase 2 reproduction becomes a regression test that fails before the fix and passes after.
- If the fix's central claim is a performance improvement, apply the before-and-after skill so the PR carries measured evidence.
- Open the PR referencing the ticket. The description states: what premise was validated and how, which solution was chosen, and why alternatives were rejected. A reviewer should be able to see the reasoning, not just the diff.
Red flags: stop if you catch yourself thinking
| Thought | Reality |
| "The author already diagnosed it; re-checking wastes time" | Tickets go stale and diagnoses miss context. Validation costs minutes; a wrong-premise PR wastes a full review cycle. |
| "The proposed fix is obviously right, no need for alternatives" | Evaluate at least one real alternative anyway. Obvious fixes are exactly where better designs hide. |
| "It's a small change, I'll code it and let the diff be the review" | A diff anchors the discussion to what was built. The checkpoint exists to review the solution before the sunk cost of code. |
| "The premise didn't hold, but I'll implement something useful nearby" | Scope discipline: report the finding and stop. New work needs its own ticket and its own premise. |
| "The user is in a hurry, so skip the checkpoint" | Compress the checkpoint, never skip it: a short premise verdict plus recommendation takes one message. |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.