zhongwei/gh-allex-znews-cc-workflow-plugin
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-29 17:52:09 +08:00
commit 863b553c2a
20 changed files with 4544 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

185
commands/complete-task.md Normal file
View File

@@ -0,0 +1,185 @@
---
description: タスクを完了としてマークする
argument-hint: [タスクID] [完了コメント（オプション）]
---
# タスクの完了
指定したタスクを完了としてマークし、進捗を更新します。
## 引数
$ARGUMENTS
## 想定される引数形式
```
/complete-task 5
/complete-task 5 ユーザーモデルのテストも完了
/complete-task 3
```
## 処理手順
### 1. 引数のパース
引数から以下を抽出します：
- **タスクID**: 数値（必須）
- **完了コメント**: 追加のメモ（オプション）
### 2. タスクファイルの読み込み
`.tasks.json` ファイルを読み込み、指定されたIDのタスクを検索します。
### 3. バリデーション
以下をチェックします：
- タスクIDが存在するか
- タスクがすでに完了していないか
- 依存関係が解決されているか（このタスクの依存タスクがすべて完了しているか）
### 4. 完了処理
タスクの状態を `completed` に更新し、以下の情報を記録します：
- `status`: "completed"
- `completedAt`: 完了日時
- `completionNote`: 完了コメント（提供されている場合）
- `actualHours`: 実際の作業時間（可能であれば startedAt から計算）
### 5. 進捗の再計算
全体の進捗率と残り時間を再計算します。
### 6. 依存タスクの通知
このタスクに依存している他のタスクがある場合、それらが開始可能になったことを通知します。
## 出力例
### 成功時（基本）
```
✅ タスク #5 を完了しました
タスク: ユーザーモデルの作成
完了日時: 2025-10-12 16:30
作業時間: 2.0時間（推定: 2時間）
## 進捗更新
- 完了: 3/7 (43%)
- 推定残り時間: 7時間
## 次に取り組めるタスク
✅ #6: 認証APIエンドポイントの実装
（依存関係が解決されました）
```
### 成功時（コメント付き）
```
✅ タスク #5 を完了しました
タスク: ユーザーモデルの作成
完了日時: 2025-10-12 16:30
作業時間: 2.5時間（推定: 2時間）
コメント: ユーザーモデルのテストも完了
## 進捗更新
- 完了: 3/7 (43%)
- 推定残り時間: 7時間
## 次に取り組めるタスク
✅ #6: 認証APIエンドポイントの実装
✅ #8: フロントエンドフォームの作成
```
### ワークフロータスク完了時
```
✅ タスク #3 を完了しました
タスク: テスト作成 (/create-tests)
完了日時: 2025-10-12 17:00
## ワークフロー進捗
✅ 1. 要件整理
✅ 2. ドキュメント作成
✅ 3. テスト作成
⬜ 4. 実装
## 次のステップ
`/implement` を実行して実装を開始
```
### 全タスク完了時
```
✅ すべてのタスクが完了しました
機能: ユーザー認証機能
開始: 2025-10-12 10:00
完了: 2025-10-12 18:00
総作業時間: 8時間（推定: 9時間）
## 完了したタスク
✅ 1. 要件整理
✅ 2. ドキュメント作成
✅ 3. テスト作成
✅ 4. 実装
✅ 5. ユーザーモデルの作成
✅ 6. 認証APIエンドポイントの実装
✅ 7. フロントエンドフォームの作成
## 推奨される次のアクション
1. コードレビューを依頼
2. 統合テストを実行
3. ステージング環境にデプロイ
4. ドキュメントを最終確認
```
### エラー時（依存関係未解決）
```
⚠️ タスクを完了できません
タスク: #6 認証APIエンドポイントの実装
理由: 依存タスクが未完了です
未完了の依存タスク:
- #5: ユーザーモデルの作成 (状態: in_progress)
推奨:
先に #5 を完了させてから、再度 `/complete-task 6` を実行してください。
```
### エラー時（タスクが見つからない）
```
❌ タスクの完了に失敗しました
原因: タスク #99 が見つかりません
利用可能なタスクID: 1, 2, 3, 4, 5, 6, 7
タスク一覧を確認: `/list-tasks`
```
### エラー時（既に完了済み）
```
ℹ️ タスクは既に完了しています
タスク: #5 ユーザーモデルの作成
完了日時: 2025-10-12 16:30
他の未完了タスク:
- #6: 認証APIエンドポイントの実装
- #7: フロントエンドフォームの作成
タスク一覧: `/list-tasks`
```
## 次のステップ
完了状況に応じて以下を提案：
- 次に取り組むべきタスクを提示
- ワークフローの次のステップを案内
- すべて完了した場合は、次のアクション（レビュー、デプロイなど）を提案

270
commands/create-docs.md Normal file
View File

