asset-spec

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

If no argument is provided, check whether

design/assets/entity-inventory.md

exists:

If it exists: read it, find the first entity or screen with status "Needed" but no spec file yet, and use
```
AskUserQuestion
```
:
- Prompt: "The next unspecced item is [name]. Generate specs for it?"
- Options:
```
[A] Yes — spec [name]
```
  /
```
[B] Pick a different item
```
  /
```
[C] Stop here
```
If no entity inventory: check
```
design/assets/asset-manifest.md
```
. If manifest exists, same flow above but reading from manifest.
If neither exists: start the Entity & Screen Inventory flow (Phase 0b below) rather than failing.

若未提供参数，检查

design/assets/entity-inventory.md

是否存在：

若存在：读取该文件，找到第一个状态为“Needed”但尚未生成规范文件的实体或界面，调用
```
AskUserQuestion
```
：
- 提示语：“下一个未生成规范的项是**[name]**。是否为其生成规范？”
- 选项：
```
[A] 是 — 为[name]生成规范
```
  /
```
[B] 选择其他项
```
  /
```
[C] 在此停止
```
若不存在实体清单：检查
```
design/assets/asset-manifest.md
```
。若该清单存在，执行上述相同流程，但从该清单读取内容。
若两者均不存在：启动实体与界面清单流程（下方第0b阶段），而非直接报错。

Phase 0b: Entity & Screen Inventory (runs when no arguments and no existing inventory)

第0b阶段：实体与界面清单（无参数且无现有清单时运行）

This flow produces

design/assets/entity-inventory.md

— the master list of everything the game needs visually. Run once before asset spec work begins.

此流程生成

design/assets/entity-inventory.md

——游戏所需所有视觉元素的主清单。需在资产规范工作开始前运行一次。

Step 1 — Gather from docs

步骤1 — 从文档收集信息

Read all available source material in parallel:

```
design/gdd/systems-index.md
```
— extract every system listed
All GDDs in
```
design/gdd/
```
— extract: Visual/Audio Requirements sections, UI elements mentioned, VFX events, any named entities (characters, enemies, buildings, items)
```
design/art/art-bible.md
```
— extract: any named visual categories, asset type expectations
```
design/narrative/
```
— scan for any character or world entity documents if they exist (optional — not required)

并行读取所有可用源材料：

```
design/gdd/systems-index.md
```
— 提取列出的所有系统
```
design/gdd/
```
下的所有GDD — 提取：视觉/音频要求章节、提及的UI元素、VFX事件、任何命名实体（角色、敌人、建筑、物品）
```
design/art/art-bible.md
```
— 提取：任何命名视觉类别、资产类型预期
```
design/narrative/
```
— 扫描是否存在角色或世界实体文档（可选，非必需）

Step 2 — Build proposed inventory

步骤2 — 构建待确认清单

Organize everything found into categories:

Characters / Protagonists
Enemies / Creatures
Buildings / Structures
Environment / Terrain
Items / Props
VFX / Particles
UI Screens (list each screen by name)
HUD Elements
Audio (SFX, music — descriptions only, no generation prompts)
Other

For each item, note the source doc it was found in.

将找到的所有内容按类别整理：

Characters / Protagonists
Enemies / Creatures
Buildings / Structures
Environment / Terrain
Items / Props
VFX / Particles
UI Screens (list each screen by name)
HUD Elements
Audio (SFX, music — descriptions only, no generation prompts)
Other

为每个项标注其来源文档。

Step 3 — Present and collaborate

步骤3 — 展示并协作

Present the full proposed inventory to the user in conversation. Then use

AskUserQuestion

Prompt: "I found [N] visual entities and [N] UI screens across your GDDs and art bible. Review the list — what's missing, what's not needed?"

Options:

```
[A] Looks good — save this inventory
```
```
[B] Add items I'll describe
```
```
[C] Remove items that don't apply
```
```
[D] Both add and remove — let me edit
```

If [B] or [D]: ask the user to describe additional items. Accept brief descriptions ("a medieval keep, used as a level background") or detailed ones — either works. Work through them collaboratively until the user is satisfied.

If [C] or [D]: ask which items to remove and why. Remove them from the list.

在对话中向用户展示完整的待确认清单。然后调用

AskUserQuestion

：

提示语：“我在您的GDD和art bible中找到了**[N]个视觉实体和[N]个UI界面**。请审核清单——有哪些遗漏或不需要的内容？”

