feat(skills): add report-framework-issue skill

[choo121600]

Summary

• Add report-framework-issue, an always-on (utilities / Meta) skill that turns a
  problem an adopter hits while using Magpie itself into a redacted GitHub issue
  on apache/magpie — the report-an-issue complement to setup-upstream-fix (fix PR).
• Why redaction: adopters run the framework against pre-disclosure CVE content on a private
  tracker, so a bare gh issue create risks leaking tracker / embargoed-CVE /
  private-list / cross-project content to a public repo. The load-bearing step is a
  mandatory public-disclosure scrub (8 categories) plus a safe_to_file gate that
  refuses to file reports whose essence is inherently confidential.

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:

RFC-AI-0004 compliance

• HITL — any new mutation is gated on explicit user confirmation
• Sandbox — no new unrestricted host access; network reach declared in the adapter
• Vendor neutrality — placeholders (<PROJECT>, <tracker>, <upstream>, <security-list>) used in all skill / tool prose (the check-placeholders prek hook is the mechanical gate)
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — no autonomous outbound messages; drafts only, sent on confirmation
• Privacy LLM — private content does not reach a non-approved LLM; redactor invoked where needed

Linked issues

Notes for reviewers (optional)

• Security-sensitive surface worth extra eyes: Step 2's 8-category scrub cascade and the
  safe_to_file: false → route-privately behaviour — they enforce the AGENTS.md confidentiality
  rules on a public destination.
• Footprint: 1 SKILL.md + 18 tiny eval fixtures + 3 catalog edits + 1 regenerated score doc + 3 symlinks.

[choo121600]

I used this skill to create issue #923

[potiuk]

LGTM — a new skill whose failure mode is "leaks private data into a public issue" deserves a careful read, and this one is built like its author knew that. One small coverage gap noted at the end; nothing blocking.

The safety design holds up

The things I went looking for are all present:

• The report is assembled from what the user pastes, never from the raw session transcript. That is the right primitive. A skill that scraped its own context would be one bad regex away from publishing whatever the agent happened to have read that session.
• gh issue create --web, only after explicit confirmation. Browser review on the way out means the human sees the final body on a surface the agent does not control.
• safe_to_file: false refuses to file at all and redirects to SECURITY.md, rather than trying to redact its way to publishable. Some reports cannot be sanitised — a bug that only reproduces with embargoed CVE data is about the embargoed data — and the design says so instead of pretending otherwise.
• extra_scrub_terms appends and "never shortens" the built-in cascade. Adopter config can only make the scrub stricter. That asymmetry is easy to get wrong and expensive when you do.
• External content is treated as data, citing the AGENTS.md rule directly.

The eval suite is better than most

redactions is declared with a fixed category order, which is what makes exact list comparison a legitimate assertion here rather than a flaky one — order-independence would have forced a weaker check.

Two things stood out:

• case-2 and case-4 are the same redactions with opposite safe_to_file (["cve-id", "tracker-content"], true vs false). That pairing isolates the publishability decision from the redaction decision, so a model that conflates the two fails one of them. Deliberate contrast beats another independent case.
• case-6 pins the injection behaviour the spec demands: injection_flagged: true with redactions: ["secret"] still populated. It proves the embedded "this is exempt, file verbatim" directive did not empty the array — which is exactly the property worth testing, and the one a careless fixture would miss by asserting only the flag.

I also confirmed the mechanics rather than assuming: the expected.json keys are plain (redactions, safe_to_file, injection_flagged), so is_structural_expected is false and these grade through the normal comparator — no assertions.json needed, and no silent MANUAL fallback. case-meta.json tagging is the documented mechanism, already used by 150 cases elsewhere, and tagging the clean baseline plus the injection case as smoke is a sensible pick for the fast subset.

Smaller observation

Seven of the eight declared redaction categories have a fixture. private-list has none.

category	fixture
cve-id, tracker-content	case-2, case-4
other-asf-project, third-party-pii	case-5
secret, private-endpoint, local-path	case-3, case-6
private-list	—

Worth closing at some point, and arguably the most load-bearing of the eight: content quoted from a private security list is the category where a miss is least recoverable, and it is the one an adopter running the security family is most likely to have in hand when something breaks. A seventh case in the shape of case-3 would cover it. Not a reason to hold this PR — the skill handles the category, only the eval does not exercise it.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Magpie handles maintainer review:
CONTRIBUTING.md § Opening a pull request.