zhongwei/gh-mh4gf-issync-claude-plugins-issync

Files

Zhongwei Li fb4d2ff5f1 Initial commit

2025-11-30 08:40:07 +08:00

26 KiB

Raw Permalink Blame History

description

description
POC実装の結果をレビューし、人間の意思決定のための材料を整理する

/issync:review-poc: POCレビューワークフロー

あなたはユーザーの .issync/docs/plan-*.md ファイルのPOCレビューフェーズをサポートしています。このコマンドは以下の11ステップのワークフローを自動化します：

Stage設定（In Progress）
POC PR URLを受け取り、PR情報を取得
Discoveries & Insightsを参照
Acceptance Criteriaの検証（達成/未達成を明確化）
Discoveries & Insightsへの追記
Open Questionsへの論点追加（強化）
Decision Log推奨案の記入（人間の最終決定を前提）
Specification / 仕様の記入（オプショナル）
POC PRをクローズ
issync pushで同期（必要な場合）
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 設定コマンド:

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から以下の情報を取得します：

# 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の特定

PR本文の解析
- 本文中のissue言及を理解（"Resolves:", "Fixes #123", "Part of #456" など、自然言語として柔軟に解釈）
- 完全URL形式（https://github.com/.../issues/番号）を優先、#番号はPRと同一リポジトリと判断
複数/未検出時の処理
- 複数issue: ユーザーに選択させる
- 未検出: issue URLまたは番号の入力を促す
使用
- 進捗ドキュメント検索: .issync/docs/plan-{issue番号}-*.md
- GitHub Projects操作（Stage更新）

ステップ3: Discoveries & Insightsの参照

進捗ドキュメントのDiscoveries & Insightsセクションを読み、POC実装中に発見された技術的制約・複雑性を確認：

## Discoveries & Insights

**YYYY-MM-DD: [発見のタイトル]**
- **発見**: [発見した技術的事実]
- **学び**: [この発見が実装にどう影響するか]

これらの発見事項とPR情報を統合し、Acceptance Criteria検証の根拠とします。

ステップ4: Acceptance Criteriaの検証（大幅強化）

目的: POCがAcceptance Criteriaを満たしているかを詳細に検証し、未達成項目の理由を明確化する。

検証プロセス

現在のAcceptance Criteriaを読む
POC PR diffとコミット、Discoveries & Insightsを参照
各項目について達成/未達成を判定
未達成の場合、その理由を分析（技術的制約? 優先度? スコープ外?）

検証結果の記入フォーマット

進捗ドキュメントに新しいセクション「POC検証結果」を追加します：

## POC検証結果

### Acceptance Criteria達成状況

**達成した項目:**
- ✅ [受け入れ基準1]
  - 検証方法: [どのように確認したか]
  - PR参照: [関連するコミットやdiff]

- ✅ [受け入れ基準2]
  - 検証方法: [どのように確認したか]
  - PR参照: [関連するコミットやdiff]

**未達成の項目:**
- ❌ [受け入れ基準3]
  - 理由: [なぜ達成できなかったか - 技術的制約、実現不可能性、優先度など]
  - 影響: [この未達成が本実装にどう影響するか]
  - 対応方針: [Open Questionに追加 / Acceptance Criteria調整 / Phase 2に延期 など]

**スコープ外と判断した項目:**
- ⚠️ [受け入れ基準4]
  - 理由: [なぜスコープ外と判断したか]
  - 将来の対応: [Phase 2で検討 / 別Issueで対応 など]

例

## 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、パフォーマンス特性など）
実現可能性の確認（「できる」「できない」の明確化）
エッジケース、想定外の動作
ライブラリ・ツールの特性
複雑性の見積もり

追記フォーマット

## Discoveries & Insights

**YYYY-MM-DD: [発見のタイトル]**
- **発見**: [発見した技術的事実]
- **学び**: [この発見が実装にどう影響するか]
- **POC参照**: [関連するコミットやPR]

例

## 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 複雑さ）
🔍 不確実性がある（スケーラビリティ、ユーザー体験など）

論点記入フォーマット

## Open Questions

### Q[番号]: [質問のタイトル]

**背景**: [なぜこの質問が生まれたか - POCで判明した事実]

**選択肢:**
- Option A: [選択肢1]
  - メリット: [利点]
  - デメリット: [欠点]
  - 実装難易度: [高/中/低]

