create-design-md

Name: create-design-md
Author: ibelick

88installs256forks

How to install create-design-md?

ibelick/ui-skills/create-design-md

$npx -y skills add ibelick/ui-skills --skill create-design-md

Installs into the current project.

Summary

Create or update a DESIGN.md from an existing product repository or public website. Use when asked to document an interface's design language, reconstruct its visual system, extract design tokens and guidance from current evidence, or give coding agents persistent UI context. Do

Files · 1

View on GitHub

SKILL.md

1	# Create DESIGN.md
2
3	Create a `DESIGN.md` for one product or coherent website. Record the design language that governs it, not every value that happens to exist.
4
5	## Boundaries
6
7	- Modify only `DESIGN.md`. Do not change product source, dependencies, configuration, or generated files.
8	- Use the DESIGN.md format contract below. Do not invent a competing schema.
9	- Do not copy every discovered token or component into the document.
10	- Do not convert repetition, local styling, or visual preference into product intent.
11
12	## 1. Choose the mode
13
14	### Repository mode
15
16	Use when a local product repository is available. Create or update `DESIGN.md` at the root of the selected product.
17
18	If the repository contains multiple deployable products, select the one named by the user. If the request does not identify one and ownership is ambiguous, ask before writing.
19
20	Repository evidence may establish normative values, token names, component ownership, and documented rationale.
21
22	### URL mode
23
24	Use when the user provides a public URL without its source repository. Create a reconstructed `DESIGN.md` draft in the current workspace.
25
26	URL mode requires rendered browser access. Inspect the DOM, computed styles, and publicly loaded stylesheets at desktop and mobile widths. Screenshots may support interpretation but cannot establish exact values by themselves.
27
28	Inspect the supplied page and shared chrome. For a site-wide request, sample up to three same-origin pages that represent distinct templates.
29
30	URL evidence may establish only observable visual patterns and computed values. It cannot establish internal token names, component ownership, undocumented rationale, or whether a pattern is intentionally canonical.
31
32	If rendered inspection is unavailable, ask for screenshots or source files. Do not create a DESIGN.md from copy, metadata, or HTML structure alone.
33
34	Choose repository mode whenever source is available. A supplied URL may verify rendered presentation but does not replace repository evidence.
35
36	## Shared evidence pipeline
37
38	The modes differ only in how they collect evidence. They must use the same record and output pipeline:
39
40	```text
41	role → value → source → scope → recurrence → confidence
42	```
43
44	1. Collect evidence using the selected mode.
45	2. Record the source, scope, and recurrence for each candidate.
46	3. Normalize candidates into the DESIGN.md schema.
47	4. Omit candidates that are uncertain, local without a contract, or not implementation-relevant.
48	5. Validate frontmatter shape and export compatibility.
49	6. Write Markdown only after the normalized frontmatter passes.
50
51	Never let repository or URL evidence introduce a second token schema. The same flat token names, mapping-shaped typography, omission rules, and export gates apply to both modes.
52
53	The generated document is private until validation passes. Never return, display, or summarize a DESIGN.md draft before lint and export succeed. If validation reports an invalid shape or missing export category, rewrite the frontmatter and rerun; if the category cannot be repaired, remove it and report it as omitted.
54
55	## 2. Trace the evidence
56
57	In repository mode, inspect in this order:
58
59	1. Existing `DESIGN.md` and explicit repository guidance
60	2. Tokens, themes, variables, and global styles
61	3. Shared primitives and their variants
62	4. Representative routes and rendered consumers
63	5. Surface-local implementations
64
65	A source participates only when the selected product imports, references, inherits, or renders it. Exclude proposals, migrations, examples, generated outputs, legacy implementations, and similarly named packages unless the selected product uses them.
66
67	In URL mode, sample representative elements for:
68
69	- colors and surface roles
70	- typography roles
71	- spacing and layout
72	- borders, radii, and elevation
73	- navigation, buttons, inputs, cards, and repeated content structures
74	- desktop and mobile presentation
75
76	Prefer computed values and loaded CSS declarations over visual estimation.
77
78	Before drafting URL-mode prose or YAML, build a private evidence ledger for each sampled page and viewport. For each candidate, record: page, viewport, element role, computed property/value, and the matching loaded-CSS declaration or custom property when available. Inspect the public stylesheets loaded by the page, including custom properties and media-query rules; a stylesheet value is usable only when it is connected to a rendered element or recurs across the sampled pages.
79
80	Promote a URL value into DESIGN.md when either (a) the rendered computed value and a loaded declaration/custom property agree, or (b) the s

