c3c10a9fcb
- game-reviewer: 删除本地审查记录,仅Issue评论 - quality-gate-review: 删除审查记录/步骤号/阶段标准 - game-dev: 删除阶段感知节,4个工作流详情拆到技能 - game-designer: 删除原型/批量生产阶段,执行案规范拆到技能 - game-pm: 去掉节号和步骤号 - 全局去掉步骤标号(①-⑧/步骤1-5/1.4.X/第一步-第四步) - 新建技能: code-implementation/deviation-report/design-execution - 原型目录扁平化: docs/design/prototype/* → docs/design/ - requirements-analysis及子文件去步骤号和阶段引用 - stage-iteration/sketch/roadmap去任务编号 - 更新所有docs/design/路径引用
2.6 KiB
2.6 KiB
name: "design-execution" description: "执行案编写技能 — 执行案的格式要求、质量标准、写作示例和技术边界红线。当需要"写执行案"、"编写执行案"、"执行案模板"时使用。"
执行案编写规范
执行案是程序实现的核心输入。本技能定义执行案的格式、必填项、质量标准和写作红线。
触发条件
- 策划产出执行案时:game-designer agent 写执行案时自动使用此技能
- 用户手动触发:用户说"写执行案"、"执行案模板"等
文件表头(必填)
每个执行案必须以以下格式开头:
# <系统名>执行案
## 迭代记录
| 迭代版本 | 修改日期 | 状态 | 说明 |
|----------|----------|------|------|
| v0.1 | YYYY-MM-DD | 📝 设计中 | 初始版本 |
> 状态标记:📝 设计中 | 🔄 开发中 | ✅ 已同步
---
## 系统概述
(描述该系统做什么、服务于什么体验目标)
## 行为规则
(当前最新状态的所有行为规则)
必须包含
- 迭代记录表头 — 文件顶部,追踪版本变更。
- 系统概述 — 做什么、服务于什么体验目标。
- 完整的行为规则 — 每个操作的触发条件 → 表现/响应 → 结束条件。
- 状态和状态转换 — 系统有哪些状态、什么条件触发状态变化。
- 边界情况处理 — 异常/极端情况下的系统行为。
- 跨系统交互 — 与其他系统的关联和影响。
写作质量标准
好的示例:
- ✅ "玩家走近交互物 1.5m 范围内 → 屏幕上方显示交互提示图标('按 E 交互')→ 按下 E 键 → 镜头从跟随位置平滑推近到距目标 0.8-1m 处 → 进入交互状态"
- ✅ "弹珠碰撞判定:弹珠完全停止滚动后 1s(建议值,可调,范围 0.5-2s),判定回合结束"
坏的示例(绝不写这些):
- ❌ "创建一个 Sphere Collision 组件做触发器"
- ❌ "用 Widget Blueprint 显示 UI"
- ❌ "大概在这个距离吧,到时候调"
- ❌ "存入 DataTable 中"
技术边界红线
执行案中绝不包含:
- 具体引擎组件(Blueprint、Widget、Actor、Component 等)
- 代码/脚本架构描述
- 数据存储格式(DataTable、DataAsset、JSON 序列化等)
- 确切的硬编码参数值(标注为"建议值,可调"并附范围)
模糊语言黑名单
执行案中绝不使用:
- "大概" "也许" "可能" "看情况" "差不多"
- "之类的" "等" "等等"(列表应穷举或明确标注为非完整示例)
- "后续再定" "到时候再说"(必须在当前版本决定或标注"vX.X 后处理")