CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

constraint-driven-development

Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is exceptionally actionable and well-sequenced: every step carries executable commands, thresholds are paired with rationales, validation is explicit, and the two bundle references are real, well-signaled, and load-bearing. Its main weakness is length — motivational and argumentative prose (Overview, rationalizations table, training-rewards paragraph) inflates the file beyond what the instructions require.

Suggestions

Cut the motivational prose to one or two sentences per section: the Overview's second and third paragraphs, Step 6's 'Someone will point out...' opener, and Step 7's closing paragraph about training rewards are argumentation for humans, not execution guidance.

Move the 'Common Rationalizations' table and the dimension→tool install matrix (Step 4) into a reference file, keeping SKILL.md to the process, the floor, and the defaults table — the two existing references show the pattern works.

Trim the CONSTRAINTS.md template to its structural skeleton (section headings plus one example row per table) since the full example duplicates rows the tool table already enumerates.

DimensionReasoningScore

Conciseness

Mostly dense and actionable (tables, commands, thresholds), but it carries trimmable motivational/editorial prose: the three-paragraph Overview ("The reason matters. When you wrote the code, reading it told you whether it was any good"), "Spec-driven development says what to build. Test-driven development proves it works", Step 6's opener ("Someone will point out that... Half right"), Step 7's closing paragraph about training rewards, and the persuasive "Common Rationalizations" table. This fits 'mostly efficient but includes some unnecessary explanation or could be tightened'; it avoids level 2 because it never pads with concepts Claude already knows, but exceeds level 4's 'minor instances' — several paragraphs are argumentation rather than instruction.

3 / 5

Actionability

Fully executable throughout: a complete package.json scripts block ("check:fast": "tsc --noEmit && eslint . && gitleaks dir . --redact --no-banner"), exact per-dimension install/run/gate commands (vitest run --coverage, osv-scanner scan source -r ., lighthouse $PREVIEW_URL --output=json), a full CONSTRAINTS.md template, a defaults table pairing every number with its reason, and shipped working scripts (scripts/quality-gate.mjs, references/floor-guard.md). Copy-paste ready and covering common cases across stacks, matching the level-5 anchor.

5 / 5

Workflow Clarity

Steps 1–7 are explicitly sequenced with commands and a detect-before-ask table, and validation is explicit and recurring: "Before calling any row enforced, run its actual CI command against a known violation and a clean control. Confirm that the violation fails, the control passes, and scanner errors fail too", plus a final Verification checklist and Red Flags list. The shipped scripts even encode error-recovery semantics (exit 2 never reads as clean), matching the level-5 anchor with explicit validation and feedback loops.

5 / 5

Progressive Disclosure

Both bundle files are real and clearly signaled at the point of need ([references/floor-guard.md], [scripts/quality-gate.mjs]), one level deep with no nested chains, and the body is well sectioned. However, the ~320-line body inlines substantial content that could live in references (the dimension→tool install matrix, the full CONSTRAINTS.md template, the rationalizations table), so SKILL.md is more than a lean overview — fitting 'good structure; most content appropriately placed; minor organization gaps' rather than the level-5 clear-overview ideal.

4 / 5

Total

17

/

20

Passed

Description

88%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description in third-person voice with concrete actions anchored to specific artifacts (CONSTRAINTS.md, named suppression comments) and an explicit, multi-scenario 'Use when' clause. The only weaknesses are a few missing natural trigger variations and minor overlap risk with closely related quality-gate skills. No suggestions needed.

DimensionReasoningScore

Specificity

Lists multiple concrete actions with exact artifacts: "Establishes a project's quality bar as a written contract", "Interviews the user on which dimensions matter", "supplies sane default thresholds", "records everything in CONSTRAINTS.md", and "watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down". Coverage is comprehensive down to named suppression comments, matching the level-5 anchor rather than the minor-gaps level-4 anchor.

5 / 5

Completeness

Clearly answers both: the 'what' enumerates concrete actions (interview, default thresholds, CONSTRAINTS.md, diff watching) and an explicit "Use when..." clause lists seven concrete trigger scenarios. The when-clause is explicit and specific, matching the level-5 anchor; level 4 requires a when-clause that 'could be more explicit', which does not apply.

5 / 5

Trigger Term Quality

Good natural-phrase coverage: "set up constraints", "define our standards", "accessibility, web performance, coverage", "keeps silencing checks or skipping tests to get to green", "don't know what number to pick". A few natural terms users would say are absent (e.g., "quality gates", "stop the agent shipping junk" — the latter appears only in the body), so it fits 'good keyword coverage; a few natural terms missing' rather than comprehensive.

4 / 5

Distinctiveness Conflict Risk

The CONSTRAINTS.md contract and diff-watch framing carve a clear niche distinct from code-review, TDD, or CI skills, and the description itself differentiates ("stops agents quietly lowering it"). However, triggers like "define our standards" and threshold-setting requests could plausibly overlap with adjacent quality/CI-pipeline skills, so it fits 'mostly distinct; minor overlap risk with closely related skills' rather than the minimal-conflict level-5 anchor.

4 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

addyosmani/agent-skills

Path

skills/constraint-driven-development/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.