---
name: contributor-pipeline-gardening
description: >-
  Maintenance of the contributor issue pipeline for JSONbored/metagraphed — closing issues that
  are already done but not marked so, and keeping the contributor-available backlog at its
  50-100+ steady-state floor with well-scoped new issues. Runs every ~8h via the scheduled task
  (raised from daily on 2026-07-15 so the floor is maintained continuously, not caught up once a
  day). 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 metagraphed-specific instance;
  JSONbored/gittensory (loopover) has its own separate copy with different conventions — do not
  cross-apply either repo's specifics to the other without being asked.
---

# Contributor pipeline gardening — metagraphed

## Scope boundary — no registry enrichment (reinforced 2026-07-19)

**This pipeline covers code/feature/bug work only.** Registry surface/subnet data work of any
kind — new-subnet intake (Enrich-SNxx), accuracy passes, probe-config fixes, or any other edit to
`registry/subnets/<slug>.json` content — is **out of scope entirely**, not just the already-documented
Enrich-SNxx exclusion below. A separate, dedicated automation owns registry enrichment end to end.
This was reinforced by the maintainer 2026-07-19 after this pipeline generated 34 registry
probe-config issues (decomposing #5932) that had to be reverted mid-run. If Pass 1's stale-sweep or
Pass 2's top-up work surfaces a real registry data gap, name it in the digest for the dedicated
registry automation to pick up — do not file issues or PRs against `registry/` from this pipeline.

**This boundary is about not _authoring_ registry content or filing new registry-data issues from
this pipeline — it is not license to skip normal issue-state hygiene for an existing issue whose
deliverable happens to touch `registry/subnets/<slug>.json`.** The "MCP execute: verify + wire SN*"
family (see the dedicated subsection under Pass 1 below) is exactly this case: those ~120 issues were
filed by a different process (the MCP-execute epic, #7013/#7014), not by this pipeline, and Pass 1's
stale-sweep still applies to them like any other issue — read-only verification of whether a closing
PR actually delivered, not authorship. Don't treat this family as untouchable just because its
deliverable is a registry file edit.

metagraphed is a Bittensor subnet registry / block-explorer product. Unlike gittensory/loopover,
**a linked issue is optional here** — the gate judges a PR on its own merit when nothing is linked,
it only auto-closes for a missing link if a linked issue was claimed and doesn't hold up (see
`.claude/skills/metagraphed/SKILL.md`). So the existential pressure to keep a full pipeline is lower
than in gittensory, but it's still the main way to (a) direct contributor effort at what actually
matters instead of ad-hoc surface PRs, and (b) hand out `gittensor:*` points fairly. Do both passes
below; treat the top-up target as "keep good, well-directed work available," not "prevent PRs from
being rejected."

## Pass 1 — stale-issue sweep (do this first, every run)

Same method as gittensory's copy of this skill (see that repo's `reference.md` if you need the full
GraphQL walkthrough) — 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, ideally, a direct
grep confirming the described code/route/page exists); leave partial work open, optionally with a
scope-clarifying comment.

**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 here and in a
sibling repo's gardening run 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.

**metagraphed-specific things to check while doing this:**

- **2026-07-25: total open issues dropped to 28 (from ~94-142 historically), and Wave 1-4 all closed
  as milestones** — see `reference.md`'s milestone-taxonomy correction for the full picture. Milestone
  **#9 "Wave 3 — Frontend (post-consolidation)"** went from 11 open (2026-07-15) to 0 open / milestone
  itself CLOSED (2026-07-25) in the space of 10 days — this repo's milestones can drain completely
  between runs just as easily as they can fill back up. Re-verify every run via
  `gh api graphql milestones(states:[OPEN,CLOSED])`, never trust a cached count here.
