ss-update

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

StyleSeed update

StyleSeed 更新

Update the engine payload, not the user's product UI. A release version describes a published line;
engineRevision
identifies the exact maintained rules, skills, entry docs, and palette engine. Two installs with the same release version are not proven equal until their revisions match.
更新engine payload,而非用户的产品UI。发布版本描述一条发布线;
engineRevision
标识精确的维护规则、skills、入口文档和调色板引擎。两个具有相同发布版本的安装,只有当它们的版本号(revision)匹配时,才能被视为完全一致。

When not to use

不适用场景

  • First installation →
    /ss-setup
    or
    $ss-setup
    .
  • One new screen or component →
    /ss-build
    ,
    /ss-page
    , or
    /ss-component
    .
  • A redesign of old UI → update first, then offer the optional retrofit step below.
  • A heavily forked StyleSeed payload → stop after the dry-run report and request a manual diff.
  • 首次安装 → 使用
    /ss-setup
    $ss-setup
  • 新增单个页面或组件 → 使用
    /ss-build
    /ss-page
    /ss-component
  • 旧UI重新设计 → 先更新,再执行下方可选的改造步骤。
  • StyleSeed payload被大量修改 → 在试运行报告后停止操作,请求手动对比差异。

Ownership boundary

所有权边界

StyleSeed owns installed
ss-*
skill payloads and compiled
.styleseed/effective-rules.md
. The project owns
STYLESEED.md
, application code, components, tokens, assets, and any existing
AGENTS.md
,
CLAUDE.md
, or Cursor instructions. Never overwrite project-owned files merely to update StyleSeed.
An update may change design-method behavior, especially across major versions. It is reversible through the user's version control, but it is not correct to promise that every update is additive or non-breaking.
StyleSeed 拥有已安装的
ss-*
skill payloads 以及编译后的
.styleseed/effective-rules.md
。项目方拥有
STYLESEED.md
、应用代码、组件、tokens、资源,以及任何已有的
AGENTS.md
CLAUDE.md
或 Cursor 指令。绝不能仅为了更新StyleSeed而覆盖项目方所有的文件。
更新可能会改变设计方法的行为,尤其是跨大版本更新时。虽然可以通过用户的版本控制回退,但不能承诺每次更新都是增量式或无破坏性的。

Step 1 — Read-only revision check

步骤1 — 只读版本检查

From the user's project root, run the bundled checker by its installed path:
bash
node <installed-ss-update>/scripts/check-update.mjs --project-root . --json
Interpret the result exactly:
  • current
    — installed and published revisions match; stop unless the user explicitly wants a reinstall.
  • update-available
    — refresh the installed payload even when the semantic versions match.
  • project-bundle-stale
    — skills are current; skip reinstall and re-resolve the project.
  • legacy-skill-conflict
    — the retired standalone seven-category reviewer remains beside the canonical skills. Show its path and hash; remove it only after confirming it is not a project-modified skill.
  • remote-revision-unavailable
    — version-only evidence cannot prove currency. Report the boundary and do not say “up to date.”
Also inspect
git status --short
. Do not modify files during this step.
从用户项目根目录,通过已安装路径运行内置的检查器:
bash
node <installed-ss-update>/scripts/check-update.mjs --project-root . --json
严格解读检查结果:
  • current
    — 已安装版本与发布版本匹配;除非用户明确要求重新安装,否则停止操作。
  • update-available
    — 即使语义化版本匹配,也要刷新已安装的payload。
  • project-bundle-stale
    — skills是最新的;跳过重新安装,重新解析项目。
  • legacy-skill-conflict
    — 已停用的独立七类评审工具仍存在于标准skills旁。显示其路径和哈希值;仅在确认它不是项目修改过的skill后再移除。
  • remote-revision-unavailable
    — 仅通过版本信息无法证明是最新状态。报告边界情况,不要说“已更新至最新版本”。
同时检查
git status --short
。此步骤请勿修改任何文件。

Step 2 — Report the update boundary

步骤2 — 报告更新边界

Before changing anything, report:
text
StyleSeed update report
- Installed: <version> @ <revision>
- Published: <version> @ <revision>
- Project bundle: <version/revision or not resolved>
- Project worktree: clean | has existing changes
- Will refresh: canonical ss-* skill payloads
- Will preserve: STYLESEED.md, app code, components, tokens, assets, project instructions
- Requires review: compiled rule-bundle diff and any copied legacy engine docs
If the worktree has unrelated changes, preserve them. Recommend a commit or backup before a method update, but do not use destructive reset/checkout commands as an update strategy.
在进行任何修改前,先报告:
text
StyleSeed 更新报告
- 已安装版本: <version> @ <revision>
- 发布版本: <version> @ <revision>
- 项目包: <version/revision 或未解析>
- 项目工作区: 干净 | 存在未提交更改
- 将刷新: 标准 ss-* skill payloads
- 将保留: STYLESEED.md、应用代码、组件、tokens、资源、项目指令
- 需要审核: 编译后的规则包差异以及任何复制的旧版引擎文档
如果工作区存在无关更改,请保留它们。建议在更新方法前提交或备份,但不要使用破坏性的reset/checkout命令作为更新策略。

Step 3 — Refresh through the original install channel

步骤3 — 通过原安装渠道刷新

Use the same channel that installed StyleSeed:
  • Agent Skills CLI installation: run
    npx skills add bitjaru/styleseed
    and select the same project/provider scope. The repository exposes exactly the canonical 23
    ss-*
    skills.
  • Claude/plugin or another provider marketplace: use that provider's normal update action.
  • Vendored source checkout: fetch the intended tag or commit, review the diff, and update the canonical engine as a set. Do not mix files from two revisions.
