sjinks/specification-skills

Use when: writing, rewriting, or auditing acceptance criteria, definition-of-done lists, or user-story AC for quality: testable, observable, single, scoped, and implementation-neutral, plus a coverage check, so each criterion can be objectively verified before work starts.

Use when: merging, unifying, or de-duplicating several same-kind planning artifacts (multiple specifications, architectures, or test plans) into one; reconciling colliding stable IDs across documents; building a single open-questions ledger; or marking superseded source documents for removal without losing requirements.

Use when: surfacing implicit assumptions in a spec, plan, design, or estimate before work starts: data shapes, ordering, scale, auth context, environment, compatibility, dependency behavior, and people-process expectations, classifying each as verify-before-build or accept-with-risk.

Use when: a specification, architecture, README, or other doc claims to reflect the current implementation ('amended from implementation', 'current state') and may have drifted; verifying file extensions, target/example names, dependency lists, public type/option/enumerator names, and baked-in counts against the live tree; or flagging stale 'excluded/absent' claims before trusting a doc.

Use when: sharpening a software requirement or a requirement set so it is buildable and decidable rather than merely well-formed - replacing vague quality words and quantifiers with a measured threshold plus a named measurement method, eliminating requirements that defer their own observable behavior to a later decision, decoupling a requirement from named implementation files or symbols so it survives refactors, making MUST/SHOULD/MAY rankings actually discriminate instead of everything being mandatory, adding a completeness matrix against a standard or dependency the spec leans on, and asserting a bidirectional traceability invariant as a mechanical gate.

Use when: auditing a draft specification, requirements document, feature request, user story, or product brief for ambiguity: vague quantifiers, undefined terms, TBD placeholders, conflicting requirements, missing actors, or untestable wording, before implementation planning starts.

Use when: defining or auditing the scope of a feature, project, spec, or task: explicit in-scope and out-of-scope lists, non-goals, deferred items, smallest valuable slice, and scope-creep risks, before work is planned or estimated.

Use when: enumerating edge cases for a feature spec, user story, or behavior description before implementation: empty and boundary inputs, error paths, permissions, concurrency, time, locale and text, limits, and lifecycle states, deciding which belong in the spec.