Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Active security hardening: scan the existing repository for
vulnerabilities and forward-facing threats, then propose concrete
remediations the user can approve, defer, or file.
This skill is the engine behind /harden. It complements the
Claude Code built-in /security-review (which scans the pending
diff) by sweeping the whole repository against citation-backed
checks rather than line-level review of in-flight code.
When To Use
Quarterly security-posture audits.
Before tagging a release that touches sensitive code paths.
After a published advisory affects the language ecosystem.
When onboarding a new repository and want a baseline.
After integrating a new dependency or upstream service.
When NOT To Use
Pending-diff review on a single PR. Use /security-review.
Architecture-level threat modeling. Use attune:war-room
with a security-focused panel.
Cryptographic protocol review. The skill flags suspect crypto
but does not propose protocol fixes (specialist work).
One-off bug hunting. Use pensive:bug-review.
Required TodoWrite Items
harden:discovery: inventory languages, build files, hooks,
CI workflows
harden:scan-python: run python-checks.md detectors when
Python is present
harden:scan-rust: run rust-checks.md detectors when Rust
is present
harden:scan-cross-cutting: run cross-cutting.md detectors
(deps, secrets, SBOM, CI)
harden:scan-frontier: run frontier-checks.md (PQC, LLM
supply chain, sandboxing)
harden:nist-mapping: map findings to NIST SSDF practices
harden:proposals: for each finding above the threshold,
draft a concrete remediation per modules/proposal-shape.md
harden:approval-gate: present proposals to the user for
apply / file / defer / reject
harden:findings-verified: citations confirmed by
citation_verifier.py
harden:report: write reviews/harden-<date>.md and
optionally post to Discussions
Progressive Loading
Load modules based on what the discovery step finds.
Detected
Load
Python files (*.py, pyproject.toml)
modules/python-checks.md
Rust files (*.rs, Cargo.toml)
modules/rust-checks.md
Any
modules/nist-controls.md (citation backbone)
Any
modules/cross-cutting.md (deps, secrets, CI)
LLM SDK use (anthropic, openai), MCP server, post-quantum surface
modules/frontier-checks.md
Any with proposals enabled
modules/proposal-shape.md
The module hub keeps the SKILL.md itself under the
estimated_tokens: 1100 budget. Detail lives in the modules.
Core Workflow
Phase 1: Discovery
Inventory the repo without modifying anything:
# Languages and build files
find . -type f \( -name '*.py' -o -name '*.rs' -o -name '*.sh' \) \
| head -200 > /tmp/harden-langs.txt
# Build manifestsls pyproject.toml Cargo.toml package.json go.mod 2>/dev/null
# CI workflows and pre-commitls .github/workflows/ .pre-commit-config.yaml 2>/dev/null
# Hooks and Dockerfiles
find . -path ./node_modules -prune -o -type f \
\( -name 'hooks.json' -o -name 'Dockerfile*' \) -print
Dispatch /discovery-prefilter if the repo has > 5000 source files
to bound the scan.
Phase 2: Citation-backed scan
For each detected language, load the matching module and run its
detector list. Each detector outputs findings with the schema
defined in modules/proposal-shape.md. The citation column is
mandatory: a finding without a NIST/CWE reference is downgraded
to "advisory" and not eligible for active proposal.
Phase 3: NIST mapping
Group findings by SSDF practice (PW.4, PW.8, RV.1, etc.) and CWE
ID. The mapping table lives in modules/nist-controls.md. The
report's executive summary references SSDF practice coverage so
the audit is comparable across runs.
Phase 4: Proposal generation
For each finding above the configured severity threshold, draft a
concrete remediation per modules/proposal-shape.md:
Specific files and lines touched
Diff or config snippet (not "consider doing X")
Blast-radius assessment via pensive:blast-radius
Reversal plan: how to revert if the change breaks behavior
Test that should pass after the change
Phase 5: Approval gate
Present proposals one at a time via AskUserQuestion. Default
options: apply, file as issue, defer to backlog,
reject. Auto-apply is opt-in via the --auto-apply flag and
respects a per-finding severity threshold.
Phase 6: Apply and validate
Apply each approved proposal as a discrete commit:
Drop or label UNVERIFIED any finding the verifier fails (exit 1); only
verified findings enter the report. See Skill(imbue:review-core) Step 5
and Skill(imbue:structured-output) for the schema.
Exit Criteria
Discovery output lists every language and build manifest
detected in the repo.
Each finding carries a CWE or NIST SSDF citation; the
report executive summary lists the SSDF practice coverage.
Each finding above the severity threshold has a concrete
proposal (file, diff or config snippet, blast radius,
reversal plan, expected-passing test).
No proposal was applied without explicit user approval
(or without an --auto-apply flag covering its severity).
Each applied proposal is its own commit, reversal-friendly.
After every apply, the project gates were re-run; any
gate failure reverted the commit and downgraded the
finding.
reviews/harden-<date>.md exists and lists every finding
with a disposition (applied / filed / deferred / rejected /
advisory).
Every reported finding carries a Location + verbatim Anchor
confirmed by citation_verifier.py (exit 0), or unverified
findings were dropped or labeled UNVERIFIED.
