poc-exploit

name	poc-exploit
description	Build realistic local/OSS-authorized PoC plans, labs, manual blackbox reproduction steps, negative controls, and exploitability evidence for Proteus candidates with concrete signal.

Proteus PoC Exploit

Use this skill only after a candidate has enough signal to justify validation. The PoC must emulate a realistic attacker path and make the vulnerable behavior explicit. The lab must not create the bug.

Follow the Proteus base research contract. Use default, documented, or normal correct-practice configuration. Do not disable controls, patch target code, or add lab-only shortcuts to make the exploit work.

Operating Method

1. Restate the candidate as attacker capability -> target behavior -> concrete impact.
2. Identify the minimum legitimate setup that reproduces the real deployment condition. Record version, runtime mode, adapter/build mode, and config legitimacy.
3. Prefer manual blackbox-style steps: normal CLI commands, HTTP requests, browser actions, file operations, or documented APIs. Automation may wrap the flow only after the manual sequence is clear.
4. Add negative controls before claiming impact: safe input, different user or tenant, correct authorization, patched/expected path, non-attacker-controlled input, and configuration boundary.
5. Capture evidence that proves root cause and effect without relying on screenshots or noisy logs alone.
6. State limitations and non-claims. A narrower truthful report beats a broad speculative one.

Exploitability Standard

• The attacker boundary must be realistic and external to the protected trust decision being broken.
• The exploit path must work without artificial lab help.
• The impact must be security-relevant, not just surprising output.
• If a script is used, the report still needs a readable manual sequence it represents.
• If the candidate depends on timing, retries, generated artifacts, or state drift, measure reliability and failure modes.

Anti-Patterns

• Do not produce a magic exploit script that hides the actual behavior.
• Do not use forced vulnerable configuration as proof unless that configuration is documented normal practice for the target.
• Do not claim report-grade if public-known/timeline, dedupe, negative controls, or Skeptic rebuttal are missing.
• Do not overclaim weak impact; route back to chaining or Cicada when framing may still improve.

Report Writing

If asked to draft or refine a report, write for a real external triager with no prior context. Use the user's or program's supplied template when provided. Do not add sections that are not in that template unless they are truly necessary for triage.

Prefer natural, objective, surgical prose. The report should not read like a legal document, a checklist, a questionnaire, or an AI-generated worksheet. Do not create long sections, excessive bullets, or heavy formatting just to prove that every validation concern was considered.

When the user asks to adjust a report, write the report text as it should appear to an external triager. Do not answer the user, narrate the adjustment, cite local paths, or reference workspace context.

The summary should usually carry most of the explanation organically: what the flaw is in simple terms, who can trigger it, why the attacker boundary is realistic, why the target owns the root cause, why this is not expected behavior, what the victim loses, and why the PoC is not a lab artifact. Include those points as natural context, not as separate checklist answers unless the template asks for them.

Avoid common LLM report habits: phrases like "this is not about X, it is about Y", defensive phrasing, unnecessary caveats, reframing the issue in Impact, "Why this matters", "This matters", "This is security relevant because", em dashes, filler, and generic severity hype.

Keep reproduction steps readable and blackbox-oriented. Prefer a small number of browser actions, HTTP requests, curl commands, or normal CLI commands over a large automation script. If a script is unavoidable, explain the manual flow it represents and keep the script secondary.

In Steps To Reproduce, keep each step to an action title and expected output. Do not include long redundant explanations inside the numbered steps. Put interpretation of output in PoC Details or immediately after the steps, without restating the same proof multiple times.

Impact should preferably be bullet points that list concrete impacts only. Do not use Impact for caveats, prerequisites, defensive framing, or explanations of why the issue is security relevant. Put requirements or limitations in Summary, PoC Details, or Limitations instead.

Do not invent extra sections, legalistic caveats, generic severity language, or internal workflow references. Do not mention Proteus, .vros, role names, workspace paths, memory records, or agent process in a submitted report.

Required output:

{
  "attackerModel": "...",
  "candidateClaim": "...",
  "configurationLegitimacy": "...",
  "testedVersionAndMode": "...",
  "manualSetupSteps": [],
  "manualAttackSteps": [],
  "expectedVulnerableResult": "...",
  "negativeControls": [],
  "reliabilityNotes": [],
  "evidenceToRecord": [],
  "limitationsAndNonClaims": [],
  "reportReadiness": "blocked|candidate|report-grade",
  "remainingGates": [],
  "contractSignature": {}
}