Pre-Release PR Triage
jamiepine/voicebox
Sorts a backlog of open pull requests into must-merge, candidate, superseded and deferred, writes a triage doc and works the merge loop before a release.
Helps maintain the slopus/happy open source project by triaging issues, drafting closing comments, finding duplicates and checking fixes, with approval before anything is posted.
Install Open Source Maintainer Assistant
$ npx skills add slopus/happy --skill maintain -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install slopus/happy maintain --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/slopus/happy.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/maintain .claude/skills/maintain && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "maintain" agent skill from https://github.com/slopus/happy/tree/main/.agents/skills/maintain into .claude/skills/maintain/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "maintain", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/slopus/happy/tree/main/.agents/skills/maintainType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add slopus/happy --skill maintain -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install slopus/happy maintain --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/slopus/happy.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/maintain .agents/skills/maintain && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "maintain" agent skill from https://github.com/slopus/happy/tree/main/.agents/skills/maintain into .agents/skills/maintain/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "maintain", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add slopus/happy --skill maintain -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install slopus/happy maintain --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/slopus/happy.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/maintain .cursor/skills/maintain && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "maintain" agent skill from https://github.com/slopus/happy/tree/main/.agents/skills/maintain into .cursor/skills/maintain/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "maintain", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/slopus/happy.git --path .agents/skills/maintain--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add slopus/happy --skill maintain -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install slopus/happy maintain --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/slopus/happy.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/maintain .gemini/skills/maintain && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "maintain" agent skill from https://github.com/slopus/happy/tree/main/.agents/skills/maintain into .gemini/skills/maintain/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "maintain", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install slopus/happy maintainInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add slopus/happy --skill maintain -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/slopus/happy.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/maintain .github/skills/maintain && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "maintain" agent skill from https://github.com/slopus/happy/tree/main/.agents/skills/maintain into .github/skills/maintain/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "maintain", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add slopus/happy --skill maintain -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install slopus/happy maintain --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/slopus/happy.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/maintain .opencode/skills/maintain && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "maintain" agent skill from https://github.com/slopus/happy/tree/main/.agents/skills/maintain into .opencode/skills/maintain/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "maintain", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
maintain- GitHub stars
- 24k
- Token cost
- ~1.9k tokens
- SKILL.md length
- 1,006 words
- Files
- 2
- Skills in repo
- 8
- Repo updated
- First seen
- Licence
- MIT
At a glance
Helps maintain the slopus/happy open source project by triaging issues, drafting closing comments, finding duplicates and checking fixes, with approval before anything is posted.
- Works in 7 steps: Check for items needing my response → Fetch and cluster → Deep dive per cluster → …
- Triaging a backlog of open issues in slopus/happy
- SKILL.md covers References (single source of…, Golden rule, Comment voice and Themes, plus 1 more section
- Calls gh and npm
What it does
The agent works as a maintainer for the slopus/happy project: triaging issues, drafting closing comments, finding duplicates, checking whether bugs are fixed on main and engaging contributors. Priorities and themes live in checkpoint.md rather than in GitHub Projects or milestones, while contribution priorities and the roadmap sit in docs files that the agent reads instead of copying.
A golden rule governs actions: never close, comment on, merge or modify issues and PRs without showing the exact text and getting explicit approval, even when told to close everything. Any feedback from the maintainer counts as still iterating, so the plan is re-presented and the agent waits for a clear directive. Merging needs passing CI with no admin bypass, the exact merge commit message shown for approval, and no batch merging across feedback boundaries. A comment voice section asks for dry, factual replies that lead with the direct answer.
When your agent uses it
- Triaging a backlog of open issues in slopus/happy
- Drafting closing comments for issues that are already fixed
- Finding duplicate issues before replying
- Preparing pull requests for merge with exact commit messages shown
Example prompts
- “Triage the new issues and draft closing comments for the ones fixed on main.”
- “Find duplicates of this bug report and show me the reply you would post.”
- “Review the open PRs and tell me which ones are ready to merge once CI is green.”
Workflow steps
7 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit 7ea7017. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
ghnpm
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use gh and npm, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Open Source Maintainer Assistant loads about 1.9k tokens when it runs. Until then it costs about 69 tokens; SKILL.md has 1,006 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from slopus/happy at commit 7ea7017, republished under its MIT licence (© slopus). 1,006 words, ~1,879 tokens.
Download SKILL.mdSave it as
.claude/skills/maintain/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.- name
- maintain
- description
- Maintain the slopus/happy open source project. Triage issues, draft closing comments, find duplicates, check if bugs are fixed on main, and engage with community contributors. NEVER posts comments or closes issues without showing exact text and getting approval first.
/maintain - Open Source Project Maintenance
You are maintaining slopus/happy as an open source project. Every issue is a relationship with a user. Every close is a chance to build trust.
References (single source of truth - read these, don't inline)
- Contribution priorities:
docs/CONTRIBUTING.md - Roadmap themes:
docs/roadmap.md - Triage checkpoint (last session state, pending items, current
focus themes):
checkpoint.md
We do NOT use GitHub Projects, milestones, or priority/size fields.
Priorities and themes live in checkpoint.md.
Golden rule
NEVER close, comment on, merge, or modify issues/PRs without showing the exact text to the maintainer first and getting explicit approval. Even when told "close all" or "do X" - show the plan, get sign-off.
Double-confirmation on ALL human-facing actions
Any action that affects humans - closing issues, posting comments, merging PRs, editing issue text, labeling, assigning - requires explicit approval with the exact text/action shown first.
Feedback = still iterating. If the maintainer gives ANY feedback (questions, corrections, "but what about...", mixed responses), that means we are still thinking. Do NOT execute actions until feedback resolves into a clear, unambiguous directive. Specifically:
- Do NOT interpret "sure", "sounds good", listing numbers, or mixed feedback (act on some + questions on others) as blanket approval.
- After feedback is given, re-present the updated plan with exact text/messages that will be posted or executed.
- Wait for an explicit directive ("merge", "close these", "post it").
- If ambiguous, ask: "ready to execute?" - never assume.
PR merge rules
- CI must pass before merging. Never use
--adminto bypass branch protections. If CI hasn't run (first-time contributor), approve the workflow run first, wait for green, then merge. - Always show merge commit messages before merging. The maintainer must see and approve the exact message that lands in git history.
- Never batch-merge across feedback boundaries. If the maintainer gave feedback on 5 PRs and said "merge" on 2, only merge those 2. Re-present the others separately.
Comment voice
- Dry, matter-of-fact, factual. Do not mimic human texting or perform casualness - nicely formatted and direct beats folksy.
- Lead with the direct, simple answer to the human (fixed / open / yes / no / what to do). Details and postmortem come second.
- First person singular: "I", never "we have in mind" or royal "we".
- Normal capitalization and punctuation in paragraphs of a sentence or more. Only a super-short one-sentence reply stays lowercase, and it drops the trailing period.
- Bullet points are welcome when they make things easier to remember: repro info requests, scope requirements, UX specs.
- Terse. Cut anything the reader doesn't need to act.
- DO end with a genuine, plain thanks and an exclamation mark: "thanks for building this!", "thank you for contributing!", "thanks @user!". Warmth is good - a dry period-ended reply reads cold. The line just has to be simple and true.
- What's banned is flattery and editorializing on how good the work was, and performed/mimicked emotion - that reads as AI slop. Banned phrases (non-exhaustive): "really appreciate you", "exactly right", "classy", "amazing/great work", "keep up the great work", "i wanted to come back and thank you properly", "please keep upstreaming", "the way you did X was perfect". State what someone did factually, then thank them plainly - don't rate their work.
- Spam (vendor/sponsorship pitches, ads, link-farming, off-topic promotion): just close, NO comment. Don't explain, don't thank, don't point them to Discussions - any reply is the engagement they came for. Silent close only.
- No mdashes (use - or commas). No "We're excited to". No AI smell.
- Credit community contributors by @mention - state what they did, not how impressive it was.
- When a fix exists, ask the reporter to help verify it.
- Only mention
npm i -g happywhen the fix is in the CLI package. - Keep it short: 3 sentences for dupes, 5 max for canonicals.
Show full SKILL.md (393 more words)Show less
Themes
Themes are broad focus areas, not specific bugs. The current priority
list lives in checkpoint.md; align with docs/roadmap.md. A theme
is "table stakes", not "fix redis streams" (too specific, just a bug).
Workflow
Phase 0: Check for items needing my response
Before triaging anything new, scan for issues and PRs where the maintainer was mentioned or commented but hasn't responded to the latest reply. Run:
# Issues/PRs where @bra1nDump was mentioned but hasn't replied last
gh search issues --repo slopus/happy --state open --mentions bra1nDump \
--sort updated --limit 50 --json number,title,updatedAt,comments
# PRs with review requests for bra1nDump
gh pr list --repo slopus/happy --search "review-requested:bra1nDump" \
--json number,title,updatedAt,authorFor each result, check if the last comment is from someone other than bra1nDump. Present these as "needs your response" with a one-line summary of what the person is waiting on.
Phase 1: Fetch and cluster
- Pull all open issues from the repo
- Group by rough topic
- Present cluster summary with counts
Phase 2: Deep dive per cluster
For each cluster, spawn a subagent. Use the cheapest good model that
will take its time (currently GPT-5.6 Luna, openai/gpt-5.6-luna).
Each subagent:
- Reads the FULL thread for every issue - body, all comments, reactions, upvotes, linked PRs, cross-references. Not just the opening body. The real context is often in the replies.
- Identifies duplicate groups with a canonical for each
- Notes who filed each issue - repeat contributor? filed a PR? detailed report? This matters for how we respond.
- Credits community members who provided fixes or analysis
- Finds related PRs (open, closed, merged, draft)
Phase 3: Code check
For each cluster's key issues, spawn a subagent that:
- Searches the codebase on main - is the bug actually fixed?
- Checks git log for related merged commits
- Identifies WHO fixed it (community PR? maintainer?)
- Verdict: FIXED_ON_MAIN, PARTIALLY_FIXED, or STILL_BROKEN
Phase 4: Draft actions
For each issue, draft ONE of:
- CLOSE_FIXED - cite the fix, ask reporter to verify
- CLOSE_DUPE - link canonical, explain the connection
- CLOSE_SPAM - close with NO comment, zero engagement
- KEEP_OPEN - record priority and theme in
checkpoint.md - NEEDS_INFO - draft a question for the reporter
Phase 5: Present for review
Show the maintainer a table per cluster:
| # | Title | Author | Action | Draft comment |
Include who opened each issue and any notable context about them. WAIT for approval before executing anything.
Phase 6: Update checkpoint
Before ending the session, update checkpoint.md: what was closed
and commented, pending follow-ups, contributor context changes, and
the current canonical issue list with priorities. Next session starts
by reconciling the checkpoint against reality (new releases, reporter
replies) before triaging anything new.
© slopus, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 1 other file in .agents/skills/maintain of slopus/happy.
- SKILL.md
- checkpoint.md
Open the folder on GitHubat commit 7ea7017
Compare with similar skills
Open Source Maintainer Assistant next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Open Source Maintainer Assistant this skillslopus/happy | 24k | — | ~1.9k | Automated safety check: Pass | MIT | |
| Pre-Release PR Triagejamiepine/voicebox | 57k | — | ~3.1k | Automated safety check: Pass | MIT | |
| Ouroboros Maintainer TriageQ00/ouroboros | 6.2k | — | ~1.7k | Automated safety check: Pass | MIT | |
| Qwen Code Issue and PR TriageQwenLM/qwen-code | 28k | — | ~1.8k | Automated safety check: Pass | Apache-2.0 | |
| GitHub Project Triagesteipete/agent-scripts | 7.3k | — | ~4k | Automated safety check: Pass | MIT | |
| Triage Contributor PRsprisma/orm | 48k | — | ~3.6k | Automated safety check: Pass | Apache-2.0 |
Similar skills
Ouroboros Maintainer Triage
Q00/ouroboros
Triages and works through GitHub issues and pull requests in the Q00/ouroboros repo as a maintainer, within a stated review boundary and clear limits on what it may change.
Qwen Code Issue and PR Triage
QwenLM/qwen-code
Gatekeeps GitHub issues and pull requests for Qwen Code maintainers through staged static reviews that post a comment after each stage, under strict safety rules.
GitHub Project Triage
steipete/agent-scripts
Produces maintainer-facing triage cards for a project's GitHub issues and pull requests, each with its URL, risk, test state, blockers and a next action.
- Official
Triage Contributor PRs
prisma/orm
Triages open pull requests from external contributors to prisma/orm, producing a per-PR verdict with evidence, without closing, commenting on or approving anything.
- Official
GitHub Triage
trailofbits/skills
Triages open GitHub issues and pull requests with the gh CLI, optionally merging ready PRs, closing resolved issues with evidence and assigning local priority and size estimates.
More from slopus/happy
All 8 skills in this repoSession History Search
slopus/happy
Searches past Claude Code, Codex and Cursor sessions and summarizes what was worked on, tried or decided, using extraction scripts instead of reading raw logs.
Agent Browser CLI
slopus/happy
Drives a real browser from the shell with the agent-browser CLI: open pages, snapshot elements by ref, click, fill and extract, for testing web flows.
Control Flow Diagrams
slopus/happy
Traces how an action moves through your code and draws it as a compact ASCII tree: functions called, payload types, state changes and components that re-render.
Happy Monorepo Dev Guide
slopus/happy
Local development guide for the Happy pnpm monorepo: install, build, test and run the CLI, server, Expo app and Tauri desktop packages.
Happy Infra Metrics and Grafana
slopus/happy
Queries live Prometheus metrics and manages Grafana dashboards as code for Happy's infrastructure, using the grafanactl CLI and the Grafana datasource proxy API.
Interactive CLI Testing With tui-test
slopus/happy
Tests interactive CLI and TUI programs with Microsoft's tui-test, driving prompts, arrow keys and screen output in a real pseudo-terminal.
Related
Works with
Categories
Questions about Open Source Maintainer Assistant
What does Open Source Maintainer Assistant do?
Helps maintain the slopus/happy open source project by triaging issues, drafting closing comments, finding duplicates and checking fixes, with approval before anything is posted. The agent works as a maintainer for the slopus/happy project: triaging issues, drafting closing comments, finding duplicates, checking whether bugs are fixed on main and engaging contributors.md rather than in GitHub Projects or milestones, while contribution priorities and the roadmap sit in docs files that the agent reads instead of copying.
When should I use Open Source Maintainer Assistant?
Open Source Maintainer Assistant fits situations like: triaging a backlog of open issues in slopus/happy; drafting closing comments for issues that are already fixed; finding duplicate issues before replying; preparing pull requests for merge with exact commit messages shown.
How do I install Open Source Maintainer Assistant in Claude Code?
Run `npx skills add slopus/happy --skill maintain -a claude-code`. Or copy the skill folder (.agents/skills/maintain in slopus/happy) into .claude/skills/maintain in your project. Claude Code loads it when a task matches its description.
How do I install Open Source Maintainer Assistant in Codex?
Run `npx skills add slopus/happy --skill maintain -a codex`. Or copy the skill folder (.agents/skills/maintain in slopus/happy) into .agents/skills/maintain in your project. Codex loads it when a task matches its description.
Can I use Open Source Maintainer Assistant in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add slopus/happy --skill maintain -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/maintain, .gemini/skills/maintain, .github/skills/maintain and .opencode/skills/maintain in your project.
What does Open Source Maintainer Assistant need to run?
Going by SKILL.md and its folder, Open Source Maintainer Assistant needs the command-line tools its instructions call (gh and npm).
Does Open Source Maintainer Assistant access the network?
SKILL.md contains no URLs. Its commands use gh and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Open Source Maintainer Assistant safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Open Source Maintainer Assistant use?
Open Source Maintainer Assistant is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Open Source Maintainer Assistant use?
About 1.9k tokens (SKILL.md is roughly 7.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Open Source Maintainer Assistant?
Skills that share tags, products or a category with Open Source Maintainer Assistant: Pre-Release PR Triage (jamiepine/voicebox, 57k stars), Ouroboros Maintainer Triage (Q00/ouroboros, 6.2k stars), Qwen Code Issue and PR Triage (QwenLM/qwen-code, 28k stars) and GitHub Project Triage (steipete/agent-scripts, 7.3k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Open Source Maintainer Assistant?
slopus (a GitHub organization) maintains it in slopus/happy, which has 24,039 GitHub stars. The repository holds 8 skills in this directory. The repository was last updated on October 7, 2026.
Source: slopus/happy on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.