setup-test

permitcrab:setup-test

This skill is a controlled test harness. The permitcrab:setup skill writes:

• The candidate permissions block into this file's frontmatter (replacing the empty baseline above).
• A test plan into ${CLAUDE_PLUGIN_ROOT}/skills/setup-test/test-plan.json.

Then it invokes this skill. When invoked, this skill executes each test case in the plan and reports whether the observed outcome matched the expectation.

How to run when invoked

1. Run the runner:

   ${CLAUDE_PLUGIN_ROOT}/skills/setup-test/scripts/run-test-plan.js
   

   The runner reads test-plan.json, replays each case by piping a synthetic tool-use JSON payload to the resolver script (the same script that runs from the PermissionRequest hook), passing this skill's own directory as the resolver's explicit skill-dir argument so the resolver loads the candidate permissions injected above. The argument bypasses transcript lookup, which is how the live hook normally derives the active skill. It prints a structured report to stdout.

2. After printing the report, the runner writes a machine-readable copy to ${CLAUDE_PLUGIN_ROOT}/skills/setup-test/last-report.json for setup to consume.

3. Do not call the restore script from here. setup calls setup-test-restore.js after reading the report so that, if a run is interrupted, the next invocation of setup still has a known starting state to clean up.

Note on hook coverage

The runner invokes the resolver directly with the same arguments and stdin shape the PermissionRequest hook uses. It does not exercise the PreToolUse auto-deny-dangerous.js hook, so dangerous-command denials produced by that hook are not covered here. Use permitcrab:audit and permitcrab:doctor to cover hook-wiring concerns.

Report shape

The runner prints one line per case:

case <id>: tool=<Tool> expected=<approve|deny|passthrough> observed=<...> -> PASS|FAIL

Followed by a summary line:

setup-test: N passed, M failed, K untestable

last-report.json has the shape {passed, failed, untestable, cases: [{id, tool, expected, observed, outcome, reason?}]}. Exit code is 0 if every testable case passed, non-zero otherwise. Untestable cases (e.g., bash patterns with no literal anchor) count as warnings, not failures.