Enforce professional design judgment in AI-generated UI code
Detects an outdated StyleSeed installation and applies safe, additive updates without touching your theme or components.
Why it matters
StyleSeed eliminates the generic AI-generated look from UI code by teaching AI agents design judgment-how designers think-and enforcing quality through a scored gate that reviews and fixes common AI tells (default indigo, rainbow lists, icon-chip clichés) before you see the output.
Outcomes
What it gets done
Lock design decisions (accent color, radius, motion) in STYLESEED.md to prevent drift across sessions
Run quality gate reviews that score UI against 74 design rules and auto-fix failures before showing output
Apply brand skins (Toss, Raycast, Arc) with consistent tokens for colors, shadows, gradients, and motion
Teach AI agents 15 design skills including refined color choices, proper empty states, and anti-template layouts
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-ui-update | bash Overview
StyleSeed Update Assistant
This skill detects an outdated StyleSeed installation, diffs it against the latest published version, and applies safe additive updates (skills, .cursorrules, DESIGN-LANGUAGE.md, merged Golden Rules) while never overwriting the project's own theme or components. Use it to update an existing StyleSeed installation safely - use /ss-setup for first-time installs, and do a manual diff review first if the project has heavily diverged from upstream.
What it does
Automatically detects and updates StyleSeed engine files in the current project, reporting what's outdated and applying updates safely. Updates are additive - new rules, components, skins, and skills get added; the project's own theme.css, components, and app code are never overwritten, and design rules only ever get added, never changed in a breaking way - so a large version jump looks like a lot changed but is almost entirely additions, and the process is safe and reversible (commit first, apply updates, run a build, git reset --hard if anything looks off).
It runs five steps. Step 1 scans the project for DESIGN-LANGUAGE.md, CLAUDE.md, skills under .claude/skills/ (current names are ss-*; ui-*/ux-* are legacy names to migrate from), theme.css, and .cursorrules, reporting what was found and where. Step 2 checks the version:
### local marker (may be absent on older installs)
cat engine/VERSION 2>/dev/null || cat VERSION 2>/dev/null || echo "unknown"
### latest published version + what's new
curl -s https://styleseed-demo.vercel.app/version.json
If the local version already matches the published version.json, it reports up-to-date and stops; otherwise it clones or pulls github.com/bitjaru/styleseed to /tmp/styleseed and diffs engine/VERSION, DESIGN-LANGUAGE.md's rule count and table of contents, the skills present locally versus upstream (listing the actual diff, not a hardcoded count), whether CLAUDE.md/AGENTS.md/.cursorrules all exist, and any new engine docs (VISUAL-CRAFT.md, APP-PLAYBOOKS.md, PAGE-TYPES.md).
Step 3 reports the findings and recommended updates to the user, tagging each as safe (auto-applied) or needing review/merge, and asks before proceeding on any flagged item. Step 4 executes: skills and .cursorrules (if missing) are copied without asking since they're always safe; DESIGN-LANGUAGE.md updates show a diff summary and ask Y/N before copying to the detected location; Golden Rules get merged into CLAUDE.md only if not already present, inserted after the first heading, explicitly preserving existing content; theme.css and the project's own components/ directory are never touched - the user is told to run /ss-lint afterward to check compliance. Step 5 prints a summary of what was updated and what was deliberately left untouched.
When to use - and when NOT to
Use it to bring an existing StyleSeed installation up to date safely. For first-time setup use /ss-setup instead; for adding just one new component or skin, copy that file manually; for a project that has heavily diverged from upstream, do a manual diff review first rather than running this. It updates engine files only - never the project's own user code or components.
Inputs and outputs
Input is the current project's StyleSeed installation state (detected automatically) and the user's Y/N responses to flagged updates. Output is updated engine files (skills, .cursorrules, DESIGN-LANGUAGE.md, merged Golden Rules) plus a summary report of what changed and what was left untouched.
Integrations
Pulls updates from the bitjaru/styleseed GitHub repository and its published version.json, and hands off to /ss-lint afterward for compliance checking against the updated rules.
Who it's for
Teams that already ran /ss-setup a while ago and are wondering whether they're behind on skills, Golden Rules, or engine docs - especially useful before starting a new feature, so the project picks up upstream fixes without anyone having to manually track StyleSeed's release history.
Source README
StyleSeed Update Assistant
When to Use
Use this skill when you need update StyleSeed engine in your project - analyzes what's outdated and updates safely.
When NOT to use
- For first-time setup → use
/ss-setup - For just one new component or skin - copy that file manually
- For projects that have heavily diverged from upstream - manual diff review first
- For updating user code/components - this updates engine files only, not your custom UI
Automatically detect and update StyleSeed files in the current project.
Reassure the user first
Updating is safe and reversible. Updates are additive - new rules,
components, skins, and skills get added; your theme.css, your components, and
your app code are never overwritten, and design rules only ever get added (never
changed in a breaking way). A big version jump looks like a lot changed, but
it's almost all additions. Do NOT warn the user that the build will break
unless you actually find a changed component/import API. Tell them: commit first,
copy the new rules + skills, run a build, and git reset --hard if anything is
off - they can't permanently break their project.
Instructions
Step 1: Detect Current Setup
Scan the project to find where StyleSeed files are:
### Find DESIGN-LANGUAGE.md
find . -name "DESIGN-LANGUAGE.md" -not -path "*/node_modules/*"
### Find CLAUDE.md
find . -name "CLAUDE.md" -not -path "*/node_modules/*"
### Find skills (ss-* is current; ui-*/ux-* are legacy names to migrate from)
find . -path "*/.claude/skills/ss-*" -o -path "*/.claude/skills/ui-*" -o -path "*/.claude/skills/ux-*" | head -20
### Find theme.css
find . -name "theme.css" -not -path "*/node_modules/*"
### Find .cursorrules
find . -name ".cursorrules"
Report what was found and where.
Step 2: Check StyleSeed Version
Fast check first - compare the local version to the published one without cloning:
### local marker (may be absent on older installs)
cat engine/VERSION 2>/dev/null || cat VERSION 2>/dev/null || echo "unknown"
### latest published version + what's new
curl -s https://styleseed-demo.vercel.app/version.json
If the local version already matches version.json's version, tell the user they're
up to date and stop. Otherwise report whatsNew and continue.
Then clone/pull to actually diff the files:
if [ -d "/tmp/styleseed" ]; then
cd /tmp/styleseed && git pull
else
git clone https://github.com/bitjaru/styleseed.git /tmp/styleseed
fi
Compare:
engine/VERSION(orversion.json) vs the local copy - the source of truth- DESIGN-LANGUAGE.md rule count + Table of Contents
- Skills present in
.claude/skills/vs upstream (don't hardcode a count - list the diff) - Whether
CLAUDE.md,AGENTS.md, and.cursorrulesexist (ship all three) - New engine docs (VISUAL-CRAFT.md, APP-PLAYBOOKS.md, PAGE-TYPES.md)
Step 3: Report & Ask
Show the user what needs updating:
StyleSeed Update Report:
Current state:
- DESIGN-LANGUAGE.md: [location] — [old/current version indicator]
- Skills: [count] found (latest: 12)
- Golden Rules: [yes/no]
- .cursorrules: [yes/no]
Recommended updates:
1. ✅ [safe] Update skills (X → 12)
2. ✅ [safe] Add .cursorrules
3. ⚠️ [review] Update DESIGN-LANGUAGE.md ([old line count] → [new line count])
4. ⚠️ [merge] Add Golden Rules to CLAUDE.md (won't overwrite existing content)
Shall I proceed? (I'll ask before each ⚠️ item)
Step 4: Execute Updates
For each update, in order:
Always safe (do without asking):
- Copy skills:
cp -r /tmp/styleseed/engine/.claude/skills/ .claude/skills/ - Copy .cursorrules (if not exists):
cp /tmp/styleseed/engine/.cursorrules .cursorrules
Ask before doing:
For DESIGN-LANGUAGE.md:
- Show diff summary: how many new rules, what sections added
- Ask: "Update DESIGN-LANGUAGE.md? (Y/N)"
- If yes: copy to the detected location
For CLAUDE.md (Golden Rules):
- Check if Golden Rules section already exists
- If not: ask "Add Golden Rules section to your CLAUDE.md? This adds 10 lines at the top. Your existing content stays untouched."
- If yes: insert Golden Rules after the first heading
Never touch:
- theme.css - say "Your theme.css (skin) is untouched."
- components/ - say "Your components are untouched. Run
/ss-lintto check compliance."
Step 5: Summary
Update complete!
✅ Skills: 12 (added X new)
✅ .cursorrules: added
✅ DESIGN-LANGUAGE.md: updated to latest
✅ Golden Rules: added to CLAUDE.md
Not touched:
- theme.css (your skin)
- components/ (your code)
Next: run /ss-lint on your pages to check for rule violations.
Important
- NEVER overwrite theme.css
- NEVER overwrite a project-specific CLAUDE.md - only MERGE the Golden Rules section
- NEVER overwrite components without explicit user approval
- Always show what will change before changing it
- If unsure, ask the user
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.