sickn33/agentic-awesome-skills/constraint-driven-development

Constraint-Driven Development

Overview

Other skills in this pack describe what good looks like. code-review-and-quality gives you five axes. test-driven-development gives you a cycle. security-and-hardening gives you a threat list. All of that lives in prose the agent reads and may or may not follow, and persisted repository instructions can survive sessions, though prose alone does not enforce behavior.

This skill produces something different: a written record of this project's bar, with numbers, that outlives the conversation and can be checked mechanically.

The reason matters. When you wrote the code, reading it told you whether it was any good. An agent writes more in an afternoon than you will read that week, so the judgement moves out of your head and into checks that run around the loop. Those checks need to exist, they need numbers you actually chose, and they need to fire close enough to the work that the agent fixes its own output.

Spec-driven development says what to build. Test-driven development supplies evidence for tested cases. Constraint-driven development defines what "good enough to ship" means, before anyone argues about it in a pull request.

When to Use

Apply this skill when:

• Starting a project or a significant feature and no quality bar is written down
• The user asks to "set up constraints", "add quality gates", "define our standards", or "stop the agent shipping junk"
• An agent is producing volume nobody is reading line by line
• CI has checks but nobody can say which ones block a merge and which ones are decoration
• Coverage, performance, or accessibility numbers get argued about per-PR instead of decided once
• You're about to run /build auto or any autonomous loop, and the only thing standing between it and main is a test suite the agent also wrote

When NOT to use:

• The project already has a CONSTRAINTS.md and the user isn't changing it — read it and follow it instead
• One-off scripts, spikes, throwaway prototypes
• The user wants a code review right now (code-review-and-quality) or a CI pipeline built (ci-cd-and-automation)
• Pre-product-market-fit code with a two-week expected lifetime — the floor below is still worth it, the rest isn't

Loading Constraints

The interview needs a live user. Don't run it in non-interactive contexts (CI, /loop, autonomous runs). If constraints are missing and you're in one of those, apply the Floor below, note that you did, and flag the rest for a human.

The Process

Step 1: Detect before you ask

Never ask what you can read. Before the first question, gather:

Report what you found in two lines, then ask only what's left.

Step 2: Four questions, each with a default

Follow the one-question-at-a-time discipline from interview-me, with one change: every question here has a default, so "I don't know" is a complete answer that still produces a working config.

Q1: Beyond the floor, which of these do you want enforced?
    (a) Test coverage on new code
    (b) Security scanning
    (c) Performance budgets
    (d) Accessibility
    (e) Architecture boundaries
GUESS: (a) and (b) — you have a test runner already and you're handling user input.
DEFAULT if unsure: (a) and (b).
Say what each pick costs: (c) and (d) need a running URL, (e) needs a rules file written.

Q2: When a check fails while the agent is mid-task, should it block or warn?
GUESS: Block. You're running agents unattended and a warning nobody reads is a warning.
DEFAULT if unsure: Block on the floor, warn on everything else for the first two weeks.

Q3: Do you have target numbers in mind, or should I measure where you are today and hold that line?
GUESS: Measure. Most teams don't have a number, and an invented one gets ignored.
DEFAULT if unsure: Measure and hold. See "Ratchets" below.

Q4: What's the slowest check you'll tolerate before the agent hands work back?
GUESS: About 90 seconds. Longer and you'll stop running it.
DEFAULT if unsure: 90 seconds at task end, unlimited in CI.

Stop at four. A twelve-question intake produces a config nobody understands and a user who regrets starting.

Step 3: Write CONSTRAINTS.md

One file at the repo root. Any agent on any harness can read it, and a change to it shows up in review where it belongs.

# Constraints
 
Last reviewed: 2026-08-08 by @addy
 
## Floor (always enforced, no setup required)
 
-No new suppression comments: `@ts-ignore`, `eslint-disable`, `# noqa`, `# type: ignore`
-No unimplemented stubs: `throw new Error("Not implemented")`, empty `catch {}`
-No skipped or deleted tests without a reason in the commit message
-No secrets in source
-This file does not get weakened to make a change pass
 
## Enforced with numbers
 
