prototype

当此技能被调用时：

1. 读取概念描述来自参数。识别此原型必须回答的核心问题。如果概念模糊，在继续之前明确陈述问题。

2. 读取 CLAUDE.md 获取项目上下文和当前技术栈。了解所使用的引擎、语言和框架，以便原型使用兼容的工具构建。

3. 创建原型计划：用 3-5 个要点定义最小可行原型的样子。核心问题是什么？回答它所需的最少代码量是多少？什么可以跳过？

4. 创建原型目录：prototypes/[concept-name]/，其中 [concept-name] 是从概念派生的短 kebab-case 标识符。

5. 在隔离目录中实现原型。每个文件必须以以下内容开头：

   // PROTOTYPE - NOT FOR PRODUCTION
   // 问题：[正在测试的核心问题]
   // 日期：[当前日期]
   

   标准有意放宽：

   • 可以随意硬编码值
   • 使用占位资源
   • 跳过错误处理
   • 使用最简单可行的方案
   • 复制代码而非从正式代码导入

6. 测试概念：运行原型。观察行为。收集可测量的数据（帧时间、交互次数、手感评估）。

7. 生成原型报告并保存到 prototypes/[concept-name]/REPORT.md：

## 原型报告：[概念名称]

### 假设
[我们预期为真的内容 — 我们要回答的问题]

### 方法
[我们构建了什么、花了多长时间、走了哪些捷径]

### 结果
[实际发生了什么 — 具体观察，而非意见]

### 指标
[测试期间收集的任何可测量数据]
- 帧时间：[如相关]
- 手感评估：[主观但具体 — "200ms 延迟时响应感觉迟钝"而非"感觉不好"]
- 玩家操作次数：[如相关]
- 迭代次数：[尝试了多少次才成功]

### 建议：[推进 / 转向 / 放弃]

[用证据解释建议的一段话]

### 如果推进
[从原型到正式实现需要改变什么]
- 架构要求
- 性能目标
- 与原设计的范围调整
- 预估正式开发工作量

### 如果转向
[结果建议的替代方向]

### 如果放弃
[为什么此概念不可行以及我们应该怎么做]

### 经验教训
[影响其他系统或未来工作的发现]

8. 输出摘要给用户：核心问题、结果和建议。附上完整报告的链接 prototypes/[concept-name]/REPORT.md。

重要约束

• 原型代码绝不能从正式源文件导入
• 正式代码绝不能从原型目录导入
• 如果建议是推进，正式实现必须从头编写 — 原型代码不会被重构为正式代码
• 原型总工作量应控制在相当于 1-3 天的工作量内
• 如果原型范围开始膨胀，停下来重新评估问题是否可以简化