issue-intake
Skill36 starsChanged 2 months agoApache-2.0View on GitHub
Use when the ready-issue queue is low or a delivery wave is closing, when a defect/finding surfaces mid-session (runtime failure, review discovery, repeated manual step), or when deciding whether an observation deserves a GitHub issue. Also use when authoring any issue body.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- jarimustonen/reitti-clitheir own version, first seen Oct 20, 2026
- runxhq/runxtheir own version, first seen Oct 13, 2026
- jarimustonen/project-canontheir own version, first seen Oct 8, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- runxhq/runx★ 97same name
- jarimustonen/reitti-cli★ 1same name
- jarimustonen/project-canon★ 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 repository52 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- agent-browserSkill
- arch-specSkill
- code-qualitySkill
- code-reviewSkill
- commitSkill
- coord-delegateSkill
- coord-handoffSkill
- coord-orchestrateSkill
- coord-requestSkill
- coord-reviewSkill
- coord-runSkill
- coord-syncSkill
- dispatchSkill
- edda-releaseSkill
- fleet-epic-splitSkill
- fleet-managerSkill
- fleet-orchestrateSkill
- fleet-pr-loopSkill
- fleet-reviewSkill
- fleet-triadSkill
- fleet-workerSkill
- ground-checkSkill
- health-checkSkill
- intel-scanSkill
- issue-actionSkill
- issue-compactSkill
- issue-createSkill
- issue-pipelineSkill
- issue-planSkill
- issue-scanSkill
- parallel-waveSkill
- path-forwardSkill
- plan-decomposeSkill
- plan-validateSkill
- pr-checkSkill
- project-planSkill
- Project PrinciplesSkill
- pr-review-loopSkill
- pr-reviewSkill
- pull-requestSkill
- regression-guardSkill
- skill-aliasSkill
- skill-craftSkill
- skill-testSkill
- spec-review-modesSkill
- tech-debtSkill
- testingSkill
- tracking-issueSkill
- verifiable-goal-loopSkill
- fleet-orchestrateSkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
1
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 8
Keep the delivery queue fed with issues that are worth doing and machine-ready — without the operator.
“Common” is measured: kept by at least 6 in 10 of the 3 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
Issue Intake
Keep the delivery queue fed with issues that are worth doing and machine-ready — without the operator. Every issue this engine ships is born in the format parallel-wave Layer 1 judges: named surface + machine-checkable doneWhen. The body contract lives once in templates.md — issue-create and fleet-epic-split emit the same shape and only point here; no parallel body formats. Composes with fleet-orchestrate (discovery rail) and parallel-wave (delivery).
Sources — check in this order
| Source | Trigger | Cost |
| Review exhaust | every review round's FOLLOW-UP ISSUE findings | free |
| Runtime scars | any failure the pipeline itself hits (stale transitions, misclassification, lost state, timeout patterns) | free |
| Self-improvement | any manual controller step repeated ≥2 times becomes a roadmap candidate | free |
| Scheduled recon | ready queue < 3 at wave close → run a read-only campaign (charter: fixed object, rotating lenses — correctness / concurrency / data-loss / false-green tests; one reviewer per cell) | paid |
| Epic split | operator-signed goal → fleet-epic-split into atomic issues | paid, operator-gated |
A finding observed mid-session is filed (or parked as a candidate) in the same session — findings that stay in the transcript are lost.
Promotion ladder
candidate → verified finding → draft → ready. Never skip a rung.
| To reach | Requires |
| verified finding | expected vs actual on a named full SHA, with evidence (repro, failing test, trace, or direct code proof); base comparison — regression or inherited? |
| draft | named surface (crate/path/symbols) + machine-checkable doneWhen list |
| ready | dedupe ran: edda ask "<domain>" AND edda search query "<keyword>" AND open-issue search — no duplicate, not already decided/fixed |
Disposition table
| Observation | Disposition |
| Evidenced defect, surface derivable | File it — use the body template in templates.md |
| Real hunch, evidence incomplete | Park as candidate WITH the attempts already made and the next bounded experiment. Do not file "investigate X" |
| Rule a linter/CI check could enforce | Automate it (or file ONE issue to add the check). Never file per-occurrence issues |
| Matches a ledger decision or an existing issue/fix | Drop, with a pointer to the duplicate |
| Product direction / high-risk change | File, label needs-operator, queue — it waits for the operator; everything else keeps moving |
The improvement loop (what "gets better" means)
At each wave close, write one edda note --tag intake line covering:
- review findings by category — a category recurring across waves becomes a new campaign lens AND a landmine line in future plan prompts;
- Layer-1 predicted surface vs Layer-3 actual
gh pr diff --name-onlydelta — chronic misprediction rewrites the surface-authoring guidance; - doneWhen adequacy — a real bug caught only OUTSIDE the acceptance ceiling means the doneWhen template gains that class of item.
Operator-absent authority
- Standing (once granted): file evidenced issues, label
fleet:pending; low-risk classes (fix/test/docs in named crates) may enter delivery. - Queued, never improvised: direction and high-risk issues wait under
needs-operator. - Anti-corruption is structural: the issue's author never reviews the PR that closes it; promotion to verified finding needs an independent check; flooding is blocked by the ladder, not by restraint.
Red flags — stop, you are rationalizing
| Thought | Reality |
| "I'll write it up at the end of the session" | Findings die in transcripts. File or park it now. |
| "The queue is low, this hunch will do" | An unevidenced issue costs a whole delivery lane later. Park it as a candidate. |
| "doneWhen is obvious, the implementer will know" | #547 shipped without doneWhen and acceptance had to be invented at dispatch. Write it. |
| "Surface is obvious from the title" | Layer 1 cannot judge a title. Name crate/paths/symbols. |
| "Probably not a duplicate" | edda ask + edda search + issue search take a minute. Run them. |
| "I wrote the spec, so I can verify the fix fastest" | Author-verifier collusion checks compliance, not design. Hand it off. |
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.