feat(selfhost): let a review skill opt out via enabled: false frontmatter

[ultrahighsuper]

Summary

Self-host operators configure per-repo review rubrics as review/skills/*.md files (read by makeLocalReviewContextReader and rendered into the reviewer's context). Today the only way to stop a skill from applying is to delete the file or hand-edit its when: glob.

This adds a small, opt-in enabled: frontmatter directive so an operator can turn a rubric off without deleting it — useful while iterating on a rubric, or parking one temporarily:

---
name: SQL rubric
enabled: false
---
…rubric body…

• New pure helper isReviewSkillEnabled(text): returns true unless the frontmatter sets a non-truthy enabled (false/no/off/0), matching the codebase's existing truthy-flag convention (/^(1|true|yes|on)$/i).
• makeLocalReviewContextReader skips disabled skills so they never enter the review context.

Fully backward-compatible: a skill with no enabled key — i.e. every existing skill — stays enabled, so behavior is byte-identical unless the directive is explicitly set. No new env flag is needed because the feature is self-gating per skill file.

No linked issue: small, additive, backward-compatible operator convenience scoped to the self-host review-skill reader; per this repo's linkedIssuePolicy: preferred, a direct PR with this rationale is appropriate.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run typecheck
• npm run test:coverage locally; the private-config suite (22 tests) passes. New tests cover isReviewSkillEnabled (default-enabled, quoted truthy, and false/no/0 disabling) and the reader omitting an enabled: false skill while keeping the active one. Both branches of every changed line are covered (verified via lcov BRDA); the existing skill-reader and parseReviewSkill tests are unchanged and still pass.
• New behavior has unit + reader-level tests

If any required check was skipped, explain why:

• Additive change to a pure helper + the self-host reader in src/selfhost; it changes no API schema, wrangler binding, migration, or UI, so OpenAPI/cf-typegen/migration regeneration is not applicable.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics. (Review skills are private self-host config; nothing new is surfaced publicly.)
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no such changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (Internal review-context assembly only; no schema change.)
• No visible UI change in this PR.

Notes

• Default-on: isReviewSkillEnabled("---\nname: x\n---\nbody") and isReviewSkillEnabled("no frontmatter") both return true; only an explicit non-truthy enabled disables. So repos with no enabled: directive get identical review context to before.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-03 02:40:13 UTC}

2 files · 1 AI reviewer · no blockers · readiness 80/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
The change adds an `enabled` frontmatter check before parsing local self-host review skills, preserving default behavior for files without the directive and adding focused tests for the helper and reader integration. The post-change wiring is coherent: disabled skill files are skipped before `parseReviewSkill`, while active skills still use the existing sorted file traversal. I do not see a reachable correctness break in the provided diff.

Nits — 4 non-blocking

• nit: src/selfhost/private-config.ts:122 duplicates the frontmatter extraction pattern used by `parseReviewSkill`, so a future tweak to supported frontmatter syntax can drift between parsing and enabled filtering.
• nit: src/selfhost/private-config.ts:125 treats `enabled:` with an empty value as enabled because `(.+)` does not match, which is worth making explicit in tests or changing if the intended rule is that any non-truthy value disables the skill.
• src/selfhost/private-config.ts:110 factor the shared frontmatter extraction into a tiny helper used by both `parseReviewSkill` and `isReviewSkillEnabled` to keep the reader's syntax rules in one place.
• test/unit/private-config.test.ts:127 add a case for `enabled:` with no scalar so the chosen behavior is locked down rather than accidental.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (size label size:S; no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 41 registered-repo PR(s), 25 merged, 5 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	ultrahighsuper; Gittensor profile; 41 PR(s), 5 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: ultrahighsuper
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 41 PR(s), 5 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.10%. Comparing base (066398e) to head (8d41273).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2590   +/-   ##
=======================================
  Coverage   96.10%   96.10%           
=======================================
  Files         237      237           
  Lines       26540    26545    +5     
  Branches     9625     9628    +3     
=======================================
+ Hits        25507    25512    +5     
  Misses        424      424           
  Partials      609      609           

Files with missing lines	Coverage Δ
src/selfhost/private-config.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.