project-execution

适用场景

• 规划阶段完成后
• 准备开始实施任务
• 需要系统化执行并跟踪进度
• 希望基于检查点进行验证
• 执行存在依赖关系的任务列表
• 监控进度和速度

不适用场景

• 尚无实施计划（先使用 Skill(attune:project-planning)）
• 仍在规划或设计（先完成规划阶段，再开始执行）
• 单个独立任务（直接执行，无需框架开销）
• 探索性编码或原型设计（改用针对性的开发方式）

集成

与 superpowers 配合：

• 使用 Skill(superpowers:executing-plans) 进行系统化执行
• 使用 Skill(superpowers:systematic-debugging) 解决问题
• 使用 Skill(superpowers:verification-before-completion) 进行验证
• 使用 Skill(superpowers:test-driven-development) 采用 TDD 工作流

与 imbue 配合：

• 在递进关卡使用 Skill(imbue:graduated-implementation)，确保每次增量的雄心都建立在对上一次增量已有充分理解的基础上，而非仅因完成上一次增量就贸然提升

不使用 superpowers 时：

• 独立的执行框架
• 内置检查点验证
• 进度跟踪模式

执行框架

执行前阶段

操作：

1. 加载实施计划
2. 验证项目已初始化
3. 检查依赖项是否已安装
4. 查看任务依赖关系图
5. 确定起始任务（无依赖项）

验证：

• ✅ 计划文件存在且有效
• ✅ 项目结构已初始化
• ✅ Git 仓库已配置
• ✅ 开发环境已就绪

任务执行循环

按依赖顺序执行每项任务：

1. PRE-TASK
   - Verify dependencies complete
   - Review acceptance criteria
   - Create feature branch (optional)
   - Set up task context

2. IMPLEMENT (TDD Cycle)
   - Write failing test (RED)
   - Implement minimal code (GREEN)
   - Refactor for quality (REFACTOR)
   - Repeat until all criteria met

3. VALIDATE
   - All tests passing?
   - All acceptance criteria met?
   - Code quality checks pass?
   - Documentation updated?

4. RAMP GATE (before the next, more ambitious task)
   - Invoke Skill(imbue:graduated-implementation)
   - Demonstrate understanding of THIS increment, sized to stakes:
     low-stakes on the evidence gate (green tests plus a recorded
     tradeoff), high-stakes on the human explaining the diff unaided
   - On a clean demonstration, record it in the ramp ledger and
     mark the rung widened; below the band, hold and split the next
     task smaller instead of ramping

5. CHECKPOINT
   - Mark task complete IMMEDIATELY (do NOT batch)
   - Update execution state
   - Report progress
   - Identify blockers

任务完成规范：每完成一项任务后，立即调用 TaskUpdate(taskId: "X", status: "completed")。切勿将完成状态更新推迟到会话结束时。

**验证：**运行 pytest -v，确认测试通过。

执行后阶段

操作：

1. 确认所有任务均已完成
2. 运行完整测试套件
3. 检查代码质量指标
4. 生成完成报告
5. 为部署/发布做准备
6. 记录经验教训（见下文）

记录经验教训（决策日志）

实施过程中会显现真实的经验教训：需要返工的方法、耗费一天时间的阻碍，以及规划阶段的假设未能成立等。现在就将这些内容如实记录到 docs/lessons-learned.md，不要让它们随着任务“完成”而消失。每条实质性经验都应单独起草并确认：

• 如果已安装 leyline，调用 Skill(leyline:decision-journal) 并按照其说明追加一条经验记录，包含 what_happened、what_didnt_work、root_cause 和具体的 action。将 phase 设为 execute。先展示草稿；确认后再追加（状态初始为 open）。
• 备用方式（未安装 leyline）：使用文件内的 ENTRY TEMPLATE，手动追加到 docs/lessons-learned.md；分配下一个 LL-NNN id。

每当执行过程中发生返工、尝试失败，或遇到耗尽两次挑战/3 次尝试上限的阻碍时，都要记录。顺利完成且没有意外时，无需记录。

终止阶段提示

这是 attune 工作流的最后阶段。执行完成后不会自动继续，工作流将在此终止。与头脑风暴、规格制定和规划阶段不同，执行阶段结束后不会自动调用后续阶段。

任务执行模式

委派检查（每项任务开始前）

