zhongwei/gh-krhrtky-agents-plugins-pbi-task-manager

Files

Zhongwei Li dc3739c3bd Initial commit

2025-11-30 08:35:56 +08:00

14 KiB

Raw Blame History

description, argument-hint, allowed-tools

description	argument-hint	allowed-tools
GitHub Issueの最新情報を同期してタスクとの整合性を確認する（リファインメントグループ・カテゴリ考慮）	<issue_number> [--force-rerefine] [--preserve-completed]	Bash, Read, Write, Edit, Glob

GitHub Issue 同期

指定されたGitHub Issue #$1 の最新情報をローカルのPBIデータと同期し、リファインメントグループとカテゴリ構造を考慮した再構成を提案します。

同期オプション

/task-sync 123                    # 標準同期（変更検知時のみ更新）
/task-sync 123 --force-rerefine   # 強制的にリファインメント再実行
/task-sync 123 --preserve-completed # 完了タスクは保護して同期

実行内容

1. 多層同期状況確認

ローカル情報の取得:

tasks/pbi-$1/README.md からローカルの最終更新日時を取得
リファインメント完了フェーズ（phase）の確認
.refine-progress.json からグループ進捗の確認
カテゴリ別タスク状況の把握

リモート情報の取得:

gh issue view $1 --json title,body,url,updatedAt,labels,milestone

多層変更検知:

Issue層: タイトル、本文、ラベル、マイルストーンの変更
リファインメント層: 既存のGroup決定事項との整合性
タスク層: カテゴリ構造と実装方針の妥当性
時系列層: Issue更新とローカル更新の時間差分析

2. 同期状況の表示（多層分析）

=== GitHub Issue #$1 同期状況 ===

📊 基本情報
   ローカル最終更新: 2024-01-15T10:30:00Z
   Issue最終更新: 2024-01-16T14:20:00Z
   リファインメントフェーズ: completed (Group 3完了)
   実装進捗: 3/8 タスク完了 (37.5%)

🔍 変更検出結果
   ✅ タイトル: 変更なし
   ⚠️  本文: 更新あり (新機能要件追加の可能性)
   ✅ ラベル: 変更なし
   ⚠️  マイルストーン: v1.0 → v1.1 に変更

📋 リファインメント整合性チェック
   Group 1 (要件・制約): 📝 再確認が必要
     - Issue本文の新要件がGroup 1決定と矛盾する可能性
   Group 2 (技術設計): ✅ 整合性維持
     - 技術スタック選択に影響なし
   Group 3 (タスク構成): ⚠️  見直し推奨
     - 新要件により追加タスクが必要な可能性

🏗️ カテゴリ別影響分析
   Setup: ✅ 影響なし (完了済み)
   Models: ⚠️  新データ要件の可能性
   Services: ⚠️  API拡張が必要な可能性
   UI: 📝 新画面要件を確認必要
   Tests: ⚠️  テストケース追加が必要な可能性

=== 更新されたIssue内容（抜粋） ===
【新機能要件】
+ "ユーザーは複数の認証方法を選択できる"
+ "ソーシャルログイン（Google、GitHub）を追加"

【変更された要件】
~ "パスワードリセット" → "パスワードリセット + 2FA設定"

... (続きは GitHub Issue で確認)

3. 多層ローカル情報の更新

README.mdの段階的更新:

---
issue: $1
title: <最新のタイトル>
url: <最新のURL>
phase: <current_phase>
sync_history:
  - date: 2024-01-16T14:30:00Z
    changes: ["milestone_updated", "requirements_added"]
    impact_analysis: "Group1_recheck_required"
created: <元の作成日時>
updated: <現在の日時>
---

同期履歴の記録:

同期実行日時と検出した変更内容
影響を受けるリファインメントグループの特定
カテゴリ別の影響度評価
推奨される次のアクション

リファインメント整合性の更新:

.refine-progress.json に同期結果を反映
Group決定事項の再検証が必要な箇所をマーク
カテゴリ別タスクの妥当性フラグ更新

4. 構造化タスク再構成の検討

変更内容のレイヤー別分析:

📊 要件レイヤー分析
   新機能: ソーシャルログイン追加
   機能拡張: 2FA機能の追加
   削除機能: なし
   優先度変更: マイルストーン v1.0 → v1.1

🏗️ アーキテクチャへの影響
   認証フロー: 大幅変更が必要
   データモデル: user_auth_methods テーブル追加
   API設計: OAuth エンドポイント追加
   セキュリティ: 外部プロバイダ連携考慮