- Option B: [選択肢2]
  - メリット: [利点]
  - デメリット: [欠点]
  - 実装難易度: [高/中/低]

**推奨**: [AIの推奨案（あれば）と根拠]

**決定者**: [人間が決定] / **決定期限**: [必要であれば]

例

## 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推奨案フォーマット

## Decision Log

> **注**: 以下は `/review-poc` による推奨案です。最終決定は人間が行ってください。
>
> **承認プロセス**: 各推奨案をレビューし、承認/修正/却下を決定してください。

### 推奨案 YYYY-MM-DD: [決定事項のタイトル]

- **推奨技術/アプローチ**: [推奨する技術・アーキテクチャ・アプローチ]
- **根拠**: [POCの結果に基づく理由、技術的制約、実現可能性]
- **トレードオフ**: [採用しなかった選択肢とその理由]（オプション）
- **最終決定**: [ ] 承認待ち / [ ] 承認済み / [ ] 却下

---

### 推奨案 YYYY-MM-DD: [決定事項のタイトル2]

...

記入内容（状況に応じて必要なものを記載）

技術選定: ライブラリ、フレームワーク、ツール
アーキテクチャパターン: デザインパターン、システム構成
データモデル: スキーマ、データ構造
API設計: エンドポイント、インターフェース
テスト戦略: テストレベル（単体/統合/E2E）、テストツール

例

## 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記入フォーマット

## Specification / 仕様

> **注**: 以下はPOCで確認された仕様です。不確実な部分は記載していません。

### [サブシステム名・機能名]

**概要**: [機能の概要]

**仕様**:
- [仕様項目1]（POCで確認済み）
- [仕様項目2]（POCで確認済み）

**実装方針**:
- [実装上の考慮事項1]
- [実装上の考慮事項2]

例（mermaid図を含む場合）

## 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に同期します。

issync push

ステップ11: Stage更新（レビュー待ち）

!env ISSYNC_GITHUB_PROJECTS_NUMBERが設定されている場合のみ、gh project item-editでStage→To Reviewに設定。失敗時も作業継続（警告のみ）。

Stage 設定コマンド:

issync projects set-stage "$ISSUE_URL" "To Review"

重要: 人間承認後、Status→implement、Stage→To Startを手動で変更。

出力フォーマット

全ステップ完了後、以下の形式でサマリーを提供：

## /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クローズ時のコメントは、次のステップ（人間のレビュー）を明記してください

人間のレビュープロセス

このコマンド完了後、必ず人間が以下をレビュー・承認してください：

POC検証結果: Acceptance Criteria達成状況は正確か？
Open Questions: 論点は明確か？選択肢は網羅されているか？
Decision Log推奨案: 推奨案は合理的か？承認/修正/却下を決定
承認後: 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検証は不要、ユーザーの責任で適切なタイミングで実行）

出力サマリー形式

## /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`に変更してください。

26 KiB Raw Permalink Blame History Unescape Escape

/issync:review-poc: POCレビューワークフロー

コンテキスト

前提条件

実行ステップ

ステップ1: Stage設定（AI作業開始）

ステップ2: POC PR URLの受け取りとPR情報取得

2.1 POC PR URLの受け取り

2.2 PR情報の取得

2.3 PRに対応するissueの特定

ステップ3: Discoveries & Insightsの参照

ステップ4: Acceptance Criteriaの検証（大幅強化）

検証プロセス

検証結果の記入フォーマット

例

未達成項目への対応

ステップ5: Discoveries & Insightsへの追記

追記フォーマット

例

ステップ6: Open Questionsへの論点追加（大幅強化）

論点追加のガイドライン

論点記入フォーマット

例

ステップ7: Decision Log推奨案の記入

Decision Log推奨案フォーマット

記入内容（状況に応じて必要なものを記載）

例

ステップ8: Specification / 仕様の記入（オプショナル）

記入内容（状況に応じて必要なものを記載）

Specification記入フォーマット

例（mermaid図を含む場合）

ステップ10: GitHub Issueへの同期

ステップ11: Stage更新（レビュー待ち）

出力フォーマット

重要な注意事項

Acceptance Criteria検証について

Discoveries & Insights追記について

Open Questions追加について

Decision Log推奨案について

Specification / 仕様について

PRクローズについて

人間のレビュープロセス

エラーハンドリング

出力サマリー形式

26 KiB

Raw Permalink Blame History