选项：

```
[A] 没问题 — 保存此清单
```
```
[B] 添加我将描述的项
```
```
[C] 删除不适用的项
```

[D] 同时添加和删除 — 让我编辑

若选择[B]或[D]：请用户描述额外的项。接受简短描述（如“用作关卡背景的中世纪城堡”）或详细描述——两种方式均可。协作处理直到用户满意。

若选择[C]或[D]：询问要删除哪些项及原因。从清单中移除这些项。

Step 4 — Write inventory

步骤4 — 写入清单

After user approval, ask: "May I write the entity inventory to

design/assets/entity-inventory.md

Write the file:

markdown

undefined

获得用户批准后，询问：“我可以将实体清单写入

design/assets/entity-inventory.md

吗？”

写入文件：

markdown

undefined

Visual Entity & Screen Inventory

Generated: [date] Sources: [list of source docs read]

Entities

#	Name	Type	Description	Source	Status
1	[name]	Character / Enemy / Building / Environment / Item / Other	[brief description]	[source doc]	Needed

#	Name	Type	Description	Source	Status
1	[name]	Character / Enemy / Building / Environment / Item / Other	[brief description]	[source doc]	Needed

UI Screens

#	Screen Name	Description	Source	Status
1	Main Menu	[description]	[source]	Needed

#	Screen Name	Description	Source	Status
1	Main Menu	[description]	[source]	Needed

HUD Elements

#	Element	Description	Source	Status

#	Element	Description	Source	Status

Audio

#	Name	Type (SFX / Music / Ambient)	Description	Source	Status


After writing, tell the user:
> "Entity inventory saved. Next steps:
> - Run `/ux-design [screen name]` for each UI screen in the inventory
> - Run `/asset-spec entity:[name]` to spec each visual entity
> - Or run `/asset-spec` again to work through the inventory one item at a time"

---

#	Name	Type (SFX / Music / Ambient)	Description	Source	Status


写入完成后，告知用户：
> “实体清单已保存。下一步：
> - 对清单中的每个UI界面运行`/ux-design [screen name]`
> - 对每个视觉实体运行`/asset-spec entity:[name]`生成规范
> - 或再次运行`/asset-spec`，逐个处理清单中的项"

---

Phase 0: Parse Arguments

第0阶段：解析参数

Extract:

Target type:
```
system
```
,
```
level
```
, or
```
character
```
Target name: the name after the colon (normalize to kebab-case)
Review mode:
```
--review [full|lean|solo]
```
if present

Mode behavior:

```
full
```
(default): spawn both
```
art-director
```
and
```
technical-artist
```
in parallel
```
lean
```
: spawn
```
art-director
```
only — faster, skips technical constraint pass
```
solo
```
: no agent spawning — main session writes specs from art bible rules alone. Use for simple asset categories or when speed matters more than depth.

提取：

目标类型：
```
system
```
、
```
level
```
或
```
character
```
目标名称：冒号后的名称（标准化为短横线分隔格式）
审核模式：若存在则为
```
--review [full|lean|solo]
```

模式行为：

```
full
```
（默认）：并行启动
```
art-director
```
和
```
technical-artist
```
```
lean
```
：仅启动
```
art-director
```
——速度更快，跳过技术约束校验
```
solo
```
：不启动Agent——主会话仅根据art bible规则编写规范。适用于简单资产类别或更注重速度而非深度的场景。

Phase 1: Gather Context

第1阶段：收集上下文

Read all source material before asking the user anything.

在询问用户任何问题之前，读取所有源材料。

Required reads:

必需读取：

Art bible: Read
```
design/art/art-bible.md
```
— fail if missing:
"No art bible found. Run
```
/art-bible
```
first — asset specs are anchored to the art bible's visual rules and asset standards." Extract: Visual Identity Statement, Color System (semantic colors), Shape Language, Asset Standards (Section 8 — dimensions, formats, polycount budgets, texture resolution tiers).
Technical preferences: Read
```
.claude/docs/technical-preferences.md
```
— extract performance budgets and naming conventions.

