design-blueprint

Name: design-blueprint
Author: techygarg

165stars12forks

How to install design-blueprint?

techygarg/lattice/design-blueprint

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

Installs into the current project.

Summary

Run a complete design workflow -- from establishing context through 5 progressive design levels to an approved blueprint. Composes context anchoring, design-first methodology, architecture, and DDD into a unified process. Handles both new features (create context doc) and resumin

Files · 1

View on GitHub

SKILL.md

1	# Design Blueprint
2
3	## Required Skills
4
5	Read apply skills order:
6
7	1. `framework:knowledge-priming` -- Load project context (tech stack, architecture, conventions) ground decisions real project
8	2. `framework:context-anchoring` -- Create or load feature context anchor doc
9	3. `framework:learning-harvest` -- Load prior operational learnings inform design; harvest new patterns at session end (always)
10	4. `framework:collaborative-judgment` -- Surface real design judgment calls structured options instead silent assuming (always)
11	5. `framework:design-first` -- Walk through 5 progressive design levels
12	6. `framework:architecture` -- Apply structural rules Component and Interaction levels
13	7. `framework:domain-driven-design` -- Apply domain modeling Component, Interaction, Contract levels
14
15	## Workflow
16
17	### Step 1: Establish Context
18
19	Use `framework:learning-harvest` Load behavior. Focus hint: "design session — focus: design patterns, reliability, structural health".
20
21	Use `framework:context-anchoring` set up feature living doc.
22
23	- Document Discovery: Check existing context anchor doc feature (scan context base directory, match by feature name or frontmatter).
24	- If exists → Load (context-anchoring Load behavior). Present structured acknowledgment -- feature name, status, decision count, open questions, constraints. Resume last design checkpoint recorded doc.
25	- If not → Create (context-anchoring Create behavior). New feature doc from template. Confirm feature name, summary, requirement doc link with user before creating.
26
27	Load requirement constraints: Read `requirement_doc` from context doc frontmatter.
28	- Null/absent → skip.
29	- Local path → read it. Extract `## Technical Constraints`. Treat as non-negotiable — same authority as architecture rules. Surface to user before Level 1.
30	- External reference (URL, ticket ID, or other non-local-path identifier) → if a connected MCP tool can resolve it, fetch and extract constraints the same way. If no MCP tool is connected or the fetch returns nothing, ask the user to paste the current constraints directly — expected, not an error.
31	- Conflict during design → surface via `framework:collaborative-judgment`. User decides; record any change back in requirement doc `## Technical Constraints` if it is a local file. If external, record the change in the context doc's Decisions Log instead — this molecule never writes back to an external system.
32
33	Write the back-link: If `requirement_doc` resolved to a readable local file at `.lattice/requirements/features/{feature-name}.md`, write into its `## Links` section: `- Design: [{feature-name}.md](../../context/{feature-name}.md)`. Discrete file edit, done once — skip if the link is already present.
34
35	### Step 2: Walk the Design Levels
36
37	If key use cases or success criteria unclear now, use `framework:collaborative-judgment` surface what needs answering before starting Level 1.
38
39	Drive through `framework:design-first` 5 levels sequentially. Each level, present design output, get user approval, then persist approved output into context anchor doc before advancing.
40
41	Enrichment rule: After user approves each level, use `framework:context-anchoring` Enrich behavior write following into context doc:
42
43	1. Approved level output itself (capabilities list, component diagram, interaction flows, or contracts) -- captured as clean, structured summary under dedicated section that level. Use same format as level presentation: numbered list Level 1, component table + diagram Level 2, sequence/flow Level 3, typed interfaces Level 4.
44	2. Decisions made during level discussion -- choices, reasoning, alternatives rejected.
45	3. Constraints identified -- non-negotiable boundaries emerged.
46	4. Open questions surfaced but remain unresolved.
47
48	NOT advance next level until current level output persisted.
49
50	When applying architectural atoms each level, use `framework:collaborative-judgment` surface real design judgment calls immediately — not batch during design.
51
52	Apply architectural atoms levels where add value:
53
54	Level 1 (Capabilities):
55	- Present capabilities list per `framework:design-first`.
56	- On approval → Enrich context doc with approved capabilities under `## Design: Level 1 -- Capabilities` section.
57
58	Level 2 (Components):
59	- Challenge each component before approving: does it need to exist? An abstraction with one known implementation, a layer with one caller, or a component solving a

