Skip to content
ss-update · styleseed · Flowy
Update StyleSeed engine in your project — analyzes what's outdated and updates safely
One skill from styleseed .
$ npx -y skills add bitjaru/styleseed --skill ss-update --agent claude-codeInstalls just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itself Claude auto-loads it when your prompt matches the work. You can call it Invoke it directly when you want it. Slash command /ss-update👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Update StyleSeed engine in your project — analyzes what's outdated and updates safely </> SKILL.md
ss-update.SKILL.md
---
name : ss-update
description : Update StyleSeed engine in your project — analyzes what's outdated and updates safely
argument-hint: "(no arguments needed)"
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
---
# StyleSeed Update Assistant
## 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
- Updating the engine is separate from re-designing your UI. Steps 1–5 update engine files only;
if you want an old generic build re-done to the new standard, that's **Step 6 (Retrofit)**.
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
Flowy AI Flows that just work. Hand-picked Claude Code plugins that fire the right skill as you prompt.
off — they can't permanently break their project.
## Instructions
### Step 1: Detect Current Setup
Scan the project to find where StyleSeed files are:
```bash
# 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:
```bash
# 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:
```bash
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` (or `version.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 `.cursorrules` exist (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-lint` to 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.
```
### Step 6: Retrofit existing UI (optional but recommended) — "re-do a generic old build"
Updating the rules doesn't re-design screens you already built with an older StyleSeed. If the
user says their existing UI still looks generic/"AI-made" (default indigo, icon-chip cliché,
tight desktop type, no focal point, no design lock), offer to **retrofit it to the new standard**.
This is the migration path for anyone who built before the distinctiveness rules existed:
1. **Write a design lock if missing.** Check for `STYLESEED.md` at the project root. If absent,
run **Quick Setup** (CLAUDE.md) *now* with the user — pin **mood** (edges/feel/density/tone),
a **domain-fit key color** (NOT the default indigo), a **chosen font**, and the **surface**
(mobile vs desktop type scale). Write the lock. Existing generic builds almost always never
had a lock — this is the biggest fix.
2. **Re-score the key screens.** Run **`/ss-score`** on the main pages. The new rubric flags
exactly the old-build tells: default-indigo accent, the icon-chip cliché (§CC-9b), body <16px
on desktop, no focal point, demo layout copied verbatim, missing states.
3. **Apply the fixes.** Run **`/ss-review`** (or `/ss-review --fix`) screen by screen to retint to
the locked key color, replace the uniform icon chips, bump the desktop type scale, and create a
focal point. Re-score to **≥ 80**. Do the highest-traffic screen first.
4. **Report the before/after score** so the upgrade is visible (e.g. "landing 63 → 88").
Frame it honestly: the rules got stronger, so a screen that passed the old bar may score lower
now — that's the point; fixing it is what makes it stop looking AI-made.
## 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
© 2026 Flowy · Free and open source
Built for Claude Code · Not affiliated with Anthropic
