<< All versions
Skill v1.0.0
currentLLM-judged scan90/100bingordinary/specflow/solution-design
──Details
PublishedOctober 21, 2026 at 09:42 PM
Content Hashsha256:e28d518eb1b2621e...
Git SHAd7df6fbae7af
──Files
Files (1 file, 2.1 KB)
SKILL.md2.1 KBactive
SKILL.md · 47 lines · 2.1 KB
version: "1.0.0" name: solution-design description: Use when the goal and scope are clear enough to discuss design, but the solution direction, tradeoffs, affected formal objects, or candidate writeback content are not yet locked.
Solution Design
Purpose
Use this skill to compare solution directions before writing candidate truth.
The design is still discussion-stage material. Only the approved direction written into candidate Spec becomes durable truth.
Process
- Start from the confirmed goal, scope, success criteria, and non-goals.
- Present two or three materially different approaches when meaningful alternatives exist.
- For each approach, state:
- core idea
- benefit
- cost
- likely unit, rule, or global rule impact
- verification implication
- Explain likely formal-object impact as an executor-facing consequence, not as terminology the user must already understand.
- Recommend one approach with the shortest path that satisfies the confirmed goal.
- Ask for only the ordinary-language decision that blocks candidate writeback.
- If the selected approach spans a user-flow anchor and one or more local capability chains, describe that as a development chain and still route only to the first legal writeback step.
Output Shape
optionsrecommended_optiontradeoff_reasonaffected_formal_objectsverification_implicationscandidate_writeback_itemsdecision_neededplain_language_decision_question
Boundaries
- Do not preserve multiple unresolved options in candidate truth as if they were all current behavior.
- Do not choose a Rule or global rule owner by directory shape alone.
- Do not begin implementation from a selected option until formal truth writeback has happened — candidate spec first, then code, per
framework/concepts.md. Gates control promotion, not the start of editing: normal units use validate/verify; rules use validate only. - Do not ask the user to choose internal command names or object-family names when the design choice can be framed as a user-facing behavior, scope, or verification decision.