gh-contribution-planner
Skill19 starsChanged 2 months agoMITView on GitHub
Daily GitHub contribution planner — analyzes the gh-logged-in user's non-archived repos (owned
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 7 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 25
Do not use this skill to operate on a specific PR you already picked — use gh-fix-ci, gh-address-comments, or github-cli-workflow directly.
- Very specific: line 41
Verify auth: Run gh auth status. If unauthenticated, ask the user to run gh auth login and stop.
- Distinctive: line 96
Halt for approval: Ask the user which buckets and which specific items to execute.
- Distinctive: line 116
Aggregate the run: When the parallel batch completes, summarize:
- Distinctive: line 119
Follow-ups that need the user's direct attention.
- Distinctive: line 128
Idempotency: before opening a new PR, the sub-agent must check for an existing open PR with the same intent (label or title heuristic) and …
- Distinctive: line 131
Drafts by default: every PR is opened as draft.
- Distinctive: line 138
Read-only on GitHub during planning.
- Very specific: line 140
Do not author commits or PRs from this skill directly — delegate every push to github-cli-workflow.
- Distinctive: line 142
Do not act on repos owned by other users beyond the external contributions bucket, and even there only via PRs (never direct pushes).
- Very specific: line 144
Do not interact with non-GitHub forges.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GitHub Contribution Planner
Discover what to work on across your GitHub footprint, propose a prioritized
daily plan, and — on approval — fan out parallel sub-agents to open draft PRs.
The skill infers the current user from the authenticated gh CLI, so no
manual configuration is required.
When to use
- "Plan my GitHub contributions for today" / "what should I work on across my repos" / "give me a daily contribution plan".
- You want to maintain your own repositories and forks without manually scanning each one.
- You want to find low-friction openings (good first issues, stale PRs, outdated forks) in projects you have already contributed to.
Do not use this skill to operate on a specific PR you already picked — use
gh-fix-ci, gh-address-comments, or github-cli-workflow directly.
Prerequisites
ghinstalled and authenticated (gh auth statusexits 0). Scopes typically required:repo,read:org.doctorreports this under Integrations.python3for the bundled analyzer.- Network access to
api.github.com(or the host configured viaGH_HOST). - A host that supports parallel sub-agent dispatch (Claude Code's
Tasktool, OpenCode's subagent fan-out, etc.). Hosts without that primitive fall back to sequential execution.
Workflow
- Verify auth. Run
gh auth status. If unauthenticated, ask the user to rungh auth loginand stop. Do not prompt for tokens. - Resolve the current user.
gh api user --jq .login— never ask the user; always infer fromgh. Run the analyzer.
python3 ~/.local/share/agent-toolkit/skills/gh-contribution-planner/scripts/inspect_contributions.py \ --since 90d --max-per-bucket 5Useful flags:
--json— machine-readable output (recommended when composing with another agent).--user <login>— override the inferred login (useful for testing or planning for an organization the user maintains).--dry-run— print theghcalls the analyzer would make and exit; useful for sanity-checking before a live run.--max-per-bucket <n>— cap items per bucket (default 5).--since <window>— lookback window for recent contributions. Accepts30d,90d,180d, or an ISO date.
The script:
- Calls
gh api userto resolve the login. - Calls
gh api graphqlto batch-fetch viewer repos (non-archived, forks + sources), open PRs authored by the user, and recent contributions across GitHub. - For each fork, compares the default branch with the parent's default
branch to compute
behind/aheadcounts. - For each owned repo, fetches open issues labeled
good first issueorhelp wanted, plus unassigned issues older than the lookback window. - Scores and buckets every item.
Present the plan in English grouped into these buckets (each item must show repo
owner/name, a one-line summary, an effort estimate, and a suggested delegate skill):- Quick wins (~15 min) — README/typo/doc fixes, dependency bumps, missing CI badges in your own repos.
- In-flight PRs — open PRs authored by you that need attention
(red CI →
gh-fix-ci; rebase needed →github-cli-workflow). - Review feedback — PRs with unresolved review comments → delegate to
gh-address-comments. - Forks needing sync — forks lagging upstream by ≥ N commits; propose a
sync via
gh repo syncor a merge-from-upstream PR. - Maintenance — own non-archived repos with stale unanswered issues, security alerts, or abandoned PRs from contributors awaiting your review.
- External contributions — repos where you contributed in the lookback
window with open
good first issue/help wantedissues that are currently unassigned.
- Halt for approval. Ask the user which buckets and which specific items to execute. Do not open PRs or push commits before approval.
Dispatch parallel sub-agents for the approved items. One sub-agent per item, capped at 5 concurrent by default. Each sub-agent receives:
- Target
owner/nameand (when relevant) issue / PR number. - A one-line goal extracted from the plan.
- A directive to start with
dev-assistantfor repo discovery, then route to the right execution skill:- PR push / draft PR creation →
github-cli-workflow. - Red CI on an existing PR →
gh-fix-ci. - Open review comments →
gh-address-comments. - Fork drift →
gh repo sync(delegate the sync step; never force).
- PR push / draft PR creation →
- An explicit instruction to open the PR as draft unless the user marks the item as ready-for-review in the approval step.
On hosts without parallel sub-agent dispatch, execute items sequentially in the same order and report progress between items.
- Target
- Aggregate the run. When the parallel batch completes, summarize:
- Draft PRs opened (
owner/repo#NN+ URL). - Items skipped or blocked (with reason).
- Follow-ups that need the user's direct attention.
- Draft PRs opened (
Parallel execution contract
- Concurrency cap: 5 sub-agents at a time. Raise only on explicit user request.
- Isolation: each sub-agent works in its own git worktree or a fresh clone
under
~/.cache/agent-toolkit/contribution-planner/<owner>-<repo>/. Never reuse the host repo working tree. - Idempotency: before opening a new PR, the sub-agent must check for an existing open PR with the same intent (label or title heuristic) and skip duplicates.
- Drafts by default: every PR is opened as draft. The user marks ready separately.
- No force pushes to branches that already exist on
originunless the user explicitly opts in.
Boundaries
- Read-only on GitHub during planning; writes only after explicit user approval, and only on approved items.
- Do not author commits or PRs from this skill directly — delegate every push
to
github-cli-workflow. - Do not act on repos owned by other users beyond the external contributions bucket, and even there only via PRs (never direct pushes).
- Do not interact with non-GitHub forges; for GitLab, route to
gitlab-cli-workflowinstead.
Bundled resources
scripts/inspect_contributions.py— stdlib-only analyzer. Defaults to Markdown output;--jsonfor machine-readable output.
Validation
skills checkreports theghandpython3requirements.doctorshowsgh auth statusunder Integrations.Smoke test:
python3 ~/.local/share/agent-toolkit/skills/gh-contribution-planner/scripts/inspect_contributions.py --dry-run
In this repository106 other files it gives its agents.
- AGENTS.mdAGENTS.md
- reviewSkill
- mcp-auditSkill
- owasp-agentic-reviewSkill
- supply-chain-auditSkill
- threat-modelingSkill
- architecture-diagramSkill
- c4-modelSkill
- aws-well-architected-reviewSkill
- cloud-design-patternsSkill
- assistantSkill
- dev-companionSkill
- onboardingSkill
- output-handshakeSkill
- pr-fallbackSkill
- projectSkill
- workspace-knowledge-syncSkill
- workspaceSkill
- dbt-validationSkill
- snowflake-validationSkill
- adrSkill
- agreementSkill
- bugSkill
- decision-logSkill
- development-workflowSkill
- epicSkill
- incidentSkill
- management-unit-assessmentSkill
- meeting-minutesSkill
- planningSkill
- prdSkill
- project-assessment-evidenceSkill
- project-assessmentSkill
- spikeSkill
- taskSkill
- technical-unit-assessmentSkill
- trdSkill
- user-storySkill
- workflow-client-bootstrapSkill
- workflow-generic-projectSkill
- work-itemSkill
- bragSkill
- brag-slimSkill
- design-assessmentSkill
- design-improvementSkill
- figma-code-connect-componentsSkill
- figma-create-design-system-rulesSkill
- figma-create-new-fileSkill
- figma-implement-designSkill
- figmaSkill
- frontend-design-reviewSkill
- frontend-designSkill
- scroll-worldSkill
- web-design-guidelinesSkill
- fix-merge-conflictsSkill
- gh-address-commentsSkill
- gh-fix-ciSkill
- github-cli-workflowSkill
- gitlab-cli-workflowSkill
- worktreeSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

