admin/trailofbits-skills
1
0
Fork 0
mirror of https://github.com/trailofbits/skills synced 2026-06-21 14:12:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(fp-check): use correct JSON response format in stop hooks (#129)

Browse Source 
* fix(fp-check): use correct JSON response format in stop hooks

Prompt-type stop hooks must respond with JSON. The previous prompts
instructed Claude to return plain text ('block' or 'approve'), causing
'Stop hook error: JSON validation failed' on every session end.

Updated both Stop and SubagentStop hook prompts to respond with:
- {"decision": "block", "reason": "..."} to prevent stopping
- {} to allow stopping (omitting decision field per Claude Code docs)

Bug discovered by Claude while debugging the JSON validation error
during active use of the fp-check skill.

* fix: use documented ok/reason schema for prompt hooks, bump to 1.0.2

Per https://code.claude.com/docs/en/hooks.md (Prompt-based hooks >
Response schema), prompt hooks must respond {"ok": true} to allow or
{"ok": false, "reason": "..."} to block — not {"decision": "block"}
or {}. Also bump to 1.0.2 since main already shipped 1.0.1 without
this fix; clients only update when the version increases.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Dan Guido <dan@trailofbits.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
jonnydevs
2026-06-10 15:41:52 -04:00
committed by GitHub
parent 64a8c3f00b
commit c070b9b588
3 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude-plugin/marketplace.json
+1 -1
View File
@@ -375,7 +375,7 @@
},
{
"name": "fp-check",
"version": "1.0.1",
"version": "1.0.2",
"description": "Systematic false positive verification for security bug analysis with mandatory gate reviews",
"author": {
"name": "Maciej Domanski"
plugins/fp-check/.claude-plugin/plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "fp-check",
"version": "1.0.1",
"version": "1.0.2",
"description": "Systematic false positive verification for security bug analysis with mandatory gate reviews",
"author": {
"name": "Maciej Domanski"
plugins/fp-check/hooks/hooks.json
+2 -2
View File
@@ -7,7 +7,7 @@
"hooks": [
{
"type": "prompt",
"prompt": "You are a verification completeness checker for the fp-check false positive analysis skill. The agent is about to stop. Check whether the verification process was completed properly.\n\nScan the conversation for evidence of ALL of the following for EVERY bug that was being verified:\n\n1. Phase 1 (Data Flow Analysis): Trust boundaries mapped, API contracts checked, environment protections analyzed, cross-references checked\n2. Phase 2 (Exploitability Verification): Attacker control confirmed or denied, mathematical bounds analyzed (or marked N/A), race conditions analyzed (or marked N/A), adversarial analysis completed\n3. Phase 3 (Impact Assessment): Real security impact vs operational robustness distinguished, primary controls vs defense-in-depth distinguished\n4. Phase 4 (PoC Creation): Pseudocode PoC created, executable/unit test PoCs created or explicitly skipped with justification, negative PoC created, PoC verification completed\n5. Phase 5 (Devil's Advocate): All 13 challenge questions addressed\n6. Gate Review: All 6 gates (Process, Reachability, Real Impact, PoC Validation, Math Bounds, Environment) evaluated with pass/fail\n7. Verdict: Each bug has a TRUE POSITIVE or FALSE POSITIVE verdict with evidence\n\nIf ANY bug is missing ANY of these phases or the gate review, return 'block' with the specific gaps.\nIf all bugs have complete verification with verdicts, return 'approve'.\nIf the conversation is not about fp-check verification at all, return 'approve'.",
"prompt": "You are a verification completeness checker for the fp-check false positive analysis skill. The agent is about to stop. Check whether the verification process was completed properly.\n\nScan the conversation for evidence of ALL of the following for EVERY bug that was being verified:\n\n1. Phase 1 (Data Flow Analysis): Trust boundaries mapped, API contracts checked, environment protections analyzed, cross-references checked\n2. Phase 2 (Exploitability Verification): Attacker control confirmed or denied, mathematical bounds analyzed (or marked N/A), race conditions analyzed (or marked N/A), adversarial analysis completed\n3. Phase 3 (Impact Assessment): Real security impact vs operational robustness distinguished, primary controls vs defense-in-depth distinguished\n4. Phase 4 (PoC Creation): Pseudocode PoC created, executable/unit test PoCs created or explicitly skipped with justification, negative PoC created, PoC verification completed\n5. Phase 5 (Devil's Advocate): All 13 challenge questions addressed\n6. Gate Review: All 6 gates (Process, Reachability, Real Impact, PoC Validation, Math Bounds, Environment) evaluated with pass/fail\n7. Verdict: Each bug has a TRUE POSITIVE or FALSE POSITIVE verdict with evidence\n\nIf ANY bug is missing ANY of these phases or the gate review, respond with JSON: {\"ok\": false, \"reason\": \"<specific gaps>\"}\nIf all bugs have complete verification with verdicts, respond with JSON: {\"ok\": true}\nIf the conversation is not about fp-check verification at all, respond with JSON: {\"ok\": true}",
"timeout": 30
}
]
@@ -19,7 +19,7 @@
"hooks": [
{
"type": "prompt",
"prompt": "You are an output completeness checker for fp-check verification agents. A subagent is about to stop. Check whether it produced complete structured output for its assigned phases.\n\nIdentify which agent type this is from the conversation context and verify completeness:\n\n**data-flow-analyzer** must include:\n- Phase 1.1: Trust boundary map with source, path, sink, and validation points (each with file:line references)\n- Phase 1.2: API contract analysis (built-in protections identified or absence noted)\n- Phase 1.3: Environment protection analysis (each classified as 'prevents entirely' or 'raises bar')\n- Phase 1.4: Cross-reference analysis (similar patterns, test coverage, history)\n- Phase 1 Conclusion with evidence\n\n**exploitability-verifier** must include:\n- Phase 2.1: Attacker control analysis with control level (full/partial/none) and evidence\n- Phase 2.2: Mathematical bounds proof with step-by-step algebra, OR explicit 'N/A — not a bounds issue'\n- Phase 2.3: Race condition feasibility analysis, OR explicit 'N/A — not a concurrency issue'\n- Phase 2.4: Adversarial analysis synthesizing 2.1-2.3\n- Phase 2 Conclusion with evidence\n\n**poc-builder** must include:\n- Phase 4.1: Pseudocode PoC with data flow diagram (always required)\n- Phase 4.2: Executable PoC or explicit skip with justification\n- Phase 4.3: Unit test PoC or explicit skip with justification\n- Phase 4.4: Negative PoC showing exploit preconditions\n- Phase 4.5: Verification that PoCs demonstrate the vulnerability\n- Phase 4 Conclusion\n\nIf the agent is not an fp-check agent, return 'approve'.\nIf required sections are missing, return 'block' with the specific gaps.\nIf all required sections are present with evidence, return 'approve'.",
"prompt": "You are an output completeness checker for fp-check verification agents. A subagent is about to stop. Check whether it produced complete structured output for its assigned phases.\n\nIdentify which agent type this is from the conversation context and verify completeness:\n\n**data-flow-analyzer** must include:\n- Phase 1.1: Trust boundary map with source, path, sink, and validation points (each with file:line references)\n- Phase 1.2: API contract analysis (built-in protections identified or absence noted)\n- Phase 1.3: Environment protection analysis (each classified as 'prevents entirely' or 'raises bar')\n- Phase 1.4: Cross-reference analysis (similar patterns, test coverage, history)\n- Phase 1 Conclusion with evidence\n\n**exploitability-verifier** must include:\n- Phase 2.1: Attacker control analysis with control level (full/partial/none) and evidence\n- Phase 2.2: Mathematical bounds proof with step-by-step algebra, OR explicit 'N/A — not a bounds issue'\n- Phase 2.3: Race condition feasibility analysis, OR explicit 'N/A — not a concurrency issue'\n- Phase 2.4: Adversarial analysis synthesizing 2.1-2.3\n- Phase 2 Conclusion with evidence\n\n**poc-builder** must include:\n- Phase 4.1: Pseudocode PoC with data flow diagram (always required)\n- Phase 4.2: Executable PoC or explicit skip with justification\n- Phase 4.3: Unit test PoC or explicit skip with justification\n- Phase 4.4: Negative PoC showing exploit preconditions\n- Phase 4.5: Verification that PoCs demonstrate the vulnerability\n- Phase 4 Conclusion\n\nIf the agent is not an fp-check agent, respond with JSON: {\"ok\": true}\nIf required sections are missing, respond with JSON: {\"ok\": false, \"reason\": \"<specific gaps>\"}\nIf all required sections are present with evidence, respond with JSON: {\"ok\": true}",
"timeout": 30
}
]