# Enforcement Agent

> Build a project-specific standards enforcement agent

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

---


# Enforcement Agent Skill

Create an agent that automatically checks code changes against documented standards in real-time.

## Context

An enforcement agent runs automatically before/after code edits to verify compliance. Unlike ceremonies (which are human-driven reviews), enforcement agents provide instant feedback while you're writing code.

## Domain Context

The Standards Enforcer Agent checks code against standards and reports violations with specific fixes. It reads:

1. Changed files (from git diff or provided list)
2. Applies a file-to-standards mapping
3. Reads applicable standards
4. Checks code against each rule
5. Reports violations with severity and fixes

Reference: `levels/L3-enforcement/agents/standards-enforcer.md`

## Instructions

1. **Define file-to-standards mapping** — Which files trigger which standards?
   - Create a mapping table: File Pattern → Applicable Standards
   - Example:
     ```
     *.ts, *.tsx → docs/standards/engineering/typescript.md
     src/api/** → docs/standards/engineering/api-design.md
     *.md → docs/standards/quality/documentation.md
     ```
   - Be specific about patterns (use glob format)
   - One file pattern can map to multiple standards
   - Deliverable: Complete file-to-standards mapping

2. **Set severity levels** — Categorize violations by impact
   - **ERROR** — Blocks merge, violates security or core principles
   - **WARN** — Should be fixed, degrades maintainability/accessibility
   - **INFO** — Nice to fix, style/preference
   - For each standard rule, determine its severity
   - Document why: "ERROR because of security implication"
   - Deliverable: Standards with severity levels assigned

3. **Write output format** — How should violations be reported?
   - Standard format (see reference):
     ```
     [SEVERITY] file:line
     Rule: standard#section
     Expected: [what rule requires]
     Found: [what code does]
     Fix: [concrete code example]
     ```
   - Deliverable: Output format template

4. **Integrate with PR workflow** — Where does enforcement happen?
   - **Option A:** Pre-hook (before tool use) — Catches obvious violations early
   - **Option B:** Post-hook (after tool use) — Catches complex violations after code written
   - **Option C:** As explicit command — User runs `/enforce` to check
   - Choose based on team preferences (balance between helpfulness and interruption)
   - Deliverable: Decision on integration point

5. **Test with examples** — Verify agent works correctly
   - Create 3-5 test scenarios: compliant code, code with WARNING, code with ERROR
   - Run agent on test scenarios
   - Verify: Correct violations detected, severity assigned correctly, fixes are actionable
   - Deliverable: Test results showing agent works as expected

6. **Document [CUSTOMIZE] markers** — Make agent reusable across projects
   - Standard names that will change between projects: [CUSTOMIZE]
   - File paths that are project-specific: [CUSTOMIZE]
   - Severity levels that might differ: [CUSTOMIZE]
   - Deliverable: Agent definition with [CUSTOMIZE] markers for portability

## Anti-Patterns

1. **Hardcoding rules instead of reading standards** — Fragile enforcement
   - Wrong: Agent has rule logic embedded in code: `if (hasAnyType) { error() }`
   - Right: Agent reads standard file and extracts rules dynamically
   - Impact: When standard updates, agent is out of sync
   - Guard: Agent should always reference standard files, not embed rules

2. **Overly strict enforcement blocking productivity** — Team disables agent
   - Wrong: Agent blocks on style issues (indentation, comment length)
   - Right: Agent blocks on substantive issues (security, architecture violations)
   - Impact: Team disables agent because it's too noisy
   - Guard: Discuss with team: which violations should ERROR vs WARN vs INFO?

3. **False positives from ambiguous standards** — Creates noise
   - Happens when: Standard rule is vague and can be interpreted multiple ways
   - Example: "Code should be clean" → no clear violation
   - Guard: Only enforce standards with specific, measurable rules
   - If you can't code it as a check, it's too vague to enforce

4. **Agent doesn't cite the standard** — User can't understand violation
   - Wrong: "Remove any type" (no citation)
   - Right: "Remove any type (see docs/standards/engineering/typescript.md#Type Safety)"
   - Impact: User doesn't know why violation matters
   - Guard: Every violation message must include standard file + section name

## Further Reading

- `levels/L3-enforcement/agents/standards-enforcer.md` — Reference agent definition
- `levels/L1-context/library/` — Reference standards to enforce
- `levels/L3-enforcement/hooks/` — Hook configurations for integration