continuous-specificationlisted

## Context marker 🔴🟢🌀 When the skill activates, begin the first commentary update with `🔴🟢🌀` and a concise `Using continuous-specification ...` announcement. Do not repeat the marker on later updates unless another skill activates. # Continuous Specification Use short feedback loops so design emerges from executable behavior rather than speculation: ``` Set → Meet → Minimize → Commit → Design ``` **REQUIRED SUB-SKILL:** Use `describe-structure` whenever adding or editing a behavior specification. Keep user requirements authoritative throughout the loop. Treat executable expectations as the authority for implemented behavior and planned `[EXPECT]` items as the completeness ledger. A green suite proves neither that a new expectation is sensitive nor that every requested behavior is complete. ## Scope Apply this workflow to every behavior-changing production edit, including a fix inside an otherwise non-behavioral task. Do not force it onto documentation, formatting, generated output, or a demonstrably behavior-preserving rename or move. For an exploratory spike, confirm that the code is disposable; start this workflow before turning spike code into maintained production code. If the user explicitly asks to skip specifications, obey and state what verification will replace them. Never use "spike," "trivial," or "already covered" as an unspoken escape hatch. Follow repository-native language, framework, naming, and file-layout conventions. Use Continuous Specific