Run any Skill in Manus with one click

poc

Stars0

Forks0

UpdatedJune 10, 2026 at 11:13

Empirical proof-of-concept for the PoC-ready findings. For each finding /verify marked confirmed-exploitable or inconclusive, synthesize a minimal harness that triggers the bug; a host script then runs it in a sandbox (Docker --network none when present, else a gated local run) and classifies the crash into a proof verdict. Attaches a poc block onto each finding. Requires /verify first.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

allsmog

allsmog/kuzushi-security-plugin

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Information Security AnalystsComputer and Mathematical Occupations·SOC 15-1212

SKILL.md

readonly

name	poc
description	Empirical proof-of-concept for the PoC-ready findings. For each finding /verify marked confirmed-exploitable or inconclusive, synthesize a minimal harness that triggers the bug; a host script then runs it in a sandbox (Docker --network none when present, else a gated local run) and classifies the crash into a proof verdict. Attaches a poc block onto each finding. Requires /verify first.
context	fork
agent	poc-builder
user-invocable	true

PoC

Build and empirically run proof-of-concepts for the PoC-ready findings.

Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/poc-prepare.mjs" --target "<repo root>". If it reports no PoC-ready findings, tell the user to run /verify first and stop.
Read the prep's prepPath. Note its sandbox field (docker / local / none) — it tells you whether the harness will actually run. For each candidate, write the smallest harness that triggers the bug described in its verification.pocSketch into the candidate's harnessDir (write files only there — never edit application code), and record it in the draft. Also wire a negative control: emit a negativeRunCommand that drives the same harness with the finding's verification.negativePoc (the benign, in-spec input). The host runs both — the attack must fire while the control stays clean; a harness that fires on both is scored non-discriminating and does not advance the finding.
Write the { candidates: [...] } bundle to the prep's draftPath, then run the assembleCommand. The host script (not you) runs each harness in the sandbox, classifies the result (differentially when a negative control is present), persists .kuzushi/poc.json with run logs, and attaches a poc block onto each finding. For a stronger, reproducibility-aware proof (the "3/3" standard — a flaky 1-in-N crash is weak evidence), pass --reproductions 3 to the assemble step: the host runs the attack N times and only a fully-reproducible, discriminated crash earns the top proof level (5); a flaky one still counts as exploited but caps lower and records the rate.
Report the proof verdict + level per finding (and which were exploited). If sandbox was none, note the harnesses were written but not executed — the user can run them manually, or re-run with Docker available.

When NOT to use

On findings that aren't PoC-ready — run /verify first; it tags what's worth proving.
As a way to find or triage bugs — /poc only empirically confirms an already-reconstructed trigger.
When you can't accept code execution — /poc builds and runs harnesses; if no sandbox is available it writes them but won't execute, and you should not run them by hand on untrusted code.

Rationalizations to Reject

"The harness is easier if it just imports the whole app." → Build the smallest harness that triggers the bug; a giant harness that crashes proves nothing specific.
"It didn't crash, so the finding is wrong." → not-reproduced is about this harness, not the finding; a weak harness or wrong payload fails to reproduce a real bug. Re-read the pocSketch.
"I'll just add a network call to make it work." → The sandbox is offline by design; a PoC that needs the network is testing the wrong thing.

More from this repository

same repository

deep-hunt

allsmog/kuzushi-security-plugin

Interprocedural, hypothesis-driven hunt — finds the multi-file source→sink bugs that pattern-gating and same-file taint miss. Ranks trace anchors (entry points + dangerous sinks), then the deep-hunter agent walks each flow ACROSS files (forward/backward call-graph CLIs) over multiple rounds, confirming propagation and defeating guards, and promotes confirmed cross-file flows into findings.json with the path stored as evidenceGraph. Token-expensive, budget-bounded. Part of the HUNT phase (run via /sweep --deep, or ask for it); leads flow to /verify (panel).

2026-06-110

deep-scan

allsmog/kuzushi-security-plugin

Whole-file deep reader — finds bugs by READING risk-ranked files in full and reasoning from first principles, not by grepping for known patterns. Catches the long tail (project-specific wrappers, business logic, cross-function flaws) that pattern-gated producers structurally miss. Token-expensive; budget-bounded and risk-ranked. Promotes leads into .kuzushi/findings.json (source "deep-scan").

