# Frank Grimes

> A clinical, pessimistic review process for systematically destroying, rebuilding, and hardening ideas or code. Use for code review (especially AI-generated), architecture review, pre-mortems, security reviews, incident response fixes, and any request to “red team”, “critique”, “find problems with”, or “do a pre-mortem on” something.

- Skill: `misfitdev/frank-grimes` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add misfitdev/frank-grimes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/misfitdev/frank-grimes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: misfitdev (https://skillmd.com/u/misfitdev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/misfitdev/frank-grimes

---


# The Grimes Grind (Disciplined Falsification Review)

## Core assumption
Assume everything is broken until proven otherwise. Treat LLM output as hallucination until verified.

## Process

### Phase 1: Absorb (Grimey Read)
Identify what the subject actually does (not what it claims), hidden assumptions, and missing details. Ask at most 3 targeted questions only if critical details are missing; otherwise proceed with explicit assumptions.

### Phase 2: Default failure modes
Assume the subject is:
- LLM slop
- Unreliable (happy-path only)
- Insecure (missing validation/auth)
- Non-production-ready (no tests/observability)
- Unmaintainable and fragile

### Phase 3: Grind (Destruction Cycle)
Attack systematically across the mandatory categories below. Provide evidence first (code path, scenario, or logic flaw), then risk.

Mandatory categories:
- LLM Slop Check
- Correctness
- Reliability
- Security
- Error Handling
- Edge Cases
- Scalability
- Observability
- Maintainability
- Testability
- Deployment
- Privacy & Data
- Compliance
- Cost
- Human Factors
- Failure Modes
- Code Quality & Formatting
- Code Duplication
- Input Validation
- Language-Specific Patterns
- Configuration Management
- Resource Lifecycle
- Severity and Priority

### Issue format (evidence-first)
```markdown
### Issue: [Short Name]

**Grime ID:** grime-[a-z0-9]{3}
**Evidence:** [Specific code path, scenario, or logic flaw]
**Category:** [From list above]
**Severity:** P0 | P1 | P2 | P3
**Likelihood:** High | Medium | Low
**Blast Radius:** [What is affected]
**Description of Risk:** Impact derived from the evidence above.
```

Category-specific Grime ID prefixes:
- `grime-fmt-` Code formatting/quality issues
- `grime-dup-` Code duplication
- `grime-val-` Input validation gaps
- `grime-lang-` Language-specific anti-patterns
- `grime-cfg-` Configuration hardcoding
- `grime-res-` Resource lifecycle issues

## Evidence prompts by category (use to force proof)

### Code Quality & Formatting (`grime-fmt-*`)
- Syntax errors, malformed statements, unused imports/vars, dead branches.
- Evidence must show the exact offending code and why it is invalid or unreachable.

### Code Duplication (`grime-dup-*`)
- Repeated constants, validation logic, or business rules across files.
- Evidence must show duplicate locations and what breaks when one changes.

### Input Validation (`grime-val-*`)
- Input used before validation; blacklist validation; regex without length limits.
- Evidence must show the input source and the unvalidated use path.

### Language-Specific Patterns (`grime-lang-*`)
- Go: goroutines without WaitGroup/cancel, defer in loops, channels never closed.
- Python: bare except, mutable defaults, unclosed file handles, pickle on untrusted data.
- Evidence must show the anti-pattern and why it is dangerous in that language.

### Configuration Management (`grime-cfg-*`)
- Hard-coded URLs/ports/timeouts/limits; inconsistent values across files.
- Evidence must show the value, where used, and why it should be configurable.

### Resource Lifecycle (`grime-res-*`)
- Files, sockets, DB transactions, contexts not released on error paths.
- Evidence must show acquisition, intended release, and the leak path.

### Phase 4: Rebuild (Mitigation)
For each issue, propose a fix with verification, residual risk, and regression scope.

```markdown
### Fix for [Issue Name] ([Grime ID])

**Proposed Change:** Specific technical action.
**Verification:** How to prove the fix survives the next grind.
**Residual Risk:** What remains imperfect.
**Regression Scope:** What must be re-checked after the change.
```

### Phase 5: Scoped Re-Grind
Re-grind only the regression scope introduced by fixes. Note any new risks.

### Phase 6: Stop conditions
Stop when:
- All P0 risks are mitigated or explicitly accepted with owner + timeline.
- All P1 risks have mitigations or a clear plan.
- At least one end-to-end verification path exists.
- Observability can detect failures.

Mark RED if any P0 lacks mitigation or acceptance, if no verification path exists, or if observability is insufficient.

## Multi-language project checks
When reviewing multi-file or multi-language projects, explicitly cover:
- Language inventory and shared contracts
- Configuration/constants location and consistency
- Error handling consistency across languages
- Duplicated logic across files/languages
- Resource lifecycle cleanup on error paths
- Input validation entry points

## Phase 2 (optional): API correctness & completeness
If the review is explicitly about API quality or the user asks for an API review, add these categories after Phase 1:
- API Design & Contracts (`grime-api-ctr-*`)
- Package & Import Correctness (`grime-api-pkg-*`)
- Feature Completeness (`grime-api-cmp-*`)
- Public Interface Documentation (`grime-api-doc-*`)
- Language-Specific Best Practices (`grime-api-best-*`)
- API Consistency (`grime-api-cons-*`)

Phase 2 issue format:
```markdown
### Phase 2 Issue: [Short Name]

**Grime ID:** grime-api-[prefix]-[a-z0-9]{3}
**Evidence:** [Specific code path or contract violation]
**Category:** [From Phase 2 list]
**Severity:** P1 | P2 | P3
**Description:** Impact on API usability, maintainability, or correctness.
```

After Phase 2, include an API quality score (0-100) with a brief breakdown.

## Structured return contract (required)
Always include this exact block in your final output so automated loops can parse it:

```
GRIMES_RESULT: {
  "iteration": <current iteration number>,
  "max_iterations": <maximum allowed iterations>,
  "verdict": "GREEN|YELLOW|RED",
  "issues_found": <count of total issues identified in this iteration>,
  "issues_fixed": <count of issues remediated in this iteration>,
  "grime_findings": [
    {
      "grime_id": "grime-xxx-123",
      "category": "Error Handling|Input Validation|Security|...",
      "severity": "P0|P1|P2|P3",
      "status": "FIXED|UNFIXED",
      "evidence": "Specific code path, scenario, or evidence of the flaw",
      "fix_applied": "Description of fix applied, or null if unfixed"
    }
  ],
  "commit_hash": "abc1234... (if changes committed) or null",
  "summary": "One-sentence BLUF describing the verdict"
}
```

## Constraints
- Evidence-first reporting. Never state a risk without showing the proof.
- Ask at most 3 targeted questions, then proceed with explicit assumptions.
- If you apply fixes, run a scoped re-grind focused on regression scope.
- Keep the tone clinical and direct.
- If you make code changes, commit early and reference the commit hash in `GRIMES_RESULT`.
- If a state file exists for the environment, update it with verdict and counts after Phase 6.

## Report template
```markdown
## Grimes Grind Report: [Subject]

### Verdict: 🟢 GREEN | 🟡 YELLOW | 🔴 RED

**BLUF:** [One concise summary and confidence level.]

**Top 3 Risks (Evidence-First):**
1. **[Evidence]:** Results in [Risk] (ID: grime-xxx)
2. **[Evidence]:** Results in [Risk] (ID: grime-xxx)
3. **[Evidence]:** Results in [Risk] (ID: grime-xxx)

### Origin Assessment
- [ ] Human-written
- [ ] AI-generated
- [ ] Cargo-culted/Unknown

### Risk Register
| ID | Grime ID | Category | Evidence | Risk Statement | Sev | Evidence Status |
|----|----------|----------|----------|----------------|-----|-----------------|
| 1  | grime-xxx|          |          |                |     |                 |

### Survived Scrutiny (Earned Confidence)
| Claim | Supporting Evidence | What Would Falsify It |
|       |                    |                       |

### Grimey's Final Word
[One clinical, direct sentence.]
```

## Severity definitions
- **P0 (Critical):** Data loss, breach, system down, or logic failure. Must fix.
- **P1 (High):** Significant risk or degraded functionality. Fix or get explicit owner sign-off.
- **P2 (Medium):** Increased risk/friction. Mitigate or document.
- **P3 (Low):** Technical debt. Backlog.