@@ -0,0 +1,270 @@
---
description: 機能仕様ドキュメントを作成する
argument-hint: [追加の指示（オプション）]
---
# 機能仕様ドキュメントの作成
前のステップで整理した要件に基づいて、詳細な機能仕様書を作成します。
## 追加の指示
$ARGUMENTS
## 前提条件の確認
ドキュメント作成を開始する前に、以下を確認してください：
### 1. タスクファイルの存在確認
```javascript
const fs = require('fs');
const tasksFile = '.tasks.json';
if (!fs.existsSync(tasksFile)) {
console.log('❌ タスクファイルが見つかりません');
console.log('\n先に要件整理を実行してください:');
console.log(' /new-feature [機能の説明]');
process.exit(1);
}
```
### 2. 前のステップ（要件整理）の完了確認
```javascript
const data = JSON.parse(fs.readFileSync(tasksFile, 'utf-8'));
// タスクID 1 (要件整理) が完了しているか確認
const requirementTask = data.tasks.find(t => t.id === 1);
if (!requirementTask || requirementTask.status !== 'completed') {
console.log('❌ 要件整理が完了していません');
console.log('\n先に要件整理を完了してください:');
console.log(' /new-feature [機能の説明]');
process.exit(1);
}
```
### 3. 重複実行の防止
```javascript
// タスクID 2 (ドキュメント作成) の状態を確認
const docTask = data.tasks.find(t => t.id === 2);
if (docTask && docTask.status === 'completed') {
console.log('⚠️ ドキュメントは既に作成されています');
console.log('\nドキュメントを確認:');
console.log(' docs/ ディレクトリを参照');
console.log('\n再作成する場合は、既存のドキュメントを削除してから実行してください。');
console.log('次のステップに進む場合:');
console.log(' /resume');
process.exit(0);
}
```
## ドキュメント作成の指針
前提条件を満たしていることを確認したら、`doc-writer` エージェントを使って、階層的なドキュメント構造を作成してください。
### ドキュメント構造
**重要**: ドキュメントは単一ファイルではなく、`docs/` ディレクトリ配下に適切な階層構造として作成します。
```
docs/
├── README.md # ドキュメント全体のインデックス
├── 00-overview/ # 全体設計
├── 01-requirements/ # 要件定義
├── 02-design/ # 基本設計
├── 03-detailed-design/ # 詳細設計（機能ごと）
├── 04-api/ # API設計
├── 05-interface/ # インターフェース設計
├── 06-test/ # テスト設計
└── 07-implementation/ # 実装ガイド
```
### 作成する内容
#### 1. 概要
```markdown
# [機能名]
## 目的
[この機能が解決する課題]
## 期待される効果
- [効果1]
- [効果2]
```
#### 2. 機能要件
```markdown
## 機能要件
### ユーザーストーリー
- As a [ユーザー], I want to [やりたいこと], so that [理由]
### 機能詳細
#### [機能1]
- 説明: [...]
- 入力: [...]
- 出力: [...]
- 振る舞い: [...]
#### [機能2]
...
```
#### 3. 技術仕様
```markdown
## 技術仕様
### アーキテクチャ
[システム構成図や説明]
### データモデル
[必要なデータ構造]
### API仕様
[エンドポイント、リクエスト/レスポンス形式]
### インターフェース
[関数シグネチャ、クラス定義など]
```
#### 4. 非機能要件
```markdown
## 非機能要件
- **パフォーマンス**: [レスポンスタイム、スループット]
- **セキュリティ**: [認証、認可、データ保護]
- **スケーラビリティ**: [負荷対応]
- **互換性**: [ブラウザ、OS、バージョン]
```
#### 5. UI/UX（該当する場合）
```markdown
## UI/UX
### 画面遷移
[遷移図やフロー]
### インタラクション
[ユーザー操作とシステム応答]
### エラーハンドリング
[エラーメッセージ、リカバリー方法]
```
#### 6. テスト戦略
```markdown
## テスト戦略
### テスト観点
- [正常系のテストケース]
- [異常系のテストケース]
- [境界値テスト]
- [エッジケース]
### パフォーマンステスト
[必要な場合]
```
#### 7. 実装の考慮事項
```markdown
## 実装の考慮事項
### 既存コードへの影響
[変更が必要な箇所、依存関係]
### マイグレーション
[必要な場合の移行計画]
### ロールバック
[問題発生時の対応]
```
## ドキュメント保存先とリンク
### ディレクトリ作成
プロジェクトルートに `docs/` ディレクトリを作成し、必要なサブディレクトリを作成します。
機能の規模に応じて、以下のように調整してください：
**小規模機能**: 最小限のディレクトリ（requirements, detailed-design）
**中規模機能**: 主要なディレクトリ（overview, requirements, design, api/interface）
**大規模機能**: 完全なディレクトリ構造
### 相互リンクの設定
各ドキュメント間で適切にリンクを設定してください：
```markdown
# 例: 01-requirements/functional.md
詳細な設計については [詳細設計](../03-detailed-design/[feature-name]/README.md) を参照してください。
# 例: 04-api/[endpoint].md
データモデルの詳細は [データモデル](../02-design/data-model.md) を参照してください。
```
### インデックスファイル (docs/README.md)
ルートの README.md にすべてのドキュメントへのリンクを含めてください：
```markdown
# [機能名] - ドキュメント
## 📚 ドキュメント構成
### [全体設計](./00-overview/README.md)
- [アーキテクチャ](./00-overview/architecture.md)
### [要件定義](./01-requirements/README.md)
- [機能要件](./01-requirements/functional.md)
- [非機能要件](./01-requirements/non-functional.md)
[...]
```
## タスク状態の更新
ドキュメント作成を開始する前に、タスク状態を更新してください：
```javascript
// .tasks.json の該当タスクを更新
{
"id": 2,
"type": "workflow",
"name": "ドキュメント作成",
"status": "in_progress", // pending → in_progress
"command": "/create-docs",
"startedAt": "[現在時刻]"
}
```
ドキュメント作成が完了したら：
```javascript
{
"id": 2,
"status": "completed", // in_progress → completed
"completedAt": "[現在時刻]"
}
```
## 次のステップ
ドキュメントを作成したら、ユーザーに以下を確認してください：
```
ドキュメントを確認してください。
承認いただければ、次のステップ（テスト作成）を自動的に開始します。
承認しますか？ (yes/no)
```
**ユーザーが承認した場合**: SlashCommandツールを使って `/create-tests` を実行してください。
**注意**:
- `post-docs-check` フックが自動的に実行され、ドキュメントの完全性をチェックします
- タスク進捗は `/list-tasks` で確認できます

173
commands/create-tasks.md Normal file
View File

