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

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

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

---

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

**输入**：`/opsx:ff` 之后的参数是变更名称（kebab-case），或用户想要构建的内容描述。

**步骤**

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

   `/opsx:ff` 之后的参数是变更名称（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**：
      - [ ] 如果涉及 UI 变更：是否包含 ASCII 界面原型？
      - [ ] 是否包含 Mermaid 用户交互流程图？
      - [ ] 是否包含代码变更表？

      对于 **design.md**：
      - [ ] 是否包含组件架构图（ASCII 层次结构）？
      - [ ] 是否包含数据流图（Mermaid 流程图）？
      - [ ] 是否包含 API 调用时序图（Mermaid 时序图）？
      - [ ] 是否包含详细代码变更清单？

      如果任何检查点未通过：**必须**在写入工件之前补充缺失的可视化内容。

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

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

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

**输出**

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

**工件创建指南**

- 遵循每个工件类型的 `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` 定义）
- 在创建新工件之前始终阅读依赖工件
- 如果上下文严重不清楚，询问用户 - 但倾向于做出合理的决定以保持势头
- 如果该名称的变更已存在，询问用户是想要继续它还是创建一个新的
- 在继续下一个之前验证每个工件文件在写入后是否存在

---

## 工件可视化要求

### proposal.md 工件（简化版本）

**必须包含**：

- **高层级 UI 原型**（如果涉及 UI 变更）：
  - 使用 ASCII 艺术绘制界面布局
  - 显示主要 UI 元素（按钮、输入框、卡片等）
  - 标注交互状态（正常、悬停、禁用、错误）

- **用户交互流程**：
  - 使用 Mermaid 时序图描述用户操作流程
  - 包含参与者：用户、前端、后端、数据库

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

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

**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: 返回认证结果
```

### design.md 工件（详细版本）

**必须包含所有 proposal.md 内容，另外加上**：

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

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

- **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: 返回响应
  ```

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

### 其他工件类型

- **specs/**/*.md**：
  - 使用 Mermaid 图描述能力模型
  - 使用表格列出功能需求

- **tasks.md**：
  - 无强制可视化要求（任务列表格式可接受）
