diff --git a/.claude/skills/contributor-pipeline-gardening/SKILL.md b/.claude/skills/contributor-pipeline-gardening/SKILL.md index 3d8a22b726..8781ab5503 100644 --- a/.claude/skills/contributor-pipeline-gardening/SKILL.md +++ b/.claude/skills/contributor-pipeline-gardening/SKILL.md @@ -67,7 +67,7 @@ work. Confirm sync every run; never assume a previous run's freshness carried ov - Genuine gaps found by reading the current codebase against a shipped feature's own stated acceptance criteria (the same technique Pass 1 uses to verify closure — used here in reverse, to find what's NOT yet done). - AMS selfhost hardening is a named standing priority — see `reference.md`. The unified AMS+ORB selfhost harness is now scoped and issue-backed (#5996, epic #6012) as of 2026-07-15 — check its sub-issues' completion state before assuming this still needs fresh scoping. 3. **Every new issue gets a real milestone — no issue ships unmilestoned.** Default to the correct existing milestone (see `reference.md`'s milestone taxonomy). Creating a new one requires a genuinely-unfitting body of work AND is a much higher bar than it sounds — see `reference.md`'s milestone-discipline note; when in doubt, fold into the closest existing bucket and say so. A new milestone is justified when nothing existing fits AND the work is either a real major initiative or a recurring category that will keep needing a home (e.g. `Miner Wave 4.5 — AMS Hardening Round 2`, created 2026-07-15 for the recurring post-Wave-4 gap-audit rounds this skill files each run) — a one-off oddity alone isn't enough. Also apply a `gittensor:bug` (0.05x), `gittensor:feature` (0.25x), or `gittensor:priority` (1.5x, reserved for mission-critical/time-sensitive work only — this repo uses it sparingly, unlike metagraphed's looser convention, see `reference.md`) label, plus `help wanted` (the maintainer confirmed this stays as a visibility signal alongside the points label, not a replacement for one). -4. Every new issue body follows the template in `reference.md` — Context, Requirements, Deliverables, Test Coverage Requirements (this repo's Codecov patch gate is 99%+, hard — every new issue implicitly inherits this unless it's `apps/**`-only UI work), Expected Outcome. No "left to interpretation" scope — the maintainer's own stated preference is that thin/ambiguous issue bodies are worse than fewer, complete ones. **The review gate only enforces what the issue text explicitly says** — see `reference.md`'s dedicated section on this; any deliverable with a file-type/path/format constraint (docs as website pages vs. markdown, native relationships vs. checklists, etc.) needs that constraint stated as an explicit, standalone rule, not left implied by Context. +4. Every new issue body follows the template in `reference.md` — a leading `> ⚠️ Definition of Done` callout, then Context, Requirements, Deliverables, Test Coverage Requirements (this repo's Codecov patch gate is 99%+, hard — every new issue implicitly inherits this unless it's `apps/**`-only UI work), Expected Outcome. No "left to interpretation" scope — the maintainer's own stated preference is that thin/ambiguous issue bodies are worse than fewer, complete ones. **The review gate only enforces what the issue text explicitly says** — see `reference.md`'s dedicated section on this; any deliverable with a file-type/path/format constraint (docs as website pages vs. markdown, native relationships vs. checklists, etc.) needs that constraint stated as an explicit, standalone rule, not left implied by Context. **Assume contributors run their own AI agents against the issue looking for the fastest way to close it** — see `reference.md`'s "Completion standard: no partial credit, no shortcuts" section: every Deliverable must be mechanically verifiable, scope-splitting/deferral must be explicitly forbidden unless the issue is deliberately narrow, and no requirement gets soft/optional phrasing. 5. **Check every new batch for real relationships, then link them with GitHub's native features, not prose or a checklist:** `addSubIssue` to attach a new issue under its parent epic, `addBlockedBy` when an issue genuinely cannot start before another lands. The check itself is the discipline — most independent bug-fix/feature-parity issues (e.g. a batch of REST/GraphQL-mirror additions) genuinely have no dependency on each other, and forcing a link where none exists is worse than no link. Only connect issues where a contributor would actually be blocked or misled by working them out of order. 6. Quality over the number in what gets filed — don't pad with weak, duplicate, or vaguely-scoped issues just to hit a count. This is NOT license to stop early: if the repo is meaningfully under the 50-100 floor, keep sourcing real, well-scoped issues (see the "if under floor" note above) until it clears or a pass genuinely turns up nothing left to scope — only then note a shortfall in the digest. diff --git a/.claude/skills/contributor-pipeline-gardening/reference.md b/.claude/skills/contributor-pipeline-gardening/reference.md index 0cedb9e93d..68f7d3c16c 100644 --- a/.claude/skills/contributor-pipeline-gardening/reference.md +++ b/.claude/skills/contributor-pipeline-gardening/reference.md @@ -232,6 +232,51 @@ Every contributor-facing issue's _entire_ body — not just its labels — has t consistent and unambiguous, checked by rereading the finished body end-to-end before publishing, not assumed correct because the individual edits each seemed right in isolation. +## Completion standard: no partial credit, no shortcuts — write for the laziest passing path + +**The maintainer's own words (2026-07-24):** "contributors will throw their AI tools at this for the +least path of resistance and submit the shittiest / lowest quality stuff possible to get it completed +as fast as possible unless we are extremely explicit on exactly what we expect — I expect the entire +issue done flawlessly start to finish, not broken up into smaller pieces and nothing skipped." + +Assume every contributor-facing issue is picked up by an AI coding agent optimizing to close the loop +fast, not a careful human reading for nuance. That agent will take whichever interpretation lets it +stop soonest: implementing one Deliverable and calling the rest "follow-up work," splitting an issue +across two PRs, stubbing a test instead of writing the real one, or doing the mechanical 80% and +skipping the hard 20% the issue didn't explicitly forbid skipping. This is the same failure mode "The +gate only enforces what the issue explicitly says" (above) already documents for file-type/pattern +ambiguity — this section extends it to **scope completeness**, not just shape. + +**Every gardening-generated contributor issue must therefore:** + +- Open with a leading `> ⚠️ Definition of Done` callout (see the updated template below) that states, + in words this explicit: _"This issue must be completed in full, in a single PR. Do not split this + work across multiple PRs. Do not defer any Deliverable below to a follow-up issue. A PR that + satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox + partially-done does NOT resolve this issue and will be closed."_ +- Make every Deliverable checkbox **mechanically verifiable**, not a vague artifact description a + shortcut could plausibly satisfy. Prefer "function `X` in `path/to/file.ts` returns `null` (not + `undefined`) when ``, verified by a new test at `path/to/file.test.ts` asserting exactly + that" over "fix the null-handling bug." If a requirement can be satisfied 80% of the way and still + look done to a fast skim, rewrite it until it can't. +- Never use soft/optional language for anything actually required — no "as time permits," "where + feasible," "ideally," "at least one of," or "consider also." Every Requirements/Deliverables bullet is + mandatory as written, or it doesn't belong in the issue at all (move it to Context as background, or + drop it). +- State explicitly, per issue, what an incomplete/shortcut submission looks like and that it does not + count — mirror the existing anti-pattern-naming convention used for file-type mistakes (see "The + gate only enforces what the issue explicitly says" above) but aimed at partial-completion, e.g. "a + PR that only adds the test coverage from Deliverable 1 without also fixing the underlying bug in + Deliverable 2 does not resolve this issue." +- When an issue has multiple Deliverables, say explicitly whether they're all required in one PR + (the default — always required unless you have an explicit, stated reason to scope narrower) or + whether the issue is intentionally narrow with a named follow-up issue for the rest. Never leave this + ambiguous by omission. + +This is a completion-standard check, not a new template section to skip past — reread every generated +issue body asking "could an AI agent do 60% of this, technically satisfy the literal words, and get a +PR through the gate?" If yes, tighten it before filing. + ## Labels - `gittensor:bug` — 0.05x multiplier. Bug fixes. @@ -252,19 +297,30 @@ assumed correct because the individual edits each seemed right in isolation. ## Issue body template (Wave-4-batch house style — use for new feature/bug work) ```md +> ⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this +> work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that +> satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox +> partially-done does NOT resolve this issue and will be closed. + ## Context ## Requirements - + ## Deliverables -- [ ] +- [ ] - [ ] + + ## Test Coverage Requirements ``` +See "Completion standard: no partial credit, no shortcuts" above for the full rationale and how to +phrase Deliverables so they can't be technically-satisfied by a fast, incomplete pass. + For pure architecture/design/spec issues (the kind that stay `maintainer-only`), use the lighter Problem/Area/Proposal/Deliverables/Resources/Boundaries shape instead — see any `AMS Cloud Readiness` issue (e.g. #5215-5230) for the exact pattern. Gardening-generated contributor issues should almost