在实现任务之前，先委派任务。 默认启用 Skill(conjure:delegation-core)，因此要做的决定是是否符合“保留本地处理”条款，而不是要不要委派。

如果任务涉及设计或权衡、其上下文包含机密、需要逐轮迭代，或其输出无法事后验证，则在本地处理。 否则交给委派器，并通过下方相同的 TDD 工作流验证返回结果。 测试就是验证方式：委派实现未通过 RED 测试时，和本地实现一样会被拒绝。

如果结果包含 fallback_reason，则没有外部模型运行。 报告尝试过哪些提供商，然后在此处实现任务。 调用链耗尽不代表任务受阻，也不应记录在 docs/lessons-learned.md 中。

TDD 工作流

RED 阶段：

# Write test that fails
def test_user_authentication():
    user = authenticate("[email protected]", "password")
    assert user.is_authenticated
# Run test → FAILS (feature not implemented)

**验证：**运行 pytest -v，确认测试通过。

GREEN 阶段：

# Implement minimal code to pass
def authenticate(email, password):
    # Simplest implementation
    user = User.find_by_email(email)
    if user and user.check_password(password):
        user.is_authenticated = True
        return user
    return None
# Run test → PASSES

**验证：**运行 pytest -v，确认测试通过。

REFACTOR 阶段：

# Improve code quality
def authenticate(email: str, password: str) -> Optional[User]:
    """Authenticate user with email and password."""
    user = User.find_by_email(email)
    if user is None:
        return None

    if not user.check_password(password):
        return None

    user.mark_authenticated()
    return user
# Run test → STILL PASSES

**验证：**运行 pytest -v，确认测试通过。

检查点验证

质量门禁：

- [ ] All acceptance criteria met
- [ ] All tests passing (unit + integration)
- [ ] Code linted (no warnings)
- [ ] Type checking passes (if applicable)
- [ ] Documentation updated
- [ ] No regression in other components

**验证：**运行 pytest -v，确认测试通过。

自动化检查：

# Run quality gates
make lint          # Linting passes
make typecheck     # Type checking passes
make test          # All tests pass
uv run pytest --cov  # Coverage threshold met

**验证：**运行 pytest -v，确认测试通过。

进度跟踪

执行状态

保存到 .attune/execution-state.json：

{
  "plan_file": "docs/implementation-plan.md",
  "started_at": "2026-01-02T10:00:00Z",
  "last_checkpoint": "2026-01-02T14:30:22Z",
  "current_sprint": "Sprint 1",
  "current_phase": "Phase 1",
  "tasks": {
    "TASK-001": {
      "status": "complete",
      "started_at": "2026-01-02T10:05:00Z",
      "completed_at": "2026-01-02T10:50:00Z",
      "duration_minutes": 45,
      "acceptance_criteria_met": true,
      "tests_passing": true
    },
    "TASK-002": {
      "status": "in_progress",
      "started_at": "2026-01-02T14:00:00Z",
      "progress_percent": 60,
      "blocker": null
    }
  },
  "metrics": {
    "tasks_complete": 15,
    "tasks_total": 40,
    "completion_percent": 37.5,
    "velocity_tasks_per_day": 3.2,
    "estimated_completion_date": "2026-02-15"
  },
  "blockers": []
}

**验证：**运行 pytest -v，确认测试通过。

进度报告

每日站会：

# Daily Standup - [Date]

## Yesterday
- ✅ [Task] ([duration])
- ✅ [Task] ([duration])

## Today
- 🔄 [Task] ([progress]%)
- 📋 [Task] (planned)

## Blockers
- [Blocker] or None

## Metrics
- Sprint progress: [X/Y] tasks ([%]%)
- [Status message]

**验证：**运行带有 --help 标志的命令，确认其可用。

冲刺报告：

# Sprint [N] Progress Report

**Dates**: [Start] - [End]
**Goal**: [Sprint objective]

## Completed ([X] tasks)
- [Task list]

## In Progress ([Y] tasks)
- [Task] ([progress]%)

## Blocked ([Z] tasks)
- [Task]: [Blocker description]

## Burndown
- Day 1: [N] tasks remaining
- Day 5: [M] tasks remaining ([status])
- Estimated completion: [Date] ([delta])

## Risks
- [Risk] or None identified

**验证：**运行带有 --help 标志的命令，确认其可用。

阻塞项管理

阻塞项检测

常见阻塞项：

