feat: surface MISSION mode taxonomy in code, skills, and adopter-facing docs#61
Merged
Merged
Conversation
…ills MISSION.md frames the framework around Mode A/B/C/D, but the taxonomy is not surfaced anywhere in the code or adopter docs. Add a maintainer- facing reference that maps each mode to the skills currently shipping, with honest status per mode (stable / experimental / proposed / off): - Mode A (triage) — 10 skills across pr-management and security - Mode B (mentoring) — proposed, no skill yet - Mode C (agent-authored fixes with human review) — partial, security-only - Mode D (narrowly-scoped fix-and-merge) — off per MISSION sequencing Also documents skills that sit outside the mode taxonomy (the setup family is framework infrastructure) and the mode lifecycle states (proposed → experimental → stable → graduated-to-D-eligible) so adopters and reviewers can map MISSION's commitments to verifiable repo state. Generated-by: Claude Code (Opus 4.7)
Tag every skill that fits the MISSION mode taxonomy (see docs/modes.md)
with a `mode:` frontmatter field — Mode A for triage skills, Mode C for
agent-authored fix skills. Setup-family skills are infrastructure and
intentionally omit the field.
Extends `skill-validator` to recognise `mode` as an optional frontmatter
key and validate the value against `{A, B, C}`. Mode D is excluded
because MISSION holds it off; a `mode: D` value would be a sequencing
violation rather than a typo.
README skill-families table gains a `Modes` column linking each family to docs/modes.md (security: A+C, pr-management: A, setup: infra). Updates the .asf.yaml github.description from "security vulnerabilities" to the broader "agent-assisted maintainership" framing the MISSION proposes — security is one mode of one family, not the project's identity.
Member
|
Wowowwowo :) |
The MISSION proposal lists the four modes but did not point at the honest snapshot of which modes are actually shipping. Add a one-line forward reference to docs/modes.md inside § Technical scope so a reader can move from "what we promise" to "what currently exists" without leaving the document.
The "Modes at a glance" row for Mode C used `partial (security-only)`, which is not a value defined in the Status legend. The detailed Mode C section already states the one shipping skill (security-issue-fix) is stable while the generic Mode C is proposed; mirror that wording in the at-a-glance row so the doc uses only legend-defined terms.
Collaborator
Author
|
This one took me some time, but I think we're on the right track. Starting the next steps now. |
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MISSION.mdframes the framework around four toggleable modes of agent-assisted repository maintainership (A: triage, B: mentoring, C: agent-authored fixes with human review, D: narrowly-scoped auto-merge). The codebase did not yet reflect that taxonomy. This PR surfaces it in three layers, smallest blast radius first:docs/modes.md— honest snapshot mapping every shipped skill to a mode (or to outside the modes for the setup family) with astable / experimental / proposed / offstatus legend. Mode B is proposed (no skill yet), Mode D is off (deliberately not implemented perMISSION.md§ Mode D). Includes a mode lifecycle and explicit cross-references to MISSION, README, and AGENTS.mode:frontmatter on SKILL.md — every skill that fits a mode getsmode: Aormode: C. Setup-family skills are infrastructure and intentionally omit the field.tools/skill-validatoris extended to recognisemodeas an optional frontmatter key and validate the value against{A, B, C}(Mode D is excluded because shipping amode: Dskill would be a sequencing violation, not a typo). New unit tests cover both branches.Skill familiestable gains aModescolumn linking todocs/modes.md; the GitHub repo description widens from "security vulnerabilities" to "agent-assisted maintainership", since security is one mode of one family rather than the project's identity.Why this ordering
The three commits are independently reviewable but ship together because they are mutually load-bearing: the validator change is meaningless without
mode:in SKILL.md, the README column is meaningless withoutdocs/modes.mdto link to. Splitting them would force readers to context-switch across PRs to evaluate any single piece. They land as one PR with three commits so each layer remains greppable ingit log.Test plan
uv run --project tools/skill-validator pytest -k 'not test_real_repo_passes'— 33 passed (thetest_real_repo_passesintegration test fails onmainwith 191 pre-existing link-validation violations and is out of scope for this PR)prek run --files <changed-files>clean on every commitskill-validatereports zero new mode-related violations against the real repodocs/modes.md— these are MISSION interpretations and should match the PMC's read of the sequencing commitmentsOut of scope