design-first

Name: design-first
Author: techygarg

165stars12forks

How to install design-first?

techygarg/lattice/design-first

$npx -y skills add techygarg/lattice --skill design-first

Installs into the current project.

Summary

Guide structured design thinking through 5 progressive levels before any code is written. Levels: Capabilities, Components, Interactions, Contracts, Implementation. Use when building new features, refactoring significant code, designing modules, or when the user says 'design this

Files · 1

View on GitHub

SKILL.md

1	# Design-First (Progressive Design Facilitation)
2
3	## The 5 Levels
4
5	### Level 1: Capabilities (The "What")
6
7	Purpose: Confirm scope. Surface user-facing outcomes system need deliver. Shared vocabulary check -- ensure human and AI talk same feature, same boundaries.
8
9	Output format: Numbered list user-facing capabilities, max 5. Each capability plain-language outcome, not implementation detail.
10
11	Boundary: No components, no architecture, no technical detail. If capability mention specific technology, class, or data structure -- belong later level. This level answer only "what user get?"
12
13	Checkpoint: "Does this Level 1 (Capabilities) look correct? Should I proceed to Level 2 (Components)?"
14
15	### Level 2: Components (The "Who")
16
17	Purpose: Identify building blocks. What major pieces system, what each one responsible for?
18
19	Output format: 3-5 components, each with single responsibility and one-line description. Include ASCII or Mermaid diagram showing how relate. Note integration points with existing infrastructure.
20
21	Boundary: No data flow, no sequence operations, no interaction detail. Each component described by what it is and what it owns -- not how communicate with others. If write "A sends X to B" -- belong Level 3.
22
23	Checkpoint: "Does this Level 2 (Components) look correct? Should I proceed to Level 3 (Interactions)?"
24
25	### Level 3: Interactions (The "How They Talk")
26
27	Purpose: Define data flow between components. How building blocks communicate deliver capabilities?
28
29	Output format: Sequence diagram (ASCII or Mermaid) or numbered flow showing order operations. For each interaction, describe WHAT data passes between components. See `./references/methodology-detail.md` for notation guidance.
30
31	Boundary: No function signatures, no type definitions, no implementation detail. Focus what passes between components, not how each component process internally. If define method parameters or return types -- belong Level 4.
32
33	Checkpoint: "Does this Level 3 (Interactions) look correct? Should I proceed to Level 4 (Contracts)?"
34
35	### Level 4: Contracts (The "Interface Definitions")
36
37	Purpose: Define interfaces, method signatures, type definitions that formalize interactions. Handoff artifact -- spec that implementation built against.
38
39	Output format: Typed interfaces, method signatures, type definitions. Language-appropriate format (TypeScript interfaces, Java interfaces, Python protocols, etc.). Use the project's primary language; if ambiguous, ask before writing contracts. No function bodies -- signatures and types only. Include error/failure types where interactions can fail. See `./references/methodology-detail.md` for interface definition patterns.
40
41	Boundary: No implementation logic. If function body appear -- belong Level 5. Contracts reflect design agreed Levels 1-3, nothing more. Utility functions, helper methods, convenience wrappers not in design not belong here. Every Level 3 interaction must map to at least one interface or type; no new interactions may appear here that weren't agreed at Level 3.
42
43	Checkpoint: "Does this Level 4 (Contracts) look correct? Should I proceed to Level 5 (Implementation)?"
44
45	### Level 5: Implementation (The "Code")
46
47	Purpose: Write code. Implement against agreed contracts, within agreed component boundaries, following agreed interaction patterns.
48
49	Output format: Working code fulfill contracts defined Level 4. Each component implemented within agreed boundary. Implementation reviewable against design -- reviewer check each component against Level 2 description, each interaction against Level 3 flow, each interface against Level 4 contract.
50
51	STOP: Only after Level 4 explicitly approved. Implementation follow design; not introduce new components, new interactions, new contracts not agreed upon.
52
53	## The Zero Implementation Rule
54
55	No code until design agreed.
56
57	STOP: If catch self writing function bodies before Level 5 approved -- return to current design level, present only output appropriate that level.
58
59	## Complexity Calibration
60
61	\| Task Complexity \| Start At \| Example \|
62	\|---\|---\|---\|
63	\| Simple utility \| Level 4 (Contracts) \| Date formatter, string helper \|
64	\| Single component \| Level 2 (Components) \| Validation service, API endpoint \|
65	\| Multi-component feature \| Level 1 (Capabilities) \| Notification system, payment flow \|
66	\| New system integration \| Level 1 + deep Level 3 \| Third-party API, e

