Back to Details

open-spec-apply

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Implement tasks from a working change.
Input: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
Steps
  1. Select the change
    If a name is provided, use it. Otherwise:
    • Infer from conversation context if the user mentioned a change
    • Auto-select if only one directory exists under 
      specs/changes/
    • If ambiguous, inspect available directories under 
      specs/changes/
      and ask the user to choose
    Always announce: "Using change: <name>" and how to override (e.g., 
    open-spec-apply <other>
    ).
  2. Read the change artifacts
    Read the files that exist under 
    specs/changes/<name>/
    :
    • proposal.md
    • design.md
    • tasks.md
    If 
    tasks.md
    is missing, pause and ask whether to create it first with the 
    open-spec-propose
    skill.
  3. Show current progress
    Display:
    • Change being used
    • Progress: "N/M tasks complete"
    • Remaining tasks overview
  4. Implement tasks (loop until done or blocked)
    For each pending task:
    • Show which task is being worked on
    • Make the code changes required
    • Keep changes minimal and focused
    • Mark task complete in the tasks file: 
      - [ ]
      → 
      - [x]
    • Continue to next task
    Pause if:
    • Task is unclear → ask for clarification
    • Implementation reveals a design issue → suggest updating artifacts
    • Error or blocker encountered → report and wait for guidance
    • User interrupts
  5. On completion or pause, show status
    Display:
    • Tasks completed this session
    • Overall progress: "N/M tasks complete"
    • If all done: suggest using the 
      open-spec-complete
      skill to sync 
      specs/features/
    • If paused: explain why and wait for guidance
Output During Implementation
undefined
根据一个进行中的变更来执行任务。
输入：可选择性地指定变更名称。如果未指定，检查是否可以从对话上下文推断出来。如果模糊或有歧义，必须提示用户选择可用的变更。
步骤
  1. 选择变更
    如果提供了名称，直接使用。否则：
    • 如果用户在对话中提到过变更，从上下文推断
    • 如果
      specs/changes/
      下只有一个目录，自动选择
    • 如果有歧义，查看
      specs/changes/
      下的可用目录并让用户选择
    必须告知："正在使用变更：<名称>"以及如何切换（例如：
    open-spec-apply <其他名称>
    ）。
  2. 读取变更工件
    读取
    specs/changes/<名称>/
    下的文件：
    • proposal.md
    • design.md
    • tasks.md
    如果缺少
    tasks.md
    ，暂停并询问是否先使用
    open-spec-propose
    skill创建它。
  3. 展示当前进度
    显示：
    • 当前使用的变更
    • 进度："已完成N/M个任务"
    • 剩余任务概览
  4. 执行任务（循环直至完成或受阻）
    针对每个待处理任务：
    • 显示正在处理的任务
    • 进行所需的代码变更
    • 保持变更最小且聚焦
    • 在任务文件中标记任务完成：
      - [ ]
      → 
      - [x]
    • 继续下一个任务
    暂停场景：
    • 任务不清晰 → 请求澄清
    • 实现过程中发现设计问题 → 建议更新工件
    • 遇到错误或阻塞 → 报告并等待指导
    • 用户中断
  5. 完成或暂停时，展示状态
    显示：
    • 本次会话完成的任务
    • 整体进度："已完成N/M个任务"
    • 如果全部完成：建议使用
      open-spec-complete
      skill同步
      specs/features/
    • 如果暂停：说明原因并等待指导
实现过程中的输出
undefined

Implementing: <change-name>

正在实现：<变更名称>

Working on task 3/7: <task description> [...implementation happening...] ✓ Task complete
Working on task 4/7: <task description> [...implementation happening...] ✓ Task complete

**Output On Completion**
正在处理任务3/7：<任务描述> [...正在实现...] ✓ 任务完成
正在处理任务4/7：<任务描述> [...正在实现...] ✓ 任务完成

**完成时的输出**

Implementation Complete

实现完成

Change: <change-name> Progress: 7/7 tasks complete ✓
变更：<变更名称> 进度：7/7任务完成 ✓

Completed This Session

本次会话完成的任务

  • Task 1
  • Task 2 ...
All tasks complete! Use the 
open-spec-complete
skill to sync 
specs/features/
and clean up workflow artifacts.

**Output On Pause (Issue Encountered)**
  • 任务1
  • 任务2 ...
所有任务已完成！请使用
open-spec-complete
skill同步
specs/features/
并清理工作流工件。

**暂停时的输出（遇到问题）**

Implementation Paused

实现暂停

Change: <change-name> Progress: 4/7 tasks complete
变更：<变更名称> 进度：4/7任务完成

Issue Encountered

遇到的问题

<description of the issue>
Options:
  1. <option 1>
  2. <option 2>
  3. Other approach
What would you like to do?

**Guardrails**
- Keep going through tasks until done or blocked
- Always read the available change artifacts before starting
- If task is ambiguous, pause and ask before implementing
- If implementation reveals issues, pause and suggest artifact updates
- Keep code changes minimal and scoped to each task
- Update task checkbox immediately after completing each task
- Pause on errors, blockers, or unclear requirements - don't guess
- Treat `specs/changes/` as working state only; completion still requires syncing `specs/features/`

**Fluid Workflow Integration**

This skill supports the "actions on a change" model:

- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
<问题描述>
选项：
  1. <选项1>
  2. <选项2>
  3. 其他方案
您想要如何处理？

**约束规则**
- 持续处理任务直至完成或受阻
- 开始前必须读取可用的变更工件
- 如果任务有歧义，暂停并询问后再实现
- 如果实现过程中发现问题，暂停并建议更新工件
- 保持代码变更最小且局限于每个任务
- 完成每个任务后立即更新任务复选框
- 遇到错误、阻塞或不明确的需求时暂停 - 不要猜测
- 将`specs/changes/`视为工作状态；完成后仍需同步`specs/features/`

**流畅的工作流集成**

该skill支持"变更操作"模型：

- **可随时调用**：在所有工件完成前（如果任务已存在）、部分实现后、与其他操作交替进行时均可调用
- **允许更新工件**：如果实现过程中发现设计问题，建议更新工件 - 不锁定阶段，工作流程流畅