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 vinvcn/addyosmani-agent-skills-zh --skill constraint-driven-developmentgit clone --depth 1 https://github.com/vinvcn/addyosmani-agent-skills-zhWrote 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/vinvcn/addyosmani-agent-skills-zh/constraint-driven-development)<a href="https://agentmods.dev/skills/vinvcn/addyosmani-agent-skills-zh/constraint-driven-development"><img src="https://agentmods.dev/badge/skills/vinvcn/addyosmani-agent-skills-zh/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/vinvcn/addyosmani-agent-skills-zh/constraint-driven-development"><img src="https://agentmods.dev/badge/skills/vinvcn/addyosmani-agent-skills-zh/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.00232 | $0.05754 |
| Opus 5.5 | $0.00093 | $0.02302 |
| Sonnet 5.5 | $0.00046 | $0.01151 |
| Haiku 4.5 | $0.00023 | $0.00575 |
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.
How it starts
The opening of the file, as written. The whole thing — 312 lines — stays where its author put it; the contents beside it link to each section on GitHub.
约束驱动开发
概览
本技能包里的其他 skill 描述的是“好”长什么样。code-review-and-quality 给你五个轴。test-driven-development 给你一个循环。security-and-hardening 给你一份威胁清单。所有这些都活在文字里，agent 读了可能照做也可能不照做，而且没有一个能活过会话结束。
这个 skill 产出的是别的东西：本项目质量线的书面记录，带数字，能活过对话，并且可以被机械地检查。
背后的原因很重要。当你亲手写代码时，读代码就能告诉你它好不好。一个 agent 一个下午写下的代码超出你一周能读完的量，于是判断就从你的脑子里挪到了围绕循环运行的检查里。这些检查需要存在，需要用到你真正选过的数字，而且需要离工作足够近，让 agent 能修好自己的产出。
Spec-driven development 说清楚要构建什么。Test-driven development 证明它能工作。Constraint-driven development 定义“好到可以发布”意味着什么——在任何人在 pull request 里为此争吵之前。
何时使用
在以下情况应用这个 skill：
- 启动一个项目或一个重要功能，而没有任何质量线被写下来
- 用户要求 "set up constraints"、"add quality gates"、"define our standards" 或 "stop the agent shipping junk"
- Agent 在产出没人逐行阅读的体量
- CI 有检查，但没人说得清哪些会阻塞合并、哪些只是摆设
- 覆盖率、性能或无障碍性的数字在每个 PR 上被争论，而不是被一次性决定
- 你正准备运行
/build auto或任何自主循环，而它和 main 之间唯一的屏障是一套 agent 自己写的测试
何时不要使用：
- 项目已经有
CONSTRAINTS.md而用户并不想改它——去读它并遵循它 - 一次性脚本、spike、用完即弃的原型
- 用户现在就要 code review（
code-review-and-quality）或要搭 CI pipeline（ci-cd-and-automation） - product-market fit 之前的代码，预期寿命两周——下面的 floor 仍然值得，其余的不值得
加载约束
这场访谈需要一个活的用户。不要在非交互上下文中运行它（CI、/loop、自主运行）。如果你在其中之一里且约束缺失，套用下面的 Floor，注明你这样做了，并把剩下的标记出来交给人来处理。
流程
Step 1: 先检测，再提问
能读到的东西绝不要问。在第一个问题之前，先收集：
| 看什么 | 去哪看 |
|---|---|
| 语言与技术栈 | package.json、pyproject.toml、go.mod、Cargo.toml |
| 测试 runner | dev 依赖、test script、已有的测试文件 |
| 已有的 linter | eslint.config.*、biome.json、.ruff.toml |
| 当前覆盖率 | coverage/ 输出，或把套件跑一遍 |
| CI | .github/workflows/、.gitlab-ci.yml |
| Agent harness | .claude/、.codex/、AGENTS.md |
用两行汇报你发现的东西，然后只问剩下的。
Step 2: 四个问题，每个都带默认值
遵循 interview-me 的一次一问纪律，只有一个变化：这里的每个问题都有默认值，所以 "I don't know" 也是一个完整的答案，并且仍能产出可用的配置。
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.
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 First seen · 312 lines · 232 tokens per session scan A f2f99812d73f
constraint-driven-development is a skill published in the GitHub repository vinvcn/addyosmani-agent-skills-zh (40 stars, last pushed 1mo ago), licensed MIT. It adds 232 tokens to every session and 5,754 once invoked, about $0.0009 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-16.
Other skills, from other repositories
test-driven-development
Drives development with tests via Red-Green-Refactor and the Prove-It pattern, with hard rules against weakening assertions or faking green suites. Use when implementing any logic, fixing any bug, or changing any behavior. Triggers on "add a feature", "fix this bug", "write tests", or any task where done must be…
spec-driven-development
Creates specs before coding, with hard rules against silently filled assumptions and untestable success criteria. Use when starting a new project, feature, or significant change and no specification exists yet. Triggers on "build me", "create a", "add a feature", or any requirement vague enough to need interpretation.
test-driven-development
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Use when asked to add tests to a function, fix a bug…
tdd
Test-driven development, from unit to end-to-end tests. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration or end-to-end tests (Playwright, Cypress). Don't use to backfill tests on existing code (/refactor) or diagnose an unknown bug (/debug).
chaos-engineering
Guides systematic fault injection and resilience testing. Use when designing for high availability, verifying disaster recovery, testing failure modes, or building fault-tolerant systems. Use when you need to prove your system survives infrastructure failures, network partitions, dependency outages, or cascading…
test-driven-development
Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.