2026-06-110

taint-analysis

allsmog/kuzushi-security-plugin

IRIS-style source→sink taint hunt. Ranks a typed CWE catalog for the repo, then drives subagents to label dangerous sinks, label sources of user input, run Joern/CodeQL dataflow queries (or same-file linking) to connect them, and triage each flow as finding/candidate/rejected. Promotes verdicts into .kuzushi/findings.json. Benefits from a prebuilt CodeQL DB / Joern CPG but degrades gracefully.

2026-06-110

threat-hunt

allsmog/kuzushi-security-plugin

Adversarial per-threat review (Carlini doctrine). For each threat in .kuzushi/threat-model.json, state attacker capabilities, walk source→sink, attempt to bypass every guard, and assign a verdict with evidence. Promotes findings into .kuzushi/findings.json. Requires /threat-model first.

2026-06-110

partition

allsmog/kuzushi-security-plugin

Split the attack surface into parallel-discovery partitions so fan-out hunters explore different subsystems instead of converging on the same shallow bug. Deterministic grouping of /x-ray entry points by component → .kuzushi/partitions.json, which a hunt coordinator hands to one subagent per partition. Run /x-ray first.

2026-06-100

benchmark

allsmog/kuzushi-security-plugin

Measure recall / precision / false-proof rate of the pipeline against a ground-truth manifest. Scores either the bundled planted-vulnerability corpus (regression) or a live run's findings.json against a manifest you supply. Deterministic — no agent, no network. Use to prove a change to the producers helps rather than hurts.

2026-06-100

name	poc
description	Empirical proof-of-concept for the PoC-ready findings. For each finding /verify marked confirmed-exploitable or inconclusive, synthesize a minimal harness that triggers the bug; a host script then runs it in a sandbox (Docker --network none when present, else a gated local run) and classifies the crash into a proof verdict. Attaches a poc block onto each finding. Requires /verify first.
context	fork
agent	poc-builder
user-invocable	true

PoC

Build and empirically run proof-of-concepts for the PoC-ready findings.

Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/poc-prepare.mjs" --target "<repo root>". If it reports no PoC-ready findings, tell the user to run /verify first and stop.
Read the prep's prepPath. Note its sandbox field (docker / local / none) — it tells you whether the harness will actually run. For each candidate, write the smallest harness that triggers the bug described in its verification.pocSketch into the candidate's harnessDir (write files only there — never edit application code), and record it in the draft. Also wire a negative control: emit a negativeRunCommand that drives the same harness with the finding's verification.negativePoc (the benign, in-spec input). The host runs both — the attack must fire while the control stays clean; a harness that fires on both is scored non-discriminating and does not advance the finding.
Write the { candidates: [...] } bundle to the prep's draftPath, then run the assembleCommand. The host script (not you) runs each harness in the sandbox, classifies the result (differentially when a negative control is present), persists .kuzushi/poc.json with run logs, and attaches a poc block onto each finding. For a stronger, reproducibility-aware proof (the "3/3" standard — a flaky 1-in-N crash is weak evidence), pass --reproductions 3 to the assemble step: the host runs the attack N times and only a fully-reproducible, discriminated crash earns the top proof level (5); a flaky one still counts as exploited but caps lower and records the rate.
Report the proof verdict + level per finding (and which were exploited). If sandbox was none, note the harnesses were written but not executed — the user can run them manually, or re-run with Docker available.

When NOT to use

On findings that aren't PoC-ready — run /verify first; it tags what's worth proving.
As a way to find or triage bugs — /poc only empirically confirms an already-reconstructed trigger.
When you can't accept code execution — /poc builds and runs harnesses; if no sandbox is available it writes them but won't execute, and you should not run them by hand on untrusted code.

Rationalizations to Reject

"The harness is easier if it just imports the whole app." → Build the smallest harness that triggers the bug; a giant harness that crashes proves nothing specific.
"It didn't crash, so the finding is wrong." → not-reproduced is about this harness, not the finding; a weak harness or wrong payload fails to reproduce a real bug. Re-read the pocSketch.
"I'll just add a network call to make it work." → The sandbox is offline by design; a PoC that needs the network is testing the wrong thing.