📋 カテゴリ別インパクト評価
   Setup: ✅ 影響小 (OAuth ライブラリ追加のみ)
   Models: 🔴 影響大 (新テーブル設計必要)
   Services: 🔴 影響大 (OAuth実装、2FA実装)
   UI: 🟡 影響中 (ソーシャルログインボタン追加)
   Tests: 🟡 影響中 (OAuth/2FA テストケース追加)

現在のタスク状況とリスク評価:

📊 現在のタスク状況
   ✅ 完了: 1タスク (Setup完了)
     影響: なし（完了済みタスクは保護）

   ⏳ 実行中: 1タスク (Models: User model実装)
     リスク: 🔴 高
     理由: 認証データ構造の大幅変更が必要
     推奨: 現在の作業を一時停止し、設計見直し

   ⬜ 未着手: 6タスク
     影響: 🔴 大部分で見直し必要
     Services: OAuth/2FA実装により大幅変更
     UI: ソーシャルログイン対応で変更
     Tests: 新機能に対応したテスト設計が必要

リファインメントグループへの影響:

🔄 Group 1 (要件・制約) - 再実行推奨
   現在の決定: 基本認証のみ、中規模対応
   新要件: マルチ認証、外部連携、2FA
   → 要件確定からやり直しが必要

🔄 Group 2 (技術設計) - 部分見直し
   現在の設計: JWT単体、シンプル認証
   新設計: OAuth対応、2FA統合、プロバイダ管理
   → 認証アーキテクチャの再設計が必要

🔄 Group 3 (タスク構成) - 全面見直し
   現在: 8タスク、シンプル実装フロー
   新構成: 12-15タスク想定、複雑な依存関係
   → 完全なタスク再分解が必要

5. 段階的再構成提案

再構成戦略の選択肢:

🎯 戦略A: 部分的更新（推奨）
   対象: 未着手タスクのみ更新
   期間: 2-3時間
   リスク: 低
   適用条件: 実行中タスクの影響が限定的

🔄 戦略B: 段階的リファインメント
   対象: Group 2から再実行
   期間: 4-6時間
   リスク: 中
   適用条件: 技術設計の大幅変更が必要

🏗️ 戦略C: 完全リファインメント
   対象: Group 1から全面やり直し
   期間: 1-2日
   リスク: 高（既存作業の無駄）
   適用条件: 要件が根本的に変更

推奨戦略: 戦略B（段階的リファインメント）

📋 実行プラン:

1. 現在の実行中タスク (wip-models-2.md) を一時停止
   - 作業内容を実装メモに記録
   - todo状態に戻して保留

2. Group 2 (技術設計) から再実行
   - OAuth/2FA対応のアーキテクチャ設計
   - 新しいデータモデル設計
   - API仕様の見直し

3. Group 3 (タスク構成) で新しいタスク分解
   - Setup: OAuth ライブラリ追加
   - Models: 認証関連テーブル設計（拡張版）
   - Services: OAuth実装、2FA実装、既存API
   - UI: ソーシャルログイン、2FA設定画面
   - Tests: 統合認証テスト

4. 既存完了タスクの統合
   - Setup-1 (完了済み) は新Setup-1にマージ
   - Models-1 (実行中) は新Models-1として再設計

カテゴリ別タスク影響分析:

📂 Setup (影響: 小)
   現在: todo-setup-1.md "プロジェクト環境構築"
   新規: OAuth ライブラリ (passport, google-auth) 追加

📂 Models (影響: 大)
   現在: wip-models-2.md "認証関連テーブル設計"
   新規: user_auth_methods, oauth_tokens テーブル追加
         2FA設定テーブル追加

📂 Services (影響: 大)
   現在: 2タスク (基本認証API)
   新規: 4-5タスク (OAuth, 2FA, 統合認証)

📂 UI (影響: 中)
   現在: 2タスク (ログイン・登録フォーム)
   新規: 3-4タスク (ソーシャル選択、2FA設定追加)

📂 Tests (影響: 中)
   現在: 1タスク (基本認証テスト)
   新規: 2-3タスク (OAuth, 2FA, 統合テスト)

6. 実行オプションと安全対策

Option A: 安全な部分更新（推奨）

/task-sync 123 --preserve-completed

実行内容:
1. 完了タスク (done-*.md) は保護
2. 実行中タスク (wip-*.md) は todo に戻して保留
3. 未着手タスク (todo-*.md) のみ削除・再生成
4. README.md の履歴に同期ログ追加
5. Group 2 から段階的リファインメント実行

Option B: 強制的な完全リファインメント

/task-sync 123 --force-rerefine

⚠️  危険: 全ての進行中作業が失われます
実行内容:
1. .refine-progress.json をリセット
2. 全タスクファイル削除（backup作成後）
3. Group 1 から完全リファインメント実行
4. 新しいカテゴリ構造で再構築

