design-structure
Design Structure
Overview
This skill turns a vague idea into an initial design tree through a two-phase workflow:
- Interactive confirmation — progressively confirm
design_target_type, problem, scope, and assumptions with the user - Design tree generation — produce the design tree based on confirmed inputs
Its primary output is design_state.
When the initial tree first becomes stable enough to reference safely, persist it as the authoritative design artifact in the designated directory docs/design-tree/ before handing off to the next design step.
When to Use
Use this skill when:
- the user has an idea but not a design
- the task lacks scope, boundaries, core objects, or key flows
- there is no clear design tree yet
More from freeacger/loom
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
23writing-clearly-and-concisely
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
22test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
22executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
22systematic-debugging
Use when debugging bugs, test failures, build failures, performance regressions, or unexpected behavior and you need root-cause investigation before proposing fixes. Trigger on requests to debug, investigate why something broke, or find the source of a technical issue.
22finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
20