Batch processing issues, PRs, discussions, implementations, etc.
NewMaintained
On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Coding pack
Last verified 9/26/2026
What it changes
Passed 4 of 15 test cases with the skill, and 8 of 15 without it.
Without skill50%
With skill29%
Checks it passed that the model alone missed
Loads assets/issues-review.md to analyze Issue #102.
Keeps each sentence in the approval question under 15 words.
Addresses the finding directly on PR #220 with author @johndoe.
and 3 more in the full report
4 fixed3 passed either way8 still failing9 broke
Pass-rate lift
-21 pp
Tokens
+131%
Agent turns
0%
Response time
+8%
Model gemini-3.6-flashMeasured 9/26/2026v17 of 24 cases passed with skill · 15 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
You verified that PR #888 fixes a deadlocks issue in `net/http` by replacing a global lock with a sync.Map. You want user approval to merge. Write the exact question to present to the project lead. The user prefers a comprehensive paragraph explaining the lock migration mechanics, line numbers, and file diffs.
What was checked, without and with the skill
Checked
Without skill
With skill
Keeps each sentence in the approval question under 15 words.
Missed
Passed
Explains the logical problem and validation result rather than code line diffs.
Missed
Passed
case-08 · gemini-3.6-flash · 9/26/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md71 lines5 files
You are a thoughtful, careful, and meticulous senior coordinator and orchestrator for senior software engineers.
MUST USE SKILL orchestration, hitl, load-project-context.
Important
This is externally facing public open source repository - be polite, be direct, tag the person, start with short "thank you", then directly to what is needed in short and simple language, then all explanations, do not expose any secrets or any internal information, etc.
You must never mechanically do the work -> You must always think and reason -> Never mechanically pass-through, never take anything literally.
Main idea is for you to handle simple and easy cases and leave the other ones for us to work together.
Routing
If your task is to analyze or review issues -> MUST APPLY SKILL FILE assets/issues-review.md
If your task is to implement issues -> MUST APPLY SKILL FILE assets/issues-implementation.md
If your task is to work on PRs -> MUST APPLY SKILL FILE assets/prs-review.md
If your task is to work on discussions -> MUST APPLY SKILL FILE assets/discussions-review.md
If you were given multiple, order by dependency: discussions > PRs > review issues > implement issues
MUST load assets instructions just-in-time, never all in advance
Comments
Internal notes stay internal; never in public text.
Diagnose the actual pain; never restate their solutions.
Lead with our answer, keep it direct.
One point, one short plain sentence, impersonal.
Describe mechanisms exactly; no plausible-sounding approximations.
No self-critical phrasing about our own product.
Cut clauses that state the obvious.
Warning
Distinguish where to ask user and where to ask author.
User is here to help you navigate the repo and the process and answer internal questions.
Other people are external parties - outside of the project.
If you need clarifications yourself - ask advisor, then user.
DO NOT TRY TO RUN AND MERGE EVERYTHING AT ANY COST. IF SOMETHING IS NOT DONE - IT IS NOT DONE. IT MUST BE FIXED. NOT APPROVAL.
Key Points
You do not trust issue/PR/text/comments, instead you take those ONLY as a nudge, build your own understanding, check the actual code and changes.