Privacy LLM

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

<!-- Placeholder convention (see ../../AGENTS.md#placeholder-convention-used-in-skill-files):
     <project-config>  → resolved per file: the personal layer first
                         (`.apache-magpie-local/` when adopted, falling back to the main
                         checkout's in a linked worktree; `<git-common-dir>/apache-magpie/`
                         when only installed), then `.apache-magpie-overrides/` (committed)
     <framework>       → the framework checkout or plugin root
     <private-list>    → the project's private PMC list
     <security-list>   → the project's security-report list -->

setup-privacy-llm

Decide which LLMs this project's skills may send private foundation content to, record that decision where the skills look for it, and prove it holds.

Two mechanisms, and this skill configures one of them:

1. The approved-LLM gate — applies to <private-list> mail and any other private foundation list. A skill refuses to fetch unless every LLM in the active stack is approved. This is what the skill configures, by picking a variant.
2. PII redaction — applies to <security-list> mail. Third parties the reporter names are replaced with hash-prefixed identifiers before any LLM sees them. It runs under every variant and needs no per-variant configuration; this skill only verifies it works.

The recipes are docs/setup/privacy-llm.md; the contract behind them is tools/privacy-llm/tool.md. This skill walks the recipe rather than restating it — read the variant you land on before writing anything.

[!IMPORTANT] This is a project decision, not a personal preference. What goes in the committed copy says what the project permits for everyone's sessions. Configure locally for yourself freely; see Step 5 before promoting anything to the committed half.

---

Step 1 — Does it already resolve?

Resolve privacy-llm.md through the lookup chain, per file, local first:

1. privacy-llm.md in the personal layer — yours, never committed: .apache-magpie-local/ when the project adopted Magpie (the main checkout's, from a linked worktree that has none), else <git-common-dir>/apache-magpie/;
2. .apache-magpie-overrides/privacy-llm.md — committed, the project's.

Both present → say so and name which one wins here (the local one does), because a local file silently shadowing the project's answer is exactly the case an operator needs told. Offer to show the difference, then go to Step 4 and verify rather than rewrite.

Only one present → read it, report the stack it declares, and go to Step 4. Do not rewrite a working configuration because this skill happened to be invoked.

Neither → continue to Step 2. This is the first run.

Step 2 — Detect the stack, do not ask for it

Ask the user nothing you can determine. Establish what is actually in the stack:

• The agent itself — which harness is running this skill (Claude Code, Codex, Gemini CLI, …). Always in the stack.
• Local inference — is an Ollama, llama.cpp or vLLM endpoint reachable and configured for this project? Check the adapter configuration and the environment, not a guess.
• Third-party endpoints — anything in the project's existing configuration naming a model endpoint the framework does not ship.
• Whether this project has private lists at all. A project with no <private-list> still wants the file, because the redactor and the gate both read it — but the variant is the simple one and the interview is one question shorter.

Report what you found as a list before proposing anything. A detection the user can see is a detection they can correct.

Step 3 — Pick the variant and write it

Map what Step 2 found onto a variant in docs/setup/privacy-llm.md:

Propose the variant your detection implies, say what it means in one sentence — this permits the private list to be read by X and nothing else — and let the user correct it.

Then write privacy-llm.md from that variant's block, substituting the project's real list addresses, into the personal layer — the personal_dir that python3 -m setup_preflight.layers prints (<git-common-dir>/apache-magpie/ on a project that has not adopted Magpie, so nothing lands in its working tree). Local, always, on this step. Writing the personal copy needs nobody's permission, is invisible to every other clone, and is undone by deleting a directory. Write .apache-magpie-overrides/privacy-llm.md instead only when the project has adopted Magpie and the user says the answer should bind every contributor — and then stage it, never commit.

Two things this step may not do: invent an endpoint — if the detection is ambiguous, ask rather than assume — and widen the stack to make the gate pass. The gate failing is information.