@@ -0,0 +1,173 @@
---
description: 機能開発のサブタスクを作成する
argument-hint: [機能名]
---
# サブタスクの作成
現在の機能開発に対するサブタスクを作成し、進捗を管理します。
## 機能名
$ARGUMENTS
## あなたの役割
`task-manager` エージェントを起動して、以下を実行してください：
### 1. メインタスク（ワークフローフタスク）の確認
まず `.tasks.json` ファイルを確認し、メインタスクが作成されていることを確認します：
**必須条件**:
- `/new-feature` によってワークフロータスク（ID 1-5）が既に作成されていること
- メインタスクには以下が含まれます：
- ID 1: 要件整理 (`/new-feature`)
- ID 2: ドキュメント作成 (`/create-docs`)
- ID 3: テスト作成 (`/create-tests`)
- ID 4: タスク作成 (`/create-tasks`)
- ID 5: 実装 (`/implement`)
**メインタスクが存在しない場合**:
```
⚠️ メインタスクが作成されていません
先に `/new-feature [機能の説明]` を実行して、
ワークフローを開始してください。
```
### 2. 既存サブタスクの確認
`.tasks.json` に既存のサブタスク（type: "subtask"）がある場合は、それを確認します。
### 3. サブタスクの分析と作成
**重要**: サブタスクは必ず親タスク（メインタスクID 5: 実装）に紐付けて作成してください。
ユーザーのリクエストと既存のドキュメント（機能仕様書など）を分析し、以下の観点でサブタスクに分割します：
- **技術領域別**: フロントエンド、バックエンド、データベース、API、テストなど
- **機能単位別**: ユーザー認証、データ保存、バリデーション、エラーハンドリングなど
- **優先度別**: 必須機能、拡張機能、最適化など
### 4. タスクの粒度
各サブタスクは以下の基準を満たすようにします：
- **適切なサイズ**: 独立して完了できる単位
- **テスト可能**: 独立してテストできる
- **明確な完了条件**: 完了したかどうかが明確に判断できる
### 5. タスクの構造
**タスクの階層関係**:
```
メインタスク（workflow）
├─ ID 1: 要件整理 (/new-feature)
├─ ID 2: ドキュメント作成 (/create-docs)
├─ ID 3: テスト作成 (/create-tests)
├─ ID 4: タスク作成 (/create-tasks)
└─ ID 5: 実装 (/implement) ← サブタスクの親
├─ ID 6: ユーザーモデルの作成（subtask）
├─ ID 7: 認証APIエンドポイントの実装（subtask）
└─ ID 8: フロントエンドフォームの作成（subtask）
```
**完全な .tasks.json の例**:
```json
{
"feature": "機能名",
"createdAt": "2025-10-12T10:00:00Z",
"updatedAt": "2025-10-12T14:00:00Z",
"tasks": [
{
"id": 4,
"type": "workflow",
"name": "タスク作成",
"status": "in_progress",
"command": "/create-tasks",
"createdAt": "2025-10-12T10:00:00Z",
"startedAt": "2025-10-12T13:00:00Z"
},
{
"id": 5,
"type": "workflow",
"name": "実装",
"status": "pending",
"command": "/implement",
"createdAt": "2025-10-12T10:00:00Z"
},
{
"id": 6,
"type": "subtask",
"name": "ユーザーモデルの作成",
"status": "pending",
"parent": 5,
"dependencies": [],
"createdAt": "2025-10-12T14:00:00Z"
},
{
"id": 7,
"type": "subtask",
"name": "認証APIエンドポイントの実装",
"status": "pending",
"parent": 5,
"dependencies": [6],
"createdAt": "2025-10-12T14:00:00Z"
}
]
}
```
**重要なポイント**:
- すべてのサブタスクは `"parent": 5` を持つ（メインタスク「実装」に紐付け）
- `type` は "subtask" にする
- ID は既存タスクと重複しない（6から開始）
- **完了したタスクは `.tasks-history.json` に移動されているため、`.tasks.json` には進行中・未完了のタスクのみが含まれる**
### 6. タスクの状態
- `pending`: 未着手
- `in_progress`: 作業中
- `completed`: 完了
- `blocked`: ブロック中（依存関係や問題により進められない）
## 出力形式
サブタスクを作成したら、以下の形式でユーザーに表示してください：
```
## サブタスク一覧
### ワークフロータスク
- [x] 1. 要件整理 (/new-feature)
- [x] 2. ドキュメント作成 (/create-docs)
- [x] 3. テスト作成 (/create-tests)
- [x] 4. タスク作成 (/create-tasks)
- [ ] 5. 実装 (/implement)
### 実装サブタスク
- [ ] 6. ユーザーモデルの作成
- [ ] 7. 認証APIエンドポイントの実装 (依存: #6)
- [ ] 8. フロントエンドフォームの作成
## 進捗
- 完了: 4/8 (50%)
```
## 次のステップ
サブタスクを作成したら、ユーザーに以下を確認してください：
```
サブタスクを確認してください。
承認いただければ、次のステップ（実装）を自動的に開始します。
承認しますか？ (yes/no)
```
**ユーザーが承認した場合**: SlashCommandツールを使って `/implement` を実行してください。
**タスク管理コマンド**:
- タスクを確認・修正する場合: `/update-task [タスクID] [新しい状態]`
- タスクを完了する場合: `/complete-task [タスクID]`
- タスク一覧を表示する場合: `/list-tasks`

215
commands/create-tests.md Normal file
View File

