zhongwei/gh-mh4gf-issync-claude-plugins-issync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:40:07 +08:00
commit fb4d2ff5f1
12 changed files with 2249 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

689
commands/review-poc.md Normal file
View File

@@ -0,0 +1,689 @@
---
description: POC実装の結果をレビューし、人間の意思決定のための材料を整理する
---
# /issync:review-poc: POCレビューワークフロー
あなたはユーザーの `.issync/docs/plan-*.md` ファイルのPOCレビューフェーズをサポートしています。このコマンドは以下の11ステップのワークフローを自動化します：
1. Stage設定（In Progress）
2. POC PR URLを受け取り、PR情報を取得
3. Discoveries & Insightsを参照
4. **Acceptance Criteriaの検証（達成/未達成を明確化）**
5. **Discoveries & Insightsへの追記**
6. **Open Questionsへの論点追加（強化）**
7. **Decision Log推奨案の記入（人間の最終決定を前提）**
8. Specification / 仕様の記入（オプショナル）
9. POC PRをクローズ
10. issync pushで同期（必要な場合）
11. Stage更新（To Review）
**重要**: このコマンドは**人間の意思決定のための材料を提供する**ことが目的です。最終的なアーキテクチャ決定は人間が行います。
## コンテキスト
このコマンドは「矛盾解消駆動開発」ワークフローの**architecture-decisionステート**で使用されます：
- POC実装が完了し、PRが作成されている状態から開始
- POCで得た技術的知見（実現可能性、複雑性、制約）を分析
- Acceptance Criteriaの達成状況を確認
- 未達成項目の理由を分析し、Open Questionsに論点を追加
- Decision Log推奨案を記入（最終決定は人間が行う）
- 人間がレビュー・承認後、手動でStatusを`implement`に変更
## 前提条件
実行前に必要なものは以下です：
- [ ] **現在のGitHub Issue Statusが `architecture-decision` であることを確認**（手動確認）
- [ ] POC実装が完了し、PRが作成されている
- [ ] `ISSYNC_GITHUB_TOKEN` 環境変数が設定されている
- [ ] 進捗ドキュメントファイルがローカルに存在する
**重要**: このコマンドは`architecture-decision`ステートで実行されることを前提としています。適切なタイミングで実行する責任はユーザーにあります。
## 実行ステップ
### ステップ1: Stage設定（AI作業開始）
`!env ISSYNC_GITHUB_PROJECTS_NUMBER`が設定されている場合のみ、`gh project item-edit`でStage→`In Progress`に設定。失敗時も作業継続（警告のみ）。
環境変数:
- `ISSYNC_GITHUB_PROJECTS_NUMBER`: プロジェクト番号（例: `1`）
- `ISSYNC_GITHUB_PROJECTS_OWNER_TYPE`: `user` または `org`（デフォルト: `user`）
**Stage 設定コマンド**:
```bash
issync projects set-stage "$ISSUE_URL" "In Progress"
```
---
### ステップ2: POC PR URLの受け取りとPR情報取得
#### 2.1 POC PR URLの受け取り
ユーザーにPOC PR URLを確認してください：
```
POC PR URLを教えてください（例: https://github.com/owner/repo/pull/123）
```
#### 2.2 PR情報の取得
POC PRから以下の情報を取得します：
```bash
# PR詳細を取得
gh pr view <PR URL> --json title,body,state,commits,comments
# PR diffを取得
gh pr diff <PR URL>
```
**収集する情報**:
- PR title
- PR description（body）
- State（open/closed）
- Commits（コミット一覧）
- Comments（レビューコメント、議論）
- Diff（変更内容）
**PRが既にクローズ済みの場合**:
- ⚠️ 警告を表示：「このPRは既にクローズされています。レビュー情報の記入のみを実行します。」
- ステップ8（PRクローズ）をスキップして続行
#### 2.3 PRに対応するissueの特定
1. **PR本文の解析**
- 本文中のissue言及を理解（"Resolves:", "Fixes #123", "Part of #456" など、自然言語として柔軟に解釈）
- 完全URL形式（`https://github.com/.../issues/番号`）を優先、`#番号`はPRと同一リポジトリと判断
2. **複数/未検出時の処理**
- 複数issue: ユーザーに選択させる
- 未検出: issue URLまたは番号の入力を促す
3. **使用**
- 進捗ドキュメント検索: `.issync/docs/plan-{issue番号}-*.md`
- GitHub Projects操作（Stage更新）
---
### ステップ3: Discoveries & Insightsの参照
進捗ドキュメントの`Discoveries & Insights`セクションを読み、POC実装中に発見された技術的制約・複雑性を確認：
```markdown
## Discoveries & Insights
**YYYY-MM-DD: [発見のタイトル]**
- **発見**: [発見した技術的事実]
- **学び**: [この発見が実装にどう影響するか]
```
これらの発見事項とPR情報を統合し、Acceptance Criteria検証の根拠とします。
---
### ステップ4: Acceptance Criteriaの検証（大幅強化）
**目的**: POCがAcceptance Criteriaを満たしているかを詳細に検証し、未達成項目の理由を明確化する。
#### 検証プロセス
1. 現在のAcceptance Criteriaを読む
2. POC PR diffとコミット、Discoveries & Insightsを参照
3. 各項目について達成/未達成を判定
4. 未達成の場合、その理由を分析（技術的制約? 優先度? スコープ外?）
#### 検証結果の記入フォーマット
進捗ドキュメントに新しいセクション「POC検証結果」を追加します：
```markdown
## POC検証結果
### Acceptance Criteria達成状況
**達成した項目:**
- ✅ [受け入れ基準1]
- 検証方法: [どのように確認したか]
- PR参照: [関連するコミットやdiff]
- ✅ [受け入れ基準2]
- 検証方法: [どのように確認したか]
- PR参照: [関連するコミットやdiff]
**未達成の項目:**
- ❌ [受け入れ基準3]
- 理由: [なぜ達成できなかったか - 技術的制約、実現不可能性、優先度など]
- 影響: [この未達成が本実装にどう影響するか]
- 対応方針: [Open Questionに追加 / Acceptance Criteria調整 / Phase 2に延期 など]
**スコープ外と判断した項目:**
- ⚠️ [受け入れ基準4]
- 理由: [なぜスコープ外と判断したか]
- 将来の対応: [Phase 2で検討 / 別Issueで対応 など]
```
#### 例
```markdown
## POC検証結果
### Acceptance Criteria達成状況
**達成した項目:**
- ✅ watch daemonがファイル変更を検知できる
- 検証方法: chokidarによるファイル監視を実装、ローカルファイル変更時に自動pushを確認
- PR参照: コミット abc123 "Add chokidar file watcher"
- ✅ リモートポーリングが動作する
- 検証方法: setIntervalで30秒間隔のポーリングを実装、remote変更時に自動pullを確認
- PR参照: コミット def456 "Add remote polling with setInterval"
**未達成の項目:**
- ❌ 1秒以内の同期を実現する
- 理由: GitHub API rate limit制約（5000 req/hour = 最短7.2秒間隔）により、1秒間隔のポーリングは不可能
- 影響: 同期遅延が発生する（現在のPOCでは30秒間隔）
- 対応方針: Open Questionに「最適なポーリング間隔」を追加し、人間が判断
**スコープ外と判断した項目:**
- ⚠️ Webhook対応
- 理由: GitHub Webhook設定の複雑さ（ngrok等の外部ツール必要）、Phase 1では優先度低
- 将来の対応: Phase 2で検討（より迅速な同期が必要と判明した場合）
```
#### 未達成項目への対応
未達成項目が簡単に解消できない場合、**必ずOpen Questionsに論点を追加**してください（ステップ5）。
---
### ステップ5: Discoveries & Insightsへの追記
POC実装で新たに発見した技術的事実を追記します。
**追記内容（状況に応じて必要なものを記載）**:
- 技術的制約（API rate limit、パフォーマンス特性など）
- 実現可能性の確認（「できる」「できない」の明確化）
- エッジケース、想定外の動作
- ライブラリ・ツールの特性
- 複雑性の見積もり
#### 追記フォーマット
```markdown
## Discoveries & Insights
**YYYY-MM-DD: [発見のタイトル]**
- **発見**: [発見した技術的事実]
- **学び**: [この発見が実装にどう影響するか]
- **POC参照**: [関連するコミットやPR]
```
#### 例
```markdown
## Discoveries & Insights
**2025-10-15: GitHub API rate limitの実測値**
- **発見**: GitHub API rate limitは5000 req/hourであり、1秒間隔のポーリングは不可能（最短7.2秒間隔）
- **学び**: Acceptance Criteriaの「1秒以内の同期」は技術的に実現不可能。ポーリング間隔を調整する必要がある
- **POC参照**: コミット abc123 "Test rate limit with 1s polling"
**2025-10-15: chokidarの安定性**
- **発見**: chokidarはクロスプラットフォームで安定動作し、ファイル変更を確実に検知できる
- **学び**: ローカルファイル監視にはchokidarが適している
- **POC参照**: コミット def456 "Add chokidar file watcher"
**2025-10-15: Pull→Pushループのリスク**
- **発見**: Remote pullでファイル更新→chokidarが検知→pushが発生する無限ループが発生
- **学び**: Grace period（猶予期間）を設けることで回避可能。pullから10秒間はpushを抑制する実装が必要
- **POC参照**: コミット ghi789 "Add grace period to prevent pull→push loop"
```
---
### ステップ6: Open Questionsへの論点追加（大幅強化）
**目的**: 未達成のAcceptance Criteriaや技術的な選択肢について、人間が意思決定するための論点を明確化する。
#### 論点追加のガイドライン
以下のような場合に論点を追加します：
- ❌ Acceptance Criteriaが未達成（簡単に解消できない）
- 🤔 技術的な選択肢が複数ある（Option A vs B）
- ⚖️ トレードオフがある（パフォーマンス vs 複雑さ）
- 🔍 不確実性がある（スケーラビリティ、ユーザー体験など）
#### 論点記入フォーマット
```markdown
## Open Questions
### Q[番号]: [質問のタイトル]
**背景**: [なぜこの質問が生まれたか - POCで判明した事実]
**選択肢:**
- Option A: [選択肢1]
- メリット: [利点]
- デメリット: [欠点]
- 実装難易度: [高/中/低]
- Option B: [選択肢2]
- メリット: [利点]
- デメリット: [欠点]
- 実装難易度: [高/中/低]
**推奨**: [AIの推奨案（あれば）と根拠]
**決定者**: [人間が決定] / **決定期限**: [必要であれば]
```
#### 例
```markdown
## Open Questions
### Q1: GitHub API rate limitを考慮した最適なポーリング間隔は？
**背景**: POCで1秒間隔のポーリングは不可能と判明（rate limit: 5000 req/hour = 最短7.2秒間隔）
**選択肢:**
- Option A: 30秒間隔（120 req/hour）
- メリット: 安全マージン大（rate limitの2.4%のみ使用）、複数プロジェクト同時watchでも余裕あり
- デメリット: 同期遅延が最大30秒発生、ユーザー体験がやや悪い
- 実装難易度: 低（POCで既に実装済み）
- Option B: 10秒間隔（360 req/hour）
- メリット: より迅速な同期（最大10秒遅延）、ユーザー体験向上
- デメリット: rate limitの7.2%使用、複数プロジェクトで制約あり
- 実装難易度: 低（setIntervalの値変更のみ）
- Option C: 設定可能にする（デフォルト30秒）
- メリット: ユーザーが自分の環境に合わせて調整可能
- デメリット: 設定の複雑さ増加、rate limit超過のリスク
- 実装難易度: 中（state.ymlにpoll_interval追加）
**推奨**: Option C（設定可能、デフォルト30秒）
- 理由: ユーザーによって同時watch数が異なるため、柔軟性が重要
- rate limit超過時のエラーハンドリングを実装すれば安全
**決定者**: [人間が決定]
---
### Q2: Pull→Pushループ防止のgrace periodは何秒が適切か？
**背景**: POCでgrace period 10秒を実装したが、最適値は未検証
**選択肢:**
- Option A: 5秒
- メリット: ローカル変更への反応が早い
- デメリット: pullが遅い場合にループのリスク
- Option B: 10秒（POC実装値）
- メリット: 安全性高い
- デメリット: ローカル変更後の同期が最大10秒遅延
- Option C: ポーリング間隔 × 1.5倍（動的調整）
- メリット: ポーリング間隔に応じて最適化
- デメリット: 実装がやや複雑
**推奨**: Option B（10秒固定）
- 理由: シンプルで安全、Phase 1では十分
**決定者**: [人間が決定]
```
---
### ステップ7: Decision Log推奨案の記入
**重要**: このステップで記入するのは**推奨案**であり、**最終決定ではありません**。人間がレビュー・承認してから確定します。
POCの知見を基に、以下の形式でDecision Log推奨案を記入します。
#### Decision Log推奨案フォーマット
```markdown
## Decision Log
> **注**: 以下は `/review-poc` による推奨案です。最終決定は人間が行ってください。
>
> **承認プロセス**: 各推奨案をレビューし、承認/修正/却下を決定してください。
### 推奨案 YYYY-MM-DD: [決定事項のタイトル]
- **推奨技術/アプローチ**: [推奨する技術・アーキテクチャ・アプローチ]
- **根拠**: [POCの結果に基づく理由、技術的制約、実現可能性]
- **トレードオフ**: [採用しなかった選択肢とその理由]（オプション）
- **最終決定**: [ ] 承認待ち / [ ] 承認済み / [ ] 却下
---
### 推奨案 YYYY-MM-DD: [決定事項のタイトル2]
...
```
#### 記入内容（状況に応じて必要なものを記載）
- **技術選定**: ライブラリ、フレームワーク、ツール
- **アーキテクチャパターン**: デザインパターン、システム構成
- **データモデル**: スキーマ、データ構造
- **API設計**: エンドポイント、インターフェース
- **テスト戦略**: テストレベル（単体/統合/E2E）、テストツール
#### 例
```markdown
## Decision Log
> **注**: 以下は `/review-poc` による推奨案です。最終決定は人間が行ってください。
>
> **承認プロセス**: 各推奨案をレビューし、承認/修正/却下を決定してください。
### 推奨案 2025-10-15: Watch daemonの実装方針
- **推奨技術**: `chokidar`ライブラリによるファイル監視 + `setInterval`によるリモートポーリング
- **根拠**: POCで検証した結果、chokidarは安定性が高く、クロスプラットフォーム対応が容易。setIntervalによるポーリングはシンプルで理解しやすい
- **トレードオフ**: Webhookベースのアプローチは設定の複雑さ（ngrok等の外部ツール必要）から初期実装では見送りを推奨。Phase 2で検討
- **最終決定**: [ ] 承認待ち
---
### 推奨案 2025-10-15: ポーリング間隔
- **推奨設定**: 設定可能にする（デフォルト30秒）
- **根拠**: GitHub API rate limit制約から、30秒間隔が安全。ユーザーによって同時watch数が異なるため、柔軟性が重要
- **トレードオフ**: 固定値（30秒）の方がシンプルだが、ユーザーのニーズに対応できない
- **最終決定**: [ ] 承認待ち（Open Question Q1で議論中）
---
### 推奨案 2025-10-15: Pull→Pushループ防止策
- **推奨実装**: Grace period 10秒（pullから10秒間はpushを抑制）
- **根拠**: POCで動作確認済み、シンプルで安全
- **トレードオフ**: 動的調整（ポーリング間隔 × 1.5倍）の方が柔軟だが、実装が複雑
- **最終決定**: [ ] 承認待ち
```
---
### ステップ8: Specification / 仕様の記入（オプショナル）
**重要**: このステップは**POCで明確になった部分のみ**記入してください。不確実な部分は記入しません。
POCで検証したアーキテクチャを基に、以下の形式でSpecification / 仕様セクションを記入します。
#### 記入内容（状況に応じて必要なものを記載）
- **システム仕様**: 機能仕様、動作仕様（POCで確認済みのもののみ）
- **アーキテクチャ図**: mermaid図などで視覚化（オプション）
- **API設計**: インターフェース、エンドポイント
- **データモデル**: スキーマ、データ構造
- **設計方針**: 実装上の重要な考慮事項
#### Specification記入フォーマット
```markdown
## Specification / 仕様
> **注**: 以下はPOCで確認された仕様です。不確実な部分は記載していません。
### [サブシステム名・機能名]
**概要**: [機能の概要]
**仕様**:
- [仕様項目1]（POCで確認済み）
- [仕様項目2]（POCで確認済み）
**実装方針**:
- [実装上の考慮事項1]
- [実装上の考慮事項2]
```
#### 例（mermaid図を含む場合）
```markdown
## Specification / 仕様
> **注**: 以下はPOCで確認された仕様です。不確実な部分は記載していません。
### Watch Daemon アーキテクチャ
**概要**: ファイル変更の監視とGitHub Issue commentへの自動同期（POCで実装確認済み）
**アーキテクチャ図**:
```mermaid
graph TD
A[Watch Daemon] --> B[File Watcher - chokidar]
A --> C[Remote Poller - setInterval]
B --> D[Push on Change]
C --> E[Pull on Remote Update]
D --> F[Grace Period Check]
F -->|10秒経過| G[GitHub API Push]
```
**仕様**:
- ファイル変更検知: chokidarによるリアルタイム監視（POCで動作確認）
- リモート変更検知: 30秒間隔でGitHub API polling（設定可能、デフォルト30秒）
- 同期方向: 双方向（local → remote, remote → local）
- Grace period: pullから10秒間はpushを抑制（ループ防止）
**実装方針**:
- Daemon processとして実行、PIDを.issync/state.ymlに記録
- Graceful shutdown（SIGTERM/SIGINT）に対応
- エラーリトライ: 3回まで、指数バックオフ（POCでは未実装、本実装で追加）
```
**記入しない例**:
- POCで検証していない機能（エラーリトライの詳細など）
- 不確実な仕様（「将来的にWebhook対応する可能性」など）
---
### ステップ9: POC PRのクローズ
POC PRをクローズします：
```bash
gh pr close <PR URL> --comment "POC完了。レビュー結果を進捗ドキュメントに記録しました。人間がレビュー・承認後、implementフェーズに進みます。"
```
**PRが既にクローズ済みの場合**:
- このステップをスキップ（ステップ1で検知済み）
---
### ステップ10: GitHub Issueへの同期
進捗ドキュメントの変更をGitHub Issueに同期します。
```bash
issync push
```
---
### ステップ11: Stage更新（レビュー待ち）
`!env ISSYNC_GITHUB_PROJECTS_NUMBER`が設定されている場合のみ、`gh project item-edit`でStage→`To Review`に設定。失敗時も作業継続（警告のみ）。
**Stage 設定コマンド**:
```bash
issync projects set-stage "$ISSUE_URL" "To Review"
```
**重要**: 人間承認後、Status→`implement`、Stage→`To Start`を手動で変更。
---
## 出力フォーマット
全ステップ完了後、以下の形式でサマリーを提供：
```markdown
## /issync:review-poc 実行結果
### 完了したステップ
- ✅ ステップ1: POC PR情報取得（PR #123: [PR Title]）
- ✅ ステップ2: Discoveries & Insights参照（[X]項目を確認）
- ✅ ステップ3: Acceptance Criteria検証（達成: [Y]項目、未達成: [Z]項目）
- ✅ ステップ4: Discoveries & Insights追記（[W]個の発見を追加）
- ✅ ステップ5: Open Questions追加（[V]個の論点を追加）
- ✅ ステップ6: Decision Log推奨案記入（[U]個の推奨案を記録）
- ✅ ステップ7: Specification / 仕様記入（オプショナル）
- ✅ ステップ8: POC PRクローズ（PR #123）
- ✅ ステップ9: GitHub Issueへの同期完了（issync push）
### Acceptance Criteria検証結果
- ✅ 達成: [達成した項目のリスト]
- ❌ 未達成: [未達成の項目のリスト]
- ⚠️ スコープ外: [スコープ外と判断した項目のリスト]
### 追加されたOpen Questions
1. Q[番号]: [質問のタイトル]
2. Q[番号]: [質問のタイトル]
...
### Decision Log推奨案
1. [推奨案1のタイトル] - [ ] 承認待ち
2. [推奨案2のタイトル] - [ ] 承認待ち
...
### 次のアクション（重要）
- [ ] **進捗ドキュメントの内容（POC検証結果、Open Questions、Decision Log推奨案）をレビューしてください**
- [ ] **Open Questionsを検討し、意思決定を行ってください**
- [ ] **Decision Log推奨案を承認/修正/却下してください**
- [ ] **承認後、GitHub Projects Statusを手動で`implement`に変更してください**
- [ ] **implementのチェックリストを確認し、本実装を開始してください**
```
---
## 重要な注意事項
### Acceptance Criteria検証について
- **全ての項目を明確に分類**してください: 達成/未達成/スコープ外
- **未達成の理由を具体的に記述**してください: 「実現できなかった」ではなく、「GitHub API rate limit制約により1秒間隔は不可能」のように
- **簡単に解消できない未達成項目は必ずOpen Questionに追加**してください
### Discoveries & Insights追記について
- **POCで新たに発見した事実のみ記述**してください
- **「できる」「できない」を明確化**してください: 曖昧な表現を避ける
- **POC参照（コミットハッシュ、PR diff）を必ず記載**してください
### Open Questions追加について
- **選択肢を具体的に記述**してください: メリット・デメリット・実装難易度を明示
- **AIの推奨案は提示するが、最終決定は人間に委ねる**ことを明記
- **複数の論点がある場合、優先度を示す**ことも有用（オプション）
### Decision Log推奨案について
- **「推奨案」であることを明記**してください: 「最終決定は人間が行う」を必ず記載
- **承認チェックボックス `[ ] 承認待ち` を必ず含める**
- **POCの結果を具体的に記述**してください: 「検証した結果、実現可能と判明」ではなく、「chokidarでファイル監視を実装し、30秒間隔のポーリングで安定動作を確認」のように
### Specification / 仕様について
- **POCで確認された部分のみ記載**してください: 不確実な部分は記載しない
- **mermaid図を活用**してください: アーキテクチャは視覚化すると理解しやすい
- **このステップはオプショナル**です: 仕様が明確でない場合はスキップしても構いません
### PRクローズについて
- **PRが既にクローズされている場合でも続行**してください（レビュー情報の記入は実行）
- **PRクローズ時のコメント**は、次のステップ（人間のレビュー）を明記してください
### 人間のレビュープロセス
このコマンド完了後、**必ず人間が以下をレビュー・承認してください**：
1. **POC検証結果**: Acceptance Criteria達成状況は正確か？
2. **Open Questions**: 論点は明確か？選択肢は網羅されているか？
3. **Decision Log推奨案**: 推奨案は合理的か？承認/修正/却下を決定
4. **承認後**: GitHub Projects Statusを手動で`implement`に変更
**重要**: このコマンドは**Status自動変更を行いません**。人間の承認後、手動で変更してください。
### エラーハンドリング
| ケース | 対応 |
|--------|------|
| POC PR URLが無効 | ❌ エラー終了（"無効なPR URLです"） |
| POC PRが既にクローズ済み | ⚠️ 警告を出して続行（レビュー情報記入のみ実行） |
| POCの知見が不足（Discoveries & Insightsが空） | ⚠️ 警告を出して続行（最小限の記入を実施） |
| Acceptance Criteriaが全て未達成 | ⚠️ 警告を出して続行（全てのOpen Questionsに追加） |
**注意**:
- このコマンドに渡されたPRは全てPoC PRとして扱います（PoC PR判定ロジックは不要）
- このコマンドは`architecture-decision`ステートで実行されることを前提としています（Status検証は不要、ユーザーの責任で適切なタイミングで実行）
---
## 出力サマリー形式
```markdown
## /issync:review-poc 実行結果
### 完了したステップ
- ✅ ステップ1-11: 全ステップ完了
### POC検証結果
- ✅ 達成: [達成項目数]項目
- ❌ 未達成: [未達成項目数]項目
- ⚠️ スコープ外: [スコープ外項目数]項目
### 次のアクション（重要）
- [ ] 進捗ドキュメントの内容（POC検証結果、Open Questions、Decision Log推奨案）をレビュー
- [ ] Open Questionsを検討し、意思決定を行う
- [ ] Decision Log推奨案を承認/修正/却下
- [ ] **承認後、GitHub Projects Statusを手動で`implement`に変更してください**
- [ ] **implementのチェックリストを確認し、本実装を開始してください**
---
## 補足: ステートマシンとの統合
このコマンド実行後の流れ：
```
pocステート完了
↓
POC実装 & PR作成
↓
Statusを architecture-decision に変更
↓
/issync:review-poc コマンド実行 (このコマンド)
├─ POC PR情報取得
├─ Discoveries & Insights参照
├─ Acceptance Criteria検証
├─ Discoveries & Insights追記
├─ Open Questions追加
├─ Decision Log推奨案記入
├─ Specification記入（オプショナル）
├─ POC PRクローズ
└─ issync push（自動同期）
↓
POCレビュー完了
↓
**人間が進捗ドキュメントをレビュー**
├─ POC検証結果の確認
├─ Open Questionsの検討・意思決定
└─ Decision Log推奨案の承認/修正/却下
↓
**人間が承認後、手動でStatusを`implement`に変更**
↓
本実装開始
```
**重要**: このコマンドは**Status自動変更を行いません**。人間が進捗ドキュメントの内容（POC検証結果、Open Questions、Decision Log推奨案）をレビューし、承認してから、手動でStatusを`implement`に変更してください。