hashintel/harden
pocs/agent-plugins/claude-pragma/skills/harden/SKILL.md
Deliberately upgrade the project's feedback harness. Use when adding a verify command, setting up CI, introducing lint/format, or making the dev loop self-enforcing. Covers canonical verify scripts, lint/format, CI configuration, and dev-loop documentation.
$ install --global
skillsauthnpx skillsauth add hashintel/labs hardenInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 15, 2026, 3:09 AM200.6s1 file scanned
SKILL.md
- name:
- harden
- description:
- Deliberately upgrade the project's feedback harness. Use when adding a verify command, setting up CI, introducing lint/format, or making the dev loop self-enforcing. Covers canonical verify scripts, lint/format, CI configuration, and dev-loop documentation.
- argument-hint:
- [what to harden, e.g. 'add verify command', 'add CI', 'add formatting']
Harden
Deliberately upgrade the project's feedback harness — the commands, gates, and automation that make verification self-enforcing. Introduce lint, formatting, CI, and a canonical verify command intentionally and incrementally.
This resolves the tension between /pragma:skeleton ("no lint/format yet") and /pragma:slice ("run the verification harness").
Input
What to harden: $ARGUMENTS
Preconditions:
- A walking skeleton must exist. If none →
/pragma:skeletonfirst. - Ideally 1-2 real slices have landed (you want to know what checks actually matter before formalizing).
Procedure
1. Audit the current harness
What commands exist? Are they consistent? Is there a single "everything is green" command? Is there CI? Does CI match local?
2. Define the target verify command
One canonical command to trust:
bun run verify # or: npm run verify, make verify, etc.
Runs in order: typecheck → lint → format check → unit tests → integration tests → build.
- Must be fast enough for pre-commit (target: < 60s)
- If some checks are slow, split:
verify(fast) andverify:full(CI-only)
3. Introduce ONE tool
Pick one improvement per /pragma:harden invocation:
- Formatting: choose one formatter, configure minimally (defaults first), run on whole codebase, add to verify
- Lint: choose one linter, default ruleset, fix existing violations, add to verify
- CI: create config running the verify command, fail on verify failure
- Pre-commit hook (optional): must be fast (< 10s) or it will be bypassed
4. Document the dev loop
Create or update a short section (README or docs/dev-loop.md):
- How to verify (canonical command)
- What it checks (ordered list)
- How to run subsets
- CI: where it runs, what triggers it
5. Verify and commit
Run the new verify command. If the new tool creates violations, fix them in this commit.
Commit: Harden: add [tool/command] to verification harness
Constraints
- One tool at a time. Do not batch formatting + lint + CI in one invocation.
- Local and CI must agree. No "CI-only" checks developers can't run locally.
- Fast by default. Slow checks go in
verify:full. - No speculative rules. Add rules that catch real problems you've seen.
- Minimal configuration. Defaults first. Customize only when a default causes real pain.
- Don't block feature work. Too much friction → back it out and try again later.
Output
- Tool added: what was introduced and why
- Verify command: current canonical command and what it runs
- Violations fixed: what existing code needed cleanup
- Dev loop doc: where the documentation lives
- Recommended next harden step: what to add next (if anything)
- Lifecycle:
State: governance,Next: /pragma:consult,Loop: /pragma:consult(default unless user explicitly continues directly)
Related Skills
hashintel/petrinaut
documentation
VerifiedTrustedCommunity
Read and write a Petri net (SDCPN) document by Automerge URL. Use when creating, editing, or querying Petri nets — adding or removing places, transitions, arcs, color types, differential equations, and parameters.
34SKILL.mdUpdated May 15, 2026
hashintel/spike
development
VerifiedTrustedCommunity
Time-boxed throwaway investigation to answer one hard question. Use when facing technical uncertainty before a slice — the output is knowledge, not production code. Retires risk by producing a spike verdict with clear recommendations.
34SKILL.mdUpdated May 15, 2026
hashintel/slice
development
VerifiedTrustedCommunity
Implement one tracer-bullet slice following the inside-out methodology. Use when you have a tracer-bullet card ready to build. Implements functional core first, then imperative shell, then end-to-end wiring, then alignment refactor.
34SKILL.mdUpdated May 15, 2026
hashintel/skeleton
tools
VerifiedTrustedCommunity
Build a walking skeleton — the thinnest runnable system that proves build, test, and runtime work end-to-end. Use when starting a new project, before any feature work. Front-loads tooling and infrastructure so every subsequent slice is cheaper.
34SKILL.mdUpdated May 15, 2026