Back to Details

marrow-apply

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Marrow Apply

Marrow Apply

You are about to build something visual. Before writing a single line of code, this skill loads the project's design soul and makes it the law for everything you produce.
你即将构建可视化内容。在编写任何代码之前，此能力会加载项目的设计灵魂，并将其作为你所有产出必须遵循的准则。

Step 1 — Check for .marrow.md

步骤1 — 检查.marrow.md

Look for 
.marrow.md
in the project root (and parent directories up to the git root).
If found: Read it completely. Every rule in it applies to this task. Proceed to Step 2.
If not found: Do not block the task. Instead, prepend a brief notice to your response:
⚠ No .marrow.md found in this project.
  Run /marrow with reference images to extract the design soul.
  Building with general best practices for now.
Then proceed with high-quality frontend defaults. Do not ask the user to run 
/marrow
repeatedly — say it once.
在项目根目录下查找
.marrow.md
（并向上遍历父目录直到git根目录）。
如果找到文件： 完整阅读其内容，里面的所有规则都适用于当前任务，进入步骤2。
如果未找到文件： 不要阻塞任务执行，而是在你的回复开头添加一段简短提示：
⚠ No .marrow.md found in this project.
  Run /marrow with reference images to extract the design soul.
  Building with general best practices for now.
之后使用高质量的前端默认规范继续开发，不要反复要求用户运行
/marrow
，仅提示一次即可。

Step 2 — Internalize Before You Build

步骤2 — 开发前内化规则

Do not skim 
.marrow.md
. Read it as instructions, not documentation.
Before touching the task, answer these internally:
  1. What is the soul of this design in one sentence? (from Section 0)
  2. What is the brand accent, and what percentage of visual area should it cover? (from Section 1 + 4)
  3. What spacing unit governs this design, and what rhythm type? (from Section 2)
  4. What are the 3 brand personality words? (from Section 0)
  5. What are the top 3 anti-patterns I must not do? (from Section 8)
If you cannot answer all 5 from 
.marrow.md
, the file is incomplete — flag which sections are missing and note what defaults you're using.
不要略读
.marrow.md
，将其视作操作指令而非文档来阅读。 在开始处理任务前，先在内部明确以下问题的答案：
  1. 用一句话概括这个设计的灵魂是什么？（来自第0节）
  2. 品牌强调色是什么，它应该覆盖多大比例的视觉区域？（来自第1节+第4节）
  3. 这个设计的间距单位是什么，遵循什么节奏类型？（来自第2节）
  4. 品牌个性的三个关键词是什么？（来自第0节）
  5. 我必须避免的三大反模式是什么？（来自第8节）
如果无法从
.marrow.md
中找到全部5个问题的答案，说明文件内容不完整——标注出缺失的章节，并说明你将使用的默认规则。

Step 3 — Build Inside the Soul

步骤3 — 在设计灵魂框架内开发

Now build what the user asked for. Every decision — spacing, color, type, motion, component structure — must be traceable back to a rule in 
.marrow.md
.
现在开始构建用户要求的内容。每一项决策——间距、颜色、字体、动效、组件结构——都必须能追溯到
.marrow.md
中的某条规则。

Enforcement rules while building:

开发时的执行规则：

Color
  • Use only the colors defined in Section 4
  • Apply the brand accent at its documented visual weight — not more
  • If you find yourself reaching for a color not in the palette, stop and find the closest documented color instead
Spacing
  • Use the base unit from Section 2 for all spacing values
  • Apply the rhythm type: if it's contextual, tight inside components and generous between. If regular, stick to the scale
  • Never tighten spacing to "fit more in" — that breaks the silence rule
Typography
  • Use the typefaces and scale from Section 3 only
  • Never introduce a new font weight that isn't documented
  • Apply tracking rules exactly — if all-caps labels use 0.08em, every all-caps label uses 0.08em
Components
  • Follow the button hierarchy from Section 5 — don't invent a new button style
  • Match the border-radius documented — don't round corners more because it "looks friendlier"
  • Follow the interactive feedback philosophy exactly
Motion
  • Use the easing curve from Section 7 as the default for all transitions
  • Use the duration scale — don't use 300ms if the scale says micro interactions are 100ms
  • If the design's motion personality is "still", do not add hover animations that weren't explicitly asked for
