[Feat]: Maintainer-assigned skill grades (S/A/B) for bundled registry skills

[rosspeili]

Feature Description

Context: #234 closed — bundled skills are executable-only; trust and quality labels are registry-verified, not self-declared in manifest.yaml.

Problem

Contributors and operators have no single, consistent signal for how strong a bundled skill is beyond “it merged.” Today, quality is implied by maintainer review and scattered CI checks (test_skill_issuer, bundle tests, doc-drift guards), but nothing surfaces a maintainer-assigned grade in the CLI, docs, or site.

Goal (future — low priority)

Introduce ARPA-assigned skill grades (e.g. S / A / B) for bundled registry skills — assigned and updated by maintainers at review time, not written by contributors in their manifest.

Grades reflect maintainer judgment on maturity, test depth, docs/examples coverage, production readiness, and similar — separate from structural CI gates (which remain the merge source of truth).

---

What grades are (and are not)

Grades are	Grades are not
Registry-maintainer metadata (like a review stamp)	Self-declared grade: S in manifest.yaml
Operator-facing signal on bundled skills	Trust/isolation or sandbox level
Optional display in skillware list, catalog, skillware.site	A replacement for human PR review
Updatable when a skill improves	A score contributors can game locally

Self-declared vs verified (from #234): issuers must not assert their own grade. Storage is registry-side (maintainer file, release metadata, or internal index — TBD in implementation PR).

---

Scope

In scope (when implemented)

• Maintainer workflow to assign/change grade for bundled skills (process + storage TBD)
• Display grade in operator-facing surfaces (skillware list, catalog pages, site — pick one to start)
• Document grading criteria (what S vs A vs B means)

Deferred / low priority

• Automated 0–100% “compliance score” — optional future helper aggregating existing pytest checks; not required for grades. Existing CI gates stay authoritative for merge.
• Merge blocking on grade — never by default
• Project / external skills — no grades; operator responsibility
• Soft / instruction-only skills — N/A (not in bundled model)

---

Possible grade criteria (draft — refine before implementation)

Example maintainer rubric (not automated v1):

Grade	Rough meaning
S	Reference skill — strong tests, docs, examples, stable API, low surprise factor
A	Production-ready bundled skill — complete bundle, good coverage, maintained
B	Acceptable / newer / narrower — ships in wheel, meets CI, room to improve

Exact definitions to be agreed in CONTRIBUTING or a short grading doc before first assignments.

---

Implementation ideas (when prioritized)

Options to pick in a future PR:

1. Registry-side YAML/JSON under maintainer control (e.g. .registry/grades.yaml or per-skill sidecar) — not in contributor manifest
2. CLI — skillware list adds optional Grade column; skillware list --grade A filter
3. Catalog / site — badge on skill pages
4. Process — PR template field for maintainer-only grade assignment on merge

Optional later: skillware score / script that runs structural checks only (manifest, issuer, test_skill.py, docs index) — informational for contributors; does not set S/A/B automatically unless maintainers explicitly wire weights (unlikely v1).

---

Relationship

Issue	Role
#234	Closed — grades are registry-verified, not manifest identity
#125	Param validation — unrelated; CI gate
#236	Extras/install — unrelated
tests/test_skill_issuer.py, tests/test_registry_docs.py	Existing structural gates; not replaced by grades

---

Acceptance (when implemented)

• Grading criteria documented (what S / A / B mean)
• Grades stored registry-side; contributors cannot self-assign in manifest
• At least one operator surface shows grade (CLI and/or catalog)
• Existing CI merge gates unchanged
• Low priority — no target release until maintainers explicitly schedule

---

Rationale

A simple maintainer grade gives operators a quick quality signal without reopening #234 identity fields or soft/hard taxonomy. Automation can stay in CI; grades capture judgment CI cannot (maturity, ergonomics, “would I bet production on this?”).

Status: Open, deferred / low priority — design holder until we want list/site badges.