frontend-design

Name: frontend-design
Author: PaulRBerg

68stars3forks

How to install frontend-design?

paulrberg/agent-skills/frontend-design

$npx -y skills add PaulRBerg/agent-skills --skill frontend-design

Installs into the current project.

Summary

Use when creating or substantially redesigning web interfaces, landing pages, dashboards, components, or other frontend UI where visual direction and implementation quality matter. Produces subject-specific art direction, accessible responsive code, and rendered visual verificati

Files · 1

View on GitHub

SKILL.md

1	# Frontend Design
2
3	Create a working frontend with a clear, subject-specific point of view, then prove it in the rendered UI.
4
5	## Contract
6
7	- For a critique, review, or design plan, inspect the relevant product and report the direction without editing files.
8	- For a build or redesign, make the requested in-scope changes and run local, non-destructive validation.
9	- Treat explicit user direction, supplied references, repository instructions, existing product behavior, and the local
10	design system as authoritative. Fidelity requests override this skill's defaults.
11	- Preserve the stack and working behavior. Do not replace the framework or design system, add dependencies, invent
12	features, or fetch or generate media unless the request requires it.
13	- Make the smallest defensible assumption when the subject, audience, or page job is missing. State it before building;
14	ask only when the answer would materially change scope or identity.
15
16	## Workflow
17
18	### 1. Read the product before drawing the page
19
20	Inspect the affected route or component, neighboring UI, tokens, typography, assets, dependencies, and repository
21	validation commands. Identify:
22
23	- the concrete subject and audience;
24	- the screen's single primary job and content hierarchy;
25	- the existing visual language and interaction conventions;
26	- the required viewports, themes, states, and accessibility constraints.
27
28	Use real product content and supplied assets wherever possible. If copy is missing, write only what the user needs to
29	understand the interface and act.
30
31	### 2. Set one art direction
32
33	Before coding, define a compact direction:
34
35	- Thesis: one sentence connecting the visual idea to the subject and screen job.
36	- System: role-based color tokens, explicit type roles and scale, spacing and density, and a layout principle.
37	- Signature: one memorable element drawn from the domain's objects, workflows, data shapes, environments, or
38	language.
39	- Risk: one deliberate departure from the obvious solution, with a reason it serves this brief.
40	- Motion and copy: when motion helps, how the interface speaks, and where restraint matters.
41
42	Adapt this direction to existing brand constraints instead of creating a parallel design language. Keep options and
43	process narration internal unless the user asked to choose among directions.
44
45	### 3. Run the anti-default critique
46
47	Apply the subject-swap test: mentally replace the subject with an unrelated one. Any major choice that still works
48	unchanged is probably a template default; revise it or justify why it is structurally correct.
49
50	Make every visual device earn its place. Cards, pills, gradients, numbering, dividers, oversized type, split heroes,
51	illustrations, and animation must communicate hierarchy, function, sequence, or subject—not merely decorate. Concentrate
52	expressive force in the signature and make the surrounding system support it.
53
54	### 4. Build the actual experience
55
56	- Follow local components, tokens, styling architecture, and dependency versions before introducing new primitives.
57	- Match composition to use: operational tools favor scannable information and efficient repeated actions; editorial or
58	marketing surfaces may use a more expressive narrative.
59	- Make the first viewport establish both identity and primary purpose. For an application or tool, show the real working
60	experience rather than wrapping it in an unrequested landing page.
61	- Use structural devices only when they encode real relationships. Use cards for genuinely grouped or repeated objects,
62	not as the default wrapper for every section, and avoid nested cards.
63	- Give typography deliberate display, body, and utility roles. Use available fonts first; do not add a font dependency
64	solely to manufacture novelty.
65	- Write interface copy from the user's side: specific nouns, active verbs, consistent action names, sentence case, and
66	useful empty and error states. A control's label must describe its result.
67	- Use familiar controls and the project's icon library. Give unfamiliar icon-only controls accessible names and visible
68	tooltips where appropriate.
69	- Keep motion purposeful and concentrated. Respect reduced-motion preferences and ensure the experience remains clear
70	without animation.
71	- Build responsive constraints from content rather than device labels. Prevent overlap, clipping, unreadable wrapping,
72	and layout shift at narrow and wide widths.
73	- Preserve semantic structure, keyboard operation, visible focus, adequate contrast,

