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.