project-execution

使用するタイミング

• 計画フェーズの完了後
• タスクの実装を開始する準備ができたとき
• 進捗を追跡しながら、体系的に実行する必要があるとき
• チェックポイントに基づいて検証したいとき
• 依存関係のあるタスクリストを実行するとき
• 進捗や作業速度を監視するとき

使用しないタイミング

• 実装計画がない場合（最初に Skill(attune:project-planning) を使用してください）
• 計画中または設計中の場合（実行前に計画フェーズを完了してください）
• 単独で完結するタスクの場合（フレームワークによるオーバーヘッドをかけずに、直接実行してください）
• 探索的なコーディングやプロトタイピングの場合（目的を絞った開発を行ってください）

統合

superpowers との連携：

• 体系的な実行には Skill(superpowers:executing-plans) を使用します
• 問題の解決には Skill(superpowers:systematic-debugging) を使用します
• 検証には Skill(superpowers:verification-before-completion) を使用します
• TDD ワークフローには Skill(superpowers:test-driven-development) を使用します

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. 学んだ教訓を記録する（以下を参照）

学んだ教訓を記録する（意思決定ジャーナル）

実装を進めると、正直な教訓が見えてきます。手戻りが必要になったアプローチ、1日を費やすことになった障害、計画時の前提が成り立たなかったことなどです。こうした教訓を「完了」の中に埋もれさせず、責任追及を避ける形で、今すぐ docs/lessons-learned.md に記録してください。重要な教訓ごとにエントリを1件作成し、内容を確認します。

• 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) はデフォルトで有効なため、判断するのは委任するかどうかではなく、Keep Local 条項に該当するかどうかです。

設計やトレードオフの検討である場合、コンテキストに秘密情報が含まれる場合、逐次的な反復が必要な場合、または出力を後から検証できない場合は、タスクをローカルで進めてください。 それ以外の場合は委任先に依頼し、以下の同じ 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 フラグを指定してコマンドを実行し、利用できることを確認します。

品質保証

完了の定義

タスクの完了条件：

• ✅ すべての受け入れ基準を満たしている
• ✅ すべてのテストが作成され、パスしている
• ✅ コードレビューが完了している（セルフレビューまたはピアレビュー）
• ✅ 警告なしでリンティングがパスしている
• ✅ 型チェックがパスしている（該当する場合）
• ✅ ドキュメントが更新されている
• ✅ 既知のリグレッションがない
• ✅ ステージング環境にデプロイされている（該当する場合）

テスト戦略

テストピラミッド：

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

検証： --help フラグを指定してコマンドを実行し、利用できることを確認します。

タスクごと：

• 単体テスト：個々の関数／クラスをテストします
• 結合テスト：コンポーネント間の相互作用をテストします
• E2E テスト：ユーザー向け機能について、ユーザーの一連の操作をテストします

ベロシティの追跡

バーンダウン指標

毎日追跡する項目：

• 残りのタスク数
• 残りのストーリーポイント
• スプリントの残り日数
• ベロシティ（1 日あたりのタスク数またはポイント数）

計算式：

**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 フラグを指定してコマンドを実行し、利用できることを確認します。

ベロシティの調整

予定より進んでいる場合：

• ストレッチタスクを追加します
• 技術的負債の削減に取り組みます
• テストカバレッジを向上させます
• ドキュメントを充実させます

予定より遅れている場合：

• 原因を特定します（ブロッカー、見積もりの甘さ）
• スコープを縮小します（優先度の低いタスクを外します）
• 集中力を高めます（気を散らすものを減らします）
• 支援を依頼するか、スケジュールを延長します

完了条件

• 計画されたすべてのタスクが完了としてマークされ、テストスイート全体がパスしていること。
• 完了レポートが生成されていること。
• 手戻り、失敗したアプローチ、または再試行回数の上限に達して作業を妨げている要因があれば、docs/lessons-learned.md に open エントリーとして記録されていること（問題なく完了した場合は不要です）。
• すべてのタスクが、委任されているか、名前が指定された 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(attune:project-implementer) - タスク実行エージェント

関連コマンド

• /attune:execute - このスキルを呼び出します
• /attune:execute --task [ID] - 指定したタスクを実行します
• /attune:execute --resume - チェックポイントから再開します

ミッションレポート

ミッション完了時に、references/mission-report.md のテンプレートを使用してミッションレポートを作成してください。レポートには、以下の内容を記録します。

• ミッションの特定情報：ブリーフ、仕様、計画へのリンク
• 所要時間：開始時刻、終了時刻、合計時間
• 結果：成功 | 部分的 | 失敗
• 納品物：作成、変更、削除したファイル
• 決定事項：主な選択とその理由
• 検証の根拠：テスト、レビュー、デモ
• フォローアップ：推奨される次のステップ

完全なテンプレートと、成功・部分的・失敗したミッションのレポート例については、references/mission-report.md を参照してください。

例

例の全文については、/attune:execute コマンドのドキュメントを参照してください。