constraint-engineering

name	constraint-engineering
description	Use when a team wants to apply the Constraint Engineering guideline to a feature or repo — audits the current repo against an 8-item build checklist (spec-first, small checked steps, right-sized models, fast checks, an independent reviewer, isolated workspaces, hard safety rules, tracked outcomes), and generates copy-ready, stack-adapted template files. Trigger phrases — "apply constraint engineering", "help me write a spec for this feature", "audit this repo against the constraint engineering checklist", "set up an independent AI reviewer", "is this repo AI-SDLC S2 or S3 ready".
allowed-tools	Read Grep Glob Write
effort	medium

Constraint Engineering — audit and starter kit

AI does whatever a team didn't explicitly forbid or specify. This skill closes that gap two ways: it audits the current repo against a checklist of 8 concrete things, and it generates copy-ready starter files, adapted to whatever language/build tool this repo actually uses — never assume Java, Node, Python, or any other stack.

Full background (the 5 habits of mind behind the checklist, and why each checklist item matters): references/checklist.md. Read it once per session before acting, not on every invocation.

When invoked

Figure out which of the two modes the user wants — ask if it's ambiguous:

1. Audit mode — "how close is this repo to the checklist?"
2. Generate mode — "help me apply this to a specific feature I'm about to build."

Audit mode

1. Detect the stack: look for pom.xml/build.gradle (Java/Maven/Gradle), package.json (Node), requirements.txt/pyproject.toml (Python), go.mod (Go), etc. Don't assume — check.
2. Check each of the 8 items against what actually exists in the repo (not what a README claims):
   • Spec-first (1) — is there a specs/ or docs/*.spec.md convention, or do features get built straight from a ticket with no written acceptance criteria?
   • Planner/builder split (2) — do .claude/agents/*.md show one agent that plans without an Edit/Write tool, dispatching to others that build?
   • Right-sized models (3) — do agent frontmatter model: fields vary by role, or is everything on the same tier?
   • Fast check after every edit (4) — does .claude/settings.json or a plugin's hooks.json run a PostToolUse check (lint/type-check/test) after Edit/Write?
   • Independent reviewer (5) — is there a review agent with no Edit tool, distinct from the implementer?
   • Isolated workspace per task (6) — does any workflow reference git worktree?
   • Hard safety rules (7) — does this repo (or a plugin it depends on) declare a base-tools dependency in its own plugin.json, or ship its own PreToolUse deny hooks?
   • Tracked outcomes (8) — any OTEL_* environment variables or custom telemetry tags?
3. Report a plain checklist: ✅ present / ⚠️ partial / ❌ missing, one line per item, with the file path that proves it (or "not found") — no item gets marked present on a guess.
4. For every ❌ or ⚠️, name the single cheapest fix (often: "add a dependencies line" beats "build a new agent architecture"). Do not recommend the same fix for every gap — read references/checklist.md's "cheapest fix first" framing.

Generate mode

1. Ask the user for a one-paragraph description of the feature, and specifically: what must always be true, and what must never happen. If they don't know the "must never happen" part yet, that question itself is the point — don't let them skip it.
2. Copy ../../templates/spec.template.md, fill in Requirements / Acceptance Criteria / Out of scope from their answer, and write it to wherever this repo keeps specs (ask if unclear; default specs/<feature-slug>.spec.md).
3. Copy the four agent templates from ../../templates/agents/, filling in the tools: frontmatter with a Bash scope that matches the detected stack (e.g. Bash(mvn test:*) for Maven, Bash(npm test*) for Node, Bash(pytest*) for Python) — never leave the {{scoped_test_command}} placeholder unfilled in what you write out.
4. Copy ../../templates/hooks.template.json, filling in the same stack-appropriate fast-check command for the PostToolUse entry. The file's shape (a top-level hooks object) is already correct for either destination: a repo's .claude/settings.json (merge it under that file's own hooks key) or a plugin's standalone hooks.json (drop the whole file in as-is, same shape as plugins/base-tools/hooks.json).
5. Point them at ../../example/ if they want to see all of the above already filled in for a worked (if generic) feature, before doing their own.
6. Do not silently skip the "must never happen" rule when writing the reviewer template's acceptance-criteria mapping — that rule is exactly what an independent reviewer exists to enforce.

What this skill deliberately does not do

• It does not install or modify base-tools' hooks — those come from the dependencies line in this plugin's own plugin.json; this skill only reports whether they're present.
• It does not pick a stack for the user — it detects one from the repo and asks if detection is ambiguous (e.g. a monorepo with more than one).
• It does not fabricate an audit result for an item it can't actually verify by reading a file.