| Dimension | Rule | Checked by | Runs at |
|-----------|------|-----------|---------|
| Types | Zero type errors | `tsc --noEmit` | every edit |
| Lint | Zero errors from our config | `biome check` | every edit |
| Secrets | No secrets in source | `gitleaks detect --redact` | every edit |
| Coverage | Changed lines ≥ 80% covered | `vitest run --coverage` + git diff | task end, CI |
| Security: code | No high findings | `semgrep scan --config p/default` | CI |
| Security: deps | Nothing at high or above | `osv-scanner scan source -r .` | CI |
| Accessibility | Zero critical or serious | `axe $PREVIEW_URL --tags wcag2a,wcag2aa,wcag21aa` | preview deploy |
| Performance | LCP ≤ 2500ms, CLS ≤ 0.1 | `lighthouse $PREVIEW_URL --output=json` | preview deploy |
 
Every row names the command that produces the verdict. A dimension with a
number and no command in this column is an aspiration, not a constraint.
 
## Measured, not yet enforced
 
| Metric | Today | Direction |
|--------|-------|-----------|
| Project coverage | 62.4% | must not fall |
| Bundle size (main) | 184 kB | must not grow |
 
## Exceptions
 
| ID | Rule | Path | Reason | Owner | Expires |
|----|------|------|--------|-------|---------|
| W1 | `no-explicit-any` | `src/legacy/**` | Rewrite tracked in ENG-441 | @addy | 2026-11-01 |

Then add one line to AGENTS.md and CLAUDE.md: Read CONSTRAINTS.md before writing code. Do not weaken it to make a change pass.

Step 4: Install what each dimension needs

Picking a dimension means installing something. Don't leave the user with a number and no mechanism, and don't invent your own checker when a de facto one exists — these tools are listed because their rule formats and thresholds are what everything else in the ecosystem targets, so the team's existing config keeps working.

Five things that will bite you if you skip them:

1. `--redact` on gitleaks is not optional. Without it the matched secret lands in the agent's transcript, which is how a leaked key ends up in a log, a summary, or a commit message. Report the rule and the location, never the value.
2. Lighthouse and axe need a URL. They only work against a running app, so they belong in the runtime stage against a preview deploy or a local server you start first. If the project has no URL to hit — a CLI, a library, a desktop app — say so and drop the dimension rather than inventing a check that can't run.
3. Scope the expensive ones to the diff. stryker run --mutate on the whole repo takes hours and gets turned off; on the files a change touched it takes under a minute. Same for Semgrep, which takes a path list.
4. Coverage needs no second test run. Read the lcov your suite already writes and intersect it with git diff. Running the suite twice to get a number is the fastest way to make people hate this.
5. Semgrep's registry rules are free to run; check the licence before redistributing them. opengrep is a drop-in fork with the same rule format and JSON output if that matters to your legal team.

Add each one to the project's own script so it's reproducible without an agent:

{
  "scripts": {
    "check:fast": "tsc --noEmit && eslint . && gitleaks detect --redact --no-banner",
    "check:task": "npm run check:fast && vitest run --coverage",
    "check:full": "npm run check:task && semgrep scan --config p/default && osv-scanner scan source -r ."
  }
}

That mapping matters more than the tools. check:fast is what runs after an edit, check:task when the agent thinks it's done, check:full in CI.

The commands now live in two places — the Checked by column in CONSTRAINTS.md and these scripts. CONSTRAINTS.md is the canonical source: it carries the reason alongside each command and it shows up in review. The scripts are convenience wrappers that must mirror it, not a second source of truth; if they drift, the file wins.

Step 5: Wire it to the lifecycle

The single biggest mistake is running everything everywhere. A check that stalls the agent gets switched off, and a gate people switched off is worse than no gate, because the bar still looks like it exists.

Two rules that keep this tolerable:

1. Scope to the diff. Check the lines this change touched, not the whole repo. Coverage of changed lines is a number the agent can move; project coverage is one it inherited.
2. Cost decides placement. Anything over a few seconds moves out of the edit loop. Mutation testing on a whole repo takes hours; on the files a change touched it takes under a minute, which is the difference between a check people run and one they don't.

Step 6: Guard the bar itself

Someone will point out that if the agent writes the code and the checks, the checks prove nothing. Half right, and worth engineering around.