Do not implement an update with a blind recursive copy into an existing skills directory. The installer must reconcile the managed payload; project-owned files stay outside that operation.
If this skill was invoked only to inspect availability, stop before the external refresh and present the report.
使用最初安装StyleSeed的相同渠道:
  • Agent Skills CLI安装:运行
    npx skills add bitjaru/styleseed
    并选择相同的项目/提供者范围。该仓库公开了恰好23个标准
    ss-*
    skills。
  • Claude/插件或其他提供者市场:使用该提供者的常规更新操作。
  • Vendored源码检出:获取目标标签或提交记录,检查差异,然后整体更新标准引擎。请勿混合两个版本的文件。
请勿通过盲目递归复制到现有skills目录来实现更新。安装程序必须协调管理的payload;项目方所有的文件应排除在该操作之外。
如果调用此skill仅为了检查更新可用性,请在外部刷新前停止操作并展示报告。

Step 4 — Prove the installed revision

步骤4 — 验证已安装的版本号

Run the new checker's path again. Require the installed and published
engineRevision
values to match before describing the engine as current. A matching version string by itself is not proof.
If the installed payload still reports the old revision, stop. Do not recompile the project from a mixed or unproven installation.
再次运行新检查器的路径。在将引擎描述为最新状态前,要求已安装和发布的
engineRevision
值匹配。仅版本字符串匹配并不足以证明是最新的。
如果已安装的payload仍显示旧版本号,请停止操作。不要从混合或未经验证的安装中重新编译项目。

Step 5 — Recompile the project context

步骤5 — 重新编译项目上下文

When
STYLESEED.md
exists:
  1. Run the installed
    ss-resolve/scripts/resolve-context.mjs
    with
    --project-root . --from-lock STYLESEED.md --agent <agent>
    .
  2. Inspect the diff for
    .styleseed/effective-rules.md
    ,
    .styleseed/manifest.json
    , and generated palette files. The manifest must record the new
    engineRevision
    .
  3. Run the same command with
    --check
    ; require exit status 0.
  4. Report the old and new bundle hashes. Do not use
    llms-full.txt
    as the project context.
The design lock persists selections, but a new engine revision may correctly change the compiled method around those selections. Present that diff instead of hiding it.
STYLESEED.md
存在时:
  1. 运行已安装的
    ss-resolve/scripts/resolve-context.mjs
    ,参数为
    --project-root . --from-lock STYLESEED.md --agent <agent>
  2. 检查
    .styleseed/effective-rules.md
    .styleseed/manifest.json
    以及生成的调色板文件的差异。manifest必须记录新的
    engineRevision
  3. 使用
    --check
    参数运行相同命令;要求退出状态为0。
  4. 报告旧包和新包的哈希值。请勿将
    llms-full.txt
    作为项目上下文。
设计锁会保留选择,但新的引擎版本号可能会在这些选择周围正确地改变编译后的方法。展示该差异,而非隐藏它。

Step 6 — Check legacy copied docs

步骤6 — 检查复制的旧版文档

Older projects may contain copied
DESIGN-LANGUAGE.md
,
PRODUCT-PRINCIPLES.md
,
RULESETS.md
, or provider entry files. Detect and report them. Do not overwrite project
AGENTS.md
,
CLAUDE.md
, or
.cursorrules
; recommend replacing only an identifiable StyleSeed-managed block or removing stale duplicate method files after review.
旧项目可能包含复制的
DESIGN-LANGUAGE.md
PRODUCT-PRINCIPLES.md
RULESETS.md
或提供者入口文件。检测并报告这些文件。请勿覆盖项目的
AGENTS.md
CLAUDE.md
.cursorrules
;建议仅替换可识别的StyleSeed管理块,或在审核后移除过时的重复方法文件。

Optional retrofit

可选改造步骤

Updating the engine does not redesign existing screens. If the user wants a retrofit:
  1. confirm or create
    STYLESEED.md
    ;
  2. re-score the highest-traffic screen against the new effective bundle;
  3. apply approved fixes with
    /ss-review
    or
    $ss-review
    ;
  4. render and inspect with
    /ss-verify
    or
    $ss-verify
    ;
  5. report before/after evidence without claiming the old score was measured when it was not.
更新引擎并不会重新设计现有页面。如果用户需要改造:
  1. 确认或创建
    STYLESEED.md
  2. 根据新的生效包重新评估流量最高的页面;
  3. 使用
    /ss-review
    $ss-review
    应用已批准的修复;
  4. 使用
    /ss-verify
    $ss-verify
    渲染并检查;
  5. 报告改造前后的证据,不要声称旧分数是在未测量时得出的。

Completion report

完成报告

Separate these states:
  • installed revision: verified | not verified;
  • project bundle: recompiled and hash-checked | stale | not present;
  • application code: unchanged | explicitly retrofitted;
  • code gate: passed | not run;
  • visual gate: passed from inspected render | not run.
Never call installation, compilation, a build, or a score a visual verification.
区分以下状态:
  • 已安装版本号: 已验证 | 未验证;
  • 项目包: 已重新编译并哈希检查 | 过时 | 不存在;
  • 应用代码: 未更改 | 已明确改造;
  • 代码检查: 通过 | 未运行;
  • 视觉检查: 通过已检查的渲染 | 未运行。
切勿将安装、编译、构建或分数称为视觉验证。