Layout
  • Follow the grid and alignment axis from Section 6
  • Respect the content-to-canvas ratio — don't fill every pixel
  • Never break the layout DNA (e.g., if it's editorial, don't make it look like a dashboard)
颜色
  • 仅使用第4节中定义的颜色
  • 按照文档规定的视觉权重使用品牌强调色，不可超额使用
  • 如果你想要使用调色板以外的颜色，请停止，改用文档中最接近的颜色
间距
  • 所有间距值都使用第2节中的基础单位
  • 遵循节奏类型：如果是上下文相关的，组件内部间距紧凑，组件之间间距宽松；如果是常规节奏，严格遵循间距尺度
  • 永远不要为了“塞下更多内容”缩小间距——这会破坏静默规则
排版
  • 仅使用第3节中的字体和字号尺度
  • 永远不要引入文档中没有的新字重
  • 严格执行字间距规则：如果全大写标签要求使用0.08em的字间距，那么所有全大写标签都要使用0.08em的字间距
组件
  • 遵循第5节中的按钮层级，不要自创按钮样式
  • 匹配文档规定的border-radius，不要因为“看起来更友好”就把圆角设得更大
  • 严格遵循交互反馈的设计理念
动效
  • 所有过渡效果默认使用第7节中的缓动曲线
  • 使用时长尺度：如果规范中定义微交互时长为100ms，就不要用300ms
  • 如果设计的动效风格是“静态”，不要添加未被明确要求的悬停动画
布局
  • 遵循第6节中的网格和对齐轴规则
  • 遵守内容与画布的比例，不要填满每一个像素
  • 永远不要破坏布局DNA（比如如果是 editorial 风格的布局，不要把它做成dashboard的样子）

Step 4 — Marrow Check Before Delivering

步骤4 — 交付前的Marrow检查

Before showing the result, run the Marrow Check from Section 11 of 
.marrow.md
internally.
If any check fails:
  • Fix the violation before delivering
  • Do not mention the check to the user unless a violation required a significant decision they should know about
If a check cannot pass because the user's request conflicts with the soul (e.g., "make this button bright red" when the palette has no red), flag it clearly:
⚠ Soul conflict: This design's palette doesn't include red (Section 4).
  The closest option that maintains the soul is [X].
  I've used [X] — let me know if you want to override.
Never silently break the soul. Never silently refuse. Flag and offer the closest valid alternative.
在展示结果前，先在内部执行
.marrow.md
第11节中的Marrow检查。
如果有任何检查未通过：
  • 交付前修复违规内容
  • 不需要向用户提及检查过程，除非违规内容需要你做出用户应该知晓的重大决策
如果因为用户的请求与设计灵魂冲突导致检查无法通过（比如调色板中没有红色，但用户要求“把这个按钮做成亮红色”），明确标注冲突：
⚠ Soul conflict: This design's palette doesn't include red (Section 4).
  The closest option that maintains the soul is [X].
  I've used [X] — let me know if you want to override.
永远不要悄悄破坏设计灵魂，也不要悄悄拒绝需求，标注冲突并提供最接近的合法替代方案。

What This Skill Does NOT Do

此能力不包含的功能

  • It does not re-run the extraction (that's 
    /marrow
    )
  • It does not ask the user questions before building — it reads 
    .marrow.md
    and acts
  • It does not override user requests — it channels them through the soul
  • It does not trigger on non-visual tasks (APIs, database, logic, tests with no UI)
  • 不会重新运行设计提取流程（那是
    /marrow
    命令的功能）
  • 开发前不会向用户提问，它会读取
    .marrow.md
    并直接执行
  • 不会覆盖用户的请求，它会通过设计灵魂框架来处理请求
  • 不会在非可视化任务中触发（API、数据库、逻辑、无UI的测试）

If .marrow.md Is Stale or Wrong

如果.marrow.md内容过时或错误

The user can re-run 
/marrow
at any time with new images to overwrite 
.marrow.md
. This skill always reads the current file — no cache, no memory of previous versions.
用户可以随时使用新图片重新运行
/marrow
命令来覆盖
.marrow.md
文件，此能力始终读取当前最新的文件内容——无缓存，不会记忆之前的版本。