@@ -0,0 +1,215 @@
---
description: テストケースを作成する（TDD）
argument-hint: [追加の指示（オプション）]
---
# テストケースの作成（テスト駆動開発）
機能仕様書に基づいて、実装前にテストケースを作成します。
TDD（Test-Driven Development）のアプローチに従い、実装のガイドとなるテストを書きます。
## 追加の指示
$ARGUMENTS
## 前提条件の確認
テスト作成を開始する前に、以下を確認してください：
### 1. 前のステップの完了確認
```javascript
const fs = require('fs');
const tasksFile = '.tasks.json';
if (!fs.existsSync(tasksFile)) {
console.log('❌ タスクファイルが見つかりません');
console.log('\n先に要件整理を実行してください:');
console.log(' /new-feature [機能の説明]');
process.exit(1);
}
const data = JSON.parse(fs.readFileSync(tasksFile, 'utf-8'));
// タスクID 2 (ドキュメント作成) が完了しているか確認
const docTask = data.tasks.find(t => t.id === 2);
if (!docTask || docTask.status !== 'completed') {
console.log('❌ ドキュメント作成が完了していません');
console.log('\n先にドキュメントを作成してください:');
console.log(' /create-docs');
console.log('\nまたは、ワークフローを再開:');
console.log(' /resume');
process.exit(1);
}
```
### 2. 重複実行の防止
```javascript
// タスクID 3 (テスト作成) の状態を確認
const testTask = data.tasks.find(t => t.id === 3);
if (testTask && testTask.status === 'completed') {
console.log('⚠️ テストは既に作成されています');
console.log('\nテストファイルを確認してください。');
console.log('次のステップに進む場合:');
console.log(' /resume');
process.exit(0);
}
```
## テスト作成の指針
前提条件を満たしていることを確認したら、`test-writer` エージェントを使って、包括的なテストスイートを作成してください。
### ステップ1: テスト環境の確認
まず、プロジェクトのテストフレームワークと規約を確認：
```bash
# package.jsonやrequirements.txtを確認
# 既存のテストファイルを参照
# テスト実行コマンドを確認
```
### ステップ2: テスト計画
以下のテストタイプを計画します：
#### ユニットテスト
- 個々の関数/メソッドのテスト
- モジュールの単独動作検証
- 外部依存をモック化
#### 統合テスト
- モジュール間の連携テスト
- データベース操作のテスト
- API統合のテスト
#### E2Eテスト（必要な場合）
- ユーザーシナリオの完全な流れ
- UI操作のテスト
### ステップ3: テストケースの構造
各テストは AAA パターンに従います：
```javascript
// JavaScript/TypeScript の例
describe('機能名', () => {
test('should [期待される動作]', () => {
// Arrange: テストデータとモックの準備
const input = {...};
const expected = {...};
// Act: テスト対象を実行
const result = functionUnderTest(input);
// Assert: 結果を検証
expect(result).toEqual(expected);
});
});
```
```python
# Python の例
def test_機能名_should_期待される動作():
# Arrange
input_data = {...}
expected = {...}
# Act
result = function_under_test(input_data)
# Assert
assert result == expected
```
### ステップ4: テストカバレッジ
以下の観点を網羅してください：
#### 正常系
- 典型的な入力パターン
- 期待される出力の検証
#### 異常系
- 不正な入力
- エラーハンドリング
- 例外処理
#### 境界値
- 最小値/最大値
- 空の値（null, undefined, empty string, etc.）
- ゼロ除算など
#### エッジケース
- 特殊文字
- 大量データ
- 同時実行
### ステップ5: モックとスタブ
外部依存を適切にモック化：
```javascript
// データベースのモック
const mockDb = {
query: jest.fn().mockResolvedValue([...]),
};
// API呼び出しのモック
jest.mock('./api', () => ({
fetchData: jest.fn().mockResolvedValue({...}),
}));
```
### ステップ6: テストデータ
テストデータを適切に準備：
```javascript
// テストフィクスチャ
const testData = {
validUser: { id: 1, name: 'Test User' },
invalidUser: { id: -1, name: '' },
};
// ファクトリー関数
function createTestUser(overrides = {}) {
return { id: 1, name: 'Test User', ...overrides };
}
```
## テスト作成のベストプラクティス
1. **明確なテスト名**: 何をテストしているか一目でわかる
2. **独立性**: 各テストは他のテストに依存しない
3. **再現性**: 何度実行しても同じ結果
4. **高速**: ユニットテストは数ミリ秒で完了
5. **可読性**: テストコードも本番コード同様に丁寧に書く
## ファイル配置
プロジェクトの規約に従って配置：
- `__tests__/[feature-name].test.js`
- `tests/test_[feature_name].py`
- `[feature-name]_test.go`
- `src/[feature-name].spec.ts`
## 次のステップ
テストケースを作成したら（この時点でテストは失敗します - Red）、ユーザーに以下を確認してください：
```
テストケースを確認してください。
承認いただければ、次のステップ（実装タスクの作成）を自動的に開始します。
承認しますか？ (yes/no)
```
**ユーザーが承認した場合**: SlashCommandツールを使って `/create-tasks` を実行してください。
**注意**:
- `post-test-check` フックが自動的に実行され、テストの品質と網羅性をチェックします
- タスクが作成された後、実装フェーズで各タスクを順次実行し、テストをGreenにしていきます

222
commands/implement.md Normal file
View File

