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

• 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.

• 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.

• 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).

• 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.

• 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.

• 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.

• 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.