process-issues
Skill325 starsChanged 55 days agoMITView on GitHub
Resolve all open GitHub issues. Each issue becomes exactly one shipped PR. Trigger when user says "process issues", "work through issues", "resolve issues", "handle open issues", "fix all issues", or asks to resolve GitHub issues end-to-end.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- mgovedarov/mcp-vcf-orchestratortheir own version, first seen Nov 1, 2026
- everruns/everrunstheir own version, first seen Oct 31, 2026
- maslennikov-ig/claude-code-orchestrator-kittheir own version, first seen Mar 5, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- maslennikov-ig/claude-code-orchestrator-kit★ 248same name
- everruns/everruns★ 66same name
- mgovedarov/mcp-vcf-orchestrator★ 7same 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.
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 3 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 17
Every qualifying open issue has a merged PR that resolves it.
- Distinctive: line 21
Only process issues that meet ONE of:
- Very specific: line 55
Do NOT duplicate any /ship steps manually — let the skill handle the full pipeline.
- Very specific: line 57
After /ship completes and the PR is merged, return to main before next issue: git checkout main && git pull origin main
- Distinctive: line 67
If an issue is unclear or not reproducible, comment asking for clarification and skip to next.
- Distinctive: line 68
If a fix would be >500 lines, split into sub-issues and link them.
- Distinctive: line 69
Never skip the failing-test-first step for bugs.
- Distinctive: line 70
Always rebase on latest main between issues.
“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
Resolve all qualifying open GitHub issues. Each issue becomes exactly one merged PR. Do not stop until every issue is resolved or explicitly deferred.
Arguments
$ARGUMENTS- Optional: specific issue numbers (e.g. "42 55") or labels. If omitted, process all open issues.
Goal
Every qualifying open issue has a merged PR that resolves it. One issue = one PR. No bundling. No skipping.
Qualifying issues
Only process issues that meet ONE of:
- Created by
chaliy - Has a comment from
chaliyapproving it
Skip all others silently.
Per-issue outcomes
For each qualifying issue (ordered by issue number), achieve ALL of these before moving to the next:
1. Issue is understood and scoped
- Classify: bug, feat, test, chore, refactor, docs
- Identify affected areas: parser, interpreter, builtins, vfs, network, git, python, tool, eval, security
- Branch created from latest main:
fix/issue-{N}-{short-slug}
2. Failing test exists (bugs) or scaffold test exists (features)
- A test that demonstrates the bug or validates the feature exists in
crates/bashkit/tests/spec_cases/or relevant module - For bugs: test fails before the fix, passes after
3. Fix or feature is implemented
- Minimal, focused changes
- Positive and negative tests pass
- Security tests added if change touches parser, interpreter, VFS, network, git, or user input (per
knowledge/security/security-testing.md) - Threat model updated if new attack surface (per
knowledge/security/threat-model.md)
4. Ship via /ship
Invoke the /ship skill to handle all remaining steps: spec updates, artifact updates, code simplification, security review, smoke testing, quality gates, PR creation, CI, and merge.
Pass context: Closes #N — <short description of the fix/feature>
Do NOT duplicate any /ship steps manually — let the skill handle the full pipeline.
After /ship completes and the PR is merged, return to main before next issue: git checkout main && git pull origin main
After all issues
Scan for #[ignore] tests that may now pass. Un-ignore any that are green. Single PR for all un-ignored tests.
Rules
- One issue = one PR. Non-negotiable. Never bundle multiple issues.
- Never close a half-done issue. If the PR only implements a subset of the issue's tasks, do NOT use
Closes #NorFixes #Nin the PR body. Instead usePartial #NorPart of #Nand list what remains. Only use closing keywords when every task/checkbox in the issue is complete. - If an issue is unclear or not reproducible, comment asking for clarification and skip to next.
- If a fix would be >500 lines, split into sub-issues and link them.
- Never skip the failing-test-first step for bugs.
- Always rebase on latest main between issues.
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.