rudder-ui-polish-maintainer

Name: rudder-ui-polish-maintainer
Author: Undertone0809

247stars30forks

How to install rudder-ui-polish-maintainer?

undertone0809/rudder/rudder-ui-polish-maintainer

$npx -y skills add Undertone0809/rudder --skill rudder-ui-polish-maintainer

Installs into the current project.

Summary

Use when implementing screenshot-driven or narrow Rudder UI polish: density, alignment, spacing, labels, cards, menus, hover states, empty states, onboarding steps, redundant pages, compact workflows, screenshots, or small visible interaction fixes.

Files · 1

View on GitHub

SKILL.md

1	# Rudder UI Polish Maintainer
2
3	Use this skill to turn concrete Rudder UI feedback into a scoped, implemented,
4	validated, and committed change.
5
6	The goal is not a full redesign. The goal is to preserve Rudder's dense,
7	operator-focused interface while fixing the specific visual or interaction
8	problem the user noticed.
9
10	## Use When
11
12	Use this skill for Rudder UI tasks such as:
13
14	- screenshot-driven visual polish
15	- alignment, line-height, spacing, density, overflow, or hover fixes
16	- adding a small status badge, label, icon, menu, or affordance
17	- simplifying settings sections or redundant explanatory copy
18	- removing a page or route that no longer belongs in the product
19	- changing an empty state, onboarding step, tutorial jump, or small workflow
20	surface
21	- producing a quick screenshot of the current UI after a local change
22	- explaining why a visible surface looks wrong when the user asks "为什么"
23	and the likely answer is current CSS/layout/data layering rather than an
24	approved implementation request
25
26	Use `build-advisor` first when the user explicitly asks "你懂我要怎么改吗",
27	"先说说", or otherwise wants the product/design direction before edits.
28	After the direction is accepted, continue here for implementation.
29
30	Use `advisor-review-loop-maintainer` instead when the user asks for reviewer
31	agents, two rounds, proposal review, or an acceptance gate before handoff.
32
33	When the user invokes `advisor-review-loop-maintainer` for a small visible fix
34	but only asks to "修一下", "优化一下", "去掉这个 button", "颜色不对", or similar,
35	treat this skill as the implementation contract after a short advisor check.
36	Say explicitly in the handoff that the work used a lightweight route rather
37	than a full two-reviewer loop.
38
39	## Do Not Use When
40
41	Do not use this skill for:
42
43	- broad architecture refactors or large feature builds
44	- pure code review with no UI change
45	- data diagnosis where the core question is "why is this page empty"; use
46	`rudder-data-path-diagnostician-maintainer`
47	- screenshot/demo data creation; use `mock-data-maintainer` and then
48	`landing-proof-shots-maintainer` when needed
49	- release, CI, Desktop packaging, or browser automation infrastructure issues
50	- UI Lab, component inventory, component fixture coverage, or design-system
51	catalog work where the main deliverable is coverage and classification rather
52	than a narrow rendered-state polish fix; route through
53	`development-lifecycle-router-maintainer` first
54
55	## Default Workflow
56
57	### 1. Resolve intent and mode
58
59	Classify the prompt before editing:
60
61	- `advice-only`: user asks to discuss, judge, or generate options.
62	- `explain-only`: user asks why a visual state looks the way it does, without
63	asking to change it yet.
64	- `implement`: user asks to fix, optimize, remove, add, or "改一下".
65	- `screenshot`: user wants the current rendered UI captured.
66	- `review-gated`: user invokes reviewers or says the result must pass review.
67	- `component-lab`: user asks to build, expand, or audit UI Lab/component
68	inventory; route out to the lifecycle/component-lab workflow first.
69
70	In `advice-only`, produce the smallest useful UI direction and stop. In
71	`explain-only`, trace the rendered reason from screenshot to component/CSS/data
72	source and stop with the likely fix direction, not a patch. In `implement`,
73	make the code change. If the user gives screenshots plus vague language, infer
74	the concrete pain from the image and surrounding product state.
75
76	In `component-lab`, do not start a narrow polish pass. The owning workflow must
77	first define component coverage, context-required labeling, route behavior,
78	tests, and browser proof. Return to this skill only for a concrete visual fix
79	inside an already-scoped component-lab task.
80
81	### 2. Build a small evidence packet
82
83	Gather only the context needed for this UI surface:
84
85	- current route, component, and API client involved
86	- relevant nearby tests
87	- `doc/engineering/DESIGN.md` for visible UI defaults when the change is layout-sensitive
88	- existing components, tokens, icons, and status labels before inventing new UI
89	- screenshot or browser state when the user provided or requested visual proof
90
91	Check `git status --short --branch` before editing. Preserve unrelated dirty
92	worktree changes.
93
94	### 3. Make the smallest coherent UI change
95
96	Prefer local product consistency over a generic design pattern:
97
98	- reuse existing Rudder components and status vocabulary
99	- keep operational screens compact, scannable, and calm
100	- remove redundant copy instead of explaining the UI inside the UI
101	- avoid wrapping cards inside cards
102	- avoid decorative treatment that competes with work content
103	- keep controls discoverable but not oversized
104	- preserve keyboard, selection, copy, and accessibility behavior