• 无法快速修复的失败测试
• 缺少依赖项或 API
• 需要研究的技术未知因素
• 资源不可用
• 范围不明确

系统化调试

遇到阻塞时，应用调试框架：

1. 复现：创建最小复现案例
2. 假设：列出可能的原因
3. 测试：逐一验证假设
4. 解决：实现修复或变通方案
5. 记录：记录解决方案以备将来使用

升级处理

需要升级处理的情况：

• 阻塞持续超过 2 小时
• 需要更改架构
• 影响关键路径
• 需要利益相关者作出决定

升级格式：

## Blocker: [TASK-XXX] - [Issue]

**Symptom**: [What's happening]

**Impact**: [Which tasks/timeline affected]

**Attempted Solutions**:
1. [Solution 1] - [Result]
2. [Solution 2] - [Result]

**Recommendation**: [Proposed path forward]

**Decision Needed**: [What needs to be decided]

**验证：**运行带有 --help 标志的命令，确认其可用。

质量保证

完成定义

满足以下条件时，任务即告完成：

• ✅ 满足所有验收标准
• ✅ 编写并通过所有测试
• ✅ 代码经过审查（自审或同行审查）
• ✅ Lint 检查通过且无警告
• ✅ 类型检查通过（如适用）
• ✅ 文档已更新
• ✅ 没有已知回归问题
• ✅ 已部署到预发布环境（如适用）

测试策略

测试金字塔：

**Verification:** Run `pytest -v` to verify tests pass.
     /\
    /E2E\      Few, slow, expensive
   /------\
  /  INT  \    Some, moderate speed
 /----------\
/   UNIT    \  Many, fast, cheap

**验证：**运行带有 --help 标志的命令，确认其可用。

每项任务：

• 单元测试：测试单个函数/类
• 集成测试：测试组件之间的交互
• E2E 测试：测试完整的用户流程（适用于面向用户的功能）

速度跟踪

燃尽指标

每日跟踪：

• 剩余任务数
• 剩余故事点数
• 冲刺剩余天数
• 速度（每天完成的任务数或点数）

公式：

**Verification:** Run `pytest -v` to verify tests pass.
Velocity = Tasks completed / Days elapsed
Estimated completion = Tasks remaining / Velocity
On track? = Estimated completion <= Sprint end date

**验证：**运行带有 --help 标志的命令，确认其可用。

速度调整

进度提前时：

• 提前开始扩展任务
• 减少技术债务
• 提高测试覆盖率
• 完善文档

进度落后时：

• 找出原因（阻塞项、估算不足）
• 缩减范围（移除低优先级任务）
• 提高专注度（减少干扰）
• 请求帮助或延长时间

退出标准

• 所有计划任务均已标记为完成，且完整测试套件通过。
• 已生成完成报告。
• 任何返工、失败的方法或重试耗尽导致的阻碍，都已作为 open 条目记录到 docs/lessons-learned.md 中（顺利执行时无需记录）。
• 每项任务要么已委派，要么依据明确命名的 Keep Local 条款予以保留。
• 委派产出通过了与本地实现相同的测试。
• 不会自动调用后续阶段（这是终止阶段）。

相关技能

• Skill(superpowers:executing-plans) - 执行框架（如可用）
• Skill(superpowers:systematic-debugging) - 调试（如可用）
• Skill(superpowers:test-driven-development) - TDD（如可用）
• Skill(superpowers:verification-before-completion) - 验证（如可用）
• Skill(conjure:delegation-core) - 默认启用的任务执行委派
• Skill(attune:mission-orchestrator) - 完整生命周期编排

相关 Agent

• Agent(attune:project-implementer) - 任务执行 Agent

相关命令

• /attune:execute - 调用此技能
• /attune:execute --task [ID] - 执行指定任务
• /attune:execute --resume - 从检查点恢复

任务报告

任务完成时，使用 references/mission-report.md 中的模板生成任务报告。报告应记录：

• 任务标识：简述、规格说明和计划的链接
• 持续时间：开始时间、结束时间和总耗时
• 结果：成功 | 部分完成 | 失败
• 交付产物：创建、修改或删除的文件
• 决策：关键选择及其理由
• 验证证据：测试、评审和演示
• 后续事项：建议的后续步骤

完整模板以及成功、部分完成和失败任务的报告示例，请参阅 references/mission-report.md。

示例

完整示例请参阅 /attune:execute 命令文档。