People who liked this also viewed

6 picks

Type

design-blueprint

165stars12forks

View on GitHub

How to install design-blueprint?

techygarg/lattice/design-blueprint

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Design Blueprint
2
3	## Required Skills
4
5	Read apply skills order:
6
7	1. `framework:knowledge-priming` -- Load project context (tech stack, architecture, conventions) ground decisions real project
8	2. `framework:context-anchoring` -- Create or load feature context anchor doc
9	3. `framework:learning-harvest` -- Load prior operational learnings inform design; harvest new patterns at session end (always)
10	4. `framework:collaborative-judgment` -- Surface real design judgment calls structured options instead silent assuming (always)
11	5. `framework:design-first` -- Walk through 5 progressive design levels
12	6. `framework:architecture` -- Apply structural rules Component and Interaction levels
13	7. `framework:domain-driven-design` -- Apply domain modeling Component, Interaction, Contract levels
14
15	## Workflow
16
17	### Step 1: Establish Context
18
19	Use `framework:learning-harvest` Load behavior. Focus hint: "design session — focus: design patterns, reliability, structural health".
20
21	Use `framework:context-anchoring` set up feature living doc.
22
23	- Document Discovery: Check existing context anchor doc feature (scan context base directory, match by feature name or frontmatter).
24	- If exists → Load (context-anchoring Load behavior). Present structured acknowledgment -- feature name, status, decision count, open questions, constraints. Resume last design checkpoint recorded doc.
25	- If not → Create (context-anchoring Create behavior). New feature doc from template. Confirm feature name, summary, requirement doc link with user before creating.
26
27	Load requirement constraints: Read `requirement_doc` from context doc frontmatter.
28	- Null/absent → skip.
29	- Local path → read it. Extract `## Technical Constraints`. Treat as non-negotiable — same authority as architecture rules. Surface to user before Level 1.
30	- External reference (URL, ticket ID, or other non-local-path identifier) → if a connected MCP tool can resolve it, fetch and extract constraints the same way. If no MCP tool is connected or the fetch returns nothing, ask the user to paste the current constraints directly — expected, not an error.
31	- Conflict during design → surface via `framework:collaborative-judgment`. User decides; record any change back in requirement doc `## Technical Constraints` if it is a local file. If external, record the change in the context doc's Decisions Log instead — this molecule never writes back to an external system.
32
33	Write the back-link: If `requirement_doc` resolved to a readable local file at `.lattice/requirements/features/{feature-name}.md`, write into its `## Links` section: `- Design: [{feature-name}.md](../../context/{feature-name}.md)`. Discrete file edit, done once — skip if the link is already present.
34
35	### Step 2: Walk the Design Levels
36
37	If key use cases or success criteria unclear now, use `framework:collaborative-judgment` surface what needs answering before starting Level 1.
38
39	Drive through `framework:design-first` 5 levels sequentially. Each level, present design output, get user approval, then persist approved output into context anchor doc before advancing.
40
41	Enrichment rule: After user approves each level, use `framework:context-anchoring` Enrich behavior write following into context doc:
42
43	1. Approved level output itself (capabilities list, component diagram, interaction flows, or contracts) -- captured as clean, structured summary under dedicated section that level. Use same format as level presentation: numbered list Level 1, component table + diagram Level 2, sequence/flow Level 3, typed interfaces Level 4.
44	2. Decisions made during level discussion -- choices, reasoning, alternatives rejected.
45	3. Constraints identified -- non-negotiable boundaries emerged.
46	4. Open questions surfaced but remain unresolved.
47
48	NOT advance next level until current level output persisted.
49
50	When applying architectural atoms each level, use `framework:collaborative-judgment` surface real design judgment calls immediately — not batch during design.
51
52	Apply architectural atoms levels where add value:
53
54	Level 1 (Capabilities):
55	- Present capabilities list per `framework:design-first`.
56	- On approval → Enrich context doc with approved capabilities under `## Design: Level 1 -- Capabilities` section.
57
58	Level 2 (Components):
59	- Challenge each component before approving: does it need to exist? An abstraction with one known implementation, a layer with one caller, or a component solving a

People who liked this also viewed

6 picks

Type