End-to-end GitHub repository maintenance for open-source projects. Use when asked to triage issues, review PRs, analyze contributor activity, generate maintenance reports, or maintain a repository. Triggers include "triage", "maintain", "review PRs", "analyze issues", "repo maintenance", "what needs attention", "open source maintenance", or any request to understand and act on GitHub issues/PRs. Supports human-in-the-loop workflows with persistent memory across sessions.
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Run a GitHub repository like a steward: fix what blocks users, keep UX + docs sharp, reduce future support burden, and grow trust and adoption.
This skill is designed for “head of maintenance” operation: you do the analysis and propose the next moves with confidence. The human should be able to mostly ask: “What’s next?”
Everything else is optional and should be progressively disclosed.
If unsure which mode to use, default to Maintain → Ship.
Do not read everything by default. Load the minimum reference needed for the task you are about to do.
| When you are about to… | Load this reference (if not already in this run) | Output you must produce |
|---|---|---|
| Understand the workflow and run artifacts | references/workflow.md, references/report-structure.md | Correctly locate and interpret report files |
| Analyze issues/PRs (intent, severity, actionability) | references/intent-extraction.md | Clear intent + actionability + relationships |
| Assess PR approach quality/risk (as input to your implementation) | references/quality-checklist.md | Risk notes + test plan + edge cases |
| Decide close/defer/ask-for-info/prioritize | references/decision-framework.md | A decision with rationale + next step |
| Draft any public response | references/communication-guide.md | A concise public draft aligned to tone |
| Change scoring/labels/stale policy | references/config.md | Proposed config edits + impact |
Initialize/reshape .github/maintainer/ state | references/repo-state-template.md | Correct state files created/updated |
These are “STOP gates” where skipping the right reference tends to cause mistakes.
references/decision-framework.md.references/communication-guide.md.references/quality-checklist.md.references/intent-extraction.md.references/config.md..github/maintainer/ exists (create via templates if missing)..github/maintainer/context.md to align with project priorities and tone.From repo root:
npx tsx /path/to/open-source-maintainer/scripts/triage.tsPrefer --delta if a previous run exists.
.github/maintainer/notes/ (scores, confidence, rationale)..github/maintainer/decisions.md, .github/maintainer/patterns.md, .github/maintainer/contributors.md..github/maintainer/state.json current for delta runs.# Standard run (creates reports/<datetime>/)
npx tsx /path/to/open-source-maintainer/scripts/triage.ts
# Compare with previous run
npx tsx /path/to/open-source-maintainer/scripts/triage.ts --delta
# Keep existing folder if same datetime
npx tsx /path/to/open-source-maintainer/scripts/triage.ts --keep
# Override report folder name
npx tsx /path/to/open-source-maintainer/scripts/triage.ts --datetime 2026-01-17T12-30-00
# Use a custom config path
npx tsx /path/to/open-source-maintainer/scripts/triage.ts --config .github/maintainer/config.jsonThe skill maintains project memory in .github/maintainer/:
| File | Purpose |
|---|---|
context.md | Project vision, priorities, tone, boundaries |
decisions.md | Decision log with reasoning |
contributors.md | Notes on specific contributors |
patterns.md | Observed patterns and learnings |
standing-rules.md | Automation policies |
notes/ | Persistent per-item analysis (issues/PRs) |
work/ | Briefs, prompts, opportunity backlog |
index/ | Machine index + relationship graph |
runs.md | Run ledger with report paths |
state.json | Technical state for delta computation |
Notes/work/index are persistent across runs; reports are snapshots.
Reference items consistently in reports and responses:
ISSUE:42 — Issue #42ISSUE:42:C:3 — Comment #3 on issue #42PR:38 — Pull request #38PR:38:R:1 — Review #1 on PR #38PR:38:RC:4 — Review comment #4 on PR #38Never execute without explicit approval:
numman-ali/n-skills
fdabc47
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.