Table of Contents generated with DocToc

• Modes — MISSION taxonomy mapped to current skills
  • Status legend
  • Modes at a glance
  • Triage
  • Mentoring
  • Drafting
  • Pairing
  • Auto-merge
  • Outside the modes
  • Mode lifecycle
  • Cross-references

Modes — MISSION taxonomy mapped to current skills

MISSION.md frames the framework around five toggleable modes of agent-assisted repository maintainership and development: Triage, Mentoring, Drafting (agent-authored fixes with human review), Pairing (developer-side dev-cycle skills with mentorship intrinsic), and Auto-merge (narrowly-scoped fix-and-merge). Each adopting project picks the modes that match its culture and risk tolerance.

This document maps that taxonomy to the skills that currently ship in the framework. It is the honest snapshot — modes that are not yet implemented are listed as such, with a tracking issue or roadmap pointer rather than a placeholder shell. Read MISSION.md for the why of each mode and the sequencing commitments behind them.

Status legend

Modes at a glance

A few skills sit outside the mode taxonomy by design — see Outside the modes below.

Triage

Inbound report and PR triage. The lowest-risk surface and the foundation everything else builds on. Skills propose labels, spot duplicates, link related discussions, classify reports against prior triaged cases, and route to the right human; they do not act without human review.

Two notes on the boundaries:

• pr-management-code-review is a deeper variant of triage — the agent reads diff and surrounding code rather than only metadata, but the output is still a suggestion for the human reviewer. It belongs to Triage by the same rule.
• security-cve-allocate is procedural rather than classificatory (CVE allocation happens after assessment), but it shares Triage’s shape: the agent prepares a paste-ready artefact, the human PMC member submits it. Listed here for navigability.

Mentoring

Status: experimental. First prototype skill shipped.

MISSION.md § Mentoring names this the highest-value project-side mode and the one off-the-shelf agent tooling skips. The spec — tone guide, hand-off protocol, adopter contract — landed ahead of the skill code so the project’s tone choices were reviewable independently from the runtime behaviour.

The prototype ships flagged mode: Mentoring + experimental. Shape may change as adopter pilots and contributor-sentiment evaluation land. The skill is read-only by default and never posts without explicit maintainer confirmation — see pr-management-mentor/SKILL.md for the full contract.

The closest existing surface is pr-management-triage/comment-templates.md, which carries Triage classification responses — informational, not pedagogical. It is not Mentoring.

Drafting

The agent drafts a fix for a well-scoped problem (a tracked issue, a triaged security report with team consensus on scope, a failing test with an obvious cause, a documentation hole) and opens a PR. Every PR is reviewed and merged by a human committer; the agent never merges its own work.

Generic Drafting is proposed. MISSION.md names lint fixes, audit-tool findings (Apache Verum, Apache Caer, CodeQL, equivalents), failing tests with obvious causes, and documentation holes as in-scope for Drafting beyond the security case. None of those are implemented yet; security-issue-fix is the only Drafting skill in the framework today.

For security-class Drafting PRs, the public surface strips CVE and private context per the project’s disclosure policy, so the public surface stays clean until the embargo lifts — see AGENTS.md § Confidentiality for the rules the skill enforces.

Pairing

Status: experimental. 1 skill.

MISSION.md § Pairing introduces this mode as the developer-side counterpart to the project-side modes. Where Triage / Mentoring / Drafting / Auto-merge describe the agent’s presence on the project’s own infrastructure, Pairing skills run in the maintainer’s or contributor’s own dev loop — multi-agent review pipelines, self-review and pre-flight patterns, scoped fix drafting under the developer’s driver’s seat. Mentorship is intrinsic to Pairing skills: the agent handles the mechanical, implementation-detail review (formatting, conventions, lint-grade nits) so the human conversation between contributor and maintainer — and between peer maintainers — stays on design, reasoning, and the trade-offs the project cares about. Pairing skills are the platform’s mechanism for protecting the ASF contribution path (contributor → committer → PMC) against being eroded by automation that replaces, rather than augments, the human-to-human relationships that path is built on.

Pairing skills don’t make state changes on behalf of the project; they share the same skill format and security posture as the project-side modes, so a maintainer who already trusts the framework for Triage gets the same posture for the patches they write themselves.

A multi-agent review pipeline (fans the diff through independent review passes) is the planned follow-on Pairing skill; it shares the self-review report format and follows this one.

Sequencing. Pairing ships before Auto-merge in the project’s automation roadmap — full auto-merge of maintainer-driven changes follows only after Pairing has established that human reasoning and relationships, not implementation chatter, are the load-bearing parts of the workflow.

Auto-merge

Status: off. Deliberately not implemented.

MISSION.md § Auto-merge holds auto-merge off until Triage, Mentoring, Drafting, and Pairing have been running for two quarters and contributor-sentiment data says the project is healthier, not just faster. Security-class changes are explicitly out of Auto-merge — no auto-merge ever touches anything embargoed or CVE-tagged.

The framework’s current .asf.yaml configuration reflects this posture: pull_requests.allow_auto_merge is set to false (.asf.yaml).

When Auto-merge ships, the eligible change classes will be declared per-adopter in <project-config>/ and gated by an allow-list that the framework refuses to grow without an adopter PR.

Outside the modes

Several skills are framework infrastructure rather than maintainership modes. They support adoption, isolation, and upgrade flows; they do not act on issues, PRs, or contributor threads on their own.

These ship as a single setup family — see docs/setup/README.md.

Mode lifecycle

A mode moves through four states as it matures:

1. proposed — designed in MISSION.md, no skill code yet. Spec PRs may land before any skill code so tone, scope, and adopter knobs are reviewable in isolation.
2. experimental — at least one skill exists, behaviour may change, no adopter pilot has run an evaluation. Adopters can opt-in but should expect breaking changes between framework versions.
3. stable — at least one adopter is running the mode in production, behaviour is backward-compatible across minor framework versions. The default state for skills shipped to adopters.
4. graduated-to-Auto-merge-eligible (future state; Triage, Mentoring, Drafting, and Pairing only) — the mode has run stable for two quarters with positive contributor-sentiment evidence, the framework will start considering an equivalent change class for Auto-merge. This state does not exist yet because Auto-merge itself is off.

A mode can be retracted from any state. The retraction triggers MISSION names — sustained negative contributor sentiment, a confidentiality leak, a sandbox bypass that escapes detection — apply per-adopter and per-mode. A retraction in one adopter does not auto-retract in another, but the framework records it for cross-adopter pattern detection.

Cross-references

• MISSION.md — the why of each mode, the sequencing commitments, and the privacy/security/vendor- neutrality posture each mode inherits.
• README.md — adopter-facing skill family table; this document is the maintainer-facing taxonomy view of the same skills.
• AGENTS.md — repository-level rules every mode inherits (external content as data, polite-but-firm tone, brevity, confidentiality).
• docs/mode-economics.md — indicative token-cost shape per mode and model class; for maintainers evaluating adoption.