美术手册（art bible）：读取
```
design/art/art-bible.md
```
——若缺失则报错：
"未找到art bible。请先运行
```
/art-bible
```
——资产规范需基于art bible的视觉规则和资产标准。" 提取：视觉身份声明、色彩系统（语义色彩）、造型语言、资产标准（第8节——尺寸、格式、多边形数量预算、纹理分辨率层级）。
技术偏好：读取
```
.claude/docs/technical-preferences.md
```
——提取性能预算和命名规范。

Source doc reads (by target type):

按目标类型读取源文档：

system: Read
```
design/gdd/[target-name].md
```
. Extract the Visual/Audio Requirements section. If it doesn't exist or reads
```
[To be designed]
```
:
"The Visual/Audio section of
```
design/gdd/[target-name].md
```
is empty. Either run
```
/design-system [target-name]
```
to complete the GDD, or describe the visual needs manually." Use
```
AskUserQuestion
```
:
```
[A] Describe needs manually
```
/
```
[B] Stop — complete the GDD first
```
level: Read
```
design/levels/[target-name].md
```
. Extract art requirements, asset list, VFX needs, and the art-director's production concept specs from Step 4.
character or entity: Read
```
design/narrative/characters/[target-name].md
```
or search
```
design/narrative/
```
and
```
design/assets/entity-inventory.md
```
for a matching entry. Extract visual description, role, and any specified distinguishing features.
- If no source doc exists: do not fail. Instead, use
```
AskUserQuestion
```
  :
  - Prompt: "No profile found for [name]. Describe it briefly — a sentence or two is enough."
  - Options:
```
[A] Describe it now
```
    /
```
[B] Skip this entity
```
    /
```
[C] Stop here
```
  - If [A]: the user's description becomes the source. Brief answers produce concise specs; detailed answers produce detailed specs. Accept whatever level of detail the user provides and work from it.

system：读取
```
design/gdd/[target-name].md
```
。提取视觉/音频要求章节。若该章节不存在或内容为
```
[To be designed]
```
：
"
```
design/gdd/[target-name].md
```
的视觉/音频章节为空。请运行
```
/design-system [target-name]
```
完成GDD，或手动描述视觉需求。" 调用
```
AskUserQuestion
```
：
```
[A] 手动描述需求
```
/
```
[B] 停止——先完成GDD
```
level：读取
```
design/levels/[target-name].md
```
。提取美术要求、资产清单、VFX需求，以及第4阶段中美术总监的制作概念规范。
character或entity：读取
```
design/narrative/characters/[target-name].md
```
，或在
```
design/narrative/
```
和
```
design/assets/entity-inventory.md
```
中搜索匹配条目。提取视觉描述、角色定位，以及任何指定的显著特征。
- 若不存在源文档：不报错。而是调用
```
AskUserQuestion
```
  ：
  - 提示语：“未找到**[name]**的档案。请简要描述——一两句话即可。”
  - 选项：
```
[A] 现在描述
```
    /
```
[B] 跳过此实体
```
    /
```
[C] 在此停止
```
  - 若选择[A]：用户的描述将作为来源。简短描述生成简洁规范；详细描述生成详细规范。接受用户提供的任何详细程度并以此为基础工作。

Optional reads:

可选读取：

Existing manifest: Read
```
design/assets/asset-manifest.md
```
if it exists — extract already-specced assets for this target to avoid duplicates.
Related specs: Glob
```
design/assets/specs/*.md
```
— scan for assets that could be shared (e.g., a common UI element specced for one system might apply here too).

现有清单：若
```
design/assets/asset-manifest.md
```
存在则读取——提取该目标已生成规范的资产，避免重复。
相关规范：遍历
```
design/assets/specs/*.md
```
——扫描可共享的资产（例如，为某一系统生成规范的通用UI元素可能也适用于此处）。

Present context summary:

展示上下文摘要：

Asset Spec: [Target Type] — [Target Name]

Source doc: [path] — [N] asset types identified

Art bible: found — Asset Standards at Section 8

Existing specs for this target: [N already specced / none]

Shared assets found in other specs: [list or "none"]

资产规范：[目标类型] — [目标名称]

源文档：[路径] — 识别出[N]种资产类型

art bible：已找到 — 资产标准位于第8节

该目标的现有规范：[N个已生成 / 无]

在其他规范中找到的共享资产：[列表或“无”]

Phase 2: Asset Identification

第2阶段：资产识别

From the source doc, extract every asset type mentioned — explicit and implied.

For systems: look for VFX events, sprite references, UI elements, audio triggers, particle effects, icon needs, and any "visual feedback" language.

