harden

---
name: harden
description: |
  Audit a software project for hardening — security, AI gaps, test coverage, code quality, and decoupling. Use when user wants to harden a project, audit for vulnerabilities, check test coverage, or separate private data from code.
license: MIT
compatibility: marvin
metadata:
  marvin-category: work
  user-invocable: true
  slash-command: /harden
  model: default
  proactive: false
---

# Project Hardening Audit

Perform a systematic hardening audit of this project. Work through each phase below, exploring the codebase to find real issues — not hypothetical ones. For each finding, explain the risk and suggest a concrete fix.

## When to Use

- When user types `/harden`
- When user wants to audit a project for security, test coverage, or code quality
- Before making a private repo public
- After a major feature or refactor to check for regressions
- When onboarding to an unfamiliar codebase to assess its health

## Process

### Step 1: Context Gathering (Phase 0)

Before scanning, ask these questions to calibrate the audit. The user can answer inline or say "skip" to assume worst-case (strictest ratings).

1. **Visibility** — Is this repo private, or could it go public?
2. **Access** — Just you, a team, or open source?
3. **Deployment** — Local only, server, or cloud?
4. **Compliance** — Any regulatory or legal requirements? (government forms, PII rules, HIPAA, etc.)
5. **Known issues** — Areas you already know are problematic? (prioritize or skip)

Use the answers to calibrate severity ratings throughout the audit. For example:
- "Private repo, solo access" — PII in git is medium, not critical
- "Going public" — PII in git is critical
- "Government forms" — output validation is high priority

If the user skips, assume: public visibility, shared access, compliance required.

**After calibration, state assumptions:**
Based on the answers, tell the user what this audit covers and what it doesn't. For example:
- "Covering: source code, config files, git history, dependencies, test coverage"
- "Not covering: infrastructure, CI/CD pipeline, database security, runtime monitoring"
- "Does this match your expectations, or should I adjust?"

Tailor the scope assumptions to the project. A web app with a Dockerfile gets different assumptions than a CLI tool. Let the user confirm or adjust before proceeding.

### Step 2: Audit Scopes

Work through these one at a time. After each scope, summarize findings and ask if the user wants to go deeper or move to the next scope.

#### Scope 1: Security
- Input validation and output sanitization (including stderr/log leakage)
- Secrets in code, config, and git history (not just current files — check committed history)
- Permission and access control
- Dependency hygiene (pinning, unused deps expanding attack surface, known CVEs)
- File system access patterns (path traversal, unsafe reads/writes)

#### Scope 2: AI-Specific Gaps
- Prompt injection risks (user input flowing into prompts unsanitized)
- Data exposure through AI context (secrets, PII, or sensitive content visible to the model)
- Access control on AI interfaces (who can invoke the AI, rate limits, cost controls)
- Output validation (does the system verify AI outputs before acting on them?)
- Fragile model assumptions (hardcoded model names, unpinned versions, deterministic output expectations)

#### Scope 3: Test Coverage
- Map existing test coverage (what has tests, what doesn't)
- Flag high-risk untested code (touches files, network, secrets, user input, money)
- Verify security and AI findings from Scopes 1-2 have test coverage
- Identify missing error path tests (what happens when things fail?)
- Suggest highest-value tests to add first, prioritized by risk

#### Scope 4: Code Quality
- Linter and formatter configuration (is one configured? If not, recommend one for the language/framework)
- Error handling (silent failures, bare `except`, swallowed exceptions)
- Dead code and stale config (unused functions, abandoned imports, orphaned files from refactors)
- Edge cases (empty inputs, nulls, unexpected types, boundary values)
- Consistency (naming, patterns, structure across similar components)
- Network and retry behavior (connection limits, timeout handling, backoff)
- Hardcoded values that should be configurable (paths, filenames, magic numbers)

#### Scope 5: Decoupling & Data Separation
- Tightly coupled components that should be independent (shared state, circular dependencies, components modifying same files)
- Private or sensitive data committed to the repo (PII, personal content, customer data)
- `.gitignore` coverage for sensitive and generated files
- Environment-specific config committed as if universal
- Data that should live outside the repo (personal content, user-specific state, local config)
- Clear boundaries between framework code and user data

### Step 3: Checkpoint Questions

During each scope, if you encounter something ambiguous — **ask before rating severity**. Only ask questions the codebase can't answer.

Examples:
- "This file has what looks like a real SSN — is this test data or production?"
- "This API key is in a committed file — is this a throwaway/dev key or production?"
- "Two skills modify the same file — is this intentional or a gap?"

**If the codebase can answer it, don't ask. If only the user knows, ask.**

Do NOT turn the audit into an interview. The skill's strength is autonomous exploration. Reserve questions for decisions that change severity or skip/prioritize a finding.

### Step 4: Scorecard

After completing all scopes, present a scorecard with letter grades per scope.

**Grading formula:**
- Points per finding: Critical = 4, High = 3, Medium = 2, Low = 1
- **Any critical finding in a scope = D minimum for that scope (cannot grade above D until critical is resolved)**

| Grade | Points |
|-------|--------|
| A | 0 |
| B | 1-4 |
| C | 5-9 |
| D | 10-14 |
| F | 15+ |

**Overall grade:** Average of scope grades (A=4, B=3, C=2, D=1, F=0), rounded.

### Step 5: Batch Plan

Propose batches for fixing the findings.

**Batching rules:**
1. **Dependencies first** — if finding X blocks finding Y, X goes in an earlier batch
2. **Logical grouping** — findings that touch the same files or fix related problems go together
3. **Severity within batches** — higher severity batches come first when no dependency constraint

### Step 6: Issue Creation (Optional)

After presenting the batch plan, ask: **"Ready to create GitHub issues? I'll file them in batch order."**

Only create issues after the user reviews and approves the batches.

## Output Format

### Scorecard

```
| Scope | Grade | Findings |
|-------|-------|----------|
| Security | C | 1 critical, 2 high, 1 medium |
| AI | B | 2 high |
| Tests | D | 3 high |
| Code Quality | B | 1 medium, 2 low |
| Decoupling | C | 2 high |

Overall: C
```

### Batch Plan

```
### Batch 1 — [description] ([count] issues)
Resolves: [finding numbers]
Dependency: [what must be done first, or "None — do this first"]
Effort: [Low / Medium / High]
```

## Rules

- Explore the codebase yourself before asking questions. Read files, check configs, scan for patterns.
- Only flag real issues you find in the code — not theoretical risks.
- Prioritize findings by severity: critical > high > medium > low, calibrated by Phase 0 context.
- The scorecard and batch plan are mandatory outputs. Do not skip them.

---

*Skill created: 2026-04-06*

More agent context in SterlingChin/marvin-template

3 other files this repository gives its agents.