@@ -0,0 +1,222 @@
---
description: 機能を実装する
argument-hint: [追加の指示（オプション）]
---
# 機能の実装
機能仕様書とテストケースに基づいて、機能を実装します。
TDDのRed-Green-Refactorサイクルに従って進めます。
## 追加の指示
$ARGUMENTS
## 実装の指針
`implementer` エージェントを使って、テストを通すための実装を進めてください。
## タスク状態の更新
実装を開始する前に、タスク状態を更新してください：
```javascript
// .tasks.json の該当タスクを更新
{
"id": 5,
"type": "workflow",
"name": "実装",
"status": "in_progress",
"command": "/implement",
"startedAt": "[現在時刻]"
}
```
実装フェーズでは、サブタスクを作成している場合、各サブタスクの状態も適宜更新してください：
- `/update-task [タスクID] in_progress` - タスク開始時
- `/complete-task [タスクID]` - タスク完了時
## Red-Green-Refactor サイクル
### フェーズ1: Red（失敗するテストの確認）
まず、作成したテストを実行して失敗を確認します：
```bash
# テストを実行
npm test # または pytest, go test, など
```
失敗メッセージから、何を実装すべきかを理解します。
### フェーズ2: Green（最小限の実装）
**目標**: テストを通すこと（美しいコードは後回し）
#### 実装の優先順位
1. **コアロジックから**
- 最も重要な機能
- 他の機能が依存する部分
2. **正常系を先に**
- 一般的なユースケース
- ハッピーパス
3. **エラーハンドリング**
- 異常系の処理
- 例外処理
4. **エッジケースの対応**
- 境界値の処理
- 特殊なケース
#### 実装のステップ
```
1. 1つのテストケースに注目
2. そのテストを通す最小限のコードを書く
3. テストを実行
4. 通ったら次のテストへ
5. 失敗したらデバッグして修正
6. すべてのテストが通るまで繰り返し
```
### フェーズ3: Refactor（リファクタリング）
すべてのテストが通ったら、コードを改善します：
#### リファクタリング観点
1. **重複の削除**
- DRY原則に従う
- 共通処理を関数化
2. **可読性の向上**
- わかりやすい変数名
- 適切なコメント
- 関数の分割
3. **設計の改善**
- 責任の分離
- 依存性の注入
- パターンの適用
4. **パフォーマンス最適化**（必要な場合）
- アルゴリズムの改善
- キャッシングの追加
- 不要な処理の削除
**重要**: リファクタリング後、必ずテストを実行して機能が壊れていないことを確認
## 実装のベストプラクティス
### 1. コーディング規約に従う
プロジェクトの既存のスタイルを確認：
- 命名規則
- インデント（スペースorタブ）
- ファイル構成
- コメントの書き方
### 2. 小さくコミット
```bash
# 機能単位でコミット
git add [変更ファイル]
git commit -m "feat: [機能の説明]"
# テストが通る状態でコミット
# こまめにコミットして履歴を残す
```
### 3. ドキュメントを書く
```javascript
/**
* ユーザー情報を取得する
* @param {number} userId - ユーザーID
* @returns {Promise<User>} ユーザー情報
* @throws {Error} ユーザーが見つからない場合
*/
async function getUser(userId) {
// ...
}
```
### 4. エラーハンドリング
```javascript
// 適切なエラーメッセージ
if (!userId) {
throw new Error('User ID is required');
}
// エラーのログ記録
try {
// ...
} catch (error) {
logger.error('Failed to fetch user', { userId, error });
throw error;
}
```
### 5. 依存関係の管理
新しいライブラリを追加する場合：
```bash
# 必要性を検討
# ライセンスを確認
# バージョンを固定
npm install --save-exact package-name
```
## 実装中のチェックリスト
- [ ] テストケースを確認した
- [ ] 最小限の実装から始めた
- [ ] テストを頻繁に実行している
- [ ] コーディング規約に従っている
- [ ] 適切なエラーハンドリングをしている
- [ ] 必要なコメント・ドキュメントを書いた
- [ ] リファクタリングをした
- [ ] すべてのテストが通る
- [ ] 既存のテストも壊していない
## 次のステップ
実装が完了したら：
1. **すべてのテストを実行**
```bash
npm test
npm run test:coverage # カバレッジも確認
```
2. **コードレビュー依頼**
- ユーザーにレビューを依頼
- フィードバックを反映
3. **ドキュメント更新**
- README
- CHANGELOG
- APIドキュメント
4. **タスクの完了**
```javascript
// .tasks.json の該当タスクを更新
{
"id": 5,
"status": "completed",
"completedAt": "[現在時刻]"
}
```
5. **完了報告**
- 実装内容のサマリー
- テスト結果
- 今後の課題（あれば）
**注意**:
- `post-implementation` フックが自動的に実行され、実装の品質チェックとテストの実行を行います
- タスク進捗は `/list-tasks` で確認できます
- すべてのサブタスクが完了していることを確認してください

261
commands/list-tasks.md Normal file
View File