For levels: look for unique environment props, atmospheric VFX, lighting setups, ambient audio, skybox/background, and any area-specific materials.

For characters: look for sprite sheets (idle, walk, attack, death), portrait/avatar, VFX attached to abilities, UI representation (icon, health bar skin).

Group assets into categories:

Sprite / 2D Art — character sprites, UI icons, tile sheets
VFX / Particles — hit effects, ambient particles, screen effects
Environment — props, tiles, backgrounds, skyboxes
UI — HUD elements, menu art, fonts (if custom)
Audio — SFX, music tracks, ambient loops (note: audio specs are descriptions only — no generation prompts)
3D Assets — meshes, materials (if applicable per engine)

Present the full identified list to the user. Use

AskUserQuestion

Prompt: "I identified [N] assets across [N] categories for [target]. Review before speccing:"
Show the grouped list in conversation text first

Options:

[A] Proceed — spec all of these

[B] Remove some assets

[C] Add assets I didn't catch

[D] Adjust categories

Do NOT proceed to Phase 3 without user confirmation of the asset list.

从源文档中提取所有提及的资产类型——包括显性和隐性的。

针对系统：查找VFX事件、精灵引用、UI元素、音频触发器、粒子效果、图标需求，以及任何“视觉反馈”相关表述。

针对关卡：查找独特环境道具、氛围VFX、光照设置、环境音频、天空盒/背景，以及任何区域特定材质。

针对角色：查找精灵表（ idle、walk、attack、death动作）、肖像/头像、技能附带VFX、UI表现（图标、血条皮肤）。

将资产按类别分组：

Sprite / 2D Art — 角色精灵、UI图标、瓦片集
VFX / Particles — 击中效果、环境粒子、屏幕特效
Environment — 道具、瓦片、背景、天空盒
UI — HUD元素、菜单美术、字体（若为自定义）
Audio — SFX、音乐曲目、环境循环音（注：音频规范仅为描述，不包含生成提示词）
3D Assets — 网格、材质（若引擎适用）

向用户展示完整的识别清单。调用

AskUserQuestion

：

提示语：“我为**[目标]**识别出[N]个资产，分属[N]个类别。生成规范前请审核：”
先在对话文本中展示分组后的清单

选项：

[A] 继续 — 为所有这些资产生成规范

[B] 删除部分资产

[C] 添加我未提到的资产

[D] 调整类别

未获得用户对资产清单的确认前，不得进入第3阶段。

Phase 3: Spec Generation

第3阶段：规范生成

Spawn specialist agents based on review mode. Issue all Task calls simultaneously — do not wait for one before starting the next.

根据审核模式启动专业Agent。同时发起所有Task调用——无需等待一个完成后再启动下一个。

Full mode — spawn in parallel:

完整模式 — 并行启动：

art-director
via Task:

Provide: full asset list from Phase 2, art bible Visual Identity Statement, Color System, Shape Language, the source doc's visual requirements, and any reference games/art mentioned in the art bible Section 9
Ask: "For each asset in this list, produce: (1) a 2–3 sentence visual description anchored to the art bible's shape language and color system — be specific enough that two different artists would produce consistent results; (2) a generation prompt ready for use with AI image tools (Midjourney/Stable Diffusion style — include style keywords, composition, color palette anchors, negative prompts); (3) which art bible rules directly govern this asset (cite by section). For audio assets, describe the sonic character instead of a generation prompt."

technical-artist
via Task:

Provide: full asset list, art bible Asset Standards (Section 8), technical-preferences.md performance budgets, engine name and version
Ask: "For each asset in this list, specify: (1) exact dimensions or polycount (match the art bible Asset Standards tiers — do not invent new sizes); (2) file format and export settings; (3) naming convention (from technical-preferences.md); (4) any engine-specific constraints this asset type must respect; (5) LOD requirements if applicable. Flag any asset type where the art bible's preferred standard conflicts with the engine's constraints."

通过Task启动**

art-director

**：

提供：第2阶段的完整资产清单、art bible视觉身份声明、色彩系统、造型语言、源文档的视觉要求，以及art bible第9节中提及的任何参考游戏/美术作品
请求：“针对清单中的每个资产，生成：(1) 2-3句基于art bible造型语言和色彩系统的视觉描述——需足够具体，确保两位不同的艺术家能产出一致结果；(2) 可直接用于AI图像工具的生成提示词（Midjourney/Stable Diffusion风格——包含风格关键词、构图、色彩 palette 锚点、反向提示词）；(3) 直接约束该资产的art bible规则（标注章节）。对于音频资产，描述其声音特征而非生成提示词。”

