菜单
Remove stale run-state files left behind by a crashed or abruptly terminated threat-model assessment. Refuses to clean when an active run is still holding the lock. Use when the Claude Code UI shows the threat-modeling skill as "scanning" forever after a session crash.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | clean-run-state |
| description | Remove stale run-state files left behind by a crashed or abruptly terminated threat-model assessment. Refuses to clean when an active run is still holding the lock. Use when the Claude Code UI shows the threat-modeling skill as "scanning" forever after a session crash. |
You are cleaning orphaned assessment run-state. This skill is not a threat-modeling run — it touches no source code, spawns no agents, and writes no threat model artifacts. It only removes the transient run-state files listed below.
--help — inline help (early exit)If the user's arguments contain --help or -h, print this block verbatim and exit.
/appsec-advisor:clean-run-state — Remove stale assessment run-state files.
USAGE
/appsec-advisor:clean-run-state [--repo <path>] [--output <path>] [--force] [--dry-run] [--json]
FLAGS
--repo <path> Repository to clean (default: current working dir)
--output <path> Output directory to clean (default: <repo>/docs/security)
--force Clean even when an active run is detected (dangerous —
will kill the other session's lock; use only when you
are certain the other process is dead)
--dry-run Report what would be cleaned without removing anything
--json Emit the result as machine-readable JSON
WHAT IS CLEANED
.appsec-lock PID lock file
.appsec-checkpoint phase= status= timestamp= line
.phase-epoch Unix-timestamp anchor used by phase timers
.session-agent-map hook session tracking
WHAT IS PRESERVED
threat-model.md (your completed threat model)
threat-model.yaml (canonical data)
threat-model.sarif.json (if present)
.fragments/ (composer input set)
.appsec-cache/ (incremental baseline cache)
.agent-run.log (audit trail)
.hook-events.log (audit trail)
All other files (this skill only touches the four files above)
WHEN TO USE
* The Claude Code UI shows the threat-modeling skill as "scanning" but no
claude process is actually running.
* /appsec-advisor:status reports a run in progress from an old session.
* A ~/appsec-advisor:create-threat-model invocation bails out with
LOCK_BLOCKED and you've verified the other session is dead.
The skill is safe to invoke at any time — if no stale state exists, it
reports "clean" and exits 0.
After printing the help block, exit. Do not proceed.
Recognized flags (and the values consumed by --repo / --output):
--repo <path> --output <path> --force --dry-run --json --help | -h
Parse these and set REPO_ROOT, OUTPUT_DIR, FORCE_MODE, DRY_RUN_MODE,
JSON_MODE.
REPO_ROOT to the current working directory.OUTPUT_DIR to $REPO_ROOT/docs/security.--repo <path> overrides REPO_ROOT.--output <path> overrides OUTPUT_DIR.If the invocation contains any token that is not one of the recognized
flags above — or is not the value consumed by --repo / --output — DO NOT
proceed. Do not resolve CLAUDE_PLUGIN_ROOT, do not invoke the helper, do
not touch any state file. Print the following block verbatim to stderr,
substituting <TOKEN> with the first unknown token, then exit with status
2:
Error: unknown argument '<TOKEN>'
/appsec-advisor:clean-run-state accepts only:
--repo <path> Repository to clean (default: current working dir)
--output <path> Output directory to clean (default: <repo>/docs/security)
--force Clean even when an active run is detected
--dry-run Report what would be cleaned without removing anything
--json Emit the result as machine-readable JSON
--help, -h Show full help and exit
Run `/appsec-advisor:clean-run-state --help` for details.
A flag that takes a value (e.g. --repo or --output) counts as unknown
when its value is missing — treat the flag itself as the offending token in
that case. Repeated occurrences of the same flag are allowed; the last value
wins.
CLAUDE_PLUGIN_ROOTif [ -z "$CLAUDE_PLUGIN_ROOT" ]; then
CLAUDE_PLUGIN_ROOT=$(find /root /home /opt -maxdepth 6 \
-path "*/appsec-advisor/skills/clean-run-state/SKILL.md" \
2>/dev/null | head -1 | xargs -r dirname | xargs -r dirname | xargs -r dirname)
fi
export CLAUDE_PLUGIN_ROOT
if [ -z "$CLAUDE_PLUGIN_ROOT" ] || [ ! -d "$CLAUDE_PLUGIN_ROOT" ]; then
echo "Error: CLAUDE_PLUGIN_ROOT could not be resolved." >&2
exit 2
fi
Branch on the --dry-run / --force flags:
ARGS="$OUTPUT_DIR"
[ "$JSON_MODE" = "true" ] && ARGS="$ARGS --json"
python3 "$CLAUDE_PLUGIN_ROOT/scripts/check_state.py" $ARGS
The script's exit code propagates — 0 when clean / active, 1 when stale
or orphan state was detected. In dry-run mode we never mutate, so exit 1
is informational ("run without --dry-run to clean").
ARGS="$OUTPUT_DIR --clean"
[ "$JSON_MODE" = "true" ] && ARGS="$ARGS --json"
python3 "$CLAUDE_PLUGIN_ROOT/scripts/check_state.py" $ARGS
EXIT=$?
Exit-code handling:
0 — cleaned successfully (or there was nothing to clean).2 — refused because an active run holds the lock. Report the situation
to the user and suggest --force if they are certain the other session
is dead.--force)When --force is passed, the skill removes the lock even when a live PID
is detected. This is dangerous — it invalidates any still-running assessment.
The skill MUST:
⚠ --force requested — removing lock regardless of PID liveness.
Any still-running assessment will lose its lock and may crash.
--force flag supplemented by a direct
rm -f on the lock files. The Python helper refuses to clean active
state by design (the state machine is the guarantor of correctness);
the skill layer owns the escape hatch:
rm -f "$OUTPUT_DIR/.appsec-lock"
rm -f "$OUTPUT_DIR/.appsec-checkpoint"
rm -f "$OUTPUT_DIR/.phase-epoch"
rm -f "$OUTPUT_DIR/.session-agent-map"
--clean) so the user sees the final
state:
python3 "$CLAUDE_PLUGIN_ROOT/scripts/check_state.py" "$OUTPUT_DIR"
The helper's output is the skill's output. Exit with the helper's exit code
(propagated from Step 3). Do not add commentary beyond the --force warning
described above.
Perform a threat assessment of a repository and produce a threat-model.md. Supports --repo to analyze external repos and --output to set the output directory. Optionally also writes threat-model.yaml with --yaml flag.
Maintainer/dev skill that triages an anonymised diagnostic bundle (appsec-diag-*.tgz, produced by scripts/diagnostic_bundle.py) a user sent after a pipeline failure. Runs the deterministic inspect, then cross-references the plugin source (scripts/, agents/phases/, AGENTS.md) and known-bug history to produce a grounded root-cause hypothesis. Does NOT re-run the pipeline and never needs the user's repo.
Answer ANY question about the threat model in this repo — read-only Q&A over the committed threat-model.yaml. The default surface for every natural-language query about the model, however simple: does one exist at all ("is there a threat model here?", "gibt es hier ein bedrohungsmodell?"), how it stands ("how bad is it?", "is it still current?"), anything about its contents ("what are the critical findings?", "does it cover SSRF / IDOR / auth?", "which findings touch the payment service?", "is there a fix for F-003?", "welche kritischen findings gibt es?", "deckt mein bedrohungsmodell XSS ab?"), and meta questions ("what does P1 mean?", "what is STRIDE here?"). Grounds every data answer in the model and cites F-ids; never analyzes code, re-scores, spawns agents, or writes files. Prefer this over show-threat-model for anything phrased as a question — show only prints a fixed summary block on explicit request. To act on findings use review-threat-model; to (re)generate use create-threat-model.
Print the standard summary block of the current threat model — scan identity, findings by severity, the remediation backlog (P1/P2/P3) and mitigation coverage, the worst-case scenarios, control posture, and whether the model is still up to date. A DISPLAY command, not a question-answering surface: use it only for an explicit request to see that block ("show me the threat model summary", "zeig mir die threat-model-uebersicht", "print the overview"). Reuses the same change detection that decides if an incremental scan is needed. Does not analyze code, write files, or compose prose — it prints a rendered block verbatim and cannot answer anything the block does not already contain. Do NOT route a natural-language question here, not even "is there a threat model?" / "gibt es hier ein bedrohungsmodell?" — every question goes to ask-threat-model, which answers directly and can produce this block too.
User-facing triage of an existing threat model — an overview-first console over an already-generated threat-model.yaml (backlog by priority, severity mix, worst-case scenarios), then one of three modes. "Just look around" browses findings read-only by severity, security aspect, requirement, or control posture. "Fix or accept findings now" applies the code fix for findings you pick — or accepts the risk instead — one at a time for review. "Build a remediation plan" decides mitigate / accept-risk per finding and emits a remediation-plan.md without code changes. Within a session you can also discuss a single finding by id (F-/T-/M-/W-), a read-only aside that changes nothing. Runs later and independently of create-threat-model; reads the model, never regenerates or re-scores it. Not an artifact-quality check (that is eval-threat-model). To only *ask* about the model without acting on it, use ask-threat-model.
Convenience alias for create-threat-model in incremental mode — re-analyzes only the components that changed since the last run. Unlike the bare create-threat-model, it does NOT bootstrap — it aborts with a clear message when no threat model exists yet, so an "update" can never silently turn into a first full assessment. An explicit mode flag the user passes (--full, --rebuild, --rerender, --resume) is honored instead of the injected --incremental. Everything else (flags, --repo, --output, behavior, output) is identical to create-threat-model.