constraints-extractor

Constraints Extractor

Extract explicit and implicit constraints from project documentation and synthesize them into a canonical CONSTRAINTS.md — a living record of the externally-imposed boundaries (compliance, security, hosting, tooling, stakeholder, scope, dependency) that shape what a project can build and how.

Relationship to Other Living Documents

This skill is deliberately narrow. If a piece of content isn't clearly a constraint, it stays out of this file. Apply the forcing-function test before writing anything down:

Forcing-function test: if this were ignored, would something break OUTSIDE
the codebase — a contract, a law, a security posture, an executive decision,
a vendor relationship? If yes, it's a constraint.

If the honest answer is "the team would just be inconsistent" or "it would
look different," it's a pattern or a procedure, not a constraint — it
belongs in config.yaml or AGENTS.md instead.

Full category definitions, the forcing-function test worked through in detail, and an in-scope/out-of-scope example table per category live in references/category-guide.md — read it before running per-document extraction.

Output Location

Determine where CONSTRAINTS.md belongs before scanning anything, so Source Discovery knows to treat an existing file as authoritative rather than as scan fodder.

1. Search the repository for an existing CONSTRAINTS.md file before doing anything else. Use a repo-wide search (find, rg, or equivalent), not a narrow check of only the root or docs/. If exactly one exists, that is the target — use it, don't ask.
2. If more than one CONSTRAINTS.md exists, stop and show the matches. Ask the user which one is authoritative rather than guessing.
3. If nothing exists, default to CONSTRAINTS.md at the repo root, alongside ARCHITECTURE.md and AGENTS.md.
4. Announce the chosen path before proceeding: "No existing CONSTRAINTS.md found — I'll write to ./CONSTRAINTS.md."