@@ -0,0 +1,261 @@
---
description: タスク一覧と進捗を表示する
---
# タスク一覧の表示
現在の機能開発のタスク一覧と進捗状況を表示します。
## タスクファイルの確認
`.tasks.json` ファイルを読み込み、以下の情報を表示してください：
### 1. 機能情報
```
## 機能: [機能名]
作成日時: [作成日時]
最終更新: [最終更新日時]
```
### 2. 進捗サマリー
```
### 進捗サマリー
- 全タスク数: X件
- 完了: Y件 (Z%)
- 作業中: A件
- 未着手: B件
- ブロック中: C件
推定残り時間: D時間
```
### 3. タスク詳細
ステータス別にタスクを表示します：
```
### ワークフロータスク
✅ 1. 要件整理 (/new-feature)
完了日時: 2025-10-12 10:30
✅ 2. ドキュメント作成 (/create-docs)
完了日時: 2025-10-12 11:00
⏳ 3. テスト作成 (/create-tests)
状態: 作業中
⬜ 4. 実装 (/implement)
状態: 未着手
### 実装サブタスク
⬜ 5. ユーザーモデルの作成
状態: 未着手
推定: 2時間
親タスク: #4 (実装)
⬜ 6. 認証APIエンドポイントの実装
状態: 未着手
推定: 3時間
依存: #5
親タスク: #4 (実装)
🚫 7. データベースマイグレーション
状態: ブロック中
理由: データベーススキーマの確認待ち
```
### 4. アイコンの凡例
- ✅ 完了
- ⏳ 作業中
- ⬜ 未着手
- 🚫 ブロック中
## タスクが存在しない場合
`.tasks.json` ファイルが存在しない、または空の場合：
```
タスクが作成されていません。
以下のコマンドでワークフローを開始してください：
- `/new-feature [機能の説明]` - 新機能開発を開始
- `/create-tasks [機能名]` - サブタスクを作成
```
## 次のステップの提案
タスク状況を分析し、具体的な次のアクションを提案してください：
### 1. 作業中のタスクがある場合
```
### 📌 次のアクション
タスク「[タスク名]」が作業中です。
続行するには:
/resume
または
[対応するコマンド] (例: /create-docs)
```
### 2. 未着手のワークフロータスクがある場合
次に実行すべきワークフロータスク（最も小さいIDのpendingタスク）を提案：
```
### 📌 次のアクション
次のステップ: [タスク名]
このタスクを開始するには:
/resume
または
[対応するコマンド] (例: /create-tests)
```
### 3. ブロックされたタスクがある場合
ブロックの理由と解決方法を提案：
```
### ⚠️ ブロック中のタスク
タスク「[タスク名]」がブロックされています。
理由: [ブロック理由]
解決方法:
1. [解決ステップ1]
2. [解決ステップ2]
ブロックを解除するには:
/update-task [タスクID] pending
```
### 4. サブタスクが残っている場合
実装サブタスクの状態を確認し、次のタスクを提案：
```
### 📌 次のアクション
実装サブタスクが残っています:
- [サブタスク名1] (状態: pending)
- [サブタスク名2] (状態: pending, 依存: #X)
実装を続行するには:
/implement
または特定のサブタスクを開始:
/update-task [タスクID] in_progress
```
### 5. すべて完了している場合
```
### 🎉 完了
すべてのタスクが完了しました！
次のステップ:
1. コードレビューを依頼
2. ドキュメントを最終確認
3. プルリクエストを作成 (該当する場合)
4. 本番環境へのデプロイを検討
新しい機能を開始するには:
/new-feature [機能の説明]
完了した作業の履歴を確認:
履歴は .tasks-history.json に保存されています
```
### 6. 依存関係で待機中の場合
依存タスクが未完了のサブタスクがある場合：
```
### 📌 次のアクション
以下のタスクは依存関係により待機中です:
- タスク #[ID]: [タスク名]
待機理由: タスク #[依存ID] ([依存タスク名]) が未完了
まず以下のタスクを完了してください:
- タスク #[依存ID]: [依存タスク名]
実行可能なタスク:
- [実行可能なタスク1]
- [実行可能なタスク2]
```
## アクション提案のロジック
```javascript
function suggestNextAction(tasks) {
// 1. ワークフローの作業中タスク
const inProgressWorkflow = tasks.find(t =>
t.type === 'workflow' && t.status === 'in_progress'
);
if (inProgressWorkflow) {
return {
action: 'resume',
task: inProgressWorkflow,
command: inProgressWorkflow.command
};
}
// 2. ワークフローの未着手タスク
const pendingWorkflow = tasks
.filter(t => t.type === 'workflow' && t.status === 'pending')
.sort((a, b) => a.id - b.id)[0];
if (pendingWorkflow) {
return {
action: 'start-next',
task: pendingWorkflow,
command: pendingWorkflow.command
};
}
// 3. ブロックされたタスク
const blockedTasks = tasks.filter(t => t.status === 'blocked');
if (blockedTasks.length > 0) {
return {
action: 'resolve-block',
tasks: blockedTasks
};
}
// 4. サブタスクが残っている
const pendingSubtasks = tasks.filter(t =>
t.type === 'subtask' && t.status !== 'completed'
);
if (pendingSubtasks.length > 0) {
// 依存関係をチェックして実行可能なタスクを探す
const executableTasks = pendingSubtasks.filter(task => {
if (!task.dependencies || task.dependencies.length === 0) {
return true;
}
return task.dependencies.every(depId => {
const depTask = tasks.find(t => t.id === depId);
return depTask && depTask.status === 'completed';
});
});
return {
action: 'continue-implementation',
executableTasks,
blockedTasks: pendingSubtasks.filter(t => !executableTasks.includes(t))
};
}
// 5. すべて完了
return {
action: 'completed'
};
}
```

154
commands/new-feature.md Normal file
View File