- **Unmilestoned-issue count**: 7 of 28 open issues as of 2026-07-25 (#507 Dependency Dashboard, plus
  6 standalone maintainer explorations/design-spikes: #6646, #6971, #7002, #7003, #7007, #8133) — the
  Enrich-SNxx family currently has **zero open issues** (its own separate automation's queue is
  temporarily empty, not evidence of a hygiene gap). Re-verify fresh each run; if genuine orphans turn
  up (a real code/schema/data issue with no milestone, not Enrich-SNxx or the Dependency Dashboard),
  fold them into the closest fit (`Foundations & Infra`, `Partner Flywheel Hardening`) same as before.
- The **native-staking feature work** (epic #5229, "take/commission management," "move/re-delegate
  stake flow," "risk disclosure copy") **fully closed as of 2026-07-25** — no open low-5200s
  native-staking issues remain. If new native-staking work reopens (a v2/follow-on epic), treat
  anything touching real stake movement, phishing surface, or a pre-launch security review as
  `maintainer-only` by default; don't second-guess that boundary.

### MCP execute "verify + wire SN*" family — special stale-sweep rule (added 2026-07-21)

~120 issues, titled "MCP execute: verify + wire SN\<n\> (\<name\>) once Phase 1 ships", one per
subnet, tracked under the epic at #7013/#7014 (issue numbers #7017-#7136). They ask a contributor to
verify a subnet's registered surfaces work via the `call_subnet_surface` MCP tool (Phase 1, shipped)
and add whatever's missing to `registry/subnets/<slug>.json`. Treat this family as an exception to
the general "don't touch registry-adjacent issues" instinct — see the Scope boundary section above
for why Pass 1's normal read-only verification still applies here.

**The completeness bar is full subnet API parity, not just what the issue's original checklist
named.** A 2026-07-21 audit of all 120 subnets found that most subnets expose real API surface the
original issue never listed — the registry is meant to catalog _everything_ a subnet's real API
exposes, not just what's currently callable by the anonymous Phase-1 tool. This explicitly includes:
fixed no-auth endpoints (register with `probe.enabled:true`), query-param-only endpoints (register
with the fixed base URL, `probe.enabled:false` — already callable today via the tool's `query` arg),
path-param endpoints (register with the literal `{param}` template, `probe.enabled:false` — needs
Phase 2, not built yet), and **auth-gated endpoints** (register anyway, with `auth_required:true`,
`probe.enabled:false` — needs Phase 3, not built yet, but the registry should still document them for
future Phase 3 and for maintainers/developers who bring their own credentials). Do not treat "not
currently callable by Phase 1" as a reason to leave something unregistered. If an issue body has a
`## Additional surface(s) found during review` section (added during the 2026-07-21 audit pass),
that content is just as much the deliverable as the issue's original `## Surface(s) to verify (N)`
list — check both when deciding whether the issue is actually satisfied.

**Known anti-pattern — confirmed live 2026-07-21, check for it every time:** many contributor PRs
against this family add _only_ a `tests/*.test.mjs` file, with zero changes to
`registry/subnets/*.json`, and the merge gate has been auto-merging them and closing the issue anyway
— even against issues carrying an explicit, itemized list of missing surfaces. A passing verification
test is not the deliverable; the registry file entry is. When Pass 1 finds one of these issues closed
via a merged PR, **do not accept "a PR merged and referenced this issue" as sufficient on its own** —
pull the PR's changed-files list (`gh pr view <n> --json files`) and confirm it actually touches
`registry/subnets/<slug>.json` with a real diff. If the merging PR only added a test file (or any
other non-registry file) and the issue's surfaces genuinely aren't in the registry, reopen it:

```
gh issue reopen <n> --repo JSONbored/metagraphed --comment "Reopening — the PR that just closed this (test-only, no \`registry/subnets/*.json\` changes) did not add any of the surfaces this issue asks for, including the gap findings documented in the **\"Additional surface(s) found during review\"** section above. A verification test alone doesn't satisfy this issue — the registry file itself needs the actual surface entries added. Please open a new PR that adds the missing surfaces (not just a test)."
```

This is read-only issue-state hygiene (checking a PR's file list, reopening if it didn't deliver) —
it is not "registry enrichment" in the sense the Scope boundary above forbids. Don't author registry
content yourself or open a PR against `registry/` from this pipeline; just don't let a closed-but-
undelivered issue sit unflagged.

## Pass 2 — backlog top-up

1. Compute this repo's own contributor-available count (unassigned, no `maintainer-only`, carries a
   `gittensor:*` label) before deciding how much to generate here — the target is **50-100+ open
   contributor-available issues, independently per repo, maintained AT ALL TIMES** (reinforced by the
   maintainer 2026-07-15 — this is a steady-state floor to keep continuously, not a one-time catch-up;
   the scheduled task's cadence was raised from daily to every 8h the same day specifically so this
   gets re-checked well within a day). This is NOT a combined/shared pool with gittensory/loopover;
   each repo is judged on its own backlog and must clear the bar on its own merits, focused on that
   repo's actual goals (corrected by the maintainer 2026-07-14 — an earlier version of this doc wrongly
   said "combined total, not per-repo"). **Exclude the "Enrich SNxxx" family (see below) from this
   count** — it's a separately-automated queue, not this skill's backlog. **Don't just aim for the
   floor (50) — push toward the top of the range (closer to 100) whenever real, non-padded gaps are
   still findable** (reinforced by the maintainer 2026-07-15: more well-scoped available issues is
   straightforwardly good for the project, since it's more real work contributors can pick up). If the
   count is under ~100, keep sourcing issues until it's close to 100 (or a pass genuinely turns up no
   more real, non-duplicate gaps) — don't stop at a modest first batch just because "quality over
   volume" (point 7 below) was satisfied, and don't declare victory the moment 50 is cleared.
   1a. **The "Enrich SN<netuid> ..." family (tracked via #427, ~20-30 issues at any time) is handled by
   a separate automation, not this skill.** Don't count them toward the 50-100 top-up target (filter
   out any issue whose title matches "Enrich SN" before comparing against the target), and don't
   generate more of them yourselves — that automation owns that queue. Pass 1's stale-sweep/hygiene
   work (closing genuinely-done ones, fixing stale checkboxes) still applies to them like any other
   issue; the exclusion is specifically about Pass 2's top-up math (confirmed by the maintainer
   2026-07-14).