People who liked this also viewed

6 picks

Type

design-first

165stars12forks

View on GitHub

How to install design-first?

techygarg/lattice/design-first

$npx -y skills add techygarg/lattice --skill design-first

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Design-First (Progressive Design Facilitation)
2
3	## The 5 Levels
4
5	### Level 1: Capabilities (The "What")
6
7	Purpose: Confirm scope. Surface user-facing outcomes system need deliver. Shared vocabulary check -- ensure human and AI talk same feature, same boundaries.
8
9	Output format: Numbered list user-facing capabilities, max 5. Each capability plain-language outcome, not implementation detail.
10
11	Boundary: No components, no architecture, no technical detail. If capability mention specific technology, class, or data structure -- belong later level. This level answer only "what user get?"
12
13	Checkpoint: "Does this Level 1 (Capabilities) look correct? Should I proceed to Level 2 (Components)?"
14
15	### Level 2: Components (The "Who")
16
17	Purpose: Identify building blocks. What major pieces system, what each one responsible for?
18
19	Output format: 3-5 components, each with single responsibility and one-line description. Include ASCII or Mermaid diagram showing how relate. Note integration points with existing infrastructure.
20
21	Boundary: No data flow, no sequence operations, no interaction detail. Each component described by what it is and what it owns -- not how communicate with others. If write "A sends X to B" -- belong Level 3.
22
23	Checkpoint: "Does this Level 2 (Components) look correct? Should I proceed to Level 3 (Interactions)?"
24
25	### Level 3: Interactions (The "How They Talk")
26
27	Purpose: Define data flow between components. How building blocks communicate deliver capabilities?
28
29	Output format: Sequence diagram (ASCII or Mermaid) or numbered flow showing order operations. For each interaction, describe WHAT data passes between components. See `./references/methodology-detail.md` for notation guidance.
30
31	Boundary: No function signatures, no type definitions, no implementation detail. Focus what passes between components, not how each component process internally. If define method parameters or return types -- belong Level 4.
32
33	Checkpoint: "Does this Level 3 (Interactions) look correct? Should I proceed to Level 4 (Contracts)?"
34
35	### Level 4: Contracts (The "Interface Definitions")
36
37	Purpose: Define interfaces, method signatures, type definitions that formalize interactions. Handoff artifact -- spec that implementation built against.
38
39	Output format: Typed interfaces, method signatures, type definitions. Language-appropriate format (TypeScript interfaces, Java interfaces, Python protocols, etc.). Use the project's primary language; if ambiguous, ask before writing contracts. No function bodies -- signatures and types only. Include error/failure types where interactions can fail. See `./references/methodology-detail.md` for interface definition patterns.
40
41	Boundary: No implementation logic. If function body appear -- belong Level 5. Contracts reflect design agreed Levels 1-3, nothing more. Utility functions, helper methods, convenience wrappers not in design not belong here. Every Level 3 interaction must map to at least one interface or type; no new interactions may appear here that weren't agreed at Level 3.
42
43	Checkpoint: "Does this Level 4 (Contracts) look correct? Should I proceed to Level 5 (Implementation)?"
44
45	### Level 5: Implementation (The "Code")
46
47	Purpose: Write code. Implement against agreed contracts, within agreed component boundaries, following agreed interaction patterns.
48
49	Output format: Working code fulfill contracts defined Level 4. Each component implemented within agreed boundary. Implementation reviewable against design -- reviewer check each component against Level 2 description, each interaction against Level 3 flow, each interface against Level 4 contract.
50
51	STOP: Only after Level 4 explicitly approved. Implementation follow design; not introduce new components, new interactions, new contracts not agreed upon.
52
53	## The Zero Implementation Rule
54
55	No code until design agreed.
56
57	STOP: If catch self writing function bodies before Level 5 approved -- return to current design level, present only output appropriate that level.
58
59	## Complexity Calibration
60
61	\| Task Complexity \| Start At \| Example \|
62	\|---\|---\|---\|
63	\| Simple utility \| Level 4 (Contracts) \| Date formatter, string helper \|
64	\| Single component \| Level 2 (Components) \| Validation service, API endpoint \|
65	\| Multi-component feature \| Level 1 (Capabilities) \| Notification system, payment flow \|
66	\| New system integration \| Level 1 + deep Level 3 \| Third-party API, e

People who liked this also viewed

6 picks

Type