Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
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.