2. This repo's contributor-availability query needs `gittensor:priority` counted alongside
   `gittensor:feature`/`gittensor:bug` — unlike gittensory, metagraphed frequently uses
   `gittensor:priority` as a **standalone** points label (54 of 59 `gittensor:priority` issues here
   carry no `gittensor:feature`/`gittensor:bug` pairing, as of 2026-07-14). Don't "fix" this to match
   gittensory's scarcer convention unless asked — it's this repo's own established norm.
3. **The "Docs page: <endpoint>" family is fully resolved as of 2026-07-19 — don't look here anymore.**
   #6225 (the fumadocs-mdx port issue) closed as superseded 2026-07-16: the docs pipeline shipped via
   a native `fumadocs-mdx` + `fumadocs-ui` + `fumadocs-openapi` integration (not Scalar as originally
   proposed), and all 10 paused issues (#3504-#3511, #3514, #3516) plus #3512/#3513/#3515 are written
   and closed. This bullet previously pointed here as a top-up source; it no longer applies — source
   Pass 2 issues elsewhere.
4. **Every new issue gets a real milestone — no issue ships unmilestoned.** A `gittensor:bug`/
   `gittensor:feature`/`gittensor:priority` label (this repo's own convention — priority isn't scarce
   here the way it is in gittensory, but still means "the maintainer actually wants this soon," don't
   apply it reflexively to everything), and `help wanted` (paired convention here too). Do NOT apply
   `good first issue` — it isn't a real convention in this repo (the label doesn't exist here,
   confirmed 2026-07-14) and the maintainer doesn't want it introduced. Only `gittensor:*` +
   `help wanted` matter for contributor-available issues.
5. Full body template — Context, Requirements, Deliverables, Expected Outcome, Links & Resources (see
   `reference.md`). Registry/surface-data contributions have their own distinct shape (one file per
   subnet, `registry/subnets/<slug>.json`) — don't template a data-contribution issue the same as a
   code/schema issue; see the `metagraphed` skill's own reference.md for the surface model if
   generating that kind of issue.