通过Task启动**

technical-artist

**：

提供：完整资产清单、art bible资产标准（第8节）、technical-preferences.md中的性能预算、引擎名称及版本
请求：“针对清单中的每个资产，指定：(1) 精确尺寸或多边形数量（匹配art bible资产标准层级——不得自定义新尺寸）；(2) 文件格式及导出设置；(3) 命名规范（来自technical-preferences.md）；(4) 该资产类型必须遵守的任何引擎特定约束；(5) 若适用，LOD要求。标记art bible首选标准与引擎约束冲突的任何资产类型。”

Lean mode — spawn art-director only (skip technical-artist).

精简模式 — 仅启动art-director（跳过technical-artist）。

Solo mode — skip both. Derive specs from art bible rules alone, noting that technical constraints were not validated.

独立模式 — 跳过两者。仅基于art bible规则推导规范，并注明技术约束未验证。

Collect both responses before Phase 4. If any conflict exists between art-director and technical-artist (e.g., art-director specifies 4K textures but technical-artist flags the engine budget requires 512px), surface it explicitly — do NOT silently resolve.

**进入第4阶段前收集两个Agent的响应。**若art-director与technical-artist存在任何冲突（例如，art-director指定4K纹理，但technical-artist指出引擎预算要求512px），需明确告知用户——不得默默解决冲突。

Phase 4: Compile and Review

第4阶段：编译与审核

Combine the agent outputs into a draft spec per asset. Present all specs in conversation text using this format:

undefined

将Agent的输出合并为每个资产的规范草稿。使用以下格式在对话文本中展示所有规范：

undefined

ASSET-[NNN] — [Asset Name]

Field	Value
Category	[Sprite / VFX / Environment / UI / Audio / 3D]
Dimensions	[e.g. 256×256px, 4-frame sprite sheet]
Format	[PNG / SVG / WAV / etc.]
Naming	[e.g. vfx_frost_hit_01.png]
Polycount	[if 3D — e.g. <800 tris]
Texture Res	[e.g. 512px — matches Art Bible §8 Tier 2]

Visual Description: [2–3 sentences. Specific enough for two artists to produce consistent results.]

Art Bible Anchors:

§3 Shape Language: [relevant rule applied]
§4 Color System: [color role — e.g. "uses Threat Blue per semantic color rules"]

Generation Prompt: [Ready-to-use prompt. Include: style keywords, composition notes, color palette anchors, lighting direction, negative prompts.]

Status: Needed


After presenting all specs, use `AskUserQuestion`:
- Prompt: "Asset specs for **[target]** — [N] assets. Review complete?"
- Options: `[A] Approve all — write to file` / `[B] Revise a specific asset` / `[C] Regenerate with different direction`

If [B]: ask which asset and what to change. Revise inline and re-present. Do NOT re-spawn agents for minor text revisions — only re-spawn if the visual direction itself needs to change.

If [C]: ask what direction to change. Re-spawn the relevant agent with the updated brief.

---

Field	Value
Category	[Sprite / VFX / Environment / UI / Audio / 3D]
Dimensions	[e.g. 256×256px, 4-frame sprite sheet]
Format	[PNG / SVG / WAV / etc.]
Naming	[e.g. vfx_frost_hit_01.png]
Polycount	[if 3D — e.g. <800 tris]
Texture Res	[e.g. 512px — matches Art Bible §8 Tier 2]

Visual Description: [2–3 sentences. Specific enough for two artists to produce consistent results.]

Art Bible Anchors:

§3 Shape Language: [relevant rule applied]
§4 Color System: [color role — e.g. "uses Threat Blue per semantic color rules"]

Generation Prompt: [Ready-to-use prompt. Include: style keywords, composition notes, color palette anchors, lighting direction, negative prompts.]

Status: Needed


展示所有规范后，调用`AskUserQuestion`：
- 提示语：“**[目标]**的资产规范——共[N]个资产。审核完成？”
- 选项：`[A] 全部批准 — 写入文件` / `[B] 修改特定资产` / `[C] 按不同方向重新生成`

