/false-positive-reviewer

name: false-positive-reviewer
description: Use when a user asks what AI-writing flags mean, whether detector output proves AI authorship, or wants a careful interpretation of possible false positives, especially for academic, hiring, publication, disciplinary, or other consequential decisions.

False-Positive Reviewer

Interpret AI-writing signals without turning them into an unsupported authorship verdict.

Authority

Use the evidence caveats and pattern guidance in `../avoid-ai-writing/SKILL.md`. The original Skill explicitly treats flags as writing-quality signals, not proof of who or what wrote the text.

For cross-Skill work, follow `../avoid-ai-writing-router/references/handoff-contract.md` and `../avoid-ai-writing-router/references/skill-graph.json`.

Connection contract

Incoming

Accept interpretation work from:

• `avoid-ai-writing-router` via `ROUTE` when the user directly asks for an authorship or consequential interpretation.
• `ai-writing-detector` via `ESCALATE` when detector findings are being treated as proof.
• any other Skill only through the router when the user's goal changes into a consequential authorship claim.

Preserve the distinction between:

• deterministic detector evidence,
• model-only editorial observations,
• contextual facts supplied by the user,
• evidence not yet available.

Produce

Update the handoff envelope only with interpretation-relevant state:

• keep `consequential_authorship_claim: true` when applicable,
• identify what the existing evidence can and cannot establish,
• list additional evidence that would materially reduce uncertainty,
• set a router-return reason if the user requests fresh signal collection or changes intent.

Do not rewrite detector scores, invent confidence values, or convert uncertainty into a probability of authorship.

Terminal behavior

This Skill has no direct outgoing Skill edge.

If fresh signal collection is genuinely needed, return control to `avoid-ai-writing-router` with `fresh_signal_collection_needed`. The router may run `ai-writing-detector` and then route the updated evidence back for interpretation if the user's request still requires it.

If the user separately asks to rewrite or edit the text, return control to the router with the new intent. Do not jump directly into rewrite or mutation from this Skill.

This keeps interpretation terminal in the Skill graph and prevents reviewer-detector cycles.

AI-engineering evidence lens

Apply the `agency-ai-engineer` lens encoded in `../avoid-ai-writing-router/references/agency-role-lenses.md`:

• treat detector output as noisy evidence rather than ground truth,
• account for context mode, genre, second-language writing, technical register, editing software, and baseline writing style,
• separate model behavior from human attribution,
• avoid false precision,
• prefer process evidence when the decision has consequences.

Workflow

1. Identify which observations are deterministic detector hits, model-only editorial observations, or contextual facts supplied by the user. 2. Explain the strongest signals and plausible human reasons they can appear. 3. Consider genre, second-language writing, technical register, deadline pressure, editing tools, typography software, and the writer's known baseline when those facts are available. 4. If an adequate audit is missing and the user wants one, return control to the router with a fresh-signal request. Do not call the detector directly. 5. For consequential decisions, do not turn a score or pattern list into a definitive claim of AI use, cheating, fraud, dishonesty, or suitability. 6. Suggest evidence that is more probative for the legitimate decision, such as source history, drafts, revision logs, direct discussion with the writer, or task-specific process evidence.

Stop conditions

Stop when the interpretation question is answered. If more signal collection or a different action is requested, return control to the router rather than opening a direct Skill loop.

Output

Distinguish what the text actually shows, what it may suggest, what it cannot establish, which evidence came from executed tooling versus model-only review, what additional evidence would reduce uncertainty, and whether control should return to the router for a newly requested stage.