Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add mamahoos/dot-files --skill constraint-driven-developmentgit clone --depth 1 https://github.com/mamahoos/dot-filesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mamahoos/dot-files/constraint-driven-development)<a href="https://agentmods.dev/skills/mamahoos/dot-files/constraint-driven-development"><img src="https://agentmods.dev/badge/skills/mamahoos/dot-files/constraint-driven-development/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mamahoos/dot-files/constraint-driven-development"><img src="https://agentmods.dev/badge/skills/mamahoos/dot-files/constraint-driven-development.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00176 | $0.04978 |
| Opus 5.5 | $0.00070 | $0.01991 |
| Sonnet 5.5 | $0.00035 | $0.00996 |
| Haiku 4.5 | $0.00018 | $0.00498 |
Grade A, and why
constraint-driven-development scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
98% identical to constraint-driven-development — 1 line differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 313 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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 none of it survives the end of the session.
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 proves it works. 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 autoor 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.mdand 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
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed · +22 tokens per session e9923eaf78ee
- 1mo ago First seen · 313 lines · 154 tokens per session scan A 63045a5769ce
constraint-driven-development is a skill published in the GitHub repository mamahoos/dot-files (5 stars, last pushed yesterday), licensed MIT. It adds 176 tokens to every session and 4,978 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 98% identical to constraint-driven-development, differing in 1 line, and is treated as a copy.
Other skills, from other repositories
gh-cli
GitHub CLI (gh) conventions and the inline PR review recipe. Use when working with GitHub repositories, PRs, issues, actions, gh api, or any GitHub operations from the command line.
gh-pr
This skill should be used when creating a GitHub pull request via gh pr create. Covers the gh CLI mechanics; PR title and body conventions come from the pr-style skill.
plan-loop
Plan work with the user in a PLAN.md, then implement it step by step, with /clear once the context fills up. Use before creating a plan, when the user mentions a PLAN.md, or when resuming work after /clear.
astro-dso-doc
Bootstraps a deep-sky object (DSO) astrophotography project from raw acquisition frames (own rig, not a smart telescope), AND generates a complete, polished HTML documentation page, a processing checklist, an AstroBin post JSON, a PixInsight process icon set (XPSM), and a ready-to-paste PixInsight project Description…
mbo-plan
Plan a new objective end-to-end in this repo's docs/mbo Management-By-Objective system — turn a GitHub issue or a gss draft-PR worktree into consistent design/spec/plan artifacts and track it in docs/mbo/index.md. Use this whenever the user wants to START planning or designing a new feature, skill, CLI, or service…
document-code
Apply Google Style documentation standards to Python, Go, TypeScript, and Terraform code. Use when writing or reviewing code that needs docstrings/comments/JSDoc, when asked to "document this code", "add docstrings", "follow Google Style", or when improving code documentation quality. Supports Python docstrings, Go…