People who liked this also viewed

6 picks

Type

rudder-ui-polish-maintainer

247stars30forks

View on GitHub

How to install rudder-ui-polish-maintainer?

undertone0809/rudder/rudder-ui-polish-maintainer

$npx -y skills add Undertone0809/rudder --skill rudder-ui-polish-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Rudder UI Polish Maintainer
2
3	Use this skill to turn concrete Rudder UI feedback into a scoped, implemented,
4	validated, and committed change.
5
6	The goal is not a full redesign. The goal is to preserve Rudder's dense,
7	operator-focused interface while fixing the specific visual or interaction
8	problem the user noticed.
9
10	## Use When
11
12	Use this skill for Rudder UI tasks such as:
13
14	- screenshot-driven visual polish
15	- alignment, line-height, spacing, density, overflow, or hover fixes
16	- adding a small status badge, label, icon, menu, or affordance
17	- simplifying settings sections or redundant explanatory copy
18	- removing a page or route that no longer belongs in the product
19	- changing an empty state, onboarding step, tutorial jump, or small workflow
20	surface
21	- producing a quick screenshot of the current UI after a local change
22	- explaining why a visible surface looks wrong when the user asks "为什么"
23	and the likely answer is current CSS/layout/data layering rather than an
24	approved implementation request
25
26	Use `build-advisor` first when the user explicitly asks "你懂我要怎么改吗",
27	"先说说", or otherwise wants the product/design direction before edits.
28	After the direction is accepted, continue here for implementation.
29
30	Use `advisor-review-loop-maintainer` instead when the user asks for reviewer
31	agents, two rounds, proposal review, or an acceptance gate before handoff.
32
33	When the user invokes `advisor-review-loop-maintainer` for a small visible fix
34	but only asks to "修一下", "优化一下", "去掉这个 button", "颜色不对", or similar,
35	treat this skill as the implementation contract after a short advisor check.
36	Say explicitly in the handoff that the work used a lightweight route rather
37	than a full two-reviewer loop.
38
39	## Do Not Use When
40
41	Do not use this skill for:
42
43	- broad architecture refactors or large feature builds
44	- pure code review with no UI change
45	- data diagnosis where the core question is "why is this page empty"; use
46	`rudder-data-path-diagnostician-maintainer`
47	- screenshot/demo data creation; use `mock-data-maintainer` and then
48	`landing-proof-shots-maintainer` when needed
49	- release, CI, Desktop packaging, or browser automation infrastructure issues
50	- UI Lab, component inventory, component fixture coverage, or design-system
51	catalog work where the main deliverable is coverage and classification rather
52	than a narrow rendered-state polish fix; route through
53	`development-lifecycle-router-maintainer` first
54
55	## Default Workflow
56
57	### 1. Resolve intent and mode
58
59	Classify the prompt before editing:
60
61	- `advice-only`: user asks to discuss, judge, or generate options.
62	- `explain-only`: user asks why a visual state looks the way it does, without
63	asking to change it yet.
64	- `implement`: user asks to fix, optimize, remove, add, or "改一下".
65	- `screenshot`: user wants the current rendered UI captured.
66	- `review-gated`: user invokes reviewers or says the result must pass review.
67	- `component-lab`: user asks to build, expand, or audit UI Lab/component
68	inventory; route out to the lifecycle/component-lab workflow first.
69
70	In `advice-only`, produce the smallest useful UI direction and stop. In
71	`explain-only`, trace the rendered reason from screenshot to component/CSS/data
72	source and stop with the likely fix direction, not a patch. In `implement`,
73	make the code change. If the user gives screenshots plus vague language, infer
74	the concrete pain from the image and surrounding product state.
75
76	In `component-lab`, do not start a narrow polish pass. The owning workflow must
77	first define component coverage, context-required labeling, route behavior,
78	tests, and browser proof. Return to this skill only for a concrete visual fix
79	inside an already-scoped component-lab task.
80
81	### 2. Build a small evidence packet
82
83	Gather only the context needed for this UI surface:
84
85	- current route, component, and API client involved
86	- relevant nearby tests
87	- `doc/engineering/DESIGN.md` for visible UI defaults when the change is layout-sensitive
88	- existing components, tokens, icons, and status labels before inventing new UI
89	- screenshot or browser state when the user provided or requested visual proof
90
91	Check `git status --short --branch` before editing. Preserve unrelated dirty
92	worktree changes.
93
94	### 3. Make the smallest coherent UI change
95
96	Prefer local product consistency over a generic design pattern:
97
98	- reuse existing Rudder components and status vocabulary
99	- keep operational screens compact, scannable, and calm
100	- remove redundant copy instead of explaining the UI inside the UI
101	- avoid wrapping cards inside cards
102	- avoid decorative treatment that competes with work content
103	- keep controls discoverable but not oversized
104	- preserve keyboard, selection, copy, and accessibility behavior

People who liked this also viewed

6 picks

Type