spec-principles

Specification principles use IS/IS-NOT distinctions to separate target states from implementation decisions, constraining design to specify user-visible choices while leaving internal choices open to prevent ambiguity in software projects.

Review a specification document by applying structured quality checks to detect common anti-patterns such as explanatory notes, phase markers, and vague language, ensuring declarative statements and explicit cross-implementer decisions are used for consistency.

Apply IS/IS-NOT distinctions during drafting by explicitly defining what the target state is and what it is not, separating the desired outcome from implementation decisions to create clear, testable project requirements.

Yes, you can use this specification review approach for any software product team, as it guides drafting, reviewing, and evaluating specifications across projects without requiring specific dependencies or component setups.

The best way to constrain design in a specification is by specifying user-visible decisions explicitly while leaving internal implementation choices open, ensuring the design is constrained without unnecessarily restricting the implementer.