People who liked this also viewed

6 picks

Type

create-design-md

88installs256forks

View on GitHub

How to install create-design-md?

ibelick/ui-skills/create-design-md

$npx -y skills add ibelick/ui-skills --skill create-design-md

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Create DESIGN.md
2
3	Create a `DESIGN.md` for one product or coherent website. Record the design language that governs it, not every value that happens to exist.
4
5	## Boundaries
6
7	- Modify only `DESIGN.md`. Do not change product source, dependencies, configuration, or generated files.
8	- Use the DESIGN.md format contract below. Do not invent a competing schema.
9	- Do not copy every discovered token or component into the document.
10	- Do not convert repetition, local styling, or visual preference into product intent.
11
12	## 1. Choose the mode
13
14	### Repository mode
15
16	Use when a local product repository is available. Create or update `DESIGN.md` at the root of the selected product.
17
18	If the repository contains multiple deployable products, select the one named by the user. If the request does not identify one and ownership is ambiguous, ask before writing.
19
20	Repository evidence may establish normative values, token names, component ownership, and documented rationale.
21
22	### URL mode
23
24	Use when the user provides a public URL without its source repository. Create a reconstructed `DESIGN.md` draft in the current workspace.
25
26	URL mode requires rendered browser access. Inspect the DOM, computed styles, and publicly loaded stylesheets at desktop and mobile widths. Screenshots may support interpretation but cannot establish exact values by themselves.
27
28	Inspect the supplied page and shared chrome. For a site-wide request, sample up to three same-origin pages that represent distinct templates.
29
30	URL evidence may establish only observable visual patterns and computed values. It cannot establish internal token names, component ownership, undocumented rationale, or whether a pattern is intentionally canonical.
31
32	If rendered inspection is unavailable, ask for screenshots or source files. Do not create a DESIGN.md from copy, metadata, or HTML structure alone.
33
34	Choose repository mode whenever source is available. A supplied URL may verify rendered presentation but does not replace repository evidence.
35
36	## Shared evidence pipeline
37
38	The modes differ only in how they collect evidence. They must use the same record and output pipeline:
39
40	```text
41	role → value → source → scope → recurrence → confidence
42	```
43
44	1. Collect evidence using the selected mode.
45	2. Record the source, scope, and recurrence for each candidate.
46	3. Normalize candidates into the DESIGN.md schema.
47	4. Omit candidates that are uncertain, local without a contract, or not implementation-relevant.
48	5. Validate frontmatter shape and export compatibility.
49	6. Write Markdown only after the normalized frontmatter passes.
50
51	Never let repository or URL evidence introduce a second token schema. The same flat token names, mapping-shaped typography, omission rules, and export gates apply to both modes.
52
53	The generated document is private until validation passes. Never return, display, or summarize a DESIGN.md draft before lint and export succeed. If validation reports an invalid shape or missing export category, rewrite the frontmatter and rerun; if the category cannot be repaired, remove it and report it as omitted.
54
55	## 2. Trace the evidence
56
57	In repository mode, inspect in this order:
58
59	1. Existing `DESIGN.md` and explicit repository guidance
60	2. Tokens, themes, variables, and global styles
61	3. Shared primitives and their variants
62	4. Representative routes and rendered consumers
63	5. Surface-local implementations
64
65	A source participates only when the selected product imports, references, inherits, or renders it. Exclude proposals, migrations, examples, generated outputs, legacy implementations, and similarly named packages unless the selected product uses them.
66
67	In URL mode, sample representative elements for:
68
69	- colors and surface roles
70	- typography roles
71	- spacing and layout
72	- borders, radii, and elevation
73	- navigation, buttons, inputs, cards, and repeated content structures
74	- desktop and mobile presentation
75
76	Prefer computed values and loaded CSS declarations over visual estimation.
77
78	Before drafting URL-mode prose or YAML, build a private evidence ledger for each sampled page and viewport. For each candidate, record: page, viewport, element role, computed property/value, and the matching loaded-CSS declaration or custom property when available. Inspect the public stylesheets loaded by the page, including custom properties and media-query rules; a stylesheet value is usable only when it is connected to a rendered element or recurs across the sampled pages.
79
80	Promote a URL value into DESIGN.md when either (a) the rendered computed value and a loaded declaration/custom property agree, or (b) the s

People who liked this also viewed

6 picks

Type