Behavioral Specification

Use this skill for substantive behavioral specification. It provides common reasoning for behavioral requirements, quality scenarios, and shared semantic contracts.

Expand the consequences of the anchor, not the scope of the product. Use lightweight goal refinement and obstacle analysis to produce the smallest coherent set of observable obligations. Thoroughness means covering material meaning, not maximizing artifact count or claiming to exhaust every imaginable case.

Boundary

Own what must be observably or semantically true, not structural realization. Do not choose components, schemas, protocols, storage, libraries, deployment topology, or implementation mechanisms unless accepted external/product authority itself fixes them.

An agent writing specifications may resolve ordinary semantic detail within the agreed task. It may not silently create a new capability, scope, material guarantee, risk acceptance, or user-reserved preference. This method adds no roles, approval stages, or mandatory modeling notation. An "anchor" here means the project's agreed product intent or brief, not a required artifact system.

Make the intended behavior easy to check

For substantial requirements, start the bundle index or existing overview with a brief explanation in everyday language: what the user wants to accomplish, what success looks like, one useful example (including an important failure when relevant), and what is deliberately outside scope. This lets the user check the interpretation before technical wording spreads into design and architecture. It is an explanation of the accepted requirements, not a second source of requirements. If the explanation and precise clauses disagree, resolve the mismatch; don't bury it in jargon or silently invent a stronger promise. Ordinary specification choices remain with the author, not a new user sign-off.

Improve existing requirement documents

When an existing requirement bundle relevant to the task is too opaque for a reader to verify the intended behavior, revise the unclear explanation and the affected requirement wording where needed, rather than adding a second summary that disagrees with the clauses. Preserve accepted meaning, identifiers, source links, priority, conditions, exceptions, verification criteria, and relationships. Replace unnecessary jargon with observable examples; keep exact terms where they distinguish real guarantees.