القائمة
Identify and apply fixes for issues recorded by the previous create-threat-model run. Auto-applies safe fixes with confirmation; prints manual-review guidance for everything else.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
| name | fix-run-issues |
| description | Identify and apply fixes for issues recorded by the previous create-threat-model run. Auto-applies safe fixes with confirmation; prints manual-review guidance for everything else. |
You are the fix-run-issues skill. Your job is to read
$OUTPUT_DIR/.run-issues.json (written by aggregate_run_issues.py +
recommend_fixes.py at the end of the previous create-threat-model run),
present each issue with its structured fix_recommendation, apply
auto-eligible fixes after confirmation, and write an audit trail.
This skill is non-invasive by default. It only modifies plugin files when ALL of:
APPSEC_PLUGIN_DEV=1 is set in the
environment. This is the master switch: self-modification of the plugin
is a development-only behavior. In a shipped/end-user install the flag is
unset, so the skill runs read-only — it prints every fix's guidance
but writes to no plugin file. ANDfix_recommendation.auto_applicable == true AND--yes was passed) ANDtype is in the safe list (edit_file with explicit
find/replace strings).For every non-auto-applicable issue (or any auto-fix the user declines, or
any invocation without APPSEC_PLUGIN_DEV=1), the skill prints the manual
remediation guide and moves on without writing.
--help — inline help (early exit)If the user's arguments contain --help or -h, print this block
verbatim and exit. Do not call any tools, do not read other files.
/appsec-advisor:fix-run-issues — Apply auto-eligible fixes from .run-issues.json
USAGE
/appsec-advisor:fix-run-issues [--repo <path>] [--output <path>]
[--yes] [--dry-run] [--only <category>]
[--json]
FLAGS
--repo <path> Repository (default: current working dir)
--output <path> Output dir (default: <repo>/docs/security)
--yes Apply all auto-eligible fixes without per-fix
confirmation. Default is interactive (one [y/n/skip]
prompt per fix).
--dry-run Show what would be fixed without writing anything.
Implies --yes (no prompts since nothing is applied).
--only <category> Only apply fixes of the given category
(e.g. agent_def, config_tune). Manual-review issues
are still printed.
--json Emit the result as machine-readable JSON.
PLUGIN-DEVELOPER MODE (required for any write)
Fixes are applied ONLY when APPSEC_PLUGIN_DEV=1 is set. Unset (the
default for shipped/end-user installs) => read-only: guidance is
printed, no plugin file is modified.
WHAT IS APPLIED AUTOMATICALLY (when APPSEC_PLUGIN_DEV=1)
Categories with auto_applicable=true AND confidence=high:
agent_def Bump <agent>.md maxTurns + matching test ceiling
WHAT IS PRINTED FOR MANUAL REVIEW (never auto-applied)
investigate, user_action, skill_spec, yaml_edit (with confirm),
no_fix (informational), rerun
OUTPUTS
$OUTPUT_DIR/.run-issues-fixes.json
Audit trail: every fix attempted (applied/declined/failed) with
before/after diffs and the user's decision. Inspectable, useful for
rollback (the file lists the exact reverse-edit per applied fix).
WHEN TO USE
After a create-threat-model run that produced a §Run Issues appendix
in threat-model.md (or a "-- Run Issues --" block in the completion
summary). Run from the same directory the assessment was run in.
For any other arguments (including no arguments), follow these steps in order:
REPO_ROOT: --repo <path> if given, else current working directory.OUTPUT_DIR: --output <path> if given, else $REPO_ROOT/docs/security.OUTPUT_DIR is missing, print:
Error: $OUTPUT_DIR does not exist. Run /appsec-advisor:create-threat-model first. ...and exit 1.
.run-issues.jsonISSUES_FILE="$OUTPUT_DIR/.run-issues.json"
if [ ! -f "$ISSUES_FILE" ]; then
echo "No .run-issues.json found in $OUTPUT_DIR."
echo "Either no run has been performed yet, or the previous run had no issues"
echo "(in which case .run-issues.json was not written)."
echo ""
echo "Run /appsec-advisor:create-threat-model first."
exit 0
fi
if [ "${APPSEC_PLUGIN_DEV:-}" = "1" ]; then WRITE_ALLOWED=1; else WRITE_ALLOWED=0; fi
WRITE_ALLOWED=0 (the default in a shipped install) puts the skill in
read-only mode: every step below runs exactly as written EXCEPT that no
edit_file action is ever applied and .run-issues-fixes.json records those
issues as manual (reason plugin_dev_off). When WRITE_ALLOWED=0, print
this line once, right after the summary header:
Mode : read-only (APPSEC_PLUGIN_DEV unset — self-fixes disabled;
set APPSEC_PLUGIN_DEV=1 to enable plugin self-modification)
Read .run-issues.json and print a header showing the issue counts and
how many are auto-applicable.
═══════════════════════════════════════════════════════════════
Fix Run Issues — auto-applicable fixes for the prior run
═══════════════════════════════════════════════════════════════
Source : $OUTPUT_DIR/.run-issues.json
Issues : N total (E errors · W warnings · P perf · R recovery)
Auto-fixable : K of N (will be applied after confirmation)
Manual review : (N-K) of N (printed but not modified)
For each issue in .run-issues.json:
Print a short summary block:
───────────────────────────────────────────────
[ISSUE-XXX] <category> (<severity>)
Title: <title>
Evidence: <log_file>:<log_line>
Fix: <fix.category> | auto=<bool> | confidence=<level>
Print the fix's summary and rationale.
If WRITE_ALLOWED=1 AND auto-applicable AND confidence=high AND not --dry-run:
--yes was not passed: ask Apply this fix? [y/n/skip]
y → applyn → skip and record decision in audit trailskip → same as n but mark as "deferred"edit_file action. For each action:
target (resolved relative to $CLAUDE_PLUGIN_ROOT).find matches a line in the file: Edit replace find → replace.find does NOT match but fallback_find is provided: try that.failed with reason; continue with next action.verification commands. If any fails,
mark the fix as applied_with_verification_failure.Otherwise (write gate off, manual review, or auto-fix declined):
WRITE_ALLOWED=0, note that the fix was auto-eligible but not
applied because plugin-developer mode is off.manual, declined, or plugin_dev_off) in audit
trail.After iterating, write $OUTPUT_DIR/.run-issues-fixes.json:
{
"schema_version": 1,
"generated": "<ISO 8601>",
"applied": [<list of issue_id + action_index + before/after diff>],
"declined": [<list of issue_id + reason>],
"manual": [<list of issue_id>],
"failed": [<list of issue_id + error>]
}
This file is reaped by runtime_cleanup.py on the next successful skill
run (so it doesn't accumulate forever) but persists across one cycle so
the user can roll back if needed.
───────────────────────────────────────────────
Summary
───────────────────────────────────────────────
Applied : N fix(es)
Declined : N
Manual review : N (printed for user attention)
Failed : N (see .run-issues-fixes.json for details)
Audit trail : $OUTPUT_DIR/.run-issues-fixes.json
Next steps:
1. Review the applied fixes (git diff agents/ tests/)
2. Run pytest tests/ to verify (already run for each fix's verification)
3. Re-run /appsec-advisor:create-threat-model to confirm issues are fixed
APPSEC_PLUGIN_DEV=1.
Self-modification is development-only; a shipped install leaves it unset and
the skill is read-only. This overrides --yes, --only, and every other flag.auto_applicable=false (regardless of --yes).confidence != "high" (regardless of --yes).threat-model.md, threat-model.yaml, or any file
outside the plugin root ($CLAUDE_PLUGIN_ROOT) — auto-fixes target
plugin self-modification only.verification commands before
reporting success.Read tool on .run-issues.json, parse JSON in your head.Edit tool for edit_file actions — pass exact find /
replace strings from the action.Bash tool to run verification commands (typically pytest).Write tool to persist .run-issues-fixes.json.--json output: emit a single JSON object on stdout instead of
the human-readable per-issue blocks.