speclisted

# ASK Spec Formalize agreed intent into one traceable specification and engineering contract before development. The agent must establish what is agreed, why it is believed, how it is observed, and what evidence will prove it. Humans own decisions; downstream agents should not need to rediscover intent. ## Proportionality - **Trivial** — skip heavy spec; use `intake` or direct execution. - **Normal** — requirements, decisions, constraints, non-goals, and observable acceptance criteria. - **Complex, risky, or release-sensitive** — add relevant assumptions, invariants, proof obligations, counterexamples, dependencies, compatibility constraints, change impact, and audit expectations. Classify requirements by impact: **ordinary** = local behavior; **material** = violation could affect behavior, correctness, data, compatibility, architecture, ownership, routing, security, production safety, or release readiness; **critical** = material with severe potential impact. Material and critical requirements need deeper detail. Use impact, not numeric scoring or document size. Do not catalogue every edge case. ## Flow **Capture** — record need, context, goals, scope, non-goals, stakeholders, constraints, risks, dependencies, compatibility boundaries, open questions, and assumptions. Flag ambiguity; never assume. Keep the artifact proportional: ordinary work may need only a short requirements and acceptance record. When a single requirement spans several independently testable capabilit