6. **Check every new batch for a real dependency, then link it with GitHub's native
   `addSubIssue`/`addBlockedBy` mutations** (confirmed available on this repo, same as gittensory) —
   never a markdown checklist. This is a required check, not optional: most batches of independent
   bug-fixes or REST/GraphQL/MCP-parity additions genuinely have no dependency on each other, and the
   correct outcome of the check is then "no links needed" — don't force one just to look thorough.
   Reserve the links for a real case where working out of order would waste a contributor's time.
7. Quality over the number in what gets filed — don't pad with weak/duplicate/vague issues. This is
   not license to stop early: see point 1's "if under floor" note.

**Every new issue must clear the full-scope completeness bar in `reference.md`** (reinforced by the
maintainer, 2026-07-25): concrete/testable Requirements, a Deliverables checklist that explicitly ships
together in one PR (not partial credit for a subset), and a falsifiable Expected Outcome. Contributors'
AI-harness agents read only the issue text and default to the least-effort interpretation that could
plausibly close the checklist — an issue that leaves any of that ambiguous gets exactly that outcome.
This is required on every issue this pass files, not just the ones with an existing precedent to name.

## Pass 3 — Strategic epic/milestone health (once-per-day cadence)

Beyond Pass 1/2's issue-level hygiene, this skill also runs a lighter, once-per-day strategic pass
over active epics/roadmap issues — a `roadmap` label, "Epic:" in the title, or any issue with a
`- [ ]`/`- [x]` child-issue checklist or native GitHub sub-issues. The scheduling automation gates
this to at most once per day independent of how often the outer job itself fires (an external cadence
tracker in the scheduling layer handles that gate — not part of this file).

**When it runs:**

1. Verify every active epic's claimed children are actually filed and in the right state — same
   GraphQL cross-reference method as Pass 1, not text search. Surface now-unblocked follow-on work
   when a previously-blocking issue closes.
2. **Source real forward-looking work, not just verify.** Read each active epic/milestone's own
   stated scope, the current shipped surface (`registry/`, `workers/`, `apps/ui`), and repo docs to
   find concrete, buildable feature or milestone-scoped work that hasn't been filed yet — grounded in
   the product as it exists and the milestone's documented direction, not speculative ideas untethered
   from evidence.
3. **Pass 3 shares Pass 2's own 50-100+ (push toward 100+) contributor-available target — one
   combined per-run volume goal, not a separate small quota** (revised 2026-07-17; an earlier version
   of this pass capped itself at "0-2 issues/day, zero is fine," which under-delivered). If Pass 2's
   own top-up already reached the target, Pass 3 doesn't need to force more just to hit a number; if
   the count is still under-target after Pass 2, Pass 3 should actively help close the gap with real
   feature/milestone issues instead of sitting in verify-only mode. Quality still matters — don't pad
   with weak/duplicate/vague issues — but that's not license to under-deliver: a pass that can't find
   enough real work should say so explicitly in the digest (what was tried, why nothing else was
   fileable), not quietly file 1-2 and call it done.
4. Respect the same "what's safe to unleash" boundary as Pass 2 (native-staking/real-money work stays
   `maintainer-only` by default — don't second-guess it).
5. **Anything that's genuinely business/monetization/competitive-strategy thinking (pricing,
   positioning, hosted-product business strategy) stays out of public issues entirely** — flag it in
   the digest for the maintainer's private roadmap instead of filing it here. This repo's issue
   tracker is contributor-facing; vague vision issues aren't actionable by a contributor anyway.
6. Link every new issue as a native sub-issue of its parent epic via `addSubIssue` where a real parent
   exists; give it a real milestone, same discipline as Pass 2.
7. Same full-scope completeness bar as Pass 2 (see above and `reference.md`) — no exceptions for
   epic-sourced issues.

## Daily digest

Same shape as gittensory's: issues closed + why, milestones/checklists fixed, new issues filed with
milestone/label (Pass 2 and Pass 3 combined), before/after contributor-available count, whether Pass 3
ran this cycle, anything left alone on purpose.