People who liked this also viewed

6 picks

Type

frontend-design

68stars3forks

View on GitHub

How to install frontend-design?

paulrberg/agent-skills/frontend-design

$npx -y skills add PaulRBerg/agent-skills --skill frontend-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Frontend Design
2
3	Create a working frontend with a clear, subject-specific point of view, then prove it in the rendered UI.
4
5	## Contract
6
7	- For a critique, review, or design plan, inspect the relevant product and report the direction without editing files.
8	- For a build or redesign, make the requested in-scope changes and run local, non-destructive validation.
9	- Treat explicit user direction, supplied references, repository instructions, existing product behavior, and the local
10	design system as authoritative. Fidelity requests override this skill's defaults.
11	- Preserve the stack and working behavior. Do not replace the framework or design system, add dependencies, invent
12	features, or fetch or generate media unless the request requires it.
13	- Make the smallest defensible assumption when the subject, audience, or page job is missing. State it before building;
14	ask only when the answer would materially change scope or identity.
15
16	## Workflow
17
18	### 1. Read the product before drawing the page
19
20	Inspect the affected route or component, neighboring UI, tokens, typography, assets, dependencies, and repository
21	validation commands. Identify:
22
23	- the concrete subject and audience;
24	- the screen's single primary job and content hierarchy;
25	- the existing visual language and interaction conventions;
26	- the required viewports, themes, states, and accessibility constraints.
27
28	Use real product content and supplied assets wherever possible. If copy is missing, write only what the user needs to
29	understand the interface and act.
30
31	### 2. Set one art direction
32
33	Before coding, define a compact direction:
34
35	- Thesis: one sentence connecting the visual idea to the subject and screen job.
36	- System: role-based color tokens, explicit type roles and scale, spacing and density, and a layout principle.
37	- Signature: one memorable element drawn from the domain's objects, workflows, data shapes, environments, or
38	language.
39	- Risk: one deliberate departure from the obvious solution, with a reason it serves this brief.
40	- Motion and copy: when motion helps, how the interface speaks, and where restraint matters.
41
42	Adapt this direction to existing brand constraints instead of creating a parallel design language. Keep options and
43	process narration internal unless the user asked to choose among directions.
44
45	### 3. Run the anti-default critique
46
47	Apply the subject-swap test: mentally replace the subject with an unrelated one. Any major choice that still works
48	unchanged is probably a template default; revise it or justify why it is structurally correct.
49
50	Make every visual device earn its place. Cards, pills, gradients, numbering, dividers, oversized type, split heroes,
51	illustrations, and animation must communicate hierarchy, function, sequence, or subject—not merely decorate. Concentrate
52	expressive force in the signature and make the surrounding system support it.
53
54	### 4. Build the actual experience
55
56	- Follow local components, tokens, styling architecture, and dependency versions before introducing new primitives.
57	- Match composition to use: operational tools favor scannable information and efficient repeated actions; editorial or
58	marketing surfaces may use a more expressive narrative.
59	- Make the first viewport establish both identity and primary purpose. For an application or tool, show the real working
60	experience rather than wrapping it in an unrequested landing page.
61	- Use structural devices only when they encode real relationships. Use cards for genuinely grouped or repeated objects,
62	not as the default wrapper for every section, and avoid nested cards.
63	- Give typography deliberate display, body, and utility roles. Use available fonts first; do not add a font dependency
64	solely to manufacture novelty.
65	- Write interface copy from the user's side: specific nouns, active verbs, consistent action names, sentence case, and
66	useful empty and error states. A control's label must describe its result.
67	- Use familiar controls and the project's icon library. Give unfamiliar icon-only controls accessible names and visible
68	tooltips where appropriate.
69	- Keep motion purposeful and concentrated. Respect reduced-motion preferences and ensure the experience remains clear
70	without animation.
71	- Build responsive constraints from content rather than device labels. Prevent overlap, clipping, unreadable wrapping,
72	and layout shift at narrow and wide widths.
73	- Preserve semantic structure, keyboard operation, visible focus, adequate contrast,

People who liked this also viewed

6 picks

Type