constraint-driven-development

Constraint-Driven Development

Overview

Other skills describe what good looks like: code-review-and-quality gives five axes, test-driven-development a cycle, security-and-hardening a threat list. That is prose an agent may or may not follow, and none of it survives the session. This skill produces a written record of this project's bar, with numbers and the command that checks each one, that outlives the conversation and runs mechanically.

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

Spec-driven development says what to build. Test-driven development proves it works. Constraint-driven development defines "good enough to ship" before anyone argues about it in a pull request.

When to Use

• Starting a project or significant feature and no quality bar is written down
• The user asks to "set up constraints", "add quality gates", "define our standards"
• An agent is producing volume nobody reads line by line
• CI runs lint, detekt, and tests, but nobody can say which ones block a merge
• Coverage, startup time, APK size, or accessibility get argued per PR instead of decided once
• Before /build auto or any autonomous loop, where the only thing between the agent and main is a test suite the agent also wrote

Skip when:

• CONSTRAINTS.md already exists and the user isn't changing it — read and follow it
• Spikes, throwaway prototypes, one-off scripts
• The user wants a review now (code-review-and-quality) or a pipeline built (ci-cd-and-automation)

Non-interactive contexts (CI, scheduled loops, autonomous runs): the interview needs a live user. If constraints are missing, apply the Floor below, say you did, and flag the rest for a human.