home / skills / matthew-plusprogramming / monorepo / enforce

enforce skill

/.claude/skills/enforce

This skill validates atomic specs achieve appropriate granularity and complete requirements coverage to prevent under or over splitting.

npx playbooks add skill matthew-plusprogramming/monorepo --skill enforce

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.3 KB
---
name: enforce
description: Validate atomic specs meet atomicity criteria
allowed-tools: Read, Glob, Task
user-invocable: true
---

# /enforce Skill

## Purpose

Validate that atomic specs are at the right level of granularity—not too coarse (needs splitting) and not too granular (needs merging). Also verifies complete requirements coverage.

## Usage

```
/enforce                      # Validate current spec group
/enforce <spec-group-id>      # Validate specific spec group
/enforce --strict             # Treat warnings as failures
```

## Prerequisites

Before running `/enforce`:
1. Spec group must exist with `manifest.json`
2. `requirements.md` must exist
3. `atomic/` directory must contain atomic specs (from `/atomize`)

## Process

1. **Locate spec group**
   - If no ID provided, look for active spec group
   - Validate required files exist

2. **Dispatch atomicity-enforcer agent**
   ```
   Task: atomicity-enforcer
   Prompt: Validate atomic specs in <spec-group-path>
   Mode: standard | strict
   ```

3. **Generate enforcement report**
   - Agent creates `enforcement-report.md` in spec group
   - Updates `manifest.json` with enforcement status

4. **Report to user**
   - Overall status (PASSING, WARNINGS, FAILING)
   - Summary of issues
   - Next steps

## Validation Criteria

### TOO_COARSE (needs splitting)
- Contains multiple distinct behaviors
- Would require multiple test suites
- Cannot partially roll back
- Reviewer needs sibling context

### TOO_GRANULAR (needs merging)
- Cannot test in isolation
- Cannot deploy meaningfully alone
- Describes code fragment, not behavior
- No standalone user value

### JUST_RIGHT (passing)
- Single testable behavior
- Deployable as standalone PR
- Reviewable without siblings
- Reversible without breaking others

### Coverage
- Every REQ-XXX must appear in at least one atomic spec

## Output

### PASSING

```
Enforcement passed for sg-logout-feature ✓

All 5 atomic specs meet atomicity criteria
Requirements coverage: 100% (4/4)

Spec group ready for user review.
Run /approve or review atomic specs in:
  .claude/specs/groups/sg-logout-feature/atomic/
```

### WARNINGS

```
Enforcement completed with warnings for sg-logout-feature

Status: WARNINGS (2 issues)

Passing: 4/5 atomic specs
Warnings:
  - as-003: Atomicity justification could be stronger

Requirements coverage: 100%

Options:
  1. Proceed to implementation (warnings are advisory)
  2. Run /atomize --refine to address warnings
  3. Run /enforce --strict to enforce stricter standards
```

### FAILING

```
Enforcement failed for sg-logout-feature ✗

Status: FAILING (3 issues)

Issues:
  - as-002: TOO_COARSE — Contains logout AND session cleanup
    → Recommend: Split into as-002a (logout), as-002b (cleanup)

  - as-005: TOO_GRANULAR — Cannot test without as-004
    → Recommend: Merge with as-004

  - MISSING_COVERAGE: REQ-003 not covered by any atomic spec
    → Recommend: Create new spec or expand existing

Next step: Run /atomize --refine to address issues
```

## Strict Mode

With `--strict`:
- All WARNINGS become FAILING
- Used before implementation to ensure maximum atomicity discipline
- Recommended for complex or high-risk features

## Integration with /atomize

The `/atomize --auto-enforce` flag creates a loop:

```
/atomize
    ↓
/enforce (automatic)
    ↓
If FAILING → /atomize --refine → /enforce
    ↓
Repeat until PASSING or max iterations
```

## State Transitions

After `/enforce`:

**If PASSING:**
- `manifest.json`:
  - `atomic_specs.enforcement_status`: "passing"
  - `atomic_specs.last_enforced`: <timestamp>
- Spec group ready for `review_state` → APPROVED

**If WARNINGS:**
- `manifest.json`:
  - `atomic_specs.enforcement_status`: "warnings"
- User decides whether to proceed or refine

**If FAILING:**
- `manifest.json`:
  - `atomic_specs.enforcement_status`: "failing"
- Must run `/atomize --refine` before implementation

## Edge Cases

### No Atomic Specs
```
Error: No atomic specs found in spec group
Run /atomize first to decompose spec.md
```

### Requirements Changed
```
Warning: requirements.md modified since last atomization
Coverage check may be inaccurate
Consider re-running /atomize
```

### Circular Dependencies Detected
```
Error: Circular dependency detected
  as-002 depends on as-003
  as-003 depends on as-002

This indicates specs are not truly atomic.
Run /atomize --refine to restructure.
```

Overview

This skill validates that atomic specs meet atomicity criteria and verifies requirements coverage for a spec group. It detects specs that are too coarse, too granular, or correctly scoped, and it writes an enforcement report and updates enforcement status in the spec manifest. Use it to gate readiness for review and implementation.

How this skill works

The skill locates the target spec group (or the active group when none is provided), confirms required files exist, and dispatches an atomicity-enforcer agent to inspect all atomic specs. It evaluates each spec against defined rules for TOO_COARSE, TOO_GRANULAR, and JUST_RIGHT, checks that every requirement ID appears in at least one atomic spec, and produces an enforcement-report.md and status updates in the manifest. A summary status (PASSING, WARNINGS, FAILING) and actionable next steps are returned to the user.

When to use it

  • Before moving a spec group to implementation or review
  • After atomizing a spec group or running /atomize --auto-enforce
  • When enforcing strict atomicity for high-risk or complex features (--strict)
  • When requirements changed and you must verify coverage
  • When CI or release gates require confirmed atomic specs

Best practices

  • Run /enforce after every atomization iteration to catch issues early
  • Use --strict before final approval to convert warnings into failures
  • Address TOO_COARSE by splitting into single-behavior specs with independent tests
  • Address TOO_GRANULAR by merging fragments into deployable, testable behaviors
  • Keep requirements.md synchronized with specs to avoid coverage warnings

Example use cases

  • Validate a new feature spec group to ensure it can be reviewed and merged as standalone PRs
  • Automate an atomize→enforce loop to iterate until PASSING before implementation
  • Detect missing REQ-XXX coverage after requirements were updated
  • Find and resolve circular dependencies among atomic specs
  • Enforce stricter discipline for a security-sensitive feature using --strict

FAQ

What does TOO_COARSE mean?

A spec contains multiple distinct behaviors that should be split into separate atomic specs, each testable and reversible independently.

What happens when --strict is used?

All warnings are treated as failures so the run only passes when every item meets the highest atomicity standards.

How are requirements coverage issues reported?

Missing REQ-XXX entries are listed as coverage failures with recommendations to create or expand atomic specs to include them.