@@ -0,0 +1,154 @@
---
description: 新機能開発ワークフローを開始する
argument-hint: [機能の説明]
---
# 新機能開発ワークフローの開始
新機能の開発リクエストを受け取り、体系的なワークフローで進めます。
## ユーザーのリクエスト
$ARGUMENTS
## ワークフロー概要
このプラグインは、以下のステップで新機能開発を進めます：
1. **要件の理解と整理** ← 今ここ
2. **ドキュメント作成** (承認後、自動的に実行)
3. **テスト作成** (承認後、自動的に実行)
4. **タスク作成** (承認後、自動的に実行)
5. **実装** (承認後、自動的に実行)
6. **テスト実行と完了**
**自動ワークフロー**: 各ステップで成果物を作成し、ユーザーの承認を待ちます。承認されると自動的に次のステップを実行します。
## あなたの役割
以下の観点からリクエストを詳しく分析し、ユーザーと対話して要件を明確化してください：
### 1. 機能の目的
- この機能は何を解決しますか？
- なぜこの機能が必要ですか？
- 期待される効果は何ですか？
### 2. 対象ユーザー
- 誰がこの機能を使いますか？
- ユーザーの技術レベルは？
- どのような状況で使われますか？
### 3. 主要な機能要件
- どのような機能が必要ですか？
- 入力と出力は何ですか？
- どのような振る舞いが期待されますか？
### 4. 技術的な制約
- 使用している技術スタック
- パフォーマンス要件
- セキュリティ要件
- 互換性の制約
### 5. 成功基準
- この機能が成功したと判断する基準は？
- どのようにテストしますか？
- リリース後の検証方法は？
### 6. スコープ
- 今回実装する範囲は？
- 将来的な拡張の可能性は？
- やらないことを明確にする
## タスク管理の初期化
要件整理が完了したら、`.tasks.json` ファイルを作成してタスク管理を開始してください：
```json
{
"feature": "[機能名]",
"createdAt": "[現在時刻のISO 8601形式]",
"updatedAt": "[現在時刻のISO 8601形式]",
"tasks": [
{
"id": 1,
"type": "workflow",
"name": "要件整理",
"status": "completed",
"command": "/new-feature",
"createdAt": "[現在時刻]",
"completedAt": "[現在時刻]"
},
{
"id": 2,
"type": "workflow",
"name": "ドキュメント作成",
"status": "pending",
"command": "/create-docs",
"createdAt": "[現在時刻]"
},
{
"id": 3,
"type": "workflow",
"name": "テスト作成",
"status": "pending",
"command": "/create-tests",
"createdAt": "[現在時刻]"
},
{
"id": 4,
"type": "workflow",
"name": "タスク作成",
"status": "pending",
"command": "/create-tasks",
"createdAt": "[現在時刻]"
},
{
"id": 5,
"type": "workflow",
"name": "実装",
"status": "pending",
"command": "/implement",
"createdAt": "[現在時刻]"
}
]
}
```
## 次のステップ
要件を整理したら、以下の形式でサマリーを作成してください：
```
## 要件サマリー
**目的**: [簡潔な説明]
**対象ユーザー**: [ユーザープロファイル]
**主要機能**:
- [機能1]
- [機能2]
- ...
**技術的制約**:
- [制約1]
- [制約2]
**成功基準**:
- [基準1]
- [基準2]
**スコープ**:
- 含む: [...]
- 含まない: [...]
```
サマリーを作成したら、ユーザーに以下を確認してください：
```
要件サマリーを確認してください。
承認いただければ、次のステップ（ドキュメント作成）を自動的に開始します。
承認しますか？ (yes/no)
```
**ユーザーが承認した場合**: SlashCommandツールを使って `/create-docs` を実行してください。
**タスク管理**: `/list-tasks` でタスク一覧を確認できます。

265
commands/resume.md Normal file
View File

@@ -0,0 +1,265 @@
---
description: 中断されたワークフローを再開する
---
# ワークフローの再開
中断された機能開発ワークフローを再開します。
## あなたの役割
`.tasks.json` ファイルを読み込み、現在のワークフロー状態を分析して、適切な次のステップを実行してください。
### ステップ1: タスクファイルの確認
まず、`.tasks.json` ファイルが存在するか確認します：
```javascript
const fs = require('fs');
const tasksFile = '.tasks.json';
if (!fs.existsSync(tasksFile)) {
// タスクファイルが存在しない
console.log('❌ 進行中のワークフローが見つかりません');
console.log('\n新しいワークフローを開始するには:');
console.log(' /new-feature [機能の説明]');
process.exit(1);
}
const data = JSON.parse(fs.readFileSync(tasksFile, 'utf-8'));
```
### ステップ2: 現在の状態を分析
ワークフロータスク（type: "workflow"）の状態を確認し、次に実行すべきタスクを特定します：
```javascript
// ワークフロータスクを取得
const workflowTasks = data.tasks.filter(t => t.type === 'workflow');
// 作業中のタスクを探す
const inProgressTask = workflowTasks.find(t => t.status === 'in_progress');
// 未着手のタスクを探す（IDの昇順で最初のもの）
const pendingTask = workflowTasks
.filter(t => t.status === 'pending')
.sort((a, b) => a.id - b.id)[0];
// 次に実行すべきタスク
const nextTask = inProgressTask || pendingTask;
```
### ステップ3: 状態に応じた処理
#### ケース1: 作業中のタスクがある
作業中のタスクがある場合、そのタスクを続行します：
```
## 📋 ワークフロー状態
**機能**: [機能名]
### 現在の進捗
- ✅ 要件整理
- ✅ ドキュメント作成
- ⏳ テスト作成 ← 作業中
- ⬜ タスク作成
- ⬜ 実装
### 次のアクション
タスク「テスト作成」が作業中です。
このタスクを続行しますか？
- **続行する場合**: `/create-tests` を実行
- **状態を確認する場合**: `/list-tasks` を実行
```
この場合、ユーザーに確認を求め、承認されたら対応するコマンドを実行します。
#### ケース2: 未着手のタスクがある
未着手のタスクがある場合、次のタスクを開始します：
```
## 📋 ワークフロー状態
**機能**: [機能名]
### 現在の進捗
- ✅ 要件整理
- ✅ ドキュメント作成
- ✅ テスト作成
- ⬜ タスク作成 ← 次のステップ
- ⬜ 実装
### 次のアクション
次は「タスク作成」です。
実装のためのサブタスクを作成します。
続行しますか？ (yes/no)
```
承認されたら、SlashCommandツールで対応するコマンドを実行します。
#### ケース3: すべて完了している
すべてのワークフロータスクが完了している場合：
```
## 📋 ワークフロー状態
**機能**: [機能名]
### 🎉 ワークフロー完了！
すべてのタスクが完了しました：
- ✅ 要件整理
- ✅ ドキュメント作成
- ✅ テスト作成
- ✅ タスク作成
- ✅ 実装
### 次のステップ
1. コードレビューを依頼
2. ドキュメントを確認
3. 本番環境へのデプロイを検討
完了したタスクは履歴ファイル (.tasks-history.json) に保存されています。
```
#### ケース4: サブタスクが残っている
ワークフロータスクは完了しているが、サブタスク（type: "subtask"）が残っている場合：
```
## 📋 ワークフロー状態
**機能**: [機能名]
### ワークフロー
すべてのワークフロータスクが完了しています。
### 実装サブタスク
- ✅ ユーザーモデルの作成
- ⏳ 認証APIエンドポイントの実装 ← 作業中
- ⬜ フロントエンドフォームの作成
### 次のアクション
サブタスク「認証APIエンドポイントの実装」が作業中です。
このタスクを続行するには:
- `/implement` を実行してください
- タスク詳細を確認: `/list-tasks`
```
## コマンドとタスクIDの対応
| タスクID | タスク名 | コマンド |
|---------|---------|---------|
| 1 | 要件整理 | `/new-feature` |
| 2 | ドキュメント作成 | `/create-docs` |
| 3 | テスト作成 | `/create-tests` |
| 4 | タスク作成 | `/create-tasks` |
| 5 | 実装 | `/implement` |
## 実装フロー
```javascript
// 1. タスクファイル読み込み
const data = loadTasksFile();
// 2. 状態分析
const currentState = analyzeWorkflowState(data);
// 3. ユーザーに状態を表示
displayWorkflowState(currentState);
// 4. 次のアクションを提案
suggestNextAction(currentState);
// 5. ユーザーの承認を待つ
// "yes" の場合、次のコマンドを自動実行
// 6. SlashCommand ツールで次のコマンドを実行
if (userApproved) {
executeCommand(currentState.nextCommand);
}
```
## エラーハンドリング
### タスクファイルが破損している場合
```
❌ タスクファイルの読み込みに失敗しました
エラー: [エラーメッセージ]
タスクファイル (.tasks.json) を確認してください。
```
### 履歴のみ存在する場合
```
ℹ️ 進行中のワークフローはありません
最近完了した機能:
- [機能名1] (完了日: YYYY-MM-DD)
- [機能名2] (完了日: YYYY-MM-DD)
新しいワークフローを開始するには:
/new-feature [機能の説明]
```
## 注意事項
- **自動実行**: ユーザーが承認した場合のみ次のコマンドを実行
- **状態確認**: 実行前に必ず現在の状態を表示
- **依存関係**: サブタスクの依存関係も考慮する
- **ブロック状態**: ブロックされたタスクがある場合は警告を表示
## 使用例
### 例1: ドキュメント作成で中断していた場合
```
$ /resume
## 📋 ワークフロー状態
**機能**: ユーザー認証機能
### 現在の進捗
- ✅ 要件整理
- ⏳ ドキュメント作成 ← 作業中
- ⬜ テスト作成
- ⬜ タスク作成
- ⬜ 実装
### 次のアクション
タスク「ドキュメント作成」が作業中です。
このタスクを続行しますか？ (yes/no)
> yes
ドキュメント作成を続行します...
[/create-docs が自動実行される]
```
### 例2: すべて完了している場合
```
$ /resume
## 📋 ワークフロー状態
**機能**: ユーザー認証機能
### 🎉 ワークフロー完了！
すべてのタスクが完了しました。
完了したタスクは履歴ファイルに保存されています。
詳細を確認するには: /list-tasks --history
```

