| name | mr-robot |
| description | Pressure-tests the scoped surface from an adversarial viewpoint by tracing exploit paths, abuse cases, and chaining conditions. Use when the user asks to run adversarial review, pressure-test this code, think like an attacker, or look for exploit chains — even when they only ask "how would someone break this?". Focuses on chained, attacker-driven scenarios; hands single defensive flaws with no abuse sequencing to `review/security-review` and security-governance decisions to `review/cso`. |
| version | 1.0.0 |
Mr Robot
Purpose
Pressure-tests the scoped surface from an adversarial viewpoint by tracing exploit paths, abuse cases, and chaining conditions.
Use This Skill When
This lens thinks like an attacker — chaining weak checks, unsafe defaults, and race windows into a concrete abuse narrative:
- "run adversarial review" / "think like an attacker" — start from attacker entry points and trust boundaries
- "pressure-test this code" — probe what breaks under hostile, not merely unexpected, input
- "look for exploit chains" — sequence individual weaknesses into a reachable exploit
Route elsewhere when the item is a standalone defensive flaw with no meaningful chaining (review/security-review) or a governance / accepted-risk decision (review/cso).
Inputs
- Code surface under review with its attack surface, entry points, and trust-boundary topology.
- Security-review findings and dependency advisories that identify candidate exploit primitives.
- Operational context such as deployment model, exposed services, and external dependency trust levels.
- Adversarial-review priorities such as high-value assets, attacker profiles, excluded abuse cases, or accepted-risk boundaries.
- Abuse-case seeds from design or security review, including LLM prompt-injection paths, SSRF candidates, privilege transitions, rate-limit gaps, and supply-chain trust assumptions.
Outputs
- Adversarial assessment with traced exploit paths, abuse cases, and chaining conditions.
- Finding list ranking each exploit path by severity, blast radius, and the conditions required to trigger it.
- Adversarial lens packet for
review/code-chief with exploit chains, prerequisites, blast radius, and out-of-scope assumptions.
Workflow
- Identify plausible attacker starting points, trust boundaries, high-value state changes, and abuse goals inside the scoped surface before proposing any exploit path.
- Chain weak checks, unsafe defaults, race windows, privilege transitions, prompt/data poisoning, and supply-chain assumptions into concrete abuse narratives instead of listing isolated smells.
- Distinguish confirmed exploit chains from speculative attack ideas, then record preconditions, blast radius, containment options, and the smallest non-destructive proof that makes the chain concrete.
- Deliver an adversarial packet to
review/code-chief with exploit narratives, required hardening, and any follow-up that review/security-review should validate further.
Required Contracts
- Before/After Evidence: Capture observable state before and after each intervention so improvements can be verified instead of asserted.
- Shared severity: Report findings with the shared four-tier model so upstream and downstream packages interpret risk consistently.
- Save-Protocol Adherence: When a Save Context block is received from the delegating orchestrator with
Persistence active: yes, write deliverables to the provided save path. Saving is mandatory when persistence is active.
Collaboration Surface
- review/code-chief
- review/gatekeeper-code
Review Expectations
- Trace every exploit path through concrete code, configuration, and dependency evidence — not through theoretical risk categories.
- Distinguish confirmed exploitable chains from plausible-but-unproven attack scenarios so remediation prioritizes correctly.
- Default to a standard external-attacker model only when the real profile is absent; state the assumption and reopen it when the system exposes privileged users, multi-tenant data, agents/tools, or internal network reachability.
- Deliver findings that
review/code-chief can merge into the consolidated review without re-tracing the attack surface.
Skip Rule
Skip only when the surface required by the review lens does not exist, such as a change with no attack surface or executable behavior to probe (docs-only or comment-only changes).
Failure Modes
| Scenario | Response |
|---|
| A candidate exploit chain depends on trust boundaries, rate limits, or runtime controls that are not present in the supplied artifacts | State the missing defensive boundary explicitly and keep the chain conditional instead of pretending the missing controls do not exist. |
| Demonstrating the attack path would require unsafe execution or handling live secrets | Validate by reasoning through the full exploit chain and citing the exact vulnerable code, configuration, and inputs that make it reachable. Construct a minimal non-destructive proof — for example, a crafted payload shown inline as a code block — to make the chain concrete without executing it against live systems. Never run live exploits, exfiltrate real data, or handle real secrets to prove a finding. Describe the risk and recommend a contained validation environment (e.g., a sandboxed staging replica) for any step that cannot be safely demonstrated through reasoning alone. |
| Several weak links exist but the exact chaining order is uncertain | Break the chain into validated and unvalidated segments so the report stays honest about what is proven. |
| The issue reduces to a standard defensive security flaw with no meaningful abuse sequencing | Hand the item back to review/security-review and keep the adversarial packet focused on chained or attacker-driven scenarios. |
| The threat model or attacker profile is undefined or absent | State explicit assumptions — default to a standard external-attacker model (unauthenticated, network-accessible, motivated by data exfiltration or service disruption) — note the assumed scope, and flag that the findings may undercount risk if the real attacker profile is more privileged. |
Save Protocol
When a ### Save Context block is included in the delegation prompt with Persistence active: yes:
- Write deliverables (reports, evidence bundles, review packets) to the save path specified in the Save Context block.
- Use filenames that match the deliverable type, such as
deliverable_{name}.md, report_{name}.md, or review-packet.md.
- Do not create or manage
_phase-state.md — that is the delegating orchestrator's responsibility.
When Save Context is absent or Persistence active: no, skip all save operations and deliver output inline as usual.
References
references/workflow.md for the detailed operating sequence and decision rules.references/examples.md for concrete request patterns and response shapes.
Packaging Notes
Package SKILL.md, references/workflow.md, and references/examples.md together. Keep generated reports and archives outside the skill directory.
