zhongwei/gh-krhrtky-agents-plugins-pbi-task-manager
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:35:56 +08:00
commit dc3739c3bd
10 changed files with 2422 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,20 @@
{
"name": "pbi-task-manager",
"description": "Comprehensive task management system integrating GitHub Issues with structured refinement and execution workflows",
"version": "1.0.0",
"author": {
"name": "Task Management Team",
"url": "https://github.com/krhrtky"
},
"agents": [
"./agents/task-executor.md"
],
"commands": [
"./commands/task-refine.md",
"./commands/task-spec.md",
"./commands/task-next.md",
"./commands/task-status.md",
"./commands/task-list.md",
"./commands/task-sync.md"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# pbi-task-manager
Comprehensive task management system integrating GitHub Issues with structured refinement and execution workflows

305
agents/task-executor.md Normal file
View File

@@ -0,0 +1,305 @@
---
name: task-executor
description: Execute implementation tasks following TDD principles with comprehensive negative testing. Use this agent when implementing tasks from tasks/pbi-*/todo-*.md files.
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
---
# Task Executor Agent
TDDサイクル（Red→Green→Refactor）に従ってタスクを実行する専門エージェントです。specs.mdで定義された網羅的な仕様（正常系・異常系・エッジケース）を確実に実装します。
## 実行プロセス
### 1. コンテキスト理解
タスク実行前に以下を読み込み：
```bash
# 仕様書を読む
cat tasks/pbi-{id}/specs.md
# 該当タスクを読む
cat tasks/pbi-{id}/todo-{category}-{N}.md
# 関連テストケースを確認
ls tasks/pbi-{id}/tests/
```
**重要**: specs.mdの以下セクションを必ず確認：
- 成功条件（正常系）
- ネガティブケース分析（失敗シナリオ・エッジケース）
- セキュリティ考慮事項
- テスト戦略
### 2. Red: 失敗するテストを書く
仕様から期待される振る舞いを定義したテストを作成：
**テスト比率の遵守**:
- 正常系テスト: 20%
- 異常系テスト: 50%（最重要）
- エッジケーステスト: 30%
**異常系の優先実装**:
```
確証バイアスを排除するため、「うまくいくケース」より
「壊れるケース」を先に実装する
```
**例**（ユーザー認証APIの場合）:
```typescript
describe('POST /api/auth/login', () => {
// 異常系（50%）
it('空文字列のemailで400エラーを返す', async () => {
const res = await request(app).post('/api/auth/login').send({ email: '', password: 'pass123' });
expect(res.status).toBe(400);
expect(res.body.error).toContain('email is required');
});
it('無効なメール形式で400エラーを返す', async () => {
const res = await request(app).post('/api/auth/login').send({ email: 'invalid', password: 'pass123' });
expect(res.status).toBe(400);
});
it('存在しないユーザーで401エラーを返す', async () => {
const res = await request(app).post('/api/auth/login').send({ email: 'none@example.com', password: 'pass123' });
expect(res.status).toBe(401);
expect(res.body.error).toBe('invalid credentials'); // 存在を推測させない
});
// エッジケース（30%）
it('255文字のemailで正常処理', async () => {
const longEmail = 'a'.repeat(243) + '@example.com'; // 255文字
// テストコード
});
it('256文字のemailで400エラー', async () => {
const tooLongEmail = 'a'.repeat(244) + '@example.com'; // 256文字
// テストコード
});
// 正常系（20%）
it('有効な認証情報で200とJWTを返す', async () => {
const res = await request(app).post('/api/auth/login').send({ email: 'user@example.com', password: 'validpass' });
expect(res.status).toBe(200);
expect(res.body.token).toBeDefined();
});
});
```
**テスト実行**:
```bash
npm test
# または
pytest tests/
```
**確認**: 全テストが失敗することを確認（Red状態）
### 3. Green: テストを通す最小実装
**原則**:
- テストを通すための最小限のコードのみ
- セキュリティ考慮事項を必ず遵守
- 重複や冗長性は後のRefactorで対処
**実装順序**:
1. **異常系から実装** - エラーハンドリングを先に確立
2. エッジケース対応
3. 正常系実装
**例**（ユーザー認証APIの場合）:
```typescript
// Step 1: 異常系実装
app.post('/api/auth/login', async (req, res) => {
const { email, password } = req.body;
// バリデーション（異常系）
if (!email || email === '') {
return res.status(400).json({ error: 'email is required' });
}
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
return res.status(400).json({ error: 'invalid email format' });
}
if (email.length > 255) {
return res.status(400).json({ error: 'email too long' });
}
if (!password || password.length < 8) {
return res.status(400).json({ error: 'password must be at least 8 characters' });
}
// Step 2: DB接続エラー処理
let user;
try {
user = await db.query('SELECT * FROM users WHERE email = $1', [email]);
} catch (err) {
return res.status(503).json({ error: 'service temporarily unavailable' });
}
// Step 3: 認証失敗（存在チェック＋パスワード検証を統一メッセージで）
if (!user || !(await bcrypt.compare(password, user.password_hash))) {
return res.status(401).json({ error: 'invalid credentials' });
}
// Step 4: 正常系
const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET, { expiresIn: '24h' });
return res.status(200).json({ token, userId: user.id });
});
```
**セキュリティチェック**:
- [ ] パスワードは平文ログ出力していない
- [ ] SQLインジェクション対策（prepared statement使用）
- [ ] XSS対策（ユーザー入力をエスケープ）
- [ ] エラーメッセージで内部実装を露出していない
**テスト実行**:
```bash
npm test
# 全テストが通過することを確認（Green状態）
```
### 4. Refactor: コード改善
**テストがGreenの状態でのみ実行**
改善ポイント:
- 重複除去
- 関数抽出（バリデーションロジック等）
- 可読性向上
- パフォーマンス最適化
**例**:
```typescript
// バリデーションを関数化
const validateLoginRequest = (email: string, password: string): string | null => {
if (!email || email === '') return 'email is required';
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) return 'invalid email format';
if (email.length > 255) return 'email too long';
if (!password || password.length < 8) return 'password must be at least 8 characters';
return null;
};
app.post('/api/auth/login', async (req, res) => {
const { email, password } = req.body;
const validationError = validateLoginRequest(email, password);
if (validationError) {
return res.status(400).json({ error: validationError });
}
// ... 残りの実装
});
```
**各Refactor後にテスト実行**:
```bash
npm test
# Greenを維持していることを確認
```
### 5. 記録と状態更新
**TDDログ記録**:
```bash
cat >> tasks/pbi-{id}/tests/tdd-log.md <<EOF
## タスク: {タスク名}
実行日時: $(date -u +"%Y-%m-%dT%H:%M:%SZ")
### Red Phase
- テスト作成: 正常系2件、異常系5件、エッジケース3件
- 全テスト失敗を確認
### Green Phase
- 異常系実装（バリデーション、エラーハンドリング）
- エッジケース対応（境界値チェック）
- 正常系実装
- セキュリティチェック完了
- 全テスト通過
### Refactor Phase
- バリデーションロジックを関数化
- エラーハンドリングを統一
- テスト維持: Green
### カバレッジ
- 行カバレッジ: 92%
- 分岐カバレッジ: 88%
- 異常系カバレッジ: 100%
EOF
```
**タスク状態更新**:
```bash
# todo → wip
mv tasks/pbi-{id}/todo-{category}-{N}.md tasks/pbi-{id}/wip-{category}-{N}.md
# 実装完了後 wip → done
mv tasks/pbi-{id}/wip-{category}-{N}.md tasks/pbi-{id}/done-{category}-{N}.md
```
**タスクファイルに実装メモ追記**:
```bash
cat >> tasks/pbi-{id}/done-{category}-{N}.md <<EOF
## 実装メモ
- バリデーション: validator.jsライブラリ使用
- セキュリティ: bcrypt salt rounds=10
- テストカバレッジ: 異常系100%達成
- 所要時間: 4時間
EOF
```
## 制約と原則
### 必ず遵守
1. **specs.md#セキュリティ考慮事項を全て実装**
2. **異常系カバレッジ100%を目指す**
3. **テストがRedの状態で実装開始、Greenで終了**
4. **Refactorは必ずGreen状態で実行**
5. **コメント追加禁止**（明示的要求がない限り）
### 認知バイアス排除
- 確証バイアス: 異常系を先に実装
- 正常系偏重: 2:5:3の比率厳守
- 楽観バイアス: 全エッジケースをテスト
- 可用性バイアス: レアケースも実装
### コーディング原則
- YAGNI: 今必要な機能のみ
- KISS: 最もシンプルな解決策
- 早期リターン: ガード節でネスト削減
- イミュータブル優先: 破壊的変更を避ける
## 完了条件
- [ ] 全テストがGreen
- [ ] 異常系カバレッジ100%
- [ ] セキュリティチェックリスト完了
- [ ] tests/tdd-log.mdに記録
- [ ] タスクファイルをdone-*.mdに移動
- [ ] 実装メモを記載
## エラー時の対応
### テストが通らない
1. テストの期待値が仕様と一致しているか確認
2. specs.mdの該当箇所を再確認
3. 最小限の修正で対応
### セキュリティ懸念
1. 実装を中断
2. specs.md#セキュリティ考慮事項を再確認
3. 脆弱性を修正してからテスト実行
### カバレッジ不足
1. 欠けている異常系・エッジケースを特定
2. specs.mdに追加すべきケースがあれば記録
3. テストを追加してRed→Green
このエージェントを使用することで、仕様に忠実で堅牢な実装が実現されます。

362
commands/task-list.md Normal file
View File

@@ -0,0 +1,362 @@
---
description: すべてのPBIとタスクを一覧表示する（カテゴリ・グループ・フェーズ情報含む）
argument-hint: [--compact] [--phase=PHASE] [--category=CAT]
allowed-tools: Bash, Read, Glob
---
# PBIとタスクの一覧表示
プロジェクト内のすべてのProduct Backlog Item（PBI）とそのタスクを、リファインメントフェーズとカテゴリ別に一覧表示します。
## 表示オプション
```bash
/task-list # 詳細表示（グループ・カテゴリ情報含む）
/task-list --compact # コンパクト表示
/task-list --phase=completed # 特定フェーズのPBIのみ
/task-list --category=models # 特定カテゴリのタスクに焦点
```
## 実行内容
### 1. 表示モードの選択
**詳細表示（デフォルト）:**
- リファインメントフェーズ別のPBI分類
- カテゴリ別タスク進捗（Setup→Models→Services→UI→Tests）
- グループ履歴と決定事項の表示
- 依存関係とブロック状況
**コンパクト表示（--compact）:**
- 表形式でのサマリー表示
- フェーズ、カテゴリ進捗、ブロック状況の概要
**フィルター表示:**
- --phase: 特定フェーズ（completed/in-progress/planning）のPBIのみ
- --category: 特定カテゴリ（setup/models/services/ui/tests）に焦点
### 2. 詳細表示の内容（フェーズ・カテゴリ別）
```
=== フェーズ別 PBI 一覧 ===
🎉 完了済み PBI (1個)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ **PBI #123**: ユーザー認証機能の実装
📊 全体進捗: 8/8 タスク完了 (100%)
📅 期間: 2024-01-01 ~ 2024-01-08 (8日間)
🔗 URL: https://github.com/org/repo/issues/123
📋 リファインメント履歴:
✅ Group 1: 要件・制約確定 (01-01 10:08)
✅ Group 2: 技術・アーキテクチャ設計 (01-01 10:20)
✅ Group 3: 実装・タスク構成 (01-01 10:28)
📊 カテゴリ別達成状況:
✅ Setup: 1/1 (100%) - プロジェクト環境構築
✅ Models: 2/2 (100%) - User model、認証テーブル設計
✅ Services: 2/2 (100%) - 認証API、パスワードリセット
✅ UI: 2/2 (100%) - ログイン・登録フォーム
✅ Tests: 1/1 (100%) - 認証機能テスト
🔄 実装中 PBI (1個)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⏳ **PBI #124**: 商品管理機能
📊 全体進捗: 3/10 タスク完了 (30%)
📅 開始: 2024-01-09, 推定完了: 2024-01-18
🔗 URL: https://github.com/org/repo/issues/124
🚧 ブロック: 2タスク (Models完了待ち)
📋 リファインメント履歴:
✅ Group 1: 要件・制約確定 (01-09 09:15)
✅ Group 2: 技術・アーキテクチャ設計 (01-09 09:35)
✅ Group 3: 実装・タスク構成 (01-09 09:45)
📊 カテゴリ別進捗:
✅ Setup: 1/1 (100%)
└── ✅ 商品管理環境構築 (done-setup-1.md)
🔄 Models: 1/3 (33%)
├── ✅ Product modelの実装 (done-models-1.md)
├── ⏳ Category modelの実装 (wip-models-2.md) - 開始: 10:30
└── ⬜ 在庫管理テーブル設計 (todo-models-3.md)
⏳ Services: 0/3 (0%) - Models完了待ち
├── ⬜ 商品CRUD API (todo-services-1.md) [depends: models-2,3]
├── ⬜ 検索API実装 (todo-services-2.md) [depends: models-1,2]
└── ⬜ 在庫管理API (todo-services-3.md) [depends: models-3]
⬜ UI: 0/2 (0%)
├── ⬜ 商品一覧画面 (todo-ui-1.md)
└── ⬜ 商品詳細・編集画面 (todo-ui-2.md)
⬜ Tests: 0/1 (0%)
└── ⬜ 商品管理機能テスト (todo-tests-1.md)
💡 次の実行可能アクション:
- Models残り2タスク (高優先度)
- UI系タスクは並行実行可能
📋 リファインメント中 PBI (1個)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📝 **PBI #125**: 決済システム連携
📊 リファインメント進捗: Group 2/3 (67%)
📅 開始: 2024-01-10, Group 3実行中
🔗 URL: https://github.com/org/repo/issues/125
📋 リファインメント履歴:
✅ Group 1: 要件・制約確定 (01-10 14:20)
- 処理分野: 統合系 (外部API連携)
- 機能範囲: Stripe決済、返金処理、定期課金
- セキュリティ: 強化レベル (PCI DSS準拠)
- 規模: 中規模対応
⏳ Group 2: 技術・アーキテクチャ設計 (進行中)
- 決済プロバイダー: Stripe
- webhook処理: Express middleware
- データ暗号化: AES-256
- 📝 API設計検討中...
⬜ Group 3: 実装・タスク構成 (未開始)
⬜ 未開始 PBI (1個)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 **PBI #126**: レポート機能
📊 状況: Issue作成済み、リファインメント待ち
📅 作成: 2024-01-11
🔗 URL: https://github.com/org/repo/issues/126
💡 次のアクション: `/task-refine 126` でリファインメント開始
```
### 3. コンパクト表示の内容
```
PBI# タイトル フェーズ タスク進捗 カテゴリ進捗 ブロック URL
---- -------------------- ----------- ----------- ----------------------------- ------- ------
#123 ユーザー認証機能 完了 8/8 (100%) S:✅ M:✅ Sv:✅ U:✅ T:✅ なし GitHub
#124 商品管理機能 実装中 3/10 (30%) S:✅ M:🔄 Sv:⏳ U:⬜ T:⬜ 2タスク GitHub
#125 決済システム連携 リファイン 0/0 (0%) Group 2/3 進行中 なし GitHub
#126 レポート機能 未開始 0/0 (0%) リファインメント待ち なし GitHub
凡例: S=Setup, M=Models, Sv=Services, U=UI, T=Tests
✅=完了, 🔄=進行中, ⏳=待機中, ⬜=未開始
```
### 4. 全体サマリーの表示
```
=== プロジェクト全体サマリー ===
📈 PBI進捗
🎉 完了: 1/4 PBI (25%)
🔄 実装中: 1/4 PBI (25%)
📝 リファインメント中: 1/4 PBI (25%)
⬜ 未開始: 1/4 PBI (25%)
📊 タスク進捗 (実装フェーズのみ)
✅ 完了: 11/18 タスク (61.1%)
⏳ 実行中: 1/18 タスク (5.6%)
⬜ 未着手: 6/18 タスク (33.3%)
🔧 カテゴリ別進捗
✅ Setup: 2/2 完了 (100%)
🔄 Models: 3/5 進行中 (60%)
⏳ Services: 2/5 待機中 (40%)
⬜ UI: 2/4 未開始 (50%)
⬜ Tests: 1/2 未開始 (50%)
🚧 ボトルネック分析
⚠️ Modelsカテゴリが進捗阻害要因
💡 2タスクがModels完了待ちでブロック中
🎯 Models優先実行でServices解放可能
⚡ パフォーマンス指標
📅 平均実装期間: 8日/PBI
🔄 現在のベロシティ: 1.4タスク/日
📈 完了予測: PBI #124は2024-01-18完了見込み
📝 推奨アクション
🎯 即座に実行可能:
• /task-next 124 --category=models (高優先度)
• /task-next 124 --category=ui (並行可能)
📋 中期計画:
• /task-refine 125 でGroup 3完了
• /task-refine 126 で新規PBI開始
🔧 最適化:
• Models完了後、Services 2タスク並行実行検討
• UI系タスクはModels依存なしで先行実行可能
```
## 使用するコマンド
```bash
# フェーズ別PBI一覧
find tasks -name "pbi-*" -type d | sort
for pbi in tasks/pbi-*; do
phase=$(grep "^phase:" "$pbi/README.md" 2>/dev/null | cut -d' ' -f2)
echo "$pbi: $phase"
done
# リファインメントグループ進捗確認
for pbi in tasks/pbi-*; do
if [ -f "$pbi/.refine-progress.json" ]; then
current_group=$(jq -r '.current_group' "$pbi/.refine-progress.json")
echo "$pbi: Group $current_group/3"
fi
done
# カテゴリ別タスクカウント（全PBI）
for category in setup models services ui tests; do
total=$(find tasks -name "*-$category-*.md" | wc -l)
done=$(find tasks -name "done-$category-*.md" | wc -l)
wip=$(find tasks -name "wip-$category-*.md" | wc -l)
todo=$(find tasks -name "todo-$category-*.md" | wc -l)
echo "$category: $done/$total 完了, $wip実行中, $todo未着手"
done
# 依存関係とブロック状況
for pbi in tasks/pbi-*; do
blocked=0
for todo_file in "$pbi"/todo-*.md; do
if [ -f "$todo_file" ]; then
depends=$(grep "depends_on:" "$todo_file" | cut -d: -f2)
for dep in $depends; do
if [ ! -f "$pbi/done-$dep.md" ]; then
((blocked++))
break
fi
done
fi
done
echo "$(basename $pbi): $blocked タスクがブロック中"
done
# ベロシティと期間計算
total_completed_tasks=$(find tasks -name "done-*.md" | wc -l)
first_task_date=$(find tasks -name "done-*.md" -exec grep "completed:" {} \; | head -1 | cut -d' ' -f2)
current_date=$(date -u +%Y-%m-%dT%H:%M:%SZ)
# 期間計算とベロシティ算出のロジック
# 推定完了日計算
for pbi in tasks/pbi-*; do
remaining_tasks=$(find "$pbi" -name "todo-*.md" -o -name "wip-*.md" | wc -l)
if [ $remaining_tasks -gt 0 ]; then
estimated_days=$((remaining_tasks / velocity))
estimated_completion=$(date -d "+$estimated_days days" +%Y-%m-%d)
echo "$(basename $pbi): 推定完了 $estimated_completion"
fi
done
# フェーズ別統計
grep "^phase:" tasks/pbi-*/README.md | cut -d: -f3 | sort | uniq -c
```
## 状態アイコンの定義
### PBIレベル
- ✅ **完了**: 全タスク完了、フェーズcompleted
- ⏳ **実行中**: wipタスクあり、フェーズcompleted
- 🔄 **進行中**: doneタスクあり、フェーズcompleted
- 📝 **リファインメント中**: Group 1-3実行中
- ⬜ **未着手**: リファインメント未開始
### タスクレベル
- ✅ **完了**: done-{category}-N.md
- ⏳ **実行中**: wip-{category}-N.md
- 🚧 **ブロック中**: todo状態だが依存タスク未完了
- ⬜ **未着手**: todo-{category}-N.md
### カテゴリレベル
- ✅ **完了**: カテゴリ内全タスク完了
- 🔄 **進行中**: 一部タスク完了、一部実行中
- ⏳ **待機中**: 依存関係によりブロック
- ⬜ **未開始**: カテゴリ内全タスクがtodo
## データ集計項目
### PBIレベル集計
- **フェーズ別分布**: completed/in-progress/planning/未開始
- **リファインメント進捗**: Group完了状況 (Group 1-3)
- **実装進捗**: タスク完了率（実装フェーズのPBIのみ）
- **期間統計**: 平均実装期間、リファインメント期間
### カテゴリレベル集計
- **カテゴリ別進捗**: Setup/Models/Services/UI/Tests毎の完了率
- **依存関係**: ブロックされているタスク数、解放待ちタスク数
- **並行度**: 同時実行可能なカテゴリとタスク数
- **ボトルネック**: 進捗阻害要因となっているカテゴリ
### パフォーマンス指標
- **ベロシティ**: タスク完了速度（タスク/日）
- **スループット**: PBI完了速度（PBI/週）
- **サイクルタイム**: リファインメント〜完了までの期間
- **品質指標**: 手戻り発生率、再リファインメント率
### 予測・最適化
- **完了予測**: 残りタスクの推定完了日
- **並行実行提案**: 依存関係を考慮した最適実行順序
- **リソース配分**: カテゴリ別の作業負荷分散提案
- **ボトルネック解消**: 進捗改善のための優先アクション
## エラーハンドリング
- tasksディレクトリが存在しない場合の案内
- PBIディレクトリは存在するがREADME.mdがない場合の警告
- タスクファイルの形式が不正な場合の警告表示
- 引数が無効な場合の使用方法表示
## 推奨アクションの提案
### 即座実行可能アクション
- **高優先度タスク**: 依存関係なし、ブロックなしの重要タスク
- **並行実行**: 異なるカテゴリの独立タスク
- **ボトルネック解消**: 他タスクのブロック要因となっているタスク
### フェーズ別推奨アクション
- **完了済みPBI**: 🎉 完了祝福、新PBI計画提案
- **実装中PBI**: 次タスク実行、並行作業検討
- **リファインメント中PBI**: Group続行、一時停止オプション
- **未開始PBI**: リファインメント開始提案
### 最適化提案
- **スケジュール最適化**: 依存関係を考慮した実行順序調整
- **リソース配分**: カテゴリ間の作業負荷バランス調整
- **並行度向上**: 独立実行可能なタスクの特定と提案
- **品質向上**: リファインメント品質改善、手戻り防止策
### 戦略的提案
- **容量計画**: 新PBI追加のタイミングと優先度
- **技術債務**: リファクタリングタスクの計画的実行
- **スキル開発**: カテゴリ別の習熟度向上計画
- **プロセス改善**: リファインメント効率化、ベロシティ向上
## 完了条件
### 基本表示要件
- フェーズ別PBI分類が適切に表示されている
- カテゴリ別タスク進捗が正確に表示されている
- リファインメントグループ進捗が表示されている
- 依存関係とブロック状況が明確に示されている
### データ精度要件
- 全体進捗率が正確に計算・表示されている
- カテゴリ別進捗率が正確に算出されている
- ベロシティと完了予測が適切に計算されている
- ボトルネック分析が正確に実行されている
### ユーザビリティ要件
- 状態アイコンが統一され理解しやすい
- 重要情報が視覚的に強調されている
- 次のアクションが具体的で実行可能
- フィルター機能が適切に動作している
### 戦略的価値要件
- プロジェクト全体の健全性が把握できる
- 意思決定に必要な情報が提供されている
- 最適化機会が明確に提示されている
- 将来予測が実用的なレベルで提供されている
実行を開始しますか？

245
commands/task-next.md Normal file
View File

@@ -0,0 +1,245 @@
---
description: 次に実行すべきタスクを取得して実行する
argument-hint: [issue_number] [--category=CAT] [--priority=high|medium|low]
allowed-tools: Bash, Read, Write, Edit, MultiEdit, Glob, Grep
---
# 次タスクの選択と実行
指定されたPBI（$1が指定された場合）または全PBIから次に実行すべきタスクを選択し、実行します。
## 実行オプション
```bash
/task-next # 全PBIから最適なタスクを選択
/task-next 123 # PBI #123から次タスクを選択
/task-next 123 --category=setup # 特定カテゴリのタスクを優先
/task-next --priority=high # 高優先度タスクのみ検索
```
## 実行内容
### 1. 次タスクの特定（カテゴリ・優先度考慮）
**PBI指定時（$1が存在）:**
- `tasks/pbi-$1/` ディレクトリ内の `todo-*.md` ファイルを検索
- カテゴリ別ファイル命名規則: `todo-{category}-{number}.md`
- 優先度とカテゴリ依存関係を考慮してタスク選択
**全PBI検索時（引数なし）:**
- `tasks/` 配下のすべての `pbi-*` ディレクトリを検索
- カテゴリ依存関係による実行可能タスクをフィルタリング
- 優先度・作成日時・ブロック状況を総合評価
**カテゴリ依存関係**:
```
Setup → Models → Services → UI → Tests
↓ ↓ ↓ ↓ ↓
基盤 データ層 API層 UI層 品質保証
```
### 2. 詳細タスク情報の表示
選択されたタスクの内容を表示：
```
【次のタスク】
PBI: #<issue_number>
カテゴリ: <category> (Setup/Models/Services/UI/Tests)
優先度: <priority> (High/Medium/Low)
推定時間: <estimated_hours>時間
タスク: <task_title>
ファイル: <task_filename>
=== 前提条件 ===
✅ 完了済み依存タスク: <dependency_tasks>
⚠️ 未完了依存タスク: <blocking_tasks>
=== タスク詳細 ===
<task_content>
=== リファインメント情報 ===
関連する要件: <requirement_trace>
技術仕様: <tech_spec_summary>
```
### 3. 実行確認と開始処理
**依存関係チェック**:
- 前提タスクの完了状況確認
- ブロック状況があれば警告表示
- 実行可能性の判定
**ユーザー確認**:
- 実行確認とブロック解除オプション提示
- 確認後、以下の処理を実行：
1. `todo-{category}-N.md` → `wip-{category}-N.md` にリネーム
2. YAMLフロントマターの `started` フィールドを現在時刻で更新
3. 作業開始をユーザーに通知
### 4. 実装作業のガイド（カテゴリ別）
**Setup系タスク**:
- 環境構築、依存関係インストール
- 設定ファイル作成、初期構造構築
- 他のカテゴリの前提条件を満たす
**Models系タスク**:
- データモデル・スキーマ定義
- データベース migration作成
- ORM/モデルクラス実装
**Services系タスク**:
- ビジネスロジック実装
- API エンドポイント作成
- 外部サービス連携
**UI系タスク**:
- コンポーネント実装
- 画面・フォーム作成
- ユーザーインタラクション
**Tests系タスク**:
- 単体テスト・統合テスト
- E2Eテスト実装
- テストデータ準備
### 5. 完了処理とカテゴリ連携
**状態更新**:
1. `wip-{category}-N.md` → `done-{category}-N.md` にリネーム
2. YAMLフロントマターの `completed` フィールドを現在時刻で更新
3. 親PBIの `README.md` のカテゴリ別タスク一覧を更新
**次タスクの解放**:
- 依存関係チェーンの確認
- ブロックされていたタスクの実行可能化
- 次の実行可能タスクの通知
**GitHub Issue連携**:
- カテゴリ付きタスク完了コメント投稿
- 進捗状況の更新（カテゴリ別進捗含む）
### 6. 進捗状況とカテゴリ分析
**PBI進捗の詳細表示**:
```
【PBI #123 進捗状況】
全体: 3/8 タスク完了 (37.5%)
カテゴリ別進捗:
✅ Setup: 1/1 完了 (100%)
🔄 Models: 1/2 進行中 (50%)
⏳ Services: 0/2 待機中 (Models完了待ち)
⬜ UI: 0/2 未開始
⬜ Tests: 0/1 未開始
次に実行可能:
- Models残り1タスク (高優先度)
```
**全体最適化提案**:
- 並行実行可能タスクの提案
- ボトルネックとなっているカテゴリの特定
- 実装順序の最適化提案
## 利用可能な検索・操作コマンド
```bash
# PBI一覧の取得
find tasks -name "pbi-*" -type d | sort
# カテゴリ別タスク検索
find tasks/pbi-$1 -name "todo-setup-*.md" # Setup系タスク
find tasks/pbi-$1 -name "todo-models-*.md" # Models系タスク
find tasks/pbi-$1 -name "todo-services-*.md" # Services系タスク
find tasks/pbi-$1 -name "todo-ui-*.md" # UI系タスク
find tasks/pbi-$1 -name "todo-tests-*.md" # Tests系タスク
# 優先度別検索
grep "priority: high" tasks/pbi-$1/todo-*.md
grep "priority: medium" tasks/pbi-$1/todo-*.md
# 依存関係確認
grep "depends_on:" tasks/pbi-$1/todo-*.md
# タスクファイルの状態変更（カテゴリ保持）
mv tasks/pbi-$1/todo-setup-1.md tasks/pbi-$1/wip-setup-1.md
mv tasks/pbi-$1/wip-setup-1.md tasks/pbi-$1/done-setup-1.md
# 進捗状況の取得
find tasks/pbi-$1 -name "done-*.md" | wc -l # 完了タスク数
find tasks/pbi-$1 -name "wip-*.md" | wc -l # 実行中タスク数
find tasks/pbi-$1 -name "todo-*.md" | wc -l # 未着手タスク数
# カテゴリ別進捗確認
find tasks/pbi-$1 -name "done-setup-*.md" | wc -l
find tasks/pbi-$1 -name "*-models-*.md" | wc -l
# GitHub Issueへのカテゴリ付きコメント投稿
gh issue comment $1 --body "✅ [Setup] タスク完了: <task_title>"
```
## カテゴリ依存関係の管理
```bash
# 依存関係チェック関数例
check_dependencies() {
local task_file="$1"
local depends_on=$(grep "depends_on:" "$task_file" | cut -d: -f2)
for dep in $depends_on; do
if [ ! -f "tasks/pbi-$1/done-$dep.md" ]; then
echo "❌ 依存タスク未完了: $dep"
return 1
fi
done
return 0
}
# 次実行可能タスクの特定
find_executable_tasks() {
for todo_file in tasks/pbi-$1/todo-*.md; do
if check_dependencies "$todo_file"; then
echo "$todo_file"
fi
done
}
```
## エラーハンドリング
### 基本エラー処理
- 指定されたPBIが存在しない場合の適切なエラー
- 実行可能なタスクが見つからない場合の案内
- GitHub CLI未認証時のエラー処理
- ファイル操作失敗時のロールバック
### カテゴリ特有のエラー処理
- 依存関係未満足時の詳細説明
- カテゴリ間の循環依存検出
- 優先度指定時の該当タスクなしエラー
- 推定時間超過時の警告
### 復旧支援機能
- 中断されたwipタスクの復旧提案
- 依存関係エラー時の解決パス提示
- カテゴリ順序の修正提案
## 完了条件
### 基本完了条件
- 次タスクが正常に特定・表示されている
- カテゴリと優先度が適切に考慮されている
- 依存関係チェックが正常に機能している
### 状態管理の完了条件
- タスク状態が適切に更新されている（todo→wip→done）
- カテゴリ情報がファイル名に保持されている
- 依存関係の解放が正常に実行されている
### 進捗管理の完了条件
- PBI進捗状況が正確に表示されている（カテゴリ別含む）
- GitHub Issueに適切なコメントが投稿されている
- 次の実行可能タスクが適切に提案されている
実行を開始しますか？

286
commands/task-refine.md Normal file
View File

@@ -0,0 +1,286 @@
---
description: GitHub IssueをProduct Backlog Item（PBI）としてリファインメントし、実装可能なタスクに分解する
argument-hint: <issue_number> [--group=N] [--from=groupN] [--edit=groupN]
allowed-tools: Bash, Read, Write, Edit, Glob
---
# GitHub Issue リファインメント・タスク分解
指定されたGitHub Issue #$1 をマイクロステップの対話を通じて、具体的な実装タスクに分解します。
## 実行モード
### 基本実行
```bash
/task-refine 123 # 全グループを順次実行
/task-refine 123 --group=1 # Group 1のみ実行
/task-refine 123 --from=group2 # Group 2から再開
/task-refine 123 --edit=group1 # Group 1のみ修正
```
## 3段階グループ構成
### Group 1: 要件・制約の確定 (5-8分)
**目的**: 何を作るかを明確化
**ステップ構成**:
- Step 1: 認証・処理方式の選択
- Step 2: 機能範囲の決定
- Step 3: セキュリティレベルの設定
- Step 4: 非機能要件の確認
**出力**: 機能要件と制約の確定
### Group 2: 技術・アーキテクチャ設計 (8-12分)
**目的**: どう実装するかを技術的に決定
**ステップ構成**:
- Step 5: 技術スタックの選択
- Step 6: データ設計・モデル構造
- Step 7: API設計・インターフェース
- Step 8: UI/UX設計方針
**前提条件**: Group 1の完了が必要
**出力**: 技術仕様と設計方針の確定
### Group 3: 実装・タスク構成 (5-8分)
**目的**: 具体的な作業手順に分解
**ステップ構成**:
- Step 9: タスク分解粒度の決定
- Step 10: 実装優先順位の設定
- Step 11: 依存関係の整理
- Step 12: 最終タスクリストの確認
**前提条件**: Group 1, 2の完了が必要
**出力**: 実装可能なタスクリスト
## 実行フロー
### 1. Issue分析と進行状況確認
```bash
# GitHub CLI でIssue情報取得
gh issue view $1 --json title,body,url
# 既存の進行状況確認
if [ -f "tasks/pbi-$1/.refine-progress.json" ]; then
# 前回の続きから再開オプション表示
fi
```
### 2. グループ別実行制御
#### Group 1実行例:
```
=== Group 1: 要件・制約の確定 ===
Progress: ▓▓▓░░░░░░░ (3/10 steps)
Step 1/4: 認証・処理方式
GitHub Issue #$1から検出キーワード: [動的表示]
Q: 主要な処理方式を選択してください
1. 認証系 (ログイン、権限管理)
2. データ処理系 (CRUD、検索、集計)
3. UI/UX系 (画面、コンポーネント)
4. 統合系 (API連携、外部サービス)
5. その他
選択: 1
Step 2/4: 機能範囲
認証系機能として、実装する機能を選択してください (複数選択可):
1. ユーザーログイン
2. ユーザー登録
3. パスワードリセット
4. 権限・ロール管理
5. プロフィール管理
6. セッション管理
選択: 1,2,3
Step 3/4: セキュリティレベル
選択した機能 (ログイン、登録、リセット) に対するセキュリティレベル:
1. 基本 (パスワード暗号化、基本バリデーション)
2. 強化 (2FA、IP制限、監査ログ)
3. 最小限 (暗号化のみ)
選択: 1
Step 4/4: 非機能要件
Q: 想定される利用規模は？
1. 小規模 (~100ユーザー)
2. 中規模 (~1,000ユーザー)
3. 大規模 (1,000ユーザー+)
選択: 2
✅ Group 1完了: 要件・制約が確定
【確定内容】
- 処理分野: 認証系
- 機能: ログイン、登録、パスワードリセット
- セキュリティ: 基本レベル
- 規模: 中規模対応
次のアクション:
1. Group 2に進む (技術・アーキテクチャ設計)
2. 後で続行 (進捗保存)
3. Group 1を修正
選択: 1
```
### 3. 進捗管理と状態保存
**.refine-progress.json 形式**:
```json
{
"issue": "$1",
"started": "2024-01-01T10:00:00Z",
"current_group": 2,
"completed_groups": [
{
"group": 1,
"completed_at": "2024-01-01T10:08:00Z",
"decisions": {
"processing_type": "authentication",
"features": ["login", "registration", "password_reset"],
"security_level": "basic",
"scale": "medium"
}
}
],
"current_step": 6,
"session_data": {
"tech_stack_proposal": "node_express",
"database_preference": "postgresql"
}
}
```
### 4. 最終ファイル生成
#### 拡張されたREADME.md形式:
```yaml
---
issue: $1
title: <issue_title>
url: <github_url>
phase: completed
refinement_completed: <ISO8601>
created: <ISO8601>
updated: <ISO8601>
---
# PBI #$1
## リファインメント履歴
### Group 1: 要件・制約確定 ✅
- 処理分野: 認証系
- 機能範囲: ログイン、登録、パスワードリセット
- セキュリティ: 基本レベル (暗号化、バリデーション)
- 規模: 中規模対応 (~1,000ユーザー)
### Group 2: 技術・アーキテクチャ設計 ✅
- バックエンド: Node.js + Express + PostgreSQL
- フロントエンド: React + TypeScript (既存環境)
- 認証方式: JWT (24時間有効期限)
- API: RESTful 4エンドポイント
### Group 3: 実装・タスク構成 ✅
- タスク数: 8個
- カテゴリ: Setup(1), Models(2), Services(2), UI(2), Tests(1)
- 実装期間: 5-8日 (1日1-2タスク想定)
## タスク一覧 (カテゴリ別)
### Setup
- [ ] プロジェクト環境構築 (todo-setup-1.md)
### Models
- [ ] User model実装 (todo-models-1.md)
- [ ] 認証関連テーブル設計 (todo-models-2.md)
### Services
- [ ] 認証API実装 (todo-services-1.md)
- [ ] パスワードリセット機能 (todo-services-2.md)
### UI
- [ ] ログインフォーム実装 (todo-ui-1.md)
- [ ] 登録フォーム実装 (todo-ui-2.md)
### Tests
- [ ] 認証機能テスト (todo-tests-1.md)
## 要件トレーサビリティ
- ログイン機能 → setup-1, models-1, services-1, ui-1, tests-1
- 登録機能 → models-1, services-1, ui-2, tests-1
- リセット機能 → models-2, services-2, tests-1
```
#### カテゴリ別タスクファイル形式:
```yaml
---
parent: $1
category: setup
priority: high
estimated_hours: 4
created: <ISO8601>
started: null
completed: null
---
# プロジェクト環境構築
## やること
Node.js + Express + PostgreSQL の認証プロジェクト環境を構築する
## 成功条件
- [ ] package.json作成 (express, jwt, bcrypt, pg依存関係)
- [ ] PostgreSQL接続設定完了
- [ ] 基本的なサーバー起動確認
- [ ] 環境変数設定 (.env.example作成)
## 技術仕様
- Node.js: v18+
- Express: v4.x
- PostgreSQL: v14+
- JWT: jsonwebtoken
- 暗号化: bcrypt
## 制約
- 環境変数でDB接続情報管理
- セキュリティ設定は本番想定
- 既存Reactプロジェクトとの統合考慮
## 実装メモ
（作業中に追記）
```
## エラーハンドリング
### 実行前チェック
- GitHub CLI認証状態確認
- Issue存在確認
- tasksディレクトリアクセス権確認
### 進行中のエラー処理
- 不正な選択肢入力時の再プロンプト
- ネットワークエラー時の状態保存
- 強制終了時の進捗復旧
### グループ間整合性チェック
- Group 2開始時にGroup 1決定事項の参照
- Group 3開始時にGroup 1, 2決定事項の参照
- 矛盾検出時の修正提案
## 完了条件
- 全3グループが正常完了している
- `tasks/pbi-$1/README.md` にリファインメント履歴が記録されている
- カテゴリ別のタスクファイルが適切に生成されている
- 各タスクが実装可能なレベルまで詳細化されている
- 要件トレーサビリティが確立されている
実行を開始しますか？

475
commands/task-spec.md Normal file
View File

@@ -0,0 +1,475 @@
---
description: プロンプトベースで対話的に仕様を策定し、TDD前提のタスクに分解する（ネガティブチェック・認知バイアス除去含む）
argument-hint: "<要望内容>" [--id=custom-id]
allowed-tools: Bash, Read, Write, Edit, Glob, AskUserQuestion
---
# プロンプトベース仕様策定・タスク分解
プロンプトで記述された要望を、対話を通じて**網羅的な仕様**（正常系・異常系・エッジケース）に昇華し、TDD前提の実装タスクに分解します。
## 実行モード
```bash
/task-spec "ユーザー認証機能を実装したい"
/task-spec "データ検索APIを作りたい" --id=search-api
```
## 実行フロー
### Phase 1: 網羅的仕様策定（20-30分）
#### Step 1: 要望分析
```bash
# ユーザープロンプト解析
- キーワード抽出（認証、API、UI、データ処理など）
- 既存コードベースとの関連確認
- 初期スコープ推定
```
#### Step 2: ポジティブ仕様の明確化（5-8分）
対話形式で以下を確定：
```
=== Step 2: ポジティブ仕様の明確化 ===
Q1: 入力は何ですか？
（例: ユーザーID、メールアドレス、JSONペイロード）
Q2: 期待される出力は何ですか？
（例: 認証トークン、ユーザー情報、HTTPステータス）
Q3: 成功の条件を具体的に教えてください
（例: 「有効な認証情報で200 + JWT返却」）
Q4: 制約や前提条件はありますか？
（例: PostgreSQL使用、既存API互換性必須）
```
#### Step 3: ネガティブチェック（認知バイアス除去）（10-15分）
##### 3-1. 失敗シナリオ分析
```
=== Step 3-1: 失敗シナリオ分析 ===
Progress: ▓▓▓▓░░░░░░ (4/10)
確証バイアスを排除するため、「どこで壊れるか」を先に考えます。
Q: この機能が失敗する可能性があるケースを選択してください（複数選択可）
1. 入力が不正（型違い、範囲外、フォーマット不正）
2. 依存リソースが存在しない（ファイル、DB、API）
3. 権限不足・認証失敗
4. タイムアウト・ネットワークエラー
5. リソース枯渇（メモリ、ディスク、CPU）
6. 並行実行による競合
7. その他（自由記述）
選択: 1,2,3
→ 選択された各ケースについて詳細を質問
```
##### 3-2. エッジケース網羅
```
=== Step 3-2: エッジケース網羅 ===
正常系偏重を避けるため、境界値での振る舞いを確認します。
以下のケースで期待される動作を確認してください（該当するものにチェック）:
□ 空文字列 / 空配列 / 空オブジェクト
→ どう処理すべきですか？ (1. エラー / 2. デフォルト値 / 3. そのまま通す)
□ null / undefined / NaN
→ どう処理すべきですか？ (1. エラー / 2. 無視 / 3. デフォルト値)
□ 最小値・最大値（数値、文字数、配列長）
→ 境界値は？ (例: 0-255文字、1-100件)
□ 0, -1, Infinity
→ 許可しますか？ 許可する場合の意味は？
□ 特殊文字（<>"'&;など）
→ エスケープ必要？ どのレベルで？
□ 非ASCII文字（絵文字、全角、Unicode）
→ サポートしますか？ 制限は？
□ 巨大なデータ（1MB超の文字列、10万件の配列）
→ 制限値は？ 超えた場合の処理は？
```
##### 3-3. セキュリティリスク分析
```
=== Step 3-3: セキュリティリスク分析 ===
楽観バイアスを排除し、攻撃シナリオを想定します。
該当する脅威を選択してください（複数選択可）:
1. XSS（クロスサイトスクリプティング）
- ユーザー入力を画面表示する箇所がある
2. SQLインジェクション
- SQL文を動的生成している
3. CSRF（クロスサイトリクエストフォージェリ）
- 状態変更操作（POST/PUT/DELETE）がある
4. 権限昇格
- 他ユーザーのデータにアクセスする可能性
5. DoS（サービス拒否）
- 大量リクエストで停止する可能性
6. 情報漏洩
- エラーメッセージに秘密情報が含まれる可能性
選択: 1,3,4
→ 各脅威に対する対策を質問
```
##### 3-4. 認知バイアスチェック
```
=== Step 3-4: 認知バイアスチェック ===
以下のバイアスを意識的に排除したか確認します:
✓ 確証バイアス
「うまくいくはず」ではなく「どこで壊れるか」を先に考えた
✓ 正常系偏重
正常系:異常系 = 1:3 の比率でテストケースを設計した
✓ 楽観バイアス
「たぶん大丈夫」を「証明されるまで信用しない」に変換した
✓ 可用性バイアス
「よくあるケース」だけでなく「レアだが致命的なケース」も網羅した
全てチェック完了後、次へ進みます。
```
#### Step 4: 失敗するテスト生成（5分）
```
=== Step 4: 失敗するテスト生成 ===
確定した仕様から、Red状態のテストコードを自動生成します。
テスト比率:
- 正常系テスト（20%）: 2件
- 異常系テスト（50%）: 5件
- エッジケーステスト（30%）: 3件
合計: 10件のテストケース
生成されたテストは tasks/pbi-{id}/tests/ に保存されます。
```
### Phase 2: タスク分解（既存Group 1-3 + ネガティブレビュー）
#### Group 1: 要件・制約の確定（5-8分）
- 処理方式の選択
- 機能範囲の決定
- セキュリティレベルの設定
- 非機能要件の確認
#### **Group 1.5: ネガティブケース・レビュー（5分）**
```
=== Group 1.5: ネガティブケース・レビュー ===
Phase 1で抽出したネガティブケースを確認します:
【失敗シナリオ】
1. 入力不正（空文字列、型違い） - Priority: High
2. DB接続失敗 - Priority: Critical
3. 権限不足 - Priority: High
【エッジケース】
1. 最大長超過（255文字） - Priority: Medium
2. 特殊文字（XSSペイロード） - Priority: Critical
3. 並行実行 - Priority: Low
Q: 追加で考慮すべき失敗シナリオはありますか？
（あれば記述、なければEnter）
→ ユーザー入力を反映してspecs.mdを更新
```
#### Group 2: 技術・アーキテクチャ設計（8-12分）
- 技術スタックの選択
- データ設計・モデル構造
- API設計・インターフェース
- UI/UX設計方針
#### Group 3: 実装・タスク構成（5-8分）
- タスク分解粒度の決定（ネガティブケース考慮）
- 実装優先順位の設定
- 依存関係の整理
- 最終タスクリストの確認
## 生成されるファイル構造
```
tasks/pbi-{timestamp or custom-id}/
├── specs.md # 網羅的仕様書（正常系+異常系+エッジケース）
├── tests/
│ ├── spec-test-positive-1.md # 正常系テスト（Red状態）
│ ├── spec-test-negative-1.md # 異常系テスト（Red状態）
│ ├── spec-test-edge-1.md # エッジケーステスト（Red状態）
│ └── tdd-log.md # Red→Green遷移記録
├── README.md # リファインメント履歴・タスク一覧
├── todo-{category}-N.md # 実装タスク（ネガティブケース含む）
└── .refine-progress.json # 進捗管理
```
### specs.md フォーマット
```markdown
---
created: 2024-01-01T10:00:00Z
updated: 2024-01-01T10:30:00Z
status: confirmed
coverage_score: 85 # ネガティブチェック網羅率
---
# 仕様: ユーザー認証機能
## 要望（オリジナルプロンプト）
ユーザー認証機能を実装したい
## 確定した仕様
### 機能概要
メールアドレスとパスワードでユーザー認証を行い、JWTトークンを返却する
### 入力
- email: string（必須、メール形式、最大255文字）
- password: string（必須、最小8文字、最大128文字）
### 出力
- 成功時: 200 OK + { token: string, userId: string }
- 失敗時: 適切なHTTPステータス + エラーメッセージ
### 制約
- JWT有効期限: 24時間
- パスワードハッシュ: bcrypt
- データベース: PostgreSQL
### 成功条件（正常系）
- [ ] 有効な認証情報で200 + JWT返却
- [ ] トークンでユーザー情報取得可能
## ネガティブケース分析
### 失敗シナリオ
#### 入力不正
- [ ] 空文字列のemail → 400 + "email is required"
- [ ] 無効なメール形式 → 400 + "invalid email format"
- [ ] パスワード7文字 → 400 + "password must be at least 8 characters"
- [ ] 型違い（数値） → 400 + "email must be a string"
#### 依存リソース欠如
- [ ] DB接続失敗 → 503 + "service temporarily unavailable" + リトライ
- [ ] DBクエリタイムアウト → 504 + "gateway timeout"
#### 権限・認証
- [ ] 存在しないユーザー → 401 + "invalid credentials"
- [ ] パスワード不一致 → 401 + "invalid credentials"
- [ ] アカウント無効化済み → 403 + "account disabled"
- [ ] ログイン試行回数超過 → 429 + "too many attempts"
#### 並行実行
- [ ] 同一ユーザーの多重ログイン → 許可（トークン複数発行）
### エッジケース
| ケース | 入力例 | 期待される振る舞い |
|--------|--------|-------------------|
| 空文字列 | `email=""` | 400 + ValidationError |
| null | `email=null` | 400 + ValidationError |
| 最大長 | 256文字のemail | 400 + "email too long" |
| 最大長境界 | 255文字のemail | 正常処理 |
| 特殊文字 | `email="<script>"` | エスケープ処理 + 通常検証 |
| 絵文字 | `password="👍pass"` | 正常処理（UTF-8対応） |
| SQL注入試行 | `email="' OR '1'='1"` | プレースホルダーで無害化 |
### セキュリティ考慮事項
- [ ] パスワードは平文ログ出力禁止
- [ ] エラーメッセージで存在ユーザーを推測不可（401で統一）
- [ ] ブルートフォース対策: 5回失敗で15分ロック
- [ ] HTTPS必須（平文通信禁止）
- [ ] CSRF対策: 状態変更なしのため不要
- [ ] レート制限: 1IP 10req/min
### 想定される失敗モード（FMEA的分析）
| 失敗モード | 発生頻度 | 影響度 | 検出容易性 | 対策 |
|-----------|---------|--------|-----------|------|
| DB接続断 | 低 | 高 | 容易 | コネクションプール + リトライ |
| パスワード平文ログ出力 | 低 | 致命的 | 困難 | ログフィルター + コードレビュー |
| ブルートフォース | 高 | 中 | 容易 | レート制限 + アカウントロック |
| タイミング攻撃 | 低 | 中 | 困難 | 固定時間比較 |
## 対話履歴
### Q1: 入力は何ですか？
A: メールアドレスとパスワード
### Q2: 失敗シナリオ - 入力不正
Q: 空文字列が渡された場合の振る舞いは？
A: 400 BadRequestでValidationErrorを返す
### Q3: エッジケース - 最大長
Q: メールアドレスの最大長は？
A: 255文字。超過時は400エラー
### Q4: セキュリティ - ブルートフォース
Q: 連続失敗時の対策は？
A: 5回失敗で15分間アカウントロック
## テスト戦略
### 正常系テスト（20%）
- test_001: 有効な認証情報で200 + JWT
- test_002: トークンでユーザー情報取得成功
### 異常系テスト（50%）
- test_101: 空文字列emailで400
- test_102: 無効なメール形式で400
- test_103: 短いパスワードで400
- test_104: 存在しないユーザーで401
- test_105: パスワード不一致で401
- test_106: DB接続失敗で503
- test_107: ログイン試行超過で429
### エッジケーステスト（30%）
- test_201: 最大長境界値（255文字）
- test_202: 最大長超過（256文字）
- test_203: XSSペイロード試行
- test_204: SQL注入試行
- test_205: パスワードにUnicode文字
### カバレッジ目標
- 行カバレッジ: 90%以上
- 分岐カバレッジ: 85%以上
- 異常系カバレッジ: 100%
```
### todo-{category}-N.md フォーマット（拡張版）
```markdown
---
parent: auth-feature
category: services
priority: high
estimated_hours: 6
negative_cases: 7 # このタスクがカバーすべき異常系の数
edge_cases: 5 # エッジケースの数
test_ratio: "2:7:5" # 正常:異常:エッジ
---
# ユーザー認証API実装
## やること
specs.mdに基づき、ユーザー認証エンドポイントを実装
## 成功条件（正常系）
- [ ] POST /api/auth/login で200 + JWT返却
- [ ] 有効なトークンでユーザー情報取得可能
## 失敗条件（異常系）
- [ ] 空email → 400 + ValidationError
- [ ] 無効なメール形式 → 400 + validation message
- [ ] パスワード7文字 → 400 + length requirement
- [ ] 存在しないユーザー → 401 + generic message
- [ ] パスワード不一致 → 401 + generic message
- [ ] DB接続失敗 → 503 + retry logic
- [ ] ログイン試行5回超過 → 429 + lockout period
## エッジケース
- [ ] メール255文字（境界値） → 正常処理
- [ ] メール256文字 → 400 error
- [ ] XSSペイロード → エスケープして検証
- [ ] SQL注入試行 → prepared statementで無害化
- [ ] Unicode文字パスワード → 正常処理
## 技術仕様
- パスワードハッシュ: bcrypt（salt rounds: 10）
- JWT署名: HS256 + 環境変数シークレット
- DB: prepared statement必須
- エラーログ: パスワード除外
## 制約
- specs.md#セキュリティ考慮事項 を全て遵守
- 認証失敗はタイミング攻撃対策で固定時間応答
- エラーメッセージでユーザー存在を推測不可
## 実装メモ
（TDD Red→Green→Refactorサイクルを記録）
```
## 実行後の出力
```
✅ 仕様策定完了
【生成ファイル】
- tasks/pbi-auth-feature/specs.md
- tasks/pbi-auth-feature/tests/spec-test-positive-1.md
- tasks/pbi-auth-feature/tests/spec-test-negative-1.md
- tasks/pbi-auth-feature/tests/spec-test-negative-2.md
- tasks/pbi-auth-feature/tests/spec-test-negative-3.md
- tasks/pbi-auth-feature/tests/spec-test-negative-4.md
- tasks/pbi-auth-feature/tests/spec-test-negative-5.md
- tasks/pbi-auth-feature/tests/spec-test-edge-1.md
- tasks/pbi-auth-feature/tests/spec-test-edge-2.md
- tasks/pbi-auth-feature/tests/spec-test-edge-3.md
- tasks/pbi-auth-feature/README.md
【ネガティブチェック網羅率】
- 失敗シナリオ: 7件
- エッジケース: 5件
- セキュリティ: 6項目
- カバレッジスコア: 85/100
【タスク数】
- Setup: 1タスク
- Models: 1タスク
- Services: 1タスク（正常2 + 異常7 + エッジ5 = 14テストケース）
- UI: 1タスク
- Tests: 1タスク
次のステップ:
1. /task-next で最初のタスクを実行
2. /task-status auth-feature で進捗確認
```
## エラーハンドリング
### 実行前チェック
- tasksディレクトリの存在確認
- プロンプトの最小文字数確認（10文字以上）
- カスタムIDの重複チェック
### 進行中のエラー処理
- 不正な選択肢入力時の再プロンプト
- ネットワークエラー時の状態保存
- 強制終了時の進捗復旧（.refine-progress.json）
## 完了条件
- Phase 1, 2の全ステップが正常完了
- specs.mdにネガティブケース分析が記録されている
- テストファイルが正常系:異常系:エッジ = 2:5:3の比率で生成されている
- 各タスクに異常系・エッジケースが割り当てられている
- カバレッジスコアが80以上

247
commands/task-status.md Normal file
View File

@@ -0,0 +1,247 @@
---
description: タスクの進捗状況を表示する（カテゴリ・グループ情報含む）
argument-hint: [issue_number] [--detail] [--category=CAT]
allowed-tools: Bash, Read, Glob
---
# タスク進捗状況の確認
指定されたPBI（$1が指定された場合）または全PBIのタスク進捗状況を、リファインメントグループとカテゴリ別に表示します。
## 表示オプション
```bash
/task-status # 全PBI概要表示
/task-status 123 # PBI #123詳細表示
/task-status 123 --detail # 詳細表示（グループ履歴含む）
/task-status --category=setup # Setup系タスクのみ表示
```
## 実行内容
### 1. PBI指定時の詳細表示（$1が存在）
**基本情報の表示:**
```
【PBI #$1】<title>
URL: <github_url>
作成日: <created>
更新日: <updated>
フェーズ: <phase> (completed/in-progress/planning)
全体進捗: <done>/<total> タスク完了 (<percentage>%)
```
**リファインメントグループ履歴** (--detail指定時):
```
=== リファインメント履歴 ===
✅ Group 1: 要件・制約確定 (2024-01-01 10:08)
- 処理分野: 認証系
- 機能範囲: ログイン、登録、パスワードリセット
- セキュリティ: 基本レベル
- 規模: 中規模対応
✅ Group 2: 技術・アーキテクチャ設計 (2024-01-01 10:20)
- バックエンド: Node.js + Express + PostgreSQL
- フロントエンド: React + TypeScript
- 認証方式: JWT (24時間有効期限)
- API: RESTful 4エンドポイント
✅ Group 3: 実装・タスク構成 (2024-01-01 10:28)
- タスク数: 8個
- カテゴリ: Setup(1), Models(2), Services(2), UI(2), Tests(1)
- 実装期間: 5-8日想定
```
**カテゴリ別進捗:**
```
=== カテゴリ別進捗 ===
✅ Setup: 1/1 完了 (100%)
└── ✅ プロジェクト環境構築 (done-setup-1.md)
🔄 Models: 1/2 進行中 (50%)
├── ✅ User model実装 (done-models-1.md)
└── ⏳ 認証関連テーブル設計 (wip-models-2.md) - 開始: 10:45
⏳ Services: 0/2 待機中 (0%) - Models完了待ち
├── ⬜ 認証API実装 (todo-services-1.md)
└── ⬜ パスワードリセット機能 (todo-services-2.md)
⬜ UI: 0/2 未開始 (0%)
├── ⬜ ログインフォーム実装 (todo-ui-1.md)
└── ⬜ 登録フォーム実装 (todo-ui-2.md)
⬜ Tests: 0/1 未開始 (0%)
└── ⬜ 認証機能テスト (todo-tests-1.md)
```
**推奨アクション:**
- 実行可能タスク: Models残り1タスク (高優先度)
- ブロック解除: Models完了後にServices 2タスクが実行可能
- 並行作業: UI系タスクは独立して実行可能
- 全完了時: 🎉 PBI完了祝福メッセージ
### 2. 全PBI一覧表示（引数なし）
**PBI別サマリー（カテゴリ・グループ情報含む）:**
```
=== PBI 一覧 ===
✅ PBI #123: ユーザー認証機能
📊 進捗: 8/8 (100%) | フェーズ: 完了
📋 カテゴリ: Setup(✅), Models(✅), Services(✅), UI(✅), Tests(✅)
🕒 期間: 2024-01-01 ~ 2024-01-08 (8日)
🔗 URL: https://github.com/org/repo/issues/123
⏳ PBI #124: 商品管理機能
📊 進捗: 3/10 (30%) | フェーズ: 実装中
📋 カテゴリ: Setup(✅), Models(🔄), Services(⏳), UI(⬜), Tests(⬜)
🚧 ブロック: 2タスク (Models完了待ち)
🔗 URL: https://github.com/org/repo/issues/124
📋 PBI #125: 決済システム
📊 進捗: 0/6 (0%) | フェーズ: リファインメント中
📋 グループ: Group 2実行中 (技術・アーキテクチャ設計)
🔗 URL: https://github.com/org/repo/issues/125
⬜ PBI #126: レポート機能
📊 進捗: 0/0 (0%) | フェーズ: 未開始
📋 ステータス: Issue作成済み、リファインメント待ち
🔗 URL: https://github.com/org/repo/issues/126
```
**全体サマリー（カテゴリ・フェーズ別）:**
```
=== 全体サマリー ===
📊 PBI進捗: 1/4 完了 (25%)
📋 タスク進捗: 11/24 完了 (45.8%)
⏳ 実行中: 2タスク、1リファインメント
📈 フェーズ別状況:
✅ 完了: 1 PBI
🔄 実装中: 1 PBI
📋 リファインメント中: 1 PBI
⬜ 未開始: 1 PBI
📂 カテゴリ別進捗:
✅ Setup: 3/3 完了 (100%)
🔄 Models: 4/6 進行中 (66.7%)
⏳ Services: 2/8 開始可能 (25%)
⬜ UI: 1/6 待機中 (16.7%)
⬜ Tests: 1/1 未開始 (0%)
🎯 次の実行可能アクション:
💡 PBI #124: Models残り2タスク
📋 PBI #125: Group 3 (タスク構成) 実行可能
➕ PBI #126: Group 1 (要件確定) から開始
```
### 3. 状況に応じた案内表示
**進捗状況別のメッセージ:**
- 全完了: 🎉 すべてのタスクが完了しています！
- 実行中あり: 💡 `/task-next` で次のタスクを実行できます
- 未着手のみ: 💡 `/task-next` で次のタスクを開始できます
## 使用するコマンド
```bash
# PBI一覧の取得
find tasks -name "pbi-*" -type d | sort
# リファインメント進捗の確認
grep "^phase:" tasks/pbi-$1/README.md
ls tasks/pbi-$1/.refine-progress.json 2>/dev/null
# カテゴリ別タスクカウント
find tasks/pbi-$1 -name "todo-setup-*.md" | wc -l
find tasks/pbi-$1 -name "wip-models-*.md" | wc -l
find tasks/pbi-$1 -name "done-services-*.md" | wc -l
find tasks/pbi-$1 -name "*-ui-*.md" | wc -l
find tasks/pbi-$1 -name "*-tests-*.md" | wc -l
# 全体のカテゴリ別集計
for cat in setup models services ui tests; do
echo "$cat: $(find tasks -name "*-$cat-*.md" | wc -l)"
done
# 優先度・依存関係情報
grep "priority:" tasks/pbi-$1/todo-*.md
grep "depends_on:" tasks/pbi-$1/todo-*.md
grep "estimated_hours:" tasks/pbi-$1/todo-*.md
# リファインメントグループ履歴
if [ -f "tasks/pbi-$1/README.md" ]; then
sed -n '/## リファインメント履歴/,/## タスク一覧/p' tasks/pbi-$1/README.md
fi
# 実行可能タスクの特定
for todo_file in tasks/pbi-$1/todo-*.md; do
# 依存関係チェック後、実行可能なタスクを特定
depends=$(grep "depends_on:" "$todo_file" | cut -d: -f2)
# 依存タスクがすべて完了している場合のみ表示
done
# フェーズ別PBI集計
grep "^phase:" tasks/pbi-*/README.md | sort | uniq -c
```
## ファイル構造の想定
```
tasks/
├── pbi-123/
│ ├── .refine-progress.json # リファインメント進捗（Group状態）
│ ├── README.md # PBI概要、グループ履歴、カテゴリ別タスク
│ ├── done-setup-1.md # 完了タスク（カテゴリ別）
│ ├── wip-models-2.md # 実行中タスク
│ ├── todo-services-1.md # 未着手タスク
│ ├── todo-services-2.md
│ ├── todo-ui-1.md
│ ├── todo-ui-2.md
│ └── todo-tests-1.md
├── pbi-124/
│ ├── .refine-progress.json # Group 2で中断中
│ └── README.md # 部分的なリファインメント情報
└── pbi-125/
└── (リファインメント未実行)
```
**リファインメント状態の分類:**
- `phase: completed` - 全グループ完了、タスク実装中
- `phase: in-progress` - グループ途中で中断
- `phase: planning` - リファインメント未開始
- `.refine-progress.json` - グループ進捗と決定履歴
## エラーハンドリング
- 指定されたPBIが存在しない場合の適切なエラー
- README.mdが見つからない場合の警告
- tasksディレクトリが存在しない場合の案内
- タスクファイルの形式が不正な場合の警告
## 表示される進捗指標
### PBI・フェーズレベル
1. **PBI進捗**: 完了PBI数/全PBI数
2. **フェーズ分布**: 完了/実装中/リファインメント中/未開始
3. **リファインメント品質**: Group完了度、決定事項の詳細度
### タスク・カテゴリレベル
4. **タスク進捗**: 完了タスク数/全タスク数（カテゴリ別）
5. **カテゴリバランス**: Setup→Models→Services→UI→Tests の進行状況
6. **依存関係状況**: ブロックされているタスク数、実行可能タスク数
### アクティビティレベル
7. **実行中作業**: 現在のwipタスク数、推定残り時間
8. **ボトルネック**: 進捗を阻害しているカテゴリ・依存関係
9. **最適化提案**: 並行実行可能タスク、優先度調整の提案
## 完了条件
- 指定されたPBIまたは全PBIの状況が正確に表示されている
- 進捗率が正しく計算されている
- 次のアクションが適切に提案されている
- エラー時も適切なガイダンスが表示されている
実行を開始しますか？

410
commands/task-sync.md Normal file
View File

@@ -0,0 +1,410 @@
---
description: GitHub Issueの最新情報を同期してタスクとの整合性を確認する（リファインメントグループ・カテゴリ考慮）
argument-hint: <issue_number> [--force-rerefine] [--preserve-completed]
allowed-tools: Bash, Read, Write, Edit, Glob
---
# GitHub Issue 同期
指定されたGitHub Issue #$1 の最新情報をローカルのPBIデータと同期し、リファインメントグループとカテゴリ構造を考慮した再構成を提案します。
## 同期オプション
```bash
/task-sync 123 # 標準同期（変更検知時のみ更新）
/task-sync 123 --force-rerefine # 強制的にリファインメント再実行
/task-sync 123 --preserve-completed # 完了タスクは保護して同期
```
## 実行内容
### 1. 多層同期状況確認
**ローカル情報の取得:**
- `tasks/pbi-$1/README.md` からローカルの最終更新日時を取得
- リファインメント完了フェーズ（phase）の確認
- `.refine-progress.json` からグループ進捗の確認
- カテゴリ別タスク状況の把握
**リモート情報の取得:**
```bash
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の段階的更新:**
```yaml
---
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: 安全な部分更新（推奨）**
```bash
/task-sync 123 --preserve-completed
実行内容:
1. 完了タスク (done-*.md) は保護
2. 実行中タスク (wip-*.md) は todo に戻して保留
3. 未着手タスク (todo-*.md) のみ削除・再生成
4. README.md の履歴に同期ログ追加
5. Group 2 から段階的リファインメント実行
```
**Option B: 強制的な完全リファインメント**
```bash
/task-sync 123 --force-rerefine
⚠️ 危険: 全ての進行中作業が失われます
実行内容:
1. .refine-progress.json をリセット
2. 全タスクファイル削除（backup作成後）
3. Group 1 から完全リファインメント実行
4. 新しいカテゴリ構造で再構築
```
**手動調整オプション**
```bash
段階的手動調整:
1. 特定カテゴリのみ更新
find tasks/pbi-$1 -name "todo-services-*.md" -delete
# サービス系タスクのみ手動再作成
2. 実行中タスクの内容更新
# wip-models-2.md の要件を新仕様に合わせて編集
# 実装メモに移行作業を記録
3. 依存関係の再調整
# カテゴリ間依存関係を新要件に合わせて更新
# タスクファイルの depends_on フィールド修正
```
**安全対策とバックアップ**
```bash
# 実行前の自動バックアップ
cp -r tasks/pbi-$1 tasks/pbi-$1.backup.$(date +%Y%m%d_%H%M%S)
# 段階的実行での中断ポイント
# Group 2 完了後、Group 3 実行前にユーザー確認
# カテゴリ別タスク生成後、依存関係確認でユーザー確認
# ロールバック機能
# 問題が発生した場合、前回の同期状態に戻すオプション
```
## 使用するコマンド
```bash
# 多層情報取得
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"
```
## 同期判定ロジック
**変更検知の条件:**
1. **タイトル変更**: ローカルタイトル ≠ Issue タイトル
2. **内容更新**: Issue updatedAt > ローカル updated
3. **URL変更**: ローカルURL ≠ Issue URL
**同期の必要性:**
- いずれかの変更が検知された場合
- ユーザーが明示的に同期を要求した場合
## 再構成時の安全対策
**実行中タスクの保護:**
- wipタスクがある場合は慎重な操作を促す
- 破壊的変更前の確認プロンプト
**完了タスクの保護:**
- doneタスクは原則として変更しない
- 履歴として保持
**バックアップの推奨:**
- 重要な変更前のディレクトリバックアップ提案
## エラーハンドリング
- GitHub CLI未認証時のエラー
- 指定されたIssueが存在しない場合
- PBIディレクトリが存在しない場合
- ネットワーク接続エラー時の対応
## 完了条件
### 基本同期要件
- Issue情報が正常に取得されている
- ローカル情報が最新の内容で更新されている
- 変更内容が適切に分析・表示されている
- 同期履歴が記録されている
### リファインメント整合性要件
- Group 1-3 の決定事項と新Issue内容の整合性が評価されている
- 影響を受けるグループが特定されている
- 必要な再リファインメント範囲が明確になっている
### カテゴリ・タスク整合性要件
- カテゴリ別の影響度が正確に評価されている
- 依存関係の変更が適切に分析されている
- 実行中タスクへの影響とリスクが明示されている
- 完了タスクの保護策が実施されている
### 再構成提案要件
- 複数の再構成戦略が提示されている
- 推奨戦略の根拠が明確に示されている
- 実行プランが具体的で実行可能
- 安全対策とロールバック手順が提供されている
### ユーザー支援要件
- 次のアクションが明確で実行可能
- リスクと期待効果が適切に説明されている
- 段階的実行でのチェックポイントが設定されている
実行を開始しますか？

69
plugin.lock.json Normal file
View File

@@ -0,0 +1,69 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:krhrtky/agents:plugins/pbi-task-manager",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "6d7bc7c539e766aa2dce53d767504d341d71440b",
"treeHash": "7c4b71676f74ae04b416a3d57ca47082ec783e464adfbd269426953d751e100d",
"generatedAt": "2025-11-28T10:19:58.027869Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "pbi-task-manager",
"description": "Comprehensive task management system integrating GitHub Issues with structured refinement and execution workflows",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "38467b88a093a4badd345a20ed21ca4f8d075099b3e3b464b2ceeb311b9b68eb"
},
{
"path": "agents/task-executor.md",
"sha256": "b098a91329a196567348da5c8e8bb8409a23003bc71f5ae4031681d2ae6a26b0"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "b28255f50475aee237a668fb272401f6d8df73e7353a4a607d52c9d507eb1b11"
},
{
"path": "commands/task-status.md",
"sha256": "7ed9c139caf0e959cd2192ae42603b3383c0d11bfbc19e1c786295971b50cc78"
},
{
"path": "commands/task-sync.md",
"sha256": "46bf6dd52d6861d07b88942ddc45857d68d4baac4a1365d4d6561cab0dccb7c5"
},
{
"path": "commands/task-list.md",
"sha256": "2ddd41353aaf58d580ae976901633c78ee307ddf5238f04642decd795df00879"
},
{
"path": "commands/task-spec.md",
"sha256": "d6c921de4838c3c329731eada119090c474df1caffcdc5e042cf67f2aadfef9e"
},
{
"path": "commands/task-refine.md",
"sha256": "acfabdc28b47fa2906c204e00bd01e1e868b428a1b9ad1916e20fb729aac3428"
},
{
"path": "commands/task-next.md",
"sha256": "a7bf835812a81805c73885bcd149d56f3e7f5e6e79667b070818ead1dfffc18b"
}
],
"dirSha256": "7c4b71676f74ae04b416a3d57ca47082ec783e464adfbd269426953d751e100d"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}