# Contributor Pipeline Gardening > Maintenance of the contributor issue pipeline for JSONbored/awesome-claude (HeyClaude) — closing issues that are already done but not marked so, and keeping a small, high-value contributor-available backlog stocked with real website/content/feature/bugfix work. Runs every ~24h via a dedicated scheduled task. Invoke for "run the issue gardening", "audit open issues for stale/complete ones", "generate new contributor issues", or any recurring/scheduled run of this process. `reference.md` (next to this file) has the exhaustive label/milestone/ template detail — read it before doing real work, not just this file. This is the awesome-claude-specific instance; JSONbored/loopover and JSONbored/metagraphed each have their own separate copy with different conventions and a much larger backlog target — do not cross-apply either repo's specifics to this one without being asked. - Skill: `gabrielmoreira/contributor-pipeline-gardening` (Agent Skill) - Install (CLI): `npx skillmds@latest add gabrielmoreira/contributor-pipeline-gardening` - Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/contributor-pipeline-gardening/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/gabrielmoreira/contributor-pipeline-gardening --- # Contributor pipeline gardening — awesome-claude (HeyClaude) HeyClaude is a curated registry/directory of Claude and AI-workflow assets, plus the website (`apps/web`), registry/schema library (`packages/registry`), and MCP package (`packages/mcp`) that serve it. **This is a much smaller, quieter repo than loopover/metagraphed** — as of 2026-07-17 it had zero open `gittensor:*`-labeled issues and a thin, fully-closed 2-milestone history. This skill exists to build and then maintain a small, deliberately curated backlog — **15-25 contributor-available issues**, not 50-100 — because padding a codebase this size to a larger number would mean weak/duplicate issues, which is explicitly worse than a smaller real backlog here. ## The one thing this skill exists to prevent **Confirmed by the maintainer, 2026-07-17:** contributors here have recently gravitated to `test(...): cover X` PRs — real tests, but zero behavior change, added purely to nudge Codecov's `codecov/patch: 70%` bar (a soft, easily-hit target — unlike loopover's 99% gate, 70% patch coverage is trivially satisfied by testing already-written code). A second anti-pattern found during this skill's initial research: issue #550 (a "growth sprint" umbrella with a long child checklist) was being farmed almost entirely for its single easiest repeatable pattern — wiring one more page into the existing `intent-event`/analytics-click convention, dozens of near-identical PRs (#5205, #5202, #5201, ... #5168, all `Made with Cursor`), rather than any of the umbrella's harder, more valuable child issues. **Never generate a standalone `test(...): cover X` issue.** A regression test attached to a real bug fix is fine and expected (see the template in `reference.md`); a test-only issue with no behavior change is not. **Never generate more instances of an already-being-farmed shallow repeatable pattern** (check open issues and recent merged-PR titles for a dense run of near-identical titles before filing anything that looks like "wire pattern X into one more file/page/route" — if 5+ near-identical PRs already exist for the same pattern, that vein is farmed out, not a gardening opportunity). The whole point of this skill is issues that "drive real value... website/content/features grow... fix bugs/issues in frontend/backend" (the maintainer's own words) — not more of what a low-effort automated farmer already does better and faster than a well-scoped issue ever could. ## Scope: code only, not content submissions `content/` (the curated directory entries themselves) is a legitimate, real contribution surface per `.gittensory.yml`'s `wantedPaths` — but content submissions are explicitly **PR-first**, with `linkedIssuePolicy: optional` and `issueDiscoveryPolicy: discouraged`, routed through a private submission gate that doesn't need or want a GitHub issue first. **This skill does not generate content-entry issues.** It scopes to the three code surfaces: `apps/web/src/` (the TanStack Start website — routes, components, lib), `packages/registry/src/` (schema/validation/submission-risk library), and `packages/mcp/` (the MCP server package), plus `scripts/` when a real gap is there. Unlike loopover/metagraphed, **a linked issue is advisory here, not a hard gate** (`gate.linkedIssue: advisory` in `.gittensory.yml`) — there is no auto-close mechanic forcing a contributor to pick an issue. That means an issue has to be genuinely worth picking up on its own merits (clear, valuable, narrow, low-ambiguity) rather than relying on gate pressure to make it attractive. Write every issue like it has to compete for a contributor's attention, because it does. ## Pass 1 — stale-issue sweep (do this first, every run) Same method as loopover/metagraphed's copy of this skill: for every open issue, query `timelineItems(itemTypes: [CROSS_REFERENCED_EVENT])` for merged PRs that referenced it, then read the actual PR body for any hit where `willCloseTarget` was false. Close what's genuinely done (with a comment naming the shipping PR and a direct code check confirming it exists); leave partial work open. Given this repo starts with a near-empty gittensor backlog, most runs will find little or nothing to sweep here until the backlog this skill builds has had time to accumulate real activity — that's expected, not a sign the check is broken. **Verify against synced upstream, not a stale local checkout.** Before treating any local grep/read as evidence that an issue's described work does or doesn't exist, confirm the code you're reading matches the default branch's current tip — fetch and fast-forward the checkout (or use a disposable worktree off `origin/main` if the primary checkout is dirty or has unpushed work on another branch) before doing any verification. A checkout that's merely *clean* isn't the same as *current* — a stale-but-clean checkout silently produced false "already done"/"not done" conclusions in the sibling loopover/metagraphed repos' gardening runs on 2026-07-17/18, causing duplicate issues to be filed for already-shipped work. Confirm sync every run; never assume a previous run's freshness carried over. Also check issue #550 (the growth-sprint umbrella) and any other checklist-style tracker each run: sync stale checkboxes against real child-issue state, same as the sibling repos' Pass 1. Do not add new child issues to #550's shallow analytics-wiring pattern (see above) even if asked to "keep it topped up" — that pattern is already over-farmed. ## Pass 2 — backlog top-up 1. Compute the current contributor-available count: `gh issue list --repo JSONbored/awesome-claude --state open --limit 1000 --json number,labels,assignees`, filtered to unassigned, no `maintainer-only`, carrying a `gittensor:*` label. Target: **15-25, maintained continuously**. If already in range, a quiet run that files 0-2 issues (or none) is a correct, expected outcome — this is a small repo, don't force volume. 2. Real gaps to scope from, in priority order: - A genuine functional gap in `apps/web/src/routes/*.tsx` (~70 routes) — missing feature parity between similar pages, a real UX/accessibility gap, a bug found by reading the code against its own stated behavior. - A real correctness/hardening gap in `packages/registry/src/` (schema/validation/risk-scoring logic) — found by reading the code, not by grepping for TODOs (a repo-wide TODO/FIXME sweep came back essentially empty as of 2026-07-17; this repo is clean, so gap-finding here means reading real logic against its own documented intent, the same technique loopover's gardening uses for its "hardening round" audits). - `packages/mcp/`'s tool/resource surface for a real, narrow parity or correctness gap. - Closed-milestone follow-ups: `Code Quality — Round 5` (#3) and `Growth & Maintainability — Round 7` (#4) are both fully closed, historical sprints — read a few of their closed issues for the kind of real, valuable work this repo's maintainer has asked for before, as a calibration reference for what "real value" looks like here, not as a source of reopenable work. 3. **Every new issue gets `Contributor Backlog (Gardening)` (milestone #5)** — the two historical Round milestones are closed and not the target. This milestone was created 2026-07-17 specifically as the evergreen home for this skill's output (see `reference.md`'s milestone-discipline note for why a new one was warranted here). 4. Apply `gittensor:bug` / `gittensor:feature` / `gittensor:priority` (same 0.05x/0.25x/1.5x convention as loopover — `gittensor:priority` reserved, sparingly applied) plus `help wanted`. Do not apply `size:*`, `category:*`, `contributor:*`, `pr:*`, or `submission-*` labels — those belong to this repo's separate content-submission/PR-automation machinery, not gardening-filed issues. 5. **Use the repo's own existing `product-feature.yml` issue-form template** (via `gh issue create --template` or matching its field structure manually) — see `reference.md` for the exact field list. This is a real, maintainer-authored template already built for exactly this use case; do not invent a different body structure. 6. Check every new batch for a real dependency, then link with native `addSubIssue`/ `addBlockedBy` (confirmed working on this repo via GraphQL) — same discipline as the sibling repos: most independent bug/feature issues need no link; only connect a genuine prerequisite relationship. 7. Quality over volume, always — this repo's small size makes padding especially visible and especially damaging to the "issues are worth picking up voluntarily" value proposition Pass 2's intro describes. ## Daily digest Same shape as the sibling repos': issues closed + why, checklists fixed, new issues filed with milestone/label, before/after contributor-available count (against the 15-25 target, not 50-100), anything left alone on purpose — including explicitly naming any shallow-pattern-farming or test-coverage-padding temptation that was deliberately declined.