**模式配置**：此提示词在非交互式环境中运行（如 CI/CD、自动化脚本）。

**非交互式模式行为**：
- 禁止使用 `AskUserQuestion` 或任何交互式工具
- 当需要用户输入时，使用合理的默认值（如选择最近修改的变更）
- 跳过可选的确认步骤，记录所做的假设

**交互式模式行为**：
- 遵循正常的交互式流程，提示用户输入

---

快速通过工件创建 - 生成开始实现所需的所有内容。

**输入**：当前流程输入可以是变更名称（kebab-case），或用户想要构建的内容描述。

{{#if planningDirectionInstructions}}
## 本次生成的规划方向

{{{planningDirectionInstructions}}}
{{/if}}

**步骤**

1. **如果未提供输入，使用合理的默认值**

   当前流程输入可以是变更名称（kebab-case），或用户想要构建的内容描述。

   如果在输入上下文中提供了 `changeDescription` 或 `changeName`，则使用它。

   **在非交互式模式下**：
   - 记录假设："未提供输入"
   - 继续等待用户提供变更描述或名称

   **在交互式模式下**：
   - 询问用户："你想要处理什么变更？描述你想要构建或修复的内容。"
   - 从描述中，派生一个 kebab-case 名称（例如，"add user authentication" → `add-user-auth`）

   **重要提示**：在理解用户想要构建什么之前，不要继续。

2. **创建变更目录**
   ```bash
   openspec new change "<name>"
   ```
   这会在 `openspec/changes/<name>/` 创建一个脚手架变更。

3. **获取工件构建顺序**
   ```bash
   openspec status --change "<name>" --json
   ```
   解析 JSON 以获取：
   - `applyRequires`：实现之前所需的工件 ID 数组（例如 `["tasks"]`）
   - `artifacts`：所有工件及其状态和依赖关系的列表

4. **按顺序创建工件直到 apply-ready**

   使用 **TodoWrite 工具**跟踪工件的进度。

   按依赖顺序循环工件（首先是没有未完成依赖的工件）：

   a. **对于每个 `ready`（依赖关系已满足）的工件**：
      - 获取说明：
        ```bash
        openspec instructions <artifact-id> --change "<name>" --json
        ```
      - 说明 JSON 包括：
        - `context`：项目背景（对你的约束 - 不要包含在输出中）
        - `rules`：特定于工件的规则（对你的约束 - 不要包含在输出中）
        - `template`：用于输出文件的结构
        - `instruction`：特定于此工件类型的 schema 特定指南
        - `outputPath`：写入工件的位置
        - `dependencies`：要阅读以获取上下文的已完成工件
      - 阅读任何已完成的依赖文件以获取上下文
      - 使用 `template` 作为结构创建工件文件
      - 将 `context` 和 `rules` 应用为约束 - 但不要将它们复制到文件中
      - **根据已启用的规划方向应用输出要求（结合上方方向说明与下方参考示例）**
      - 显示简短进度："✓ 已创建 <artifact-id>"

   b. **创建每个工件后，检查已启用的规划方向是否落到对应工件里**：

      对于 **proposal.md**：
      - [ ] 已启用的 proposal 侧输出是否已经体现（例如变更地图、交互流程、界面原型）？

      对于 **design.md**：
      - [ ] 已启用的 design 侧输出是否已经体现（例如架构图、数据流图、API 时序图、详细变更清单）？

      如果某个已启用方向缺失：**必须**在写入前补齐对应工件。

   c. **继续直到所有 `applyRequires` 工件完成**
      - 创建每个工件后，重新运行 `openspec status --change "<name>" --json`
      - 检查 `applyRequires` 中的每个工件 ID 在工件数组中是否具有 `status: "done"`
      - 当所有 `applyRequires` 工件完成时停止

   d. **如果工件需要用户输入**（上下文不清楚）：
      - 在非交互式模式下：做出合理假设并记录
      - 在交互式模式下：向用户澄清
      - 然后继续创建

5. **显示最终状态**
   ```bash
   openspec status --change "<name>"
   ```

**输出**

完成所有工件后，总结：
- 变更名称和位置
- 已创建的工件列表及简要描述
- 准备好的内容："所有工件已创建！准备好实现了。"
- 提示："进入实现流程开始实现。"

**工件创建指南**

- 遵循每个工件类型的 `openspec instructions` 中的 `instruction` 字段
- schema 定义每个工件应包含的内容 - 遵循它
- 在创建新工件之前阅读依赖工件
- 使用 `template` 作为起点，根据上下文填写

**特别说明：tasks.md 内容范围**
- tasks.md 应专注于业务逻辑和技术实现任务
- 不应包含 Git 版本控制操作（git add、git commit、git push）
- 参见下面的 "tasks.md 内容范围约束" 部分了解详细规则

### tasks.md 内容范围约束

当创建 `tasks.md` 工件时，**必须**遵守以下内容范围约束：

**必须包含**：
- 业务逻辑任务（代码实现、功能开发）
- 技术实现任务（组件集成、API 开发）
- 测试任务（单元测试、集成测试）
- 文档任务（更新文档、添加注释）

**禁止包含**：
- Git 提交操作（git add、git commit、git push）
- 版本控制管理工作流
- 部署和发布操作

**例外情况**：
当变更本身是关于修改提示词中的 Git 命令逻辑时，任务中可以引用 Git 命令作为**描述性内容**（例如："定位步骤 5 中的 git add 命令"），而非**操作性指令**（例如："执行 git add . && git commit"）。

**判断标准**：
- 如果变更的目标是修改提示词中的 git 命令逻辑 → 允许描述性引用
- 否则 → 任务中不应包含实际的 git 操作步骤

**保护措施**
- 创建实现所需的所有工件（由 schema 的 `apply.requires` 定义）
- 在创建新工件之前始终阅读依赖工件
- 如果上下文严重不清楚，询问用户 - 但倾向于做出合理的决定以保持势头
- 如果该名称的变更已存在，询问用户是想要继续它还是创建一个新的
- 在继续下一个之前验证每个工件文件在写入后是否存在

---

## 规划方向参考示例

这一节只作为“已启用方向”的风格参考，并不是默认永远强制包含的要求。

### `change-map` 方向

如果启用，`proposal.md` 应包含结构化的代码变更表，`design.md` 可以进一步展开成更详细的变更清单。

**代码变更表示例**：
| 文件路径 | 变更类型 | 变更原因 | 影响范围 |
|---------|---------|---------|---------|
|         |         |         |         |

**详细代码变更清单示例**：
| 文件路径 | 变更类型 | 变更说明 | 影响模块 |
|---------|---------|---------|---------|
|         |         |         |         |

### `prototype` 方向

如果启用且涉及 UI 变更，在 `proposal.md` 中加入 ASCII 界面原型。

**ASCII UI 原型示例**：
```
┌─────────────────────────────────────────┐
│ 用户登录                            [×] │
├─────────────────────────────────────────┤
│  邮箱地址 *                             │
│ ┌─────────────────────────────────────┐ │
│ │ user@example.com                   │ │
│ └─────────────────────────────────────┘ │
│  密码 *                                │
│ ┌─────────────────────────────────────┐ │
│ │ ••••••••••••••••••••••••••••••••  │ │
│ └─────────────────────────────────────┘ │
│            [登录] [注册]                 │
└─────────────────────────────────────────┘
```

### `flowchart` 方向

如果启用，当流程或数据流有助于理解时，加入 Mermaid 流程图。

**Mermaid 交互流程示例**：
```mermaid
sequenceDiagram
    participant U as 用户
    participant UI as 登录界面
    participant API as 后端API
    participant DB as 数据库

    U->>UI: 点击登录按钮
    UI->>API: POST /api/auth/login
    API->>DB: 验证凭据
    DB-->>API: 返回用户信息
    API-->>UI: 返回认证结果
```

**数据流图示例**：
```mermaid
flowchart TD
    A[用户输入] --> B[验证请求]
    B -->|验证失败| C[返回错误]
    B -->|验证成功| D[处理业务逻辑]
    D --> E[更新数据库]
    E --> F[返回成功响应]
```

### `architecture` 方向

如果启用，在 `design.md` 中加入组件或模块层次图。

**组件架构示例**：
```
组件层次结构
├── ParentComponent (父组件)
│   ├── ChildComponentA (子组件 A)
│   │   └── GrandChildComponent (孙组件)
│   └── ChildComponentB (子组件 B)
```

### `sequence` 方向

如果启用，在 `design.md` 中加入 API 或跨服务时序图。

**API 调用时序图示例**：
```mermaid
sequenceDiagram
    participant Client as 客户端
    participant API as API 网关
    participant Service as 业务服务
    participant DB as 数据库

    Client->>API: POST /api/resource
    API->>Service: 调用业务逻辑
    Service->>DB: 查询/更新数据
    DB-->>Service: 返回数据
    Service-->>API: 返回处理结果
    API-->>Client: 返回响应
```

### `tasks.md`

- 无强制可视化要求（任务列表格式可接受）