若选择[B]：询问要修改哪个资产及修改内容。在线修改并重新展示。仅当视觉方向本身需要更改时才重新启动Agent——小文本修改无需重新启动Agent。

若选择[C]：询问更改方向。使用更新后的需求重新启动相关Agent。

---

Phase 5: Write Spec File

第5阶段：写入规范文件

After approval, ask: "May I write the spec to

design/assets/specs/[target-name]-assets.md

Write the file with:

markdown

undefined

获得批准后，询问：“我可以将规范写入

design/assets/specs/[target-name]-assets.md

吗？”

写入文件，格式如下：

markdown

undefined

Asset Specs — [Target Type]: [Target Name]

Source: [path to source GDD/level/character doc] Art Bible: design/art/art-bible.md Generated: [date] Status: [N] assets specced / [N] approved / [N] in production / [N] done

[all asset specs in ASSET-NNN format]


Then update `design/assets/asset-manifest.md`. If it doesn't exist, create it:

```markdown

Source: [path to source GDD/level/character doc] Art Bible: design/art/art-bible.md Generated: [date] Status: [N] assets specced / [N] approved / [N] in production / [N] done

[all asset specs in ASSET-NNN format]


然后更新`design/assets/asset-manifest.md`。若该文件不存在则创建：

```markdown

Asset Manifest

Last updated: [date]

Progress Summary

Total	Needed	In Progress	Done	Approved
[N]	[N]	[N]	[N]	[N]

Total	Needed	In Progress	Done	Approved
[N]	[N]	[N]	[N]	[N]

Assets by Context

[Target Type]: [Target Name]

Asset ID	Name	Category	Status	Spec File
ASSET-001	[name]	[category]	Needed	design/assets/specs/[target]-assets.md


If the manifest already exists, append the new context block and update the Progress Summary counts.

Ask: "May I update `design/assets/asset-manifest.md`?"

---

Asset ID	Name	Category	Status	Spec File
ASSET-001	[name]	[category]	Needed	design/assets/specs/[target]-assets.md


若清单已存在，追加新的上下文块并更新进度摘要计数。

询问：“我可以更新`design/assets/asset-manifest.md`吗？”

---

Phase 6: Close

第6阶段：结束

Use

AskUserQuestion

Prompt: "Asset specs complete for [target]. What's next?"

Options:

[A] Spec another system — /asset-spec system:[next-system]

[B] Spec a level — /asset-spec level:[level-name]

[C] Spec a character — /asset-spec character:[character-name]

[D] Run /asset-audit — validate delivered assets against specs

```
[E] Stop here
```

调用

AskUserQuestion

：

提示语：“**[目标]**的资产规范已完成。下一步？”

选项：

[A] 为其他系统生成规范 — /asset-spec system:[next-system]

[B] 为关卡生成规范 — /asset-spec level:[level-name]

[C] 为角色生成规范 — /asset-spec character:[character-name]

[D] 运行/asset-audit — 根据规范验证交付的资产

```
[E] 在此停止
```

Asset ID Assignment

资产ID分配

Asset IDs are assigned sequentially across the entire project — not per-context. Read the manifest before assigning IDs to find the current highest number:

Grep pattern="ASSET-" path="design/assets/asset-manifest.md"

Start new assets from

ASSET-[highest + 1]

. This ensures IDs are stable and unique across the whole project.

If no manifest exists yet, start from

ASSET-001

资产ID在整个项目中按顺序分配——而非按上下文分配。分配ID前读取清单，找到当前最高编号：

Grep pattern="ASSET-" path="design/assets/asset-manifest.md"

从

ASSET-[最高编号+1]

开始分配新资产ID。确保ID在整个项目中稳定且唯一。

若尚未存在清单，从

ASSET-001

开始。

Shared Asset Protocol

共享资产协议

Before speccing an asset, check if an equivalent already exists in another context's spec:

Common UI elements (health bars, score displays) are often shared across systems
Generic environment props may appear in multiple levels
Character VFX (hit sparks, death effects) may reuse a base spec with color variants

If a match is found: reference the existing ASSET-ID rather than creating a duplicate. Note the shared usage in the manifest's referenced-by column.

"ASSET-012 (Generic Hit Spark) already specced for Combat system. Reusing for Tower Defense — adding tower-defense to referenced-by."

生成资产规范前，检查其他上下文的规范中是否已存在等效资产：

