project-continue

/project:continue

このスキルを使用するタイミング

次の場合はこのスキルを使用します…	次の場合は project-discovery を使用します…
PRD と機能トラッカーの状態がある既知のプロジェクトの作業を再開する場合	ツールや構成を把握する必要がある、なじみのないコードベースに取り組む場合
トラッカーの状態を確認してから、このリポジトリで次のタスクを実装する場合	編集を行わず、未完了のタスク、PR、ジャーナルの ToDo を読み取り専用で確認するには、代わりに session-plugin:session-spinup を使用します
休止後に機能トラッカーから次のタスクを選ぶ場合	次のステップが失敗するテストの反復作業である場合は、代わりに project-test-loop を使用します
ブループリントの状態が確立されているプロジェクトで「次は何をしますか」と尋ねる場合	まだプロジェクト構成がない場合は、代わりに project-init を使用します
TDD セッションを再開して、自分で実装を始める場合	コーディングを続けるのではなく、ブループリントに次の論理的なアクション（derive/sync/work-order）を選んで実行してほしい場合は、代わりに /blueprint:execute を使用します

現在の状態を分析し、作業を再開してプロジェクト開発を続けます。

注: コマンドを自動検出できるように、プロジェクト固有のテスト／ビルドコマンドを CLAUDE.md または .claude/rules/ で設定してください。

手順:

1. 現在の状態を確認する:

   # Check git status
   git status
   
   # Check recent commits
   git log -5 --oneline
   
   # Check current branch
   git branch --show-current
   

2. プロジェクトのコンテキストを読み取る:

   • PRD: docs/prds/ 内のすべてのファイルを読み取ります
     • プロジェクトの目標と要件を把握します
     • 機能とフェーズを特定します
   • 機能トラッカー: docs/blueprint/feature-tracker.json の tasks セクションを読み取ります
     • 現在のフェーズと進捗
     • 完了済み、進行中、保留中のタスク
   • 作業指示書: docs/blueprint/work-orders/ を確認します
     • 最近の作業指示書（完了した作業を確認）
     • 保留中の作業指示書（予定されている作業を確認）

3. 状態を分析し、次のタスクを決定する:

   未コミットの変更がある場合:

   • 未コミットのファイルを確認します
   • 作業中の作業を続けるべきか判断します
   • 現在の作業を続けるか、最初から始めるかをユーザーに尋ねます

   クリーンな状態の場合:

   • 機能トラッカーのタスクと PRD の要件を比較します
   • 次に取り組むべき論理的なタスクを特定します:
     • feature-tracker.json の次の保留中タスク
     • PRD の次の要件
     • 次に実行する作業指示書
   • 依存関係を考慮します（まずブロックされていないタスクから始めます）

4. 開始前に状況を報告する:

   📊 Project Status:
   
   Current Branch: [branch]
   Uncommitted Changes: [yes/no - list files if yes]
   
   Recent Work:
   - [Last 3 commits]
   
   PRDs Found:
   - [List PRD files with brief summary]
   
   Work Overview: Phase [N] - [Phase name]
   ✅ Completed: [N] tasks
   ⏳ In Progress: [Current task if any]
   ⏹️ Pending: [N] tasks
   
   Next Task: [Identified next task]
   Approach: [Brief plan]
   

5. TDD に従って作業を開始する:

   • プロジェクト固有のスキルを自動的に有効にします:
     • アーキテクチャパターン
     • テスト戦略
     • 実装ガイド
     • 品質基準
   • RED → GREEN → REFACTOR のワークフローに従います:
     • まず失敗するテストを書く
     • テストを通すための最小限の実装を行う
     • テストを成功状態に保ちながらリファクタリングする
   • 段階的にコミットします:
     • Conventional Commits を使用します
     • RED → GREEN → REFACTOR の各サイクル後にコミットします
     • コミットメッセージで PRD または issue を参照します

6. 作業を進めながら機能トラッカーを更新する:

   • タスクを進行中にします
   • タスクを完了にします
   • 次のステップを更新します

重要:

• 必ずテストから始めます（TDD の要件）
• プロジェクトのスキルを適用します（アーキテクチャ、テスト、実装、品質）
• 段階的にコミットします（サイクルが成功するたびに）
• 機能トラッカーを更新します（プロジェクトの状態を最新に保ちます）

よくあるシナリオへの対応:

シナリオ: 新機能を開始する:

1. /blueprint:work-order で最初に作業指示書を作成します
2. その後、このコマンドで作業を続けます

シナリオ: 依存関係によってブロックされている:

1. ブロッカーを報告します
2. 別のタスクに取り組むことを提案します
3. または、依存関係を先に実装することを提案します

シナリオ: テストが失敗している:

1. 失敗を分析します
2. 失敗しているテストを修正します（必ず RED ステップを先に完了します）
3. テストが通ったら続行します

シナリオ: 次に何をすべきか不明:

1. 要件を確認するために PRD を読み直します
2. ユーザーに説明を求めます
3. 明確にするために作業指示書を作成することを提案します

エージェントチーム（任意）

複数の作業を並行して進める必要がある大規模なコードベースでは、チームメイトを起動して並行作業を進めます。

チームメイト	担当分野	メリット
調査担当のチームメイト	コードベースの状態、PRD、作業指示を調査	コンテキストを並行して収集
実装担当のチームメイト	機能トラッカーの次のタスクに着手	すぐに実装を開始

調査担当のチームメイトがプロジェクトの状態を収集する一方で、実装担当のチームメイトは最も明確な次のタスクに着手します。これは任意です。ほとんどのプロジェクトでは、単一セッションでの継続で問題ありません。