$npx -y skills add bitjaru/styleseed --skill ss-buildBuild a screen with StyleSeed's composed design method — choose or compile an output grammar, apply domain/page/profile/lock constraints, then run the code and pixel gates before presenting.
| 1 | # Build with the composed StyleSeed method |
| 2 | |
| 3 | The build method is the product. Score and screenshots are auxiliary evidence, not the source |
| 4 | of design judgment. |
| 5 | |
| 6 | ## Step 1 — Establish the rule set before code |
| 7 | |
| 8 | Read `PRODUCT-PRINCIPLES.md` and `ADAPTERS.md`. If `STYLESEED.md` exists, validate its values and referenced |
| 9 | grammar. If it does not, run `/ss-setup` and write it before UI code. |
| 10 | |
| 11 | If the user supplied a visual reference that the selected built-in grammar does not capture, |
| 12 | run `/ss-reference` first. Never reduce an unfamiliar reference to a palette swap. |
| 13 | |
| 14 | ## Step 2 — Compose, do not improvise |
| 15 | |
| 16 | Read and combine in authority order: |
| 17 | |
| 18 | 1. core invariants in `PRODUCT-PRINCIPLES.md`; |
| 19 | 2. selected built-in grammar in `RULESETS.md`, or compiled `RULESET.md`; |
| 20 | 3. selected surface adapter in `ADAPTERS.md` and its companion renderer contract; |
| 21 | 4. matching `APP-PLAYBOOKS.md` domain and `PAGE-TYPES.md` page/artifact type; |
| 22 | 5. optional aesthetic profile in `PRESETS.md`; |
| 23 | 6. bounded values in `STYLESEED.md`; |
| 24 | 7. detailed craft in `DESIGN-LANGUAGE.md` and `VISUAL-CRAFT.md`. |
| 25 | |
| 26 | Before code, state the effective rule set in one line, for example: |
| 27 | |
| 28 | ```text |
| 29 | operations-console × SaaS × dashboard × swiss × locked brand tokens |
| 30 | ``` |
| 31 | |
| 32 | Resolve conflicts by authority. A profile or lock cannot waive task fitness, coherence, or |
| 33 | accessibility. |
| 34 | |
| 35 | ## Step 3 — Build with design judgment |
| 36 | |
| 37 | - Make the grammar's user job and primary decision visible in the first viewport. |
| 38 | - Establish one focal point; avoid equal-weight template grids. |
| 39 | - Use the grammar's composition, density, type, color, surface, imagery/data, action, state, |
| 40 | responsive, and motion contracts. |
| 41 | - Use product-specific content and evidence. Never copy the StyleSeed demo or a reference screen. |
| 42 | - Implement loading, empty, error, focus, reduced-motion, and responsive behavior where relevant. |
| 43 | |
| 44 | ## Step 4 — Code gate loop |
| 45 | |
| 46 | Run `/ss-score` on the actual implementation. The score must name the effective rule set and |
| 47 | check both core invariants and grammar-specific tells. Fix the highest-gain failures and |
| 48 | re-score, up to roughly three passes, until ≥80. If it cannot pass, report the real blocker. |
| 49 | |
| 50 | ## Step 5 — Pixel gate loop |
| 51 | |
| 52 | For every renderable artifact, invoke `/ss-verify`: use the adapter renderer, inspect every |
| 53 | required viewport/frame/page and relevant state, fix perceptual failures, and re-render. If no renderer |
| 54 | is available, say the visual gate was skipped; never imply it passed. |
| 55 | |
| 56 | ## Step 6 — Present with proof |
| 57 | |
| 58 | Report: |
| 59 | |
| 60 | - effective rule set and why it fits; |
| 61 | - final code score; |
| 62 | - visual verification status and viewport; |
| 63 | - material fixes made by the gates; |
| 64 | - `STYLESEED.md` and any compiled grammar path. |
| 65 | |
| 66 | ## Rules |
| 67 | |
| 68 | - Grammar before code; code gate after build; pixel gate last. |
| 69 | - Output grammar is functional. Aesthetic profile is optional and never substitutes for it. |
| 70 | - The primary action must remain identifiable; additional color is permitted only where the |
| 71 | grammar gives it stable semantic or categorical meaning. |
| 72 | - Re-read the lock and grammar on every UI change. |