| name | dojo-hack |
| category | process |
| stage | S4 |
| version | 0.2.0 |
| description | Codojo S4 阶段唯一 skill：魔改（可选进阶）。S3 教学完成后的实战环节，
AI 基于项目分析为用户推荐多个魔改方向（加功能、重构、性能优化等），
用户可多选或自定义，然后制定 `.codojo/plan.md` 并按计划对项目进行实际改造。
两种状态模式（自动路由）：
- init : plan.md 不存在 → 推荐魔改方向 → 用户选择 → 生成 plan.md
- resume : plan.md 已存在 → 读取计划 → 从上次断点继续执行
plan.md 随用户需求持续更新，S4 不设边界，直到用户主动说"结束"为止。
触发关键词：魔改、改造项目、加功能、S4、hack、我想改这个项目、
动手改、重构、优化、加个功能、实战。
前置条件：`.codojo/schedule.md` 总进度 = 100%（S3 已完成）。
若前置不满足，必须提示用户先完成 S3 教学，不可跳过。
后置产出：`.codojo/plan.md`（持续更新） + 对项目代码的实际修改。
注意：本 skill 会**实际修改项目代码**，每次代码改动前必须先展示方案并等用户
确认"执行"后才动手，不可自作主张直接改代码。
如果用户未完成 S3 就说"我想改项目"，应由 dojo-stage 拦截并提示先完成教学。
|
dojo-hack — S4 魔改阶段
一句话定位：推荐魔改方向，制定计划，动手改造项目，直到用户满意。
何时使用
- ✅ S3 教学 100% 完成，用户选择进入 S4
- ✅ 用户说"我想魔改"、"给项目加功能"、"改造一下"
- ❌ S3 未完成 → 提示先完成 S3，转
dojo-teach
- ❌ 用户只是想学习不想改代码 → 不强制进入
前置条件
<repo-root>/.codojo/schedule.md 存在且显示 100% 完成
若前置条件不满足，提示用户先完成 S3 教学。
工作流
Step 1：项目深度分析与推荐
全面分析项目代码，从以下维度推荐魔改方向：
- 功能扩展：基于项目已有能力，可以新增哪些实用功能
- 代码重构：哪些地方可以优化结构、提升可读性
- 性能优化：有没有明显的性能瓶颈可以改进
- 测试完善：缺少哪些测试覆盖
- 工程化改进：CI/CD、日志、监控、文档等
输出推荐列表：
## 🎯 魔改方向推荐
根据项目分析，为你推荐以下魔改方向（可多选，也可以自己提需求）：
### 功能扩展类
1. **<功能名>**：<一句话描述 + 预估工作量>
2. **<功能名>**：<一句话描述 + 预估工作量>
### 代码优化类
3. **<优化点>**：<一句话描述 + 预估工作量>
4. **<优化点>**：<一句话描述 + 预估工作量>
### 工程化改进类
5. **<改进点>**：<一句话描述 + 预估工作量>
---
请回复你想做的编号（如「1 3 5」），或者直接告诉我你想做什么改动。
回复「不了」可以跳过 S4，结束整个学习流程。
推荐原则：
- 推荐 5-8 个方向，不要太多造成选择困难
- 每个方向要有具体可落地的改动点，不要空泛
- 按难度从低到高排列
- 预估工作量帮助用户做选择
Step 2：制定 plan.md
根据用户选择（可多选 + 自定义），生成 <repo-root>/.codojo/plan.md：
# 魔改计划
> 根据你的选择生成，AI 将按此计划协助你改造项目。
## 概要
- **选定方向**：<列出>
- **预计总工作量**：约 X 小时
- **当前状态**：进行中
## 任务清单
### 任务 1：<任务名>
- **目标**：<达成什么效果>
- **涉及文件**：<文件路径列表>
- **实施步骤**：
1. <具体步骤>
2. <具体步骤>
3. <具体步骤>
- **验证方式**：<如何确认改动生效>
- **状态**：⚪ 未开始
### 任务 2：<任务名>
...
## 变更日志
<!-- 每次有新需求或计划变更时追加记录 -->
生成后向用户确认：
plan.md 已生成，共 N 个任务。先从「任务 1：<名称>」开始？
Step 3：执行改造
按 plan.md 任务顺序，逐个协助用户完成改造。
代码改动确认协议：
每个任务开始前，AI 必须先向用户展示改动方案并等待确认：
## 🔧 任务 N：<任务名>
**改动方案**：
1. 修改 `<文件路径>` — <改动说明>
2. 新增 `<文件路径>` — <说明>
3. ...
**影响范围**：<哪些现有功能可能受影响>
**验证方式**：<如何确认改动生效>
确认开始？回复「开始」执行，或提出修改意见。
用户回复"开始"、"可以"、"执行"后，才能动手修改代码。
执行流程：
- 讲解思路：这个改动要做什么、为什么这样做、会影响哪些文件
- 协作实施：AI 生成代码改动，解释每处修改的含义，引导用户理解
- 验证结果：指导用户验证改动效果（编译、运行、测试等）
- 更新 plan.md：将任务状态更新为 ✅，记录完成时间
每完成一个任务：
---
✅ 任务 1「<名称>」已完成！
📋 **魔改进度**: 1/N 任务完成
⏭️ 下一个：任务 2「<名称>」
继续？或者有新想法随时告诉我。
---
Step 4：持续迭代
S4 阶段不设终点，持续接受用户新需求：
- 用户新增需求 → 追加到
plan.md 任务清单，在变更日志中记录
- 用户修改需求 → 更新
plan.md 对应任务，在变更日志中记录
- 用户取消某个任务 → 标记为 ❌ 已取消，在变更日志中记录
- 用户说"满意了"/"结束" → 输出完成总结
Step 5：完成总结（用户主动结束时）
## 📋 S4 魔改阶段 完成
**成果总结** ✅
- 完成任务：X 个
- 取消任务：X 个
- 涉及文件：X 个
**改动清单**：
- ✅ 任务 1：<名称> — <一句话成果>
- ✅ 任务 2：<名称> — <一句话成果>
- ...
🎉 整个学习+魔改流程圆满结束！这个项目现在是你的了。
产出
| 文件 | 路径 | 说明 |
|---|
plan.md | <repo-root>/.codojo/plan.md | 魔改计划（持续更新） |
| 代码改动 | <repo-root>/ 项目源码 | 实际代码改造 |
Gotchas
- 魔改最容易翻车的点是破坏原有功能——每个任务完成后必须引导用户做回归验证（至少编译通过）
- 一次改动太多文件会让用户跟不上——即使一个任务涉及多个文件，也要逐个文件讲解和修改，不要一次性全改完
- plan.md 与实际改动容易脱节——每次代码改动后必须同步更新 plan.md 的任务状态和变更日志
- 用户新增需求时容易忘记更新 plan.md——任何新需求、取消、变更都必须先写入 plan.md 再执行
- 推荐魔改方向时不要推荐超出用户当前能力的方向——参考 open-questions.md 的评估结果判断用户水平
- 不要把"用户说可以"误判为"用户说开始"——确认协议要求用户明确回复"开始"、"可以"、"执行"才能动手改代码
不该做的事
- 🚫 在 S3 未完成时直接进入 S4
- 🚫 不经用户确认就修改项目代码（必须遵循代码改动确认协议）
- 🚫 忘记更新 plan.md 的任务状态和变更日志
- 🚫 一次做太大的改动（每次聚焦一个任务，逐文件讲解）
- 🚫 用户提出新需求时不更新 plan.md
- 🚫 改完代码不引导用户做回归验证
输出风格约束
详见共用 reference：../_shared/output-style-guide.md