通用UI元素（血条、分数显示）通常在多个系统间共享
通用环境道具可能出现在多个关卡中
角色VFX（击中火花、死亡效果）可能重用基础规范并调整颜色变体

若找到匹配项：引用现有ASSET-ID而非创建重复项。在清单的“引用自”列中注明共享使用情况。

“ASSET-012（通用击中火花）已为Combat系统生成规范。为Tower Defense重用该规范——在引用自中添加tower-defense。”

Error Recovery Protocol

错误恢复协议

If any spawned agent returns BLOCKED or cannot complete:

Surface immediately: "[AgentName]: BLOCKED — [reason]"
In
```
lean
```
mode or if
```
technical-artist
```
blocks: proceed with art-director output only — note that technical constraints were not validated
In
```
solo
```
mode or if
```
art-director
```
blocks: derive descriptions from art bible rules — flag as "Art director not consulted — verify against art bible before production"
Always produce a partial spec — never discard work because one agent blocked

若任何启动的Agent返回BLOCKED或无法完成：

立即告知用户：“[AgentName]: BLOCKED — [原因]”
在精简模式或technical-artist阻塞时：仅使用art-director的输出继续——注明技术约束未验证
在独立模式或art-director阻塞时：基于art bible规则推导描述——标记为“未咨询美术总监——生产前需对照art bible验证”
始终生成部分规范——不得因一个Agent阻塞而丢弃已完成工作

Collaborative Protocol

协作协议

Every phase follows: Identify → Confirm → Generate → Review → Approve → Write

Never spec assets without first confirming the asset list with the user
Always anchor specs to the art bible — a spec that contradicts the art bible is wrong
Surface all agent disagreements — do not silently pick one
Write the spec file only after explicit approval
Update the manifest immediately after writing the spec

每个阶段遵循：识别 → 确认 → 生成 → 审核 → 批准 → 写入

未先获得用户对资产清单的确认，不得生成资产规范
规范必须始终基于art bible——与art bible冲突的规范无效
需明确告知用户所有Agent的分歧——不得默默选择某一方
仅在获得明确批准后才写入规范文件
写入规范后立即更新清单

asset-spec

Original

Translation

Phase 0b: Entity & Screen Inventory (runs when no arguments and no existing inventory)

第0b阶段：实体与界面清单（无参数且无现有清单时运行）

Step 1 — Gather from docs

步骤1 — 从文档收集信息

Step 2 — Build proposed inventory

步骤2 — 构建待确认清单

Step 3 — Present and collaborate

步骤3 — 展示并协作

Step 4 — Write inventory

步骤4 — 写入清单

Visual Entity & Screen Inventory

Visual Entity & Screen Inventory

Entities

Entities

UI Screens

UI Screens

HUD Elements

HUD Elements

Audio

Audio

Phase 0: Parse Arguments

第0阶段：解析参数

Phase 1: Gather Context

第1阶段：收集上下文

Required reads:

必需读取：

Source doc reads (by target type):

按目标类型读取源文档：

Optional reads:

可选读取：

Present context summary:

展示上下文摘要：

Phase 2: Asset Identification

第2阶段：资产识别

Phase 3: Spec Generation

第3阶段：规范生成

Full mode — spawn in parallel:

完整模式 — 并行启动：

Lean mode — spawn art-director only (skip technical-artist).

精简模式 — 仅启动art-director（跳过technical-artist）。

Solo mode — skip both. Derive specs from art bible rules alone, noting that technical constraints were not validated.

独立模式 — 跳过两者。仅基于art bible规则推导规范，并注明技术约束未验证。

Phase 4: Compile and Review

第4阶段：编译与审核

ASSET-[NNN] — [Asset Name]

ASSET-[NNN] — [Asset Name]

Phase 5: Write Spec File

第5阶段：写入规范文件

Asset Specs — [Target Type]: [Target Name]

Asset Specs — [Target Type]: [Target Name]

Asset Manifest

Asset Manifest

Progress Summary

Progress Summary

Assets by Context

Assets by Context

[Target Type]: [Target Name]

[Target Type]: [Target Name]

Phase 6: Close

第6阶段：结束

Asset ID Assignment

资产ID分配

Shared Asset Protocol

共享资产协议

Error Recovery Protocol

错误恢复协议

Collaborative Protocol

协作协议

Recommended Next Steps

推荐下一步