手動調整オプション

段階的手動調整:
1. 特定カテゴリのみ更新
   find tasks/pbi-$1 -name "todo-services-*.md" -delete
   # サービス系タスクのみ手動再作成

2. 実行中タスクの内容更新
   # wip-models-2.md の要件を新仕様に合わせて編集
   # 実装メモに移行作業を記録

3. 依存関係の再調整
   # カテゴリ間依存関係を新要件に合わせて更新
   # タスクファイルの depends_on フィールド修正

安全対策とバックアップ

# 実行前の自動バックアップ
cp -r tasks/pbi-$1 tasks/pbi-$1.backup.$(date +%Y%m%d_%H%M%S)

# 段階的実行での中断ポイント
# Group 2 完了後、Group 3 実行前にユーザー確認
# カテゴリ別タスク生成後、依存関係確認でユーザー確認

# ロールバック機能
# 問題が発生した場合、前回の同期状態に戻すオプション

使用するコマンド

# 多層情報取得
gh issue view $1 --json title,body,url,updatedAt,labels,milestone,assignees

# ローカル状態の包括的確認
grep "^updated:" tasks/pbi-$1/README.md
grep "^phase:" tasks/pbi-$1/README.md
ls tasks/pbi-$1/.refine-progress.json 2>/dev/null

# リファインメントグループ進捗の確認
if [ -f "tasks/pbi-$1/.refine-progress.json" ]; then
    jq -r '.current_group, .completed_groups[].group' tasks/pbi-$1/.refine-progress.json
fi

# カテゴリ別タスク状況確認
for category in setup models services ui tests; do
    echo "$category:"
    find tasks/pbi-$1 -name "done-$category-*.md" | wc -l
    find tasks/pbi-$1 -name "wip-$category-*.md" | wc -l
    find tasks/pbi-$1 -name "todo-$category-*.md" | wc -l
done

# 依存関係とブロック状況の確認
for todo_file in tasks/pbi-$1/todo-*.md; do
    if [ -f "$todo_file" ]; then
        depends=$(grep "depends_on:" "$todo_file" | cut -d: -f2)
        echo "$(basename $todo_file): depends on [$depends]"
    fi
done

# 同期履歴の更新
sync_entry="{
  \"date\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
  \"changes\": [\"issue_updated\"],
  \"impact_analysis\": \"group2_recheck_required\"
}"

# README.mdの拡張メタデータ更新
sed -i.bak "s/^updated:.*/updated: $(date -u +%Y-%m-%dT%H:%M:%SZ)/" tasks/pbi-$1/README.md
echo "sync_history:" >> tasks/pbi-$1/README.md
echo "  - $sync_entry" >> tasks/pbi-$1/README.md

# バックアップの作成
backup_dir="tasks/pbi-$1.backup.$(date +%Y%m%d_%H%M%S)"
cp -r tasks/pbi-$1 $backup_dir
echo "Backup created: $backup_dir"

同期判定ロジック

変更検知の条件:

タイトル変更: ローカルタイトル ≠ Issue タイトル
内容更新: Issue updatedAt > ローカル updated
URL変更: ローカルURL ≠ Issue URL

同期の必要性:

いずれかの変更が検知された場合
ユーザーが明示的に同期を要求した場合

再構成時の安全対策

実行中タスクの保護:

wipタスクがある場合は慎重な操作を促す
破壊的変更前の確認プロンプト

完了タスクの保護:

doneタスクは原則として変更しない
履歴として保持

バックアップの推奨:

重要な変更前のディレクトリバックアップ提案

エラーハンドリング

GitHub CLI未認証時のエラー
指定されたIssueが存在しない場合
PBIディレクトリが存在しない場合
ネットワーク接続エラー時の対応

完了条件

基本同期要件

Issue情報が正常に取得されている
ローカル情報が最新の内容で更新されている
変更内容が適切に分析・表示されている
同期履歴が記録されている

リファインメント整合性要件

Group 1-3 の決定事項と新Issue内容の整合性が評価されている
影響を受けるグループが特定されている
必要な再リファインメント範囲が明確になっている

カテゴリ・タスク整合性要件

カテゴリ別の影響度が正確に評価されている
依存関係の変更が適切に分析されている
実行中タスクへの影響とリスクが明示されている
完了タスクの保護策が実施されている

再構成提案要件

複数の再構成戦略が提示されている
推奨戦略の根拠が明確に示されている
実行プランが具体的で実行可能
安全対策とロールバック手順が提供されている

ユーザー支援要件

次のアクションが明確で実行可能
リスクと期待効果が適切に説明されている
段階的実行でのチェックポイントが設定されている

実行を開始しますか？

14 KiB Raw Blame History Unescape Escape