# Harden

> 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.

- Skill: `hashintel/harden` (Agent Skill)
- Install (CLI): `npx skillmds@latest add hashintel/harden`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hashintel/harden/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: hashintel (https://skillmd.com/u/hashintel)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hashintel/harden

---


# 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:skeleton` first.
- 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) and `verify: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`):
1. How to verify (canonical command)
2. What it checks (ordered list)
3. How to run subsets
4. 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

1. **Tool added**: what was introduced and why
2. **Verify command**: current canonical command and what it runs
3. **Violations fixed**: what existing code needed cleanup
4. **Dev loop doc**: where the documentation lives
5. **Recommended next harden step**: what to add next (if anything)
6. **Lifecycle**: `State: governance`, `Next: /pragma:consult`, `Loop: /pragma:consult` (default unless user explicitly continues directly)