<!-- SPDX-License-Identifier: Apache-2.0
     https://www.apache.org/licenses/LICENSE-2.0 -->

<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*

- [Prerequisites for running framework skills](#prerequisites-for-running-framework-skills)
  - [Prerequisites for running the agent skills](#prerequisites-for-running-the-agent-skills)
    - [1. An agentic tool + access to an LLM](#1-an-agentic-tool--access-to-an-llm)
    - [2. A mail backend (read + draft — Gmail is one option, not the only one)](#2-a-mail-backend-read--draft--gmail-is-one-option-not-the-only-one)
    - [3. A tracker + change-request backend (GitHub by default — not required)](#3-a-tracker--change-request-backend-github-by-default--not-required)
    - [4. PMC membership (only for CVE allocation)](#4-pmc-membership-only-for-cve-allocation)
    - [5. Browser (for the human-click steps)](#5-browser-for-the-human-click-steps)
    - [6. Local `<upstream>` clone (only for `security-issue-fix`)](#6-local-upstream-clone-only-for-security-issue-fix)
    - [7. `uv` (for `generate-cve-json`)](#7-uv-for-generate-cve-json)
    - [8. ASF project-metadata MCP (`apache-projects`)](#8-asf-project-metadata-mcp-apache-projects)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

<!-- SPDX-License-Identifier: Apache-2.0
     https://www.apache.org/licenses/LICENSE-2.0 -->

# Prerequisites for running framework skills

If you only plan to **comment on issues** from the project
board, skip this document — a browser and your tracker
collaborator access are enough. If you plan to **invoke any
framework skill**, check the following before running it.
Each skill also runs a short Step 0 pre-flight against this
list and stops with a clear message if something is missing.

## Prerequisites for running the agent skills

If you only plan to **comment on issues** from the board, skip this
section — a browser and your `<tracker>` collaborator access are
enough.

If you plan to **run any of the agent skills** (`import`, `sync`,
`security-cve-allocate`, `fix`, `generate-cve-json`, `deduplicate`) — typically
as a rotational triager, remediation developer, or release manager —
check the following setup **before** invoking a skill. Each skill also
runs a short Step 0 pre-flight against the same list and stops with a
clear message if something is missing, so you do not discover a
missing piece half-way through a workflow.

### 1. An agentic tool + access to an LLM

Running Magpie needs two things: an **agentic coding tool** that speaks
the `SKILL.md` / [`AGENTS.md`](https://agents.md/) skill convention, and
**access to an LLM** for that tool to drive. There is no hard dependency
on any single vendor for either — any agent that reads the shared
`.agents/skills/*/SKILL.md` files and follows their steps should work.

**Agentic tool — two are fully supported today:**

- **[OpenCode](https://opencode.ai/)** is the **reference implementation**:
  it is open source and model-agnostic, so it can drive *every* LLM-access
  option below.
- **[Claude Code](https://www.anthropic.com/claude-code)** is a second
  complete implementation, powered by Anthropic subscriptions — the paid
  plans, or the free tier Anthropic often grants to open-source
  maintainers.

Support for more runtimes (Codex, Gemini CLI, Cursor, Copilot, …) is
tracked in the
[open adapter issues](https://github.com/apache/magpie/issues?q=is%3Aissue%20is%3Aopen%20adapter).

**Access to an LLM — any one of these works:**

- a **paid LLM subscription** (e.g. Anthropic, for Claude Code);
- a **free subscription** — several providers grant free or discounted
  access to open-source maintainers;
- an **organisation-hosted LLM** — for example the planned
  [`llm.apache.org`](https://llm.apache.org) endpoint for ASF projects;
- an **open-weight model** — hosted on a provider of your choice, or run
  **locally** (Ollama, llama.cpp, vLLM) for sovereign or air-gapped use.

Because **OpenCode is model-agnostic it is the reference tool — it allows
all of the above**; Claude Code is the complete alternative for the
Anthropic-subscription paths. That is also the concrete answer to *"what
does an LLM or agent need to provide to be usable with Magpie?"*: an agent
on the `SKILL.md` / `AGENTS.md` convention, plus any one of the LLM-access
paths above.

The agent runs against pre-disclosure CVE content (private mail
threads, draft advisories, in-flight tracker discussions). Run it
with the credential-isolation setup documented in
[`docs/setup/secure-agent-setup.md`](setup/secure-agent-setup.md) — a layered
defence built around the agent's filesystem sandbox, tool-level
permission rules, and a harness-neutral clean-env wrapper
(`agent-iso.sh`, exposing both a `claude-iso` and an `opencode-iso`
launcher) that strips credential-shaped variables from the agent's
environment. The permission + sandbox posture is enforced for both
harnesses — a `PreToolUse` hook / `tool.execute.before` plugin
(`agent-guard`), plus `permission-audit` / `sandbox-lint` for the
Claude `settings.json` and OpenCode `opencode.json` policies. The
sandbox primitives (`bubblewrap`, `socat`) are pinned with a 7-day
upstream-release cooldown, mirroring the same convention the
framework uses for its `[tool.uv] exclude-newer` and Dependabot
configs. The agent CLI itself (`claude-code` / `opencode`) is
deliberately **not** pinned — it installs at `@latest` so it always
carries the newest permission-rule, sandbox, and prompt-injection
fixes; pinning the runtime to an older build would only increase
the security lag.

### 2. A mail backend (read + draft — Gmail is one option, not the only one)

The import, sync, and security-cve-allocate skills **read the security-list
mail thread** for each tracker and **draft replies** on it. Both sides are
vendor-neutral contracts — `contract:mail-source` / `contract:mail-archive`
for reads and `contract:mail-create` for drafts — so **Gmail is one
backend, not a requirement:**

- **Read** backends: the
  [Claude Gmail MCP](https://docs.anthropic.com/en/docs/build-with-claude/mcp)
  (a security-team member's Gmail subscribed to the list), the ASF
  **PonyMail** MCP (below), or a **local mbox / Maildir archive** for
  offline / forensic triage
  ([`tools/mail-source/mbox`](../tools/mail-source/mbox/README.md)).
- **Draft** backends: Gmail, or the offline local **Maildir** backend
  (below).

The ASF-default setup is described next; a project on a different mail
stack declares its own backends in
`<project-config>/project.md → Mail sources`.

There is now an official ASF alternative for the **read** side:
[`apache/comdev`'s `mcp/ponymail-mcp/`](https://github.com/apache/comdev/tree/main/mcp/ponymail-mcp)
(under the ComDev PMC; originally authored by Rich Bowen, former ASF
board director and ComDev lead, with supply-chain hardening and
private-list restrictions layered in upstream) supports ASF LDAP
OAuth and can read private ASF lists. Individual triagers can wire
it up to read inbound `security@<project>.apache.org` threads
without subscribing a personal Gmail account — see
[`tools/ponymail/tool.md`](../tools/ponymail/tool.md) for the
setup. (PonyMail MCP is read-only — it has no `create_draft`
equivalent — so it covers the archive **read** side only.)

On the **draft (reply)** side, Gmail is no longer the only option.
Alongside the Gmail backend, Magpie now ships a local
[**Maildir** draft backend](../tools/maildir/) (`contract:mail-create`,
vendor `Maildir`): it composes an editable RFC 5322 message into a
local Maildir with **no cloud account, no credentials and no
network**, and any Maildir-aware mail client (Thunderbird, mutt,
Evolution, …) picks it up to review, edit and send. So the reply
path no longer requires Gmail — Gmail stays the default where a
triager already reads the list there, and the offline Maildir
backend covers everyone else. Like every `contract:mail-create`
backend, both only ever create drafts; a human sends.

**For ASF projects the PonyMail MCP is a mandatory prerequisite,
not an opt-in backstop.** The reference adopter's manifest declares
`ponymail` with `mandatory: yes` (see
[`<project-config>/project.md → Mail sources`](<project-config>/project.md#mail-sources)),
so the mail-reading skills that run the Step 0 mail-source check
(`security-issue-import`, `security-issue-sync`) **refuse to start**
if it is not installed and reachable — the configured
`contract:mail-create` backend (Gmail by default, or the offline
Maildir backend) handles the drafts, but PonyMail must also be
present for the read side. (Skills that
only read a single Gmail thread opportunistically, such as
`security-cve-allocate`, do not hard-gate on it.) Install it from the **latest `main`** of `apache/comdev`
(the MCP servers ship as in-repo source with no tagged releases —
`main` is the only channel; see
[`tools/ponymail/tool.md → Keeping the checkout current`](../tools/ponymail/tool.md#keeping-the-checkout-current)).
A non-ASF adopter with no `lists.apache.org` archive sets that row
to `mandatory: no`.

**Without this connection:** `security-issue-import` cannot find new
reports, `security-issue-sync` cannot reconcile status with the mail
thread, and no skill can draft replies to reporters. The skills will
refuse to start and tell you to configure the MCP first.

### 3. A tracker + change-request backend (GitHub by default — not required)

Every skill reads and writes issues on the project's **tracker**, and the
`pr-management-*` skills drive its **change-request** (review + merge)
backend. Both are vendor-neutral contracts — `contract:tracker` (GitHub or
JIRA), `contract:change-request` (GitHub PRs, JIRA patches, or dev@
`[PATCH]` mail), `contract:source-control` (Git, GitHub, or SVN) — so
*which* connection you need depends on how the project is hosted, and
**`gh` is not a universal prerequisite:**

- **GitHub-hosted projects (the ASF default).** Authenticate the `gh` CLI
  (`gh auth status`) on the shell the agent runs in, with collaborator
  access (any level) on `<tracker>`. `security-issue-fix` additionally
  needs a fork of `<upstream>` on your GitHub account (it pushes a branch
  there, then opens the PR via `gh pr create --web`). Claude Code also
  ships a GitHub MCP; `gh` covers the rest and is what OpenCode uses.
- **JIRA / SVN-first projects.** No `gh` is required. The tracker is JIRA,
  review + merge run through `jira-patch` or `dev@` `[PATCH]` mail, and
  commits land via SVN — declare those backends in
  `<project-config>/project.md` and install their CLIs (`svn`, the JIRA
  connection) instead.

The security-team roster is maintained per-project; for the active project
see
[`<project-config>/release-trains.md`](<project-config>/release-trains.md#security-team-roster).

### 4. PMC membership (only for CVE allocation)

The adopting project's CVE-tool allocation form is **PMC-gated** on
the server side — only the project's PMC members can submit a CVE
allocation. Non-PMC triagers can still run `security-cve-allocate`; the
skill detects this up front (it asks *"are you a PMC member of
`<PROJECT>`?"*) and produces a relay message for a PMC member to
click through instead. The concrete tool + URL is declared in
[`<project-config>/project.md → CVE tooling`](<project-config>/project.md#cve-tooling).

The same PMC gate applies to ponymail URL lookups on private ASF
lists — only PMC members (via ASF LDAP) can see private-list
archives directly, whether through `ponymail-mcp`'s OAuth flow or
the `lists.apache.org` web UI.

### 5. Browser (for the human-click steps)

Several parts of the process involve a form a human has to fill in
and click — the CVE-tool allocation form, the CVE record `#source`
paste, the `gh pr create --web` compose view. The skills prepare
the URL and the exact text to paste and hand it off to the browser;
they do not try to automate those clicks.

### 6. Local `<upstream>` clone (only for `security-issue-fix`)

The fix skill writes the change in your local clone, runs local
checks and tests, pushes a branch to your fork, and opens a PR via
`gh pr create --web`. You need:

- a clean clone of `<upstream>` reachable from the agent's working
  directory — the path comes from `.apache-magpie-overrides/user.md →
  environment.upstream_clone`, set interactively the first time
  you run the skill;
- the adopting project's dev toolchain installed per
  [`<project-config>/fix-workflow.md → Toolchain`](<project-config>/fix-workflow.md#toolchain);
- a remote named for your GitHub fork that `gh pr create` can push
  to.

### 7. `uv` (for `generate-cve-json`)

The `generate-cve-json` script is a small `uv`-managed Python
project. Install `uv` once
(<https://github.com/astral-sh/uv>); the script bootstraps the
rest.

### 8. ASF project-metadata MCP (`apache-projects`)

The skills that reason about **rosters, people, and release
history** — `contributor-nomination` (Apache ID verification,
vendor-neutrality / employer context), the roster-resolution paths
in `security-issue-sync` / `security-cve-allocate`, and the
forthcoming `release-*` family — read ASF project metadata through
the official ASF
[`apache/comdev` `mcp/apache-projects-mcp/`](https://github.com/apache/comdev/tree/main/mcp/apache-projects-mcp).
It is **read-only and unauthenticated** — it wraps the public
`projects.apache.org/json` feeds, so there is no LDAP/OAuth step.

**For ASF projects this MCP is a mandatory prerequisite.** The
manifest's
[`project_metadata`](<project-config>/project.md#project-metadata)
block declares `kind: apache-projects-mcp` with `mandatory: true`
as the ASF default, and the consuming skills gate on it in their
Step 0 / Step 1 pre-flight rather than degrading to hand-scraping
`committer.cgi` / `committee.html`. Install it from the **latest
`main`** of `apache/comdev` — the same checkout that hosts the
PonyMail MCP (both live under `mcp/` in that repo) — per
[`tools/apache-projects/tool.md`](../tools/apache-projects/tool.md).

**Without this connection:** `contributor-nomination` cannot verify
an Apache ID or cross-check committee affiliation and will stop with
a clear message asking you to register and reach the MCP first. A
non-ASF adopter with no `projects.apache.org` record sets
`project_metadata.mandatory: false` and supplies roster /
affiliation context by hand.
