Plan: {Feature Name}

Source PRD: {path} Selected Milestone: {milestone or phase name} Complexity: {Small | Medium | Large}

Summary

{2-3 sentences}

Patterns to Mirror

Category	Source	Pattern
Naming	path:line	{short description}
Errors	path:line	{short description}
Tests	path:line	{short description}

Files to Change

File	Action	Why
path	CREATE / UPDATE / DELETE	{reason}

Tasks

Task 1: {name}

• Action: {what to do}
• Mirror: {pattern to follow}
• Validate: {command that proves correctness}

Validation

{project-specific validation commands}

Risks

Risk	Likelihood	Mitigation

Acceptance

• [ ] All tasks complete
• [ ] Validation passes
• [ ] Patterns mirrored, not reinvented

这套结构有几个可验证性的设计：每个任务（Task）都带 **Validate** 字段（一条能证明正确性的命令），"Patterns to Mirror" 表用 `path:line` 精确引用代码位置，"Files to Change" 表把每个文件变更标注为 CREATE / UPDATE / DELETE 并给出理由。写入工件后，`/plan` 会报告其路径并**等待确认，然后才允许写代码**。

## 确认门控：文本确认与可视化确认

文档中用 CRITICAL 标注的核心规则是：

> 在用户显式确认（"yes"、"proceed" 或类似肯定回复）之前，该命令**不会写任何代码**。

如果想修改计划，可以用这些回复方式：

- `modify: [your changes]`
- `different approach: [alternative]`
- `skip phase 2 and do phase 3 first`

除文本确认外，仓库还提供了一个可视化的确认通道：**Plan Canvas**。源文档说明可以用 `/plan-canvas`（或 `plan-canvas` skill）把计划工件在浏览器中打开，用户直接在页面上标注计划内容并点击 **Approve plan** 或 **Request changes**，该裁决即作为确认信号返回给 agent。

从源码看，Plan Canvas 是一条独立的 CLI 回路：[commands/plan-canvas.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/commands/plan-canvas.md?utm_source=gitcode_repo_files) 描述了它的工作流——先 `ecc-plan-canvas open <artifact>` 打开浏览器，再 `ecc-plan-canvas await <artifact>` 阻塞等待反馈，`approve` 裁决等同于 `/plan` 门控的计划确认。其实现位于 [scripts/plan-canvas.js](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/scripts/plan-canvas.js?utm_source=gitcode_repo_files) 与 [scripts/lib/plan-canvas/](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/scripts/lib/plan-canvas?utm_source=gitcode_repo_files)（含 server、sessions、markdown 解析等模块），并由 [skills/plan-canvas/SKILL.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/skills/plan-canvas/SKILL.md?utm_source=gitcode_repo_files) 定义完整规则；配套的会话与挂起反馈处理还有对应测试 [tests/hooks/plan-canvas-sessions-hook.test.js](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/tests/hooks/plan-canvas-sessions-hook.test.js?utm_source=gitcode_repo_files) 和 [tests/hooks/plan-canvas-pending-hook.test.js](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/tests/hooks/plan-canvas-pending-hook.test.js?utm_source=gitcode_repo_files)。值得注意的是 `stop:plan-canvas-pending` hook 会阻止 agent 在还有未送达反馈时结束回合——这保证了"人反馈了、agent 却没听见"这类静默失效被兜住。

## 使用示例

原文档给出了一个完整的对话式示例（自由文本输入）：

```
用户: /plan Necesito añadir notificaciones en tiempo real cuando los mercados se resuelven

助手:
# Plan de Implementación: Notificaciones de Resolución de Mercados en Tiempo Real

## Reformulación de Requisitos
- Enviar notificaciones a usuarios cuando los mercados que observan se resuelven
- Soporte para múltiples canales (en-app, email, webhook)
- Asegurar entrega confiable de notificaciones

## Fases de Implementación

### Fase 1: Schema de Base de Datos
- Añadir tabla de notificaciones con columnas: id, user_id, market_id, type, status, created_at

### Fase 2: Servicio de Notificaciones
- Crear servicio en lib/notifications.ts
- Implementar cola de notificaciones con BullMQ/Redis

## Riesgos
- ALTO: Entregabilidad de email (SPF/DKIM requerido)
- MEDIO: Rendimiento con 1000+ usuarios por mercado

## Complejidad Estimada: MEDIA

**ESPERANDO CONFIRMACIÓN**: ¿Proceder con este plan? (sí/no/modificar)
```

英文版示例（[commands/plan.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/commands/plan.md?utm_source=gitcode_repo_files)）在此基础上更完整，包含四个实现阶段（数据库 Schema → 通知服务 → 集成点 → 前端组件）、依赖清单（Redis、邮件服务、实时订阅）、四级风险标注（HIGH/MEDIUM/LOW）以及按前后端拆分的工作量估算（总计 9–13 小时），最后以 `**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)` 收尾。

## 与下游命令的集成

`/plan` 是流水线的中段，文档明确了规划完成后的衔接路径：

- 使用 **tdd-workflow skill** 进行测试驱动的实现；
- 出现构建错误时使用 `/build-fix`；
- 使用 `/code-review` 审查已完成的实现；
- 使用 `/pr` 或 `/prp-pr` 打开 pull request。

其中 tdd-workflow 与 `/plan` 的交接在 [skills/tdd-workflow/SKILL.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/skills/tdd-workflow/SKILL.md?utm_source=gitcode_repo_files) 中有专门章节：它会显式地把 `*.plan.md` 作为**不受信任的规划输入（untrusted planning input）**对待——读取计划文本，但不直接执行其中嵌入的命令；先对计划中的验证命令做净化、白名单匹配与用户批准，再将其转化为 RED/GREEN 证据链。这是一条安全边界：计划文件里写"ignore previous rules"之类的文字只会被记录为计划内容，不会被当作指令执行。

再看整条流水线的定位。[docs/PLAN-PRD-PATTERN.md](https://gitcode.com/GitHub_Trending/ev/ECC/blob/22e8cf01d0b54719b3a49002fab2ccbda4ff5b9e/docs/PLAN-PRD-PATTERN.md?utm_source=gitcode_repo_files) 用一张图概括了 ECC 的"markdown 暂存文件"规划模式：

```
/plan-prd "<idea>"  → .claude/prds/X.prd.md      （需求阶段）
/plan <prd-path>    → .claude/plans/X.plan.md    （设计阶段）
tdd-workflow skill  → code + tests               （实现阶段）
/pr                 → GitHub PR                  （交付阶段）