tackle-issue
Skill84 starsChanged 6 days agoMITView on GitHub
Start-of-work triage in this monorepo. Trigger on: a GitHub issue number ("tackle issue 99", "work on #42", bare #N), pasted proposal/spec text ("investigate this", "pressure-test this", "scope this"), or picker phrasing ("tackle the next issue", "what should I work on"). Read-only investigation that tries to falsify the premise, then recommends SHIP / SHIP WITH CAVEAT / DEFER / SKIP. On SHIP verdicts for a real issue number it offers branch checkout + task seeding; --investigate-only suppresses that handoff. Not for PR review or work already in progress.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- lancy69/skillstheir own version, first seen Nov 8, 2026
- gtapps/hermitdword for word, first seen Nov 7, 2026
- spalladino/claude-skillstheir own version, first seen Nov 1, 2026
- yamcodes/arkenvtheir own version, first seen Oct 8, 2026
- Luis85/agentic-workflowtheir own version, first seen May 9, 2026
Other versions5 projects use a version of this.
Word for word · 1
- gtapps/hermitd★ 84100% same
Edited · 0
None found.
Wrote their own version · 4
- yamcodes/arkenv★ 151same name
- spalladino/claude-skills★ 1same name
- lancy69/skills★ 0same name
- Luis85/agentic-workflow★ 0same 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 repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- bump-core-reqSkill
- claude-harness-canarySkill
- commitSkill
- docs-driftSkill
- downstream-impactSkill
- fleet-releaseSkill
- pipeline-digestSkill
- pre-release-reviewSkill
- pricing-refreshSkill
- releaseSkill
- release-statusSkill
- routine-test-pingSkill
- stale-proposalsSkill
- test-runSkill
- bump-core-reqSkill
- commitSkill
- docs-driftSkill
- downstream-impactSkill
- fleet-releaseSkill
- pipeline-digestSkill
- pre-release-reviewSkill
- pricing-refreshSkill
- releaseSkill
- release-statusSkill
- routine-test-pingSkill
- stale-proposalsSkill
- test-runSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 6 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 41
Read the comments: they often say "already fixed" or change scope, and they override the body.
- Distinctive: line 76
Run against current code before forming any verdict.
- Distinctive: line 78
Does the bug reproduce, or does the code already handle it?: Read the cited paths; check whether the described failure mode is real.
- Very specific: line 187
If the branch already exists locally: git checkout <branch> and warn.
- Distinctive: line 196
Commit, push, open PRs, comment on issues, change labels, or close issues.
- Very specific: line 197
Write to .hermit/ (hermit-runtime state, not workflow state).
- Distinctive: line 199
Verify by paraphrasing the issue: evidence lines describe what the code showed, not what the issue said.
- Distinctive: line 201
Default to SHIP because the premise verified: verified premise + weak ROI = SKIP.
“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
Tackle Issue
Triage first, then optionally set up the work. Read-only until the operator picks "go" at the end. Implementation, commit, and PR happen outside this skill.
Mindset
An issue or proposal is a hypothesis, not a spec. Most issues here are filed by AI agents (hermit-scribe): intent is usually right, framing often is not (stale paths, first-idea fix, oversized scope, premise already fixed, or no bug at all). Falsify the premise before planning anything. If it survives, judge separately whether the change is worth its cost.
Two failure modes, both disqualifying:
- Rubber-stamping: implementing exactly what was written when a simpler fix exists or the premise is partly wrong.
- Reflex-pushback: manufactured objections. If the premise holds and ROI is good, say "ship as written" plainly.
Proportionality: scale investigation to blast radius. A one-file doc fix needs falsification steps 1 and 3 only, and a two-line trade-off note. Anything touching hooks, shipped skills, or release machinery gets the full pass, including a live probe when a harness-behavior claim is load-bearing.
Dispatch
- Issue number ("tackle issue 99", "#42", "owner/repo#N"):
gh issue view <N> --repo <owner/repo from input, default gtapps/hermitd> --json title,body,labels,comments,author,state,urlRead the comments: they often say "already fixed" or change scope, and they override the body. Pull referenced issues/PRs when the body leans on them. Closed issue → surface that and ask before continuing. Also rungh pr list --repo <repo> --state open --search "<N>": an open PR already covering the issue usually means DEFER to that PR. - Pasted content (proposal, spec, free-form): treat the text as the task body. Triage output only, no handoff.
- Picker ("tackle the next issue", "what should I work on", bare
/tackle-issue): run Picker below, then continue as issue-number mode. - Ambiguous ("tackle this", no number, no paste): ask which mode before fetching anything.
--investigate-only(combines with issue-number mode): full triage report including the plan sections on positive verdicts, then stop. No branch, no tasks.
PROP-NNN references: for issues in this repo, read the matching
.hermit/proposals/PROP-NNN-* file and fold its ## Problem /
## Proposed Solution into the evidence. Never dereference PROP ids from other repos
(numbering is per-repo).
Handoff applies only to gtapps/hermitd issues. Cross-repo issues get the triage report only.
Picker
gh issue list --repo gtapps/hermitd --label ready --state open --json number,title,labels,updatedAt --limit 30. Zero results → "No ready-labelled open issues; label issuesreadyto opt in." Stop.- Drop issues referenced by open PRs:
gh pr list --repo gtapps/hermitd --state open --json number,body,headRefName --limit 100, matching#Nin bodies and(feat|fix|chore)/N-in head branch names. - Drop issues with a
skipevent in the last 7 days or adeferevent in the last 24h in.claude/state/tackle-issue-log.jsonl(read at most the last 100 lines; missing file = no exclusions). - Sort
priority:highfirst, thenupdatedAtdescending. Take the first. Empty after filters → say so and stop.
Falsification workflow
Run against current code before forming any verdict.
- Does the bug reproduce, or does the code already handle it? Read the cited paths; check whether the described failure mode is real.
- Is the feature already shipped under another name? Grep symbols and concepts; check docs/README.
- Are cited paths, symbols, and behaviors current? Renames silently invalidate issue bodies.
- Did the situation change after filing?
git logon cited files,git log -S "<symbol>"for named symbols. - Load-bearing claims about live Claude Code behavior get probed, not recalled. "The hook
doesn't receive X" can't be falsified with Read/Grep. Use a tmux
claude --model haikuprobe per root AGENTS.md § Development and verification (a probe doesn't mutate the repo; it stays inside the read-only posture). Only for load-bearing claims; most issues don't need one.
Skim sibling tests for the existing behavior contract. Every load-bearing claim gets an evidence
line tagged [probed live | read code | recalled].
Absence is not proof. A grep that finds nothing proves absence only within the searched tree. Per-deployment config, operator-added routines, and live harness behavior are invisible to repo search. When a verdict pivots on a single negative claim ("nothing calls X"), that is the claim to probe, never the one to trust.
Verdict (premise), then Recommendation (ROI)
Verdict, pick one:
- Confirmed as-is — accurate, and the proposed fix is sound.
- Refined approach — accurate premise, simpler fix exists.
- Corrected scope — fix needed, but smaller/larger/differently shaped.
- Nothing to do — premise is wrong. Output only Verdict + Evidence + the suggested close/comment text (operator executes it). No Trade-offs, no Recommendation, no plan, no handoff. Higher bar: if this verdict rests on a negative claim you couldn't reproduce from defaults, probe it live or ask the operator first. Never conclude Nothing-to-do on grep-silence alone; a false close costs more than over-investigating.
Recommendation (first three verdicts only):
- SHIP — net positive, proceed now.
- SHIP WITH CAVEAT — proceed, flag the specific risk or follow-up.
- DEFER — worth doing, not now. Say what unblocks it.
- SKIP — premise holds, ROI weak. A legitimate outcome; name it plainly.
Output format
Present in chat. Never call ExitPlanMode.
## Verdict: <Confirmed as-is | Refined approach | Corrected scope | Nothing to do>
## Evidence
- <file or symbol checked> → <what was confirmed or falsified> [probed live | read code | recalled]
## Trade-offs
**Pros:** <concrete value> **Cons:** <concrete cost> **Cost of doing nothing:** <...>
## Recommendation: <SHIP | SHIP WITH CAVEAT | DEFER | SKIP>
<one-line why>On SHIP / SHIP WITH CAVEAT, append:
## Proposed approach
<steps; if deviating from the issue: "Deviating from source: <what> because <why>">
## Files to touch
- <path> — <change>
## Verification plan
- <test or command that proves it; a live tmux probe for behavior unit tests can't capture>Trade-off lines must name concrete costs (files affected, maintenance burden, edge cases at risk). If you can't name one, don't pad the section.
Handoff
Runs only when: recommendation is SHIP or SHIP WITH CAVEAT, input was a
gtapps/hermitd issue number, and --investigate-only was not passed.
Guardrails: dirty tree (any branch) → stop, point at /commit. Mid-rebase, mid-merge, or
detached HEAD → stop. On a feature branch with commits ahead of base → AskUserQuestion: continue
current work or switch. gh auth status fails → stop with auth instructions.
Branch name: bug label → fix/<N>-<slug>; enhancement/feature → feat/<N>-<slug>;
else chore/<N>-<slug>. Slug from the title: lowercase, drop non-ASCII and stopwords, first 5
tokens joined with -, max 40 chars.
Plan: 3–6 imperative bullets. Reuse the Proposed-approach steps verbatim when present.
Present issue number, title, URL, labels, linked PROP, branch, and plan, then AskUserQuestion (header "Tackle issue"):
- go — check out branch, seed tasks
- skip — log a 7-day dedup event, exit
- defer — log a 24h cooldown event, exit
- stop — exit with no log entry (analysis-only, no cooldown)
Log terminal choices (go/skip/defer only, nothing before the answer) to
.claude/state/tackle-issue-log.jsonl:
{"ts":"<iso>","issue":N,"action":"go|skip|defer","branch":"…","verdict":"…","recommendation":"…"}
(branch/verdict fields on go only).
On go:
git fetch origin
BASE=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)
git checkout -b <branch> origin/$BASEIf the branch already exists locally: git checkout <branch> and warn.
TaskCreate one task per plan bullet, then three trailing tasks: run
/simplify, run /commit, run /open-pr.
Report "On branch <branch>, ready to implement" and stop. No code edits, no commits, no PR.
Never
- Call ExitPlanMode.
- Commit, push, open PRs, comment on issues, change labels, or close issues.
- Write to
.hermit/(hermit-runtime state, not workflow state). - Pick more than one issue per invocation.
- Verify by paraphrasing the issue: evidence lines describe what the code showed, not what the issue said.
- Default to SHIP because the premise verified: verified premise + weak ROI = SKIP.
- Fold "while we're here" cleanup into the plan: mention it in chat after the report instead.
Plan sections follow the global engineering principles (Simplicity First, Surgical Changes): the minimum change that resolves the verdict.
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.