118
commands/update-task.md Normal file
View File

@@ -0,0 +1,118 @@
---
description: タスクの状態を更新する
argument-hint: [タスクID] [新しい状態] [理由（オプション）]
---
# タスク状態の更新
指定したタスクの状態を更新します。
## 引数
$ARGUMENTS
## 想定される引数形式
```
/update-task 5 in_progress
/update-task 7 blocked データベーススキーマの確認待ち
/update-task 3 pending
```
## 状態の種類
- `pending`: 未着手
- `in_progress`: 作業中
- `completed`: 完了（`/complete-task` の使用を推奨）
- `blocked`: ブロック中（理由を記載してください）
## 処理手順
### 1. 引数のパース
引数から以下を抽出します：
- **タスクID**: 数値
- **新しい状態**: pending, in_progress, completed, blocked のいずれか
- **理由**: 状態変更の理由（blocked の場合は必須）
### 2. タスクファイルの読み込み
`.tasks.json` ファイルを読み込み、指定されたIDのタスクを検索します。
### 3. バリデーション
以下をチェックします：
- タスクIDが存在するか
- 状態が有効な値か
- blocked の場合、理由が提供されているか
- 依存関係の問題がないか（依存タスクが未完了なのに in_progress にしようとしていないか）
### 4. 状態の更新
タスクの状態を更新し、以下の情報も記録します：
- `updatedAt`: 更新日時
- `blockReason`: ブロック理由（blocked の場合）
- `startedAt`: 開始日時（pending → in_progress の場合）
### 5. 依存関係のチェック
タスクを `completed` にする場合、このタスクに依存している他のタスクがあれば通知します。
## 出力例
### 成功時
```
✅ タスク #5 の状態を更新しました
タスク: ユーザーモデルの作成
旧状態: pending → 新状態: in_progress
開始日時: 2025-10-12 14:30
このタスクに依存しているタスク:
- #6: 認証APIエンドポイントの実装
```
### ブロック時
```
🚫 タスク #7 をブロック状態にしました
タスク: データベースマイグレーション
理由: データベーススキーマの確認待ち
推奨アクション:
1. 関係者に確認を依頼
2. 他のタスク（#5, #6）を先に進める
3. 問題が解決したら `/update-task 7 pending` で再開
```
### エラー時
```
❌ タスクの更新に失敗しました
原因: タスク #99 が見つかりません
利用可能なタスクID: 1, 2, 3, 4, 5, 6, 7
タスク一覧を確認: `/list-tasks`
```
### 依存関係エラー時
```
⚠️ 依存関係の警告
タスク #6 を in_progress にしようとしていますが、
依存タスク #5 (ユーザーモデルの作成) がまだ完了していません。
推奨:
- 先に #5 を完了させる
- または依存関係を見直す
```
## 次のステップ
状態に応じて以下を提案：
- `in_progress` にした場合: 作業のヒントや関連ドキュメントを提示
- `blocked` にした場合: 代わりに取り組めるタスクを提案
- `completed` にした場合: 次のタスクを提案（`/complete-task` を推奨）