CLAUDE.md

GDD First Workflow（内容改动流程）

当用户提出"游戏内容更改/新增玩法/数值与关卡调整/UI 流程变化/平台与发布策略变化"等需求时，必须遵循以下顺序：

1. 先更新 GDD

   • 优先改动 docs/gdd/（必要时新增/拆分章节、更新表格或验收标准）。
   • GDD 要能反映变更的目的、范围、影响面与验收方式。

2. 再立马提交一次 Git（只包含 GDD 变更）

   • 规则：GDD 更新后应立即提交，不得与实现改动混在同一提交。
   • 提交内容应仅限 docs/gdd/**（以及与文档结构直接相关的少量文件，如索引/目录调整）。
   • 若用户未提供提交信息，使用清晰的默认信息（例如：📝 DOCS: 更新 <主题> 的 GDD）。

3. 最后再进行实现层面的更改

   • 在完成第 2 步提交后，才开始改代码、资源或工程配置。
   • 若实现过程中发现需求需要调整，回到第 1 步先修订 GDD，再继续实现。

适用范围

"游戏内容"包括但不限于：玩法规则、数值、强化池、敌人/Boss、关卡脚本、UI/UX、继续游玩规则、跨平台/CI 发布策略。

Git 提交信息标准（必选格式）

格式：<emoji> <类型大写>: <简短描述>，描述优先使用中文。

类型	Emoji	含义
NEW	📦	新功能/新模块
ADD	🎮	新增玩法、系统或资源
DOCS	📝	文档与 GDD 相关变更
FIX	🐛	修复问题
CHORE	🔧	杂项维护（配置、移除无用项等）
REFACTOR	♻️	重构、结构调整
UI	🎨	UI/界面/样式调整

示例：

• 📦 NEW: 生成游戏 GDD
• 🎮 ADD: 实现第二个敌人炮台机及敌人子弹
• 📝 DOCS: 补充经验数值与继续游玩细则
• 🐛 FIX: 调整拖拽控制与屏幕边界
• 🔧 CHORE: 移除移速提升升级选项
• 🎨 UI: 放大暂停与重新开始按钮

当本规则要求"先提交一次 GDD 变更"时，使用 📝 DOCS: ...。

Git 命令习惯（本项目约定）

当需要提交实现层面的改动时：

• 使用 git add * 一次性加入所有改动（包括新文件和删除），而不是逐个文件 git add xxx。
• 提交完成后，自动执行一次 git push，保持远端与本地同步。