mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-08 18:33:28 +08:00
feat(ecc): prune plugin 43→12 items, promote 7 rules to .claude/rules/ (#245)
ECC community plugin pruning: removed 530+ non-essential files (.cursor/, .opencode/, docs/ja-JP, docs/zh-CN, docs/zh-TW, language-specific skills/agents/rules). Retained 4 agents, 3 commands, 5 skills. Promoted 13 rule files (8 common + 5 typescript) to .claude/rules/ for CC native loading. Extracted reusable patterns to EXTRACTED-PATTERNS.md.
This commit is contained in:
park-kyungchan
@@ -1,113 +0,0 @@
|
||||
# コマンド
|
||||
|
||||
コマンドはスラッシュ（`/command-name`）で起動するユーザー起動アクションです。有用なワークフローと開発タスクを実行します。
|
||||
|
||||
## コマンドカテゴリ
|
||||
|
||||
### ビルド & エラー修正
|
||||
- `/build-fix` - ビルドエラーを修正
|
||||
- `/go-build` - Go ビルドエラーを解決
|
||||
- `/go-test` - Go テストを実行
|
||||
|
||||
### コード品質
|
||||
- `/code-review` - コード変更をレビュー
|
||||
- `/python-review` - Python コードをレビュー
|
||||
- `/go-review` - Go コードをレビュー
|
||||
|
||||
### テスト & 検証
|
||||
- `/tdd` - テスト駆動開発ワークフロー
|
||||
- `/e2e` - E2E テストを実行
|
||||
- `/test-coverage` - テストカバレッジを確認
|
||||
- `/verify` - 実装を検証
|
||||
|
||||
### 計画 & 実装
|
||||
- `/plan` - 機能実装計画を作成
|
||||
- `/skill-create` - 新しいスキルを作成
|
||||
- `/multi-*` - マルチプロジェクト ワークフロー
|
||||
|
||||
### ドキュメント
|
||||
- `/update-docs` - ドキュメントを更新
|
||||
- `/update-codemaps` - Codemap を更新
|
||||
|
||||
### 開発 & デプロイ
|
||||
- `/checkpoint` - 実装チェックポイント
|
||||
- `/evolve` - 機能を進化
|
||||
- `/learn` - プロジェクトについて学ぶ
|
||||
- `/orchestrate` - ワークフロー調整
|
||||
- `/pm2` - PM2 デプロイメント管理
|
||||
- `/setup-pm` - PM2 を設定
|
||||
- `/sessions` - セッション管理
|
||||
|
||||
### インスティンク機能
|
||||
- `/instinct-import` - インスティンク をインポート
|
||||
- `/instinct-export` - インスティンク をエクスポート
|
||||
- `/instinct-status` - インスティンク ステータス
|
||||
|
||||
## コマンド実行
|
||||
|
||||
Claude Code でコマンドを実行：
|
||||
|
||||
```bash
|
||||
/plan
|
||||
/tdd
|
||||
/code-review
|
||||
/build-fix
|
||||
```
|
||||
|
||||
または AI エージェントから：
|
||||
|
||||
```
|
||||
ユーザー：「新しい機能を計画して」
|
||||
Claude：実行 → `/plan` コマンド
|
||||
```
|
||||
|
||||
## よく使うコマンド
|
||||
|
||||
### 開発ワークフロー
|
||||
1. `/plan` - 実装計画を作成
|
||||
2. `/tdd` - テストを書いて機能を実装
|
||||
3. `/code-review` - コード品質をレビュー
|
||||
4. `/build-fix` - ビルドエラーを修正
|
||||
5. `/e2e` - E2E テストを実行
|
||||
6. `/update-docs` - ドキュメントを更新
|
||||
|
||||
### デバッグワークフロー
|
||||
1. `/verify` - 実装を検証
|
||||
2. `/code-review` - 品質をチェック
|
||||
3. `/build-fix` - エラーを修正
|
||||
4. `/test-coverage` - カバレッジを確認
|
||||
|
||||
## カスタムコマンドを追加
|
||||
|
||||
カスタムコマンドを作成するには：
|
||||
|
||||
1. `commands/` に `.md` ファイルを作成
|
||||
2. Frontmatter を追加：
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Brief description shown in /help
|
||||
---
|
||||
|
||||
# Command Name
|
||||
|
||||
## Purpose
|
||||
|
||||
What this command does.
|
||||
|
||||
## Usage
|
||||
|
||||
\`\`\`
|
||||
/command-name [args]
|
||||
\`\`\`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
3. Step 3
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**覚えておいてください**：コマンドはワークフローを自動化し、繰り返しタスクを簡素化します。チームの一般的なパターンに対する新しいコマンドを作成することをお勧めします。
|
||||
@@ -1,29 +0,0 @@
|
||||
# ビルド修正
|
||||
|
||||
TypeScript およびビルドエラーを段階的に修正します：
|
||||
|
||||
1. ビルドを実行：npm run build または pnpm build
|
||||
|
||||
2. エラー出力を解析：
|
||||
* ファイル別にグループ化
|
||||
* 重大度で並び替え
|
||||
|
||||
3. 各エラーについて：
|
||||
* エラーコンテキストを表示（前後 5 行）
|
||||
* 問題を説明
|
||||
* 修正案を提案
|
||||
* 修正を適用
|
||||
* ビルドを再度実行
|
||||
* エラーが解決されたか確認
|
||||
|
||||
4. 以下の場合に停止：
|
||||
* 修正で新しいエラーが発生
|
||||
* 同じエラーが 3 回の試行後も続く
|
||||
* ユーザーが一時停止をリクエスト
|
||||
|
||||
5. サマリーを表示：
|
||||
* 修正されたエラー
|
||||
* 残りのエラー
|
||||
* 新たに導入されたエラー
|
||||
|
||||
安全のため、一度に 1 つのエラーのみを修正してください！
|
||||
@@ -1,78 +0,0 @@
|
||||
# チェックポイントコマンド
|
||||
|
||||
ワークフロー内でチェックポイントを作成または検証します。
|
||||
|
||||
## 使用します方法
|
||||
|
||||
`/checkpoint [create|verify|list] [name]`
|
||||
|
||||
## チェックポイント作成
|
||||
|
||||
チェックポイントを作成する場合：
|
||||
|
||||
1. `/verify quick` を実行して現在の状態が clean であることを確認
|
||||
2. チェックポイント名を使用して git stash またはコミットを作成
|
||||
3. チェックポイントを `.claude/checkpoints.log` に記録：
|
||||
|
||||
```bash
|
||||
echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
|
||||
```
|
||||
|
||||
4. チェックポイント作成を報告
|
||||
|
||||
## チェックポイント検証
|
||||
|
||||
チェックポイントに対して検証する場合：
|
||||
|
||||
1. ログからチェックポイントを読む
|
||||
|
||||
2. 現在の状態をチェックポイントと比較：
|
||||
* チェックポイント以降に追加されたファイル
|
||||
* チェックポイント以降に修正されたファイル
|
||||
* 現在のテスト成功率と時時の比較
|
||||
* 現在のカバレッジと時時の比較
|
||||
|
||||
3. レポート：
|
||||
|
||||
```
|
||||
CHECKPOINT COMPARISON: $NAME
|
||||
============================
|
||||
Files changed: X
|
||||
Tests: +Y passed / -Z failed
|
||||
Coverage: +X% / -Y%
|
||||
Build: [PASS/FAIL]
|
||||
```
|
||||
|
||||
## チェックポイント一覧表示
|
||||
|
||||
すべてのチェックポイントを以下を含めて表示：
|
||||
|
||||
* 名前
|
||||
* タイムスタンプ
|
||||
* Git SHA
|
||||
* ステータス（current、behind、ahead）
|
||||
|
||||
## ワークフロー
|
||||
|
||||
一般的なチェックポイント流：
|
||||
|
||||
```
|
||||
[Start] --> /checkpoint create "feature-start"
|
||||
|
|
||||
[Implement] --> /checkpoint create "core-done"
|
||||
|
|
||||
[Test] --> /checkpoint verify "core-done"
|
||||
|
|
||||
[Refactor] --> /checkpoint create "refactor-done"
|
||||
|
|
||||
[PR] --> /checkpoint verify "feature-start"
|
||||
```
|
||||
|
||||
## 引数
|
||||
|
||||
$ARGUMENTS:
|
||||
|
||||
* `create <name>` - 指定の名前でチェックポイント作成
|
||||
* `verify <name>` - 指定の名前のチェックポイントに対して検証
|
||||
* `list` - すべてのチェックポイントを表示
|
||||
* `clear` - 古いチェックポイント削除（最新 5 個を保持）
|
||||
@@ -1,43 +0,0 @@
|
||||
# コードレビュー
|
||||
|
||||
未コミットの変更を包括的にセキュリティと品質に対してレビューします：
|
||||
|
||||
1. 変更されたファイルを取得：`git diff --name-only HEAD`
|
||||
|
||||
2. 変更された各ファイルについて、チェック：
|
||||
|
||||
**セキュリティ問題（重大）：**
|
||||
|
||||
* ハードコードされた認証情報、API キー、トークン
|
||||
* SQL インジェクション脆弱性
|
||||
* XSS 脆弱性
|
||||
* 入力検証の不足
|
||||
* 不安全な依存関係
|
||||
* パストラバーサルリスク
|
||||
|
||||
**コード品質（高）：**
|
||||
|
||||
* 関数の長さが 50 行以上
|
||||
* ファイルの長さが 800 行以上
|
||||
* ネストの深さが 4 層以上
|
||||
* エラーハンドリングの不足
|
||||
* `console.log` ステートメント
|
||||
* `TODO`/`FIXME` コメント
|
||||
* 公開 API に JSDoc がない
|
||||
|
||||
**ベストプラクティス（中）：**
|
||||
|
||||
* 可変パターン（イミュータブルパターンを使用しますすべき）
|
||||
* コード/コメント内の絵文字使用します
|
||||
* 新しいコードのテスト不足
|
||||
* アクセシビリティ問題（a11y）
|
||||
|
||||
3. 以下を含むレポートを生成：
|
||||
* 重大度：重大、高、中、低
|
||||
* ファイル位置と行番号
|
||||
* 問題の説明
|
||||
* 推奨される修正方法
|
||||
|
||||
4. 重大または高優先度の問題が見つかった場合、コミットをブロック
|
||||
|
||||
セキュリティ脆弱性を含むコードは絶対に許可しないこと！
|
||||
@@ -1,370 +0,0 @@
|
||||
---
|
||||
description: Playwright を使用してエンドツーエンドテストを生成して実行します。テストジャーニーを作成し、テストを実行し、スクリーンショット/ビデオ/トレースをキャプチャし、アーティファクトをアップロードします。
|
||||
---
|
||||
|
||||
# E2E コマンド
|
||||
|
||||
このコマンドは **e2e-runner** エージェントを呼び出して、Playwright を使用してエンドツーエンドテストを生成、保守、実行します。
|
||||
|
||||
## このコマンドの機能
|
||||
|
||||
1. **テストジャーニー生成** - ユーザーフローの Playwright テストを作成
|
||||
2. **E2E テスト実行** - 複数ブラウザ間でテストを実行
|
||||
3. **アーティファクトキャプチャ** - 失敗時のスクリーンショット、ビデオ、トレース
|
||||
4. **結果アップロード** - HTML レポートと JUnit XML
|
||||
5. **不安定なテスト識別** - 不安定なテストを分離
|
||||
|
||||
## いつ使用しますするか
|
||||
|
||||
以下の場合に `/e2e` を使用します：
|
||||
|
||||
* 重要なユーザージャーニーをテスト（ログイン、取引、支払い）
|
||||
* マルチステップフローがエンドツーエンドで機能することを検証
|
||||
* UI インタラクションとナビゲーションをテスト
|
||||
* フロントエンドとバックエンド間の統合を検証
|
||||
* 本番環境デプロイメント向けの準備
|
||||
|
||||
## 動作方法
|
||||
|
||||
e2e-runner エージェントは：
|
||||
|
||||
1. **ユーザーフローを分析**してテストシナリオを特定
|
||||
2. **ページオブジェクトモデルパターンを使用して Playwright テストを生成**
|
||||
3. **複数ブラウザ間（Chrome、Firefox、Safari）でテストを実行**
|
||||
4. **失敗をキャプチャ**（スクリーンショット、ビデオ、トレース含む）
|
||||
5. **結果とアーティファクトを含むレポートを生成**
|
||||
6. **不安定なテストを特定**して修正を推奨
|
||||
|
||||
## 使用します示例
|
||||
|
||||
````
|
||||
User: /e2e Test the market search and view flow
|
||||
|
||||
Agent (e2e-runner):
|
||||
# E2E Test Generation: Market Search and View Flow
|
||||
|
||||
## Test Scenario Identified
|
||||
|
||||
**User Journey:** Market Search → View Results → Click Market → View Details
|
||||
|
||||
**Test Coverage:**
|
||||
1. Navigate to markets page
|
||||
2. Perform semantic search
|
||||
3. Verify search results
|
||||
4. Click on first result
|
||||
5. Verify market details page loads
|
||||
6. Verify chart renders
|
||||
|
||||
## Generated Test Code
|
||||
|
||||
```typescript
|
||||
// tests/e2e/markets/search-and-view.spec.ts
|
||||
import { test, expect } from '@playwright/test'
|
||||
import { MarketsPage } from '../../pages/MarketsPage'
|
||||
import { MarketDetailsPage } from '../../pages/MarketDetailsPage'
|
||||
|
||||
test.describe('Market Search and View Flow', () => {
|
||||
test('user can search markets and view details', async ({ page }) => {
|
||||
// 1. Navigate to markets page
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Verify page loaded
|
||||
await expect(page).toHaveTitle(/Markets/)
|
||||
await expect(page.locator('h1')).toContainText('Markets')
|
||||
|
||||
// 2. Perform semantic search
|
||||
await marketsPage.searchMarkets('election')
|
||||
|
||||
// Wait for API response
|
||||
await page.waitForResponse(resp =>
|
||||
resp.url().includes('/api/markets/search') && resp.status() === 200
|
||||
)
|
||||
|
||||
// 3. Verify search results
|
||||
const marketCards = marketsPage.marketCards
|
||||
await expect(marketCards.first()).toBeVisible()
|
||||
const resultCount = await marketCards.count()
|
||||
expect(resultCount).toBeGreaterThan(0)
|
||||
|
||||
// Take screenshot of search results
|
||||
await page.screenshot({ path: 'artifacts/search-results.png' })
|
||||
|
||||
// 4. Click on first result
|
||||
const firstMarketTitle = await marketCards.first().textContent()
|
||||
await marketCards.first().click()
|
||||
|
||||
// 5. Verify market details page loads
|
||||
await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/)
|
||||
|
||||
const detailsPage = new MarketDetailsPage(page)
|
||||
await expect(detailsPage.marketName).toBeVisible()
|
||||
await expect(detailsPage.marketDescription).toBeVisible()
|
||||
|
||||
// 6. Verify chart renders
|
||||
await expect(detailsPage.priceChart).toBeVisible()
|
||||
|
||||
// Verify market name matches
|
||||
const detailsTitle = await detailsPage.marketName.textContent()
|
||||
expect(detailsTitle?.toLowerCase()).toContain(
|
||||
firstMarketTitle?.toLowerCase().substring(0, 20) || ''
|
||||
)
|
||||
|
||||
// Take screenshot of market details
|
||||
await page.screenshot({ path: 'artifacts/market-details.png' })
|
||||
})
|
||||
|
||||
test('search with no results shows empty state', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Search for non-existent market
|
||||
await marketsPage.searchMarkets('xyznonexistentmarket123456')
|
||||
|
||||
// Verify empty state
|
||||
await expect(page.locator('[data-testid="no-results"]')).toBeVisible()
|
||||
await expect(page.locator('[data-testid="no-results"]')).toContainText(
|
||||
/no.*results|no.*markets/i
|
||||
)
|
||||
|
||||
const marketCount = await marketsPage.marketCards.count()
|
||||
expect(marketCount).toBe(0)
|
||||
})
|
||||
|
||||
test('can clear search and see all markets again', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Initial market count
|
||||
const initialCount = await marketsPage.marketCards.count()
|
||||
|
||||
// Perform search
|
||||
await marketsPage.searchMarkets('trump')
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Verify filtered results
|
||||
const filteredCount = await marketsPage.marketCards.count()
|
||||
expect(filteredCount).toBeLessThan(initialCount)
|
||||
|
||||
// Clear search
|
||||
await marketsPage.searchInput.clear()
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Verify all markets shown again
|
||||
const finalCount = await marketsPage.marketCards.count()
|
||||
expect(finalCount).toBe(initialCount)
|
||||
})
|
||||
})
|
||||
````
|
||||
|
||||
## テスト実行
|
||||
|
||||
```bash
|
||||
# Run the generated test
|
||||
npx playwright test tests/e2e/markets/search-and-view.spec.ts
|
||||
|
||||
Running 3 tests using 3 workers
|
||||
|
||||
✓ [chromium] › search-and-view.spec.ts:5:3 › user can search markets and view details (4.2s)
|
||||
✓ [chromium] › search-and-view.spec.ts:52:3 › search with no results shows empty state (1.8s)
|
||||
✓ [chromium] › search-and-view.spec.ts:67:3 › can clear search and see all markets again (2.9s)
|
||||
|
||||
3 passed (9.1s)
|
||||
|
||||
Artifacts generated:
|
||||
- artifacts/search-results.png
|
||||
- artifacts/market-details.png
|
||||
- playwright-report/index.html
|
||||
```
|
||||
|
||||
## テストレポート
|
||||
|
||||
```
|
||||
╔══════════════════════════════════════════════════════════════╗
|
||||
║ E2E Test Results ║
|
||||
╠══════════════════════════════════════════════════════════════╣
|
||||
║ Status: ✅ ALL TESTS PASSED ║
|
||||
║ Total: 3 tests ║
|
||||
║ Passed: 3 (100%) ║
|
||||
║ Failed: 0 ║
|
||||
║ Flaky: 0 ║
|
||||
║ Duration: 9.1s ║
|
||||
╚══════════════════════════════════════════════════════════════╝
|
||||
|
||||
Artifacts:
|
||||
📸 Screenshots: 2 files
|
||||
📹 Videos: 0 files (only on failure)
|
||||
🔍 Traces: 0 files (only on failure)
|
||||
📊 HTML Report: playwright-report/index.html
|
||||
|
||||
View report: npx playwright show-report
|
||||
```
|
||||
|
||||
✅ E2E テストスイートは CI/CD 統合の準備ができました！
|
||||
|
||||
````
|
||||
|
||||
## Test Artifacts
|
||||
|
||||
When tests run, the following artifacts are captured:
|
||||
|
||||
**On All Tests:**
|
||||
- HTML Report with timeline and results
|
||||
- JUnit XML for CI integration
|
||||
|
||||
**On Failure Only:**
|
||||
- Screenshot of the failing state
|
||||
- Video recording of the test
|
||||
- Trace file for debugging (step-by-step replay)
|
||||
- Network logs
|
||||
- Console logs
|
||||
|
||||
## Viewing Artifacts
|
||||
|
||||
```bash
|
||||
# View HTML report in browser
|
||||
npx playwright show-report
|
||||
|
||||
# View specific trace file
|
||||
npx playwright show-trace artifacts/trace-abc123.zip
|
||||
|
||||
# Screenshots are saved in artifacts/ directory
|
||||
open artifacts/search-results.png
|
||||
````
|
||||
|
||||
## 不安定なテスト検出
|
||||
|
||||
テストが断続的に失敗する場合：
|
||||
|
||||
```
|
||||
⚠️ FLAKY TEST DETECTED: tests/e2e/markets/trade.spec.ts
|
||||
|
||||
Test passed 7/10 runs (70% pass rate)
|
||||
|
||||
Common failure:
|
||||
"Timeout waiting for element '[data-testid="confirm-btn"]'"
|
||||
|
||||
Recommended fixes:
|
||||
1. Add explicit wait: await page.waitForSelector('[data-testid="confirm-btn"]')
|
||||
2. Increase timeout: { timeout: 10000 }
|
||||
3. Check for race conditions in component
|
||||
4. Verify element is not hidden by animation
|
||||
|
||||
Quarantine recommendation: Mark as test.fixme() until fixed
|
||||
```
|
||||
|
||||
## ブラウザ設定
|
||||
|
||||
デフォルトでは、テストは複数のブラウザで実行されます：
|
||||
|
||||
* ✅ Chromium（デスクトップ Chrome）
|
||||
* ✅ Firefox（デスクトップ）
|
||||
* ✅ WebKit（デスクトップ Safari）
|
||||
* ✅ Mobile Chrome（オプション）
|
||||
|
||||
`playwright.config.ts` で設定してブラウザを調整します。
|
||||
|
||||
## CI/CD 統合
|
||||
|
||||
CI パイプラインに追加：
|
||||
|
||||
```yaml
|
||||
# .github/workflows/e2e.yml
|
||||
- name: Install Playwright
|
||||
run: npx playwright install --with-deps
|
||||
|
||||
- name: Run E2E tests
|
||||
run: npx playwright test
|
||||
|
||||
- name: Upload artifacts
|
||||
if: always()
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: playwright-report
|
||||
path: playwright-report/
|
||||
```
|
||||
|
||||
## PMX 固有の重要フロー
|
||||
|
||||
PMX の場合、以下の E2E テストを優先：
|
||||
|
||||
**🔴 重大（常に成功する必要）：**
|
||||
|
||||
1. ユーザーがウォレットを接続できる
|
||||
2. ユーザーが市場をブラウズできる
|
||||
3. ユーザーが市場を検索できる（セマンティック検索）
|
||||
4. ユーザーが市場の詳細を表示できる
|
||||
5. ユーザーが取引注文を配置できる（テスト資金使用します）
|
||||
6. 市場が正しく決済される
|
||||
7. ユーザーが資金を引き出せる
|
||||
|
||||
**🟡 重要：**
|
||||
|
||||
1. 市場作成フロー
|
||||
2. ユーザープロフィール更新
|
||||
3. リアルタイム価格更新
|
||||
4. チャートレンダリング
|
||||
5. 市場のフィルタリングとソート
|
||||
6. モバイルレスポンシブレイアウト
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
**すべき事：**
|
||||
|
||||
* ✅ 保守性を高めるためページオブジェクトモデルを使用します
|
||||
* ✅ セレクタとして data-testid 属性を使用します
|
||||
* ✅ 任意のタイムアウトではなく API レスポンスを待機
|
||||
* ✅ 重要なユーザージャーニーのエンドツーエンドテスト
|
||||
* ✅ main にマージする前にテストを実行
|
||||
* ✅ テスト失敗時にアーティファクトをレビュー
|
||||
|
||||
**すべきでない事：**
|
||||
|
||||
* ❌ 不安定なセレクタを使用します（CSS クラスは変わる可能性）
|
||||
* ❌ 実装の詳細をテスト
|
||||
* ❌ 本番環境に対してテストを実行
|
||||
* ❌ 不安定なテストを無視
|
||||
* ❌ 失敗時にアーティファクトレビューをスキップ
|
||||
* ❌ E2E テストですべてのエッジケースをテスト（単体テストを使用します）
|
||||
|
||||
## 重要な注意事項
|
||||
|
||||
**PMX にとって重大：**
|
||||
|
||||
* 実際の資金に関わる E2E テストは**テストネット/ステージング環境でのみ実行**する必要があります
|
||||
* 本番環境に対して取引テストを実行しないでください
|
||||
* 金融テストに `test.skip(process.env.NODE_ENV === 'production')` を設定
|
||||
* 少量のテスト資金を持つテストウォレットのみを使用します
|
||||
|
||||
## 他のコマンドとの統合
|
||||
|
||||
* `/plan` を使用してテストする重要なジャーニーを特定
|
||||
* `/tdd` を単体テストに使用します（より速く、より細粒度）
|
||||
* `/e2e` を統合とユーザージャーニーテストに使用します
|
||||
* `/code-review` を使用してテスト品質を検証
|
||||
|
||||
## 関連エージェント
|
||||
|
||||
このコマンドは `~/.claude/agents/e2e-runner.md` の `e2e-runner` エージェントを呼び出します。
|
||||
|
||||
## 快速命令
|
||||
|
||||
```bash
|
||||
# Run all E2E tests
|
||||
npx playwright test
|
||||
|
||||
# Run specific test file
|
||||
npx playwright test tests/e2e/markets/search.spec.ts
|
||||
|
||||
# Run in headed mode (see browser)
|
||||
npx playwright test --headed
|
||||
|
||||
# Debug test
|
||||
npx playwright test --debug
|
||||
|
||||
# Generate test code
|
||||
npx playwright codegen http://localhost:3000
|
||||
|
||||
# View report
|
||||
npx playwright show-report
|
||||
```
|
||||
@@ -1,120 +0,0 @@
|
||||
# Evalコマンド
|
||||
|
||||
評価駆動開発ワークフローを管理します。
|
||||
|
||||
## 使用方法
|
||||
|
||||
`/eval [define|check|report|list] [機能名]`
|
||||
|
||||
## Evalの定義
|
||||
|
||||
`/eval define 機能名`
|
||||
|
||||
新しい評価定義を作成します。
|
||||
|
||||
1. テンプレートを使用して `.claude/evals/機能名.md` を作成:
|
||||
|
||||
```markdown
|
||||
## EVAL: 機能名
|
||||
作成日: $(date)
|
||||
|
||||
### 機能評価
|
||||
- [ ] [機能1の説明]
|
||||
- [ ] [機能2の説明]
|
||||
|
||||
### 回帰評価
|
||||
- [ ] [既存の動作1が正常に動作する]
|
||||
- [ ] [既存の動作2が正常に動作する]
|
||||
|
||||
### 成功基準
|
||||
- 機能評価: pass@3 > 90%
|
||||
- 回帰評価: pass^3 = 100%
|
||||
```
|
||||
|
||||
2. ユーザーに具体的な基準を記入するよう促す
|
||||
|
||||
## Evalのチェック
|
||||
|
||||
`/eval check 機能名`
|
||||
|
||||
機能の評価を実行します。
|
||||
|
||||
1. `.claude/evals/機能名.md` から評価定義を読み込む
|
||||
2. 各機能評価について:
|
||||
- 基準の検証を試行
|
||||
- PASS/FAILを記録
|
||||
- `.claude/evals/機能名.log` に試行を記録
|
||||
3. 各回帰評価について:
|
||||
- 関連するテストを実行
|
||||
- ベースラインと比較
|
||||
- PASS/FAILを記録
|
||||
4. 現在のステータスを報告:
|
||||
|
||||
```
|
||||
EVAL CHECK: 機能名
|
||||
========================
|
||||
機能評価: X/Y 合格
|
||||
回帰評価: X/Y 合格
|
||||
ステータス: 進行中 / 準備完了
|
||||
```
|
||||
|
||||
## Evalの報告
|
||||
|
||||
`/eval report 機能名`
|
||||
|
||||
包括的な評価レポートを生成します。
|
||||
|
||||
```
|
||||
EVAL REPORT: 機能名
|
||||
=========================
|
||||
生成日時: $(date)
|
||||
|
||||
機能評価
|
||||
----------------
|
||||
[eval-1]: PASS (pass@1)
|
||||
[eval-2]: PASS (pass@2) - 再試行が必要でした
|
||||
[eval-3]: FAIL - 備考を参照
|
||||
|
||||
回帰評価
|
||||
----------------
|
||||
[test-1]: PASS
|
||||
[test-2]: PASS
|
||||
[test-3]: PASS
|
||||
|
||||
メトリクス
|
||||
-------
|
||||
機能評価 pass@1: 67%
|
||||
機能評価 pass@3: 100%
|
||||
回帰評価 pass^3: 100%
|
||||
|
||||
備考
|
||||
-----
|
||||
[問題、エッジケース、または観察事項]
|
||||
|
||||
推奨事項
|
||||
--------------
|
||||
[リリース可 / 要修正 / ブロック中]
|
||||
```
|
||||
|
||||
## Evalのリスト表示
|
||||
|
||||
`/eval list`
|
||||
|
||||
すべての評価定義を表示します。
|
||||
|
||||
```
|
||||
EVAL 定義一覧
|
||||
================
|
||||
feature-auth [3/5 合格] 進行中
|
||||
feature-search [5/5 合格] 準備完了
|
||||
feature-export [0/4 合格] 未着手
|
||||
```
|
||||
|
||||
## 引数
|
||||
|
||||
$ARGUMENTS:
|
||||
- `define <名前>` - 新しい評価定義を作成
|
||||
- `check <名前>` - 評価を実行してチェック
|
||||
- `report <名前>` - 完全なレポートを生成
|
||||
- `list` - すべての評価を表示
|
||||
- `clean` - 古い評価ログを削除（最新10件を保持）
|
||||
@@ -1,193 +0,0 @@
|
||||
---
|
||||
name: evolve
|
||||
description: 関連するinstinctsをスキル、コマンド、またはエージェントにクラスター化
|
||||
command: true
|
||||
---
|
||||
|
||||
# Evolveコマンド
|
||||
|
||||
## 実装
|
||||
|
||||
プラグインルートパスを使用してinstinct CLIを実行:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" evolve [--generate]
|
||||
```
|
||||
|
||||
または`CLAUDE_PLUGIN_ROOT`が設定されていない場合(手動インストール):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [--generate]
|
||||
```
|
||||
|
||||
instinctsを分析し、関連するものを上位レベルの構造にクラスター化します:
|
||||
- **Commands**: instinctsがユーザーが呼び出すアクションを記述する場合
|
||||
- **Skills**: instinctsが自動トリガーされる動作を記述する場合
|
||||
- **Agents**: instinctsが複雑な複数ステップのプロセスを記述する場合
|
||||
|
||||
## 使用方法
|
||||
|
||||
```
|
||||
/evolve # すべてのinstinctsを分析して進化を提案
|
||||
/evolve --domain testing # testingドメインのinstinctsのみを進化
|
||||
/evolve --dry-run # 作成せずに作成される内容を表示
|
||||
/evolve --threshold 5 # クラスター化に5以上の関連instinctsが必要
|
||||
```
|
||||
|
||||
## 進化ルール
|
||||
|
||||
### → Command(ユーザー呼び出し)
|
||||
instinctsがユーザーが明示的に要求するアクションを記述する場合:
|
||||
- 「ユーザーが...を求めるとき」に関する複数のinstincts
|
||||
- 「新しいXを作成するとき」のようなトリガーを持つinstincts
|
||||
- 繰り返し可能なシーケンスに従うinstincts
|
||||
|
||||
例:
|
||||
- `new-table-step1`: "データベーステーブルを追加するとき、マイグレーションを作成"
|
||||
- `new-table-step2`: "データベーステーブルを追加するとき、スキーマを更新"
|
||||
- `new-table-step3`: "データベーステーブルを追加するとき、型を再生成"
|
||||
|
||||
→ 作成: `/new-table`コマンド
|
||||
|
||||
### → Skill(自動トリガー)
|
||||
instinctsが自動的に発生すべき動作を記述する場合:
|
||||
- パターンマッチングトリガー
|
||||
- エラーハンドリング応答
|
||||
- コードスタイルの強制
|
||||
|
||||
例:
|
||||
- `prefer-functional`: "関数を書くとき、関数型スタイルを優先"
|
||||
- `use-immutable`: "状態を変更するとき、イミュータブルパターンを使用"
|
||||
- `avoid-classes`: "モジュールを設計するとき、クラスベースの設計を避ける"
|
||||
|
||||
→ 作成: `functional-patterns`スキル
|
||||
|
||||
### → Agent(深さ/分離が必要)
|
||||
instinctsが分離の恩恵を受ける複雑な複数ステップのプロセスを記述する場合:
|
||||
- デバッグワークフロー
|
||||
- リファクタリングシーケンス
|
||||
- リサーチタスク
|
||||
|
||||
例:
|
||||
- `debug-step1`: "デバッグするとき、まずログを確認"
|
||||
- `debug-step2`: "デバッグするとき、失敗しているコンポーネントを分離"
|
||||
- `debug-step3`: "デバッグするとき、最小限の再現を作成"
|
||||
- `debug-step4`: "デバッグするとき、テストで修正を検証"
|
||||
|
||||
→ 作成: `debugger`エージェント
|
||||
|
||||
## 実行内容
|
||||
|
||||
1. `~/.claude/homunculus/instincts/`からすべてのinstinctsを読み取る
|
||||
2. instinctsを以下でグループ化:
|
||||
- ドメインの類似性
|
||||
- トリガーパターンの重複
|
||||
- アクションシーケンスの関係
|
||||
3. 3以上の関連instinctsの各クラスターに対して:
|
||||
- 進化タイプを決定(command/skill/agent)
|
||||
- 適切なファイルを生成
|
||||
- `~/.claude/homunculus/evolved/{commands,skills,agents}/`に保存
|
||||
4. 進化した構造をソースinstinctsにリンク
|
||||
|
||||
## 出力フォーマット
|
||||
|
||||
```
|
||||
🧬 Evolve Analysis
|
||||
==================
|
||||
|
||||
進化の準備ができた3つのクラスターを発見:
|
||||
|
||||
## クラスター1: データベースマイグレーションワークフロー
|
||||
Instincts: new-table-migration, update-schema, regenerate-types
|
||||
Type: Command
|
||||
Confidence: 85%(12件の観測に基づく)
|
||||
|
||||
作成: /new-tableコマンド
|
||||
Files:
|
||||
- ~/.claude/homunculus/evolved/commands/new-table.md
|
||||
|
||||
## クラスター2: 関数型コードスタイル
|
||||
Instincts: prefer-functional, use-immutable, avoid-classes, pure-functions
|
||||
Type: Skill
|
||||
Confidence: 78%(8件の観測に基づく)
|
||||
|
||||
作成: functional-patternsスキル
|
||||
Files:
|
||||
- ~/.claude/homunculus/evolved/skills/functional-patterns.md
|
||||
|
||||
## クラスター3: デバッグプロセス
|
||||
Instincts: debug-check-logs, debug-isolate, debug-reproduce, debug-verify
|
||||
Type: Agent
|
||||
Confidence: 72%(6件の観測に基づく)
|
||||
|
||||
作成: debuggerエージェント
|
||||
Files:
|
||||
- ~/.claude/homunculus/evolved/agents/debugger.md
|
||||
|
||||
---
|
||||
これらのファイルを作成するには`/evolve --execute`を実行してください。
|
||||
```
|
||||
|
||||
## フラグ
|
||||
|
||||
- `--execute`: 実際に進化した構造を作成(デフォルトはプレビュー)
|
||||
- `--dry-run`: 作成せずにプレビュー
|
||||
- `--domain <name>`: 指定したドメインのinstinctsのみを進化
|
||||
- `--threshold <n>`: クラスターを形成するために必要な最小instincts数(デフォルト: 3)
|
||||
- `--type <command|skill|agent>`: 指定したタイプのみを作成
|
||||
|
||||
## 生成されるファイルフォーマット
|
||||
|
||||
### Command
|
||||
```markdown
|
||||
---
|
||||
name: new-table
|
||||
description: マイグレーション、スキーマ更新、型生成で新しいデータベーステーブルを作成
|
||||
command: /new-table
|
||||
evolved_from:
|
||||
- new-table-migration
|
||||
- update-schema
|
||||
- regenerate-types
|
||||
---
|
||||
|
||||
# New Tableコマンド
|
||||
|
||||
[クラスター化されたinstinctsに基づいて生成されたコンテンツ]
|
||||
|
||||
## ステップ
|
||||
1. ...
|
||||
2. ...
|
||||
```
|
||||
|
||||
### Skill
|
||||
```markdown
|
||||
---
|
||||
name: functional-patterns
|
||||
description: 関数型プログラミングパターンを強制
|
||||
evolved_from:
|
||||
- prefer-functional
|
||||
- use-immutable
|
||||
- avoid-classes
|
||||
---
|
||||
|
||||
# Functional Patternsスキル
|
||||
|
||||
[クラスター化されたinstinctsに基づいて生成されたコンテンツ]
|
||||
```
|
||||
|
||||
### Agent
|
||||
```markdown
|
||||
---
|
||||
name: debugger
|
||||
description: 体系的なデバッグエージェント
|
||||
model: sonnet
|
||||
evolved_from:
|
||||
- debug-check-logs
|
||||
- debug-isolate
|
||||
- debug-reproduce
|
||||
---
|
||||
|
||||
# Debuggerエージェント
|
||||
|
||||
[クラスター化されたinstinctsに基づいて生成されたコンテンツ]
|
||||
```
|
||||
@@ -1,183 +0,0 @@
|
||||
---
|
||||
description: Goビルドエラー、go vet警告、リンター問題を段階的に修正します。最小限の外科的修正のためにgo-build-resolverエージェントを呼び出します。
|
||||
---
|
||||
|
||||
# Go Build and Fix
|
||||
|
||||
このコマンドは**go-build-resolver**エージェントを呼び出し、最小限の変更でGoビルドエラーを段階的に修正します。
|
||||
|
||||
## このコマンドの機能
|
||||
|
||||
1. **診断の実行**: `go build`、`go vet`、`staticcheck`を実行
|
||||
2. **エラーの解析**: ファイル別にグループ化し、重要度順にソート
|
||||
3. **段階的修正**: 一度に1つのエラーを修正
|
||||
4. **各修正の検証**: 各変更後にビルドを再実行
|
||||
5. **サマリーのレポート**: 修正されたものと残っているものを表示
|
||||
|
||||
## 使用するタイミング
|
||||
|
||||
以下の場合に`/go-build`を使用します:
|
||||
- `go build ./...`がエラーで失敗する場合
|
||||
- `go vet ./...`が問題を報告する場合
|
||||
- `golangci-lint run`が警告を表示する場合
|
||||
- モジュール依存関係が壊れている場合
|
||||
- ビルドを壊す変更をプルした後
|
||||
|
||||
## 実行される診断コマンド
|
||||
|
||||
```bash
|
||||
# プライマリビルドチェック
|
||||
go build ./...
|
||||
|
||||
# 静的解析
|
||||
go vet ./...
|
||||
|
||||
# 拡張リンティング(利用可能な場合)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# モジュール問題
|
||||
go mod verify
|
||||
go mod tidy -v
|
||||
```
|
||||
|
||||
## セッション例
|
||||
|
||||
```text
|
||||
User: /go-build
|
||||
|
||||
Agent:
|
||||
# Goビルド解決
|
||||
|
||||
## 初期診断
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
internal/service/user.go:25:15: undefined: UserRepository
|
||||
internal/handler/api.go:42:9: cannot use x (type string) as type int
|
||||
internal/handler/api.go:58:2: missing return at end of function
|
||||
```
|
||||
|
||||
エラー検出: 3件
|
||||
|
||||
## 修正1: 未定義の識別子
|
||||
|
||||
File: internal/service/user.go:25
|
||||
Error: undefined: UserRepository
|
||||
Cause: インポート欠落
|
||||
|
||||
```go
|
||||
// インポートを追加
|
||||
import "project/internal/repository"
|
||||
|
||||
// 変更前
|
||||
var repo UserRepository
|
||||
// 変更後
|
||||
var repo repository.UserRepository
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# 残り2件のエラー
|
||||
```
|
||||
|
||||
## 修正2: 型の不一致
|
||||
|
||||
File: internal/handler/api.go:42
|
||||
Error: cannot use x (type string) as type int
|
||||
|
||||
```go
|
||||
// 変更前
|
||||
count := params.Get("count")
|
||||
// 変更後
|
||||
countStr := params.Get("count")
|
||||
count, _ := strconv.Atoi(countStr)
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# 残り1件のエラー
|
||||
```
|
||||
|
||||
## 修正3: 戻り値の欠落
|
||||
|
||||
File: internal/handler/api.go:58
|
||||
Error: missing return at end of function
|
||||
|
||||
```go
|
||||
func GetUser(id string) (*User, error) {
|
||||
if id == "" {
|
||||
return nil, ErrInvalidID
|
||||
}
|
||||
user := findUser(id)
|
||||
// 欠落していた戻り値を追加
|
||||
return user, nil
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
$ go build ./...
|
||||
# ビルド成功!
|
||||
```
|
||||
|
||||
## 最終検証
|
||||
|
||||
```bash
|
||||
$ go vet ./...
|
||||
# 問題なし
|
||||
|
||||
$ go test ./...
|
||||
ok project/internal/service 0.015s
|
||||
ok project/internal/handler 0.023s
|
||||
```
|
||||
|
||||
## サマリー
|
||||
|
||||
| 指標 | 件数 |
|
||||
|--------|-------|
|
||||
| 修正されたビルドエラー | 3 |
|
||||
| 修正されたVet警告 | 0 |
|
||||
| 変更されたファイル | 2 |
|
||||
| 残存問題 | 0 |
|
||||
|
||||
ビルドステータス: ✅ 成功
|
||||
```
|
||||
|
||||
## 修正される一般的なエラー
|
||||
|
||||
| エラー | 典型的な修正 |
|
||||
|-------|-------------|
|
||||
| `undefined: X` | インポートを追加またはタイプミスを修正 |
|
||||
| `cannot use X as Y` | 型変換または代入を修正 |
|
||||
| `missing return` | return文を追加 |
|
||||
| `X does not implement Y` | 欠落しているメソッドを追加 |
|
||||
| `import cycle` | パッケージを再構築 |
|
||||
| `declared but not used` | 変数を削除または使用 |
|
||||
| `cannot find package` | `go get`または`go mod tidy` |
|
||||
|
||||
## 修正戦略
|
||||
|
||||
1. **まずビルドエラー** - コードがコンパイルできる必要がある
|
||||
2. **次にVet警告** - 疑わしい構造を修正
|
||||
3. **最後にLint警告** - スタイルとベストプラクティス
|
||||
4. **一度に1つの修正** - 各変更を検証
|
||||
5. **最小限の変更** - リファクタリングではなく、修正のみ
|
||||
|
||||
## 停止条件
|
||||
|
||||
以下の場合、エージェントは停止してレポートします:
|
||||
- 同じエラーが3回の試行後も持続
|
||||
- 修正がさらなるエラーを引き起こす
|
||||
- アーキテクチャの変更が必要
|
||||
- 外部依存関係が欠落
|
||||
|
||||
## 関連コマンド
|
||||
|
||||
- `/go-test` - ビルド成功後にテストを実行
|
||||
- `/go-review` - コード品質をレビュー
|
||||
- `/verify` - 完全な検証ループ
|
||||
|
||||
## 関連
|
||||
|
||||
- Agent: `agents/go-build-resolver.md`
|
||||
- Skill: `skills/golang-patterns/`
|
||||
@@ -1,148 +0,0 @@
|
||||
---
|
||||
description: 慣用的なパターン、並行性の安全性、エラーハンドリング、セキュリティについての包括的なGoコードレビュー。go-reviewerエージェントを呼び出します。
|
||||
---
|
||||
|
||||
# Go Code Review
|
||||
|
||||
このコマンドは、Go固有の包括的なコードレビューのために**go-reviewer**エージェントを呼び出します。
|
||||
|
||||
## このコマンドの機能
|
||||
|
||||
1. **Go変更の特定**: `git diff`で変更された`.go`ファイルを検出
|
||||
2. **静的解析の実行**: `go vet`、`staticcheck`、`golangci-lint`を実行
|
||||
3. **セキュリティスキャン**: SQLインジェクション、コマンドインジェクション、競合状態をチェック
|
||||
4. **並行性のレビュー**: goroutineの安全性、チャネルの使用、mutexパターンを分析
|
||||
5. **慣用的なGoチェック**: コードがGoの慣習とベストプラクティスに従っていることを確認
|
||||
6. **レポート生成**: 問題を重要度別に分類
|
||||
|
||||
## 使用するタイミング
|
||||
|
||||
以下の場合に`/go-review`を使用します:
|
||||
- Goコードを作成または変更した後
|
||||
- Go変更をコミットする前
|
||||
- Goコードを含むプルリクエストのレビュー時
|
||||
- 新しいGoコードベースへのオンボーディング時
|
||||
- 慣用的なGoパターンの学習時
|
||||
|
||||
## レビューカテゴリ
|
||||
|
||||
### CRITICAL(必須修正)
|
||||
- SQL/コマンドインジェクションの脆弱性
|
||||
- 同期化なしの競合状態
|
||||
- goroutineリーク
|
||||
- ハードコードされた資格情報
|
||||
- 安全でないポインタの使用
|
||||
- クリティカルパスでのエラーの無視
|
||||
|
||||
### HIGH(修正推奨)
|
||||
- コンテキストを含まないエラーラッピングの欠落
|
||||
- エラー戻り値の代わりにパニック
|
||||
- コンテキストが伝播されていない
|
||||
- デッドロックを引き起こすバッファなしチャネル
|
||||
- インターフェース未実装エラー
|
||||
- mutexによる保護の欠落
|
||||
|
||||
### MEDIUM(検討)
|
||||
- 非慣用的なコードパターン
|
||||
- エクスポート時のgodocコメントの欠落
|
||||
- 非効率的な文字列連結
|
||||
- 事前割り当てされていないスライス
|
||||
- テーブル駆動テストが使用されていない
|
||||
|
||||
## 実行される自動チェック
|
||||
|
||||
```bash
|
||||
# 静的解析
|
||||
go vet ./...
|
||||
|
||||
# 高度なチェック(インストールされている場合)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# 競合検出
|
||||
go build -race ./...
|
||||
|
||||
# セキュリティ脆弱性
|
||||
govulncheck ./...
|
||||
```
|
||||
|
||||
## 使用例
|
||||
|
||||
```text
|
||||
User: /go-review
|
||||
|
||||
Agent:
|
||||
# Goコードレビューレポート
|
||||
|
||||
## レビューされたファイル
|
||||
- internal/handler/user.go (変更)
|
||||
- internal/service/auth.go (変更)
|
||||
|
||||
## 静的解析結果
|
||||
✓ go vet: 問題なし
|
||||
✓ staticcheck: 問題なし
|
||||
|
||||
## 発見された問題
|
||||
|
||||
[CRITICAL] 競合状態
|
||||
File: internal/service/auth.go:45
|
||||
Issue: 同期化なしで共有マップにアクセス
|
||||
```go
|
||||
var cache = map[string]*Session{} // 並行アクセス!
|
||||
|
||||
func GetSession(id string) *Session {
|
||||
return cache[id] // 競合状態
|
||||
}
|
||||
```
|
||||
Fix: sync.RWMutexまたはsync.Mapを使用
|
||||
```go
|
||||
var (
|
||||
cache = map[string]*Session{}
|
||||
cacheMu sync.RWMutex
|
||||
)
|
||||
|
||||
func GetSession(id string) *Session {
|
||||
cacheMu.RLock()
|
||||
defer cacheMu.RUnlock()
|
||||
return cache[id]
|
||||
}
|
||||
```
|
||||
|
||||
[HIGH] エラーコンテキストの欠落
|
||||
File: internal/handler/user.go:28
|
||||
Issue: コンテキストなしでエラーを返す
|
||||
```go
|
||||
return err // コンテキストなし
|
||||
```
|
||||
Fix: コンテキストでラップ
|
||||
```go
|
||||
return fmt.Errorf("get user %s: %w", userID, err)
|
||||
```
|
||||
|
||||
## サマリー
|
||||
- CRITICAL: 1
|
||||
- HIGH: 1
|
||||
- MEDIUM: 0
|
||||
|
||||
推奨: ❌ CRITICAL問題が修正されるまでマージをブロック
|
||||
```
|
||||
|
||||
## 承認基準
|
||||
|
||||
| ステータス | 条件 |
|
||||
|--------|-----------|
|
||||
| ✅ 承認 | CRITICALまたはHIGH問題なし |
|
||||
| ⚠️ 警告 | MEDIUM問題のみ(注意してマージ) |
|
||||
| ❌ ブロック | CRITICALまたはHIGH問題が発見された |
|
||||
|
||||
## 他のコマンドとの統合
|
||||
|
||||
- まず`/go-test`を使用してテストが合格することを確認
|
||||
- `/go-build`をビルドエラー発生時に使用
|
||||
- `/go-review`をコミット前に使用
|
||||
- `/code-review`をGo固有でない問題に使用
|
||||
|
||||
## 関連
|
||||
|
||||
- Agent: `agents/go-reviewer.md`
|
||||
- Skills: `skills/golang-patterns/`, `skills/golang-testing/`
|
||||
@@ -1,268 +0,0 @@
|
||||
---
|
||||
description: Goのテスト駆動開発(TDD)ワークフローを適用します。テーブル駆動テストを最初に記述し、その後実装します。go test -coverで80%以上のカバレッジを確認します。
|
||||
---
|
||||
|
||||
# Go TDD コマンド
|
||||
|
||||
このコマンドは、Goのイディオム的なテストパターンを使用したテスト駆動開発手法を適用します。
|
||||
|
||||
## このコマンドの機能
|
||||
|
||||
1. **型/インターフェースの定義**: 関数シグネチャを最初にスキャフォールディング
|
||||
2. **テーブル駆動テストの作成**: 包括的なテストケースを作成(RED)
|
||||
3. **テストの実行**: テストが正しい理由で失敗することを確認
|
||||
4. **コードの実装**: テストをパスするための最小限のコードを記述(GREEN)
|
||||
5. **リファクタリング**: テストをグリーンに保ちながら改善
|
||||
6. **カバレッジの確認**: 80%以上のカバレッジを保証
|
||||
|
||||
## 使用するタイミング
|
||||
|
||||
`/go-test` は次の場合に使用します:
|
||||
- 新しいGo関数の実装時
|
||||
- 既存コードへのテストカバレッジ追加時
|
||||
- バグ修正時(失敗するテストを最初に作成)
|
||||
- 重要なビジネスロジックの構築時
|
||||
- GoでのTDDワークフローの学習時
|
||||
|
||||
## TDD サイクル
|
||||
|
||||
```
|
||||
RED → 失敗するテーブル駆動テストを作成
|
||||
GREEN → テストをパスするための最小限のコードを実装
|
||||
REFACTOR → コードを改善、テストはグリーンを保持
|
||||
REPEAT → 次のテストケースへ
|
||||
```
|
||||
|
||||
## セッション例
|
||||
|
||||
```text
|
||||
User: /go-test メールアドレスを検証する関数が必要です
|
||||
|
||||
Agent:
|
||||
# TDD セッション: メールバリデーター
|
||||
|
||||
## ステップ 1: インターフェースの定義
|
||||
|
||||
```go
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
// ValidateEmail checks if the given string is a valid email address.
|
||||
// Returns nil if valid, error describing the issue otherwise.
|
||||
func ValidateEmail(email string) error {
|
||||
panic("not implemented")
|
||||
}
|
||||
```
|
||||
|
||||
## ステップ 2: テーブル駆動テストの作成 (RED)
|
||||
|
||||
```go
|
||||
// validator/email_test.go
|
||||
package validator
|
||||
|
||||
import (
|
||||
"testing"
|
||||
)
|
||||
|
||||
func TestValidateEmail(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
email string
|
||||
wantErr bool
|
||||
}{
|
||||
// 有効なメールアドレス
|
||||
{"simple email", "user@example.com", false},
|
||||
{"with subdomain", "user@mail.example.com", false},
|
||||
{"with plus", "user+tag@example.com", false},
|
||||
{"with dots", "first.last@example.com", false},
|
||||
|
||||
// 無効なメールアドレス
|
||||
{"empty string", "", true},
|
||||
{"no at sign", "userexample.com", true},
|
||||
{"no domain", "user@", true},
|
||||
{"no local part", "@example.com", true},
|
||||
{"double at", "user@@example.com", true},
|
||||
{"spaces", "user @example.com", true},
|
||||
{"no tld", "user@example", true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
err := ValidateEmail(tt.email)
|
||||
if tt.wantErr && err == nil {
|
||||
t.Errorf("ValidateEmail(%q) = nil; want error", tt.email)
|
||||
}
|
||||
if !tt.wantErr && err != nil {
|
||||
t.Errorf("ValidateEmail(%q) = %v; want nil", tt.email, err)
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## ステップ 3: テストの実行 - 失敗を確認
|
||||
|
||||
```bash
|
||||
$ go test ./validator/...
|
||||
|
||||
--- FAIL: TestValidateEmail (0.00s)
|
||||
--- FAIL: TestValidateEmail/simple_email (0.00s)
|
||||
panic: not implemented
|
||||
|
||||
FAIL
|
||||
```
|
||||
|
||||
✓ テストが期待通り失敗しました(panic)。
|
||||
|
||||
## ステップ 4: 最小限のコード実装 (GREEN)
|
||||
|
||||
```go
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
import (
|
||||
"errors"
|
||||
"regexp"
|
||||
)
|
||||
|
||||
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
|
||||
|
||||
var (
|
||||
ErrEmailEmpty = errors.New("email cannot be empty")
|
||||
ErrEmailInvalid = errors.New("email format is invalid")
|
||||
)
|
||||
|
||||
func ValidateEmail(email string) error {
|
||||
if email == "" {
|
||||
return ErrEmailEmpty
|
||||
}
|
||||
if !emailRegex.MatchString(email) {
|
||||
return ErrEmailInvalid
|
||||
}
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
## ステップ 5: テストの実行 - パスを確認
|
||||
|
||||
```bash
|
||||
$ go test ./validator/...
|
||||
|
||||
PASS
|
||||
ok project/validator 0.003s
|
||||
```
|
||||
|
||||
✓ すべてのテストが通りました!
|
||||
|
||||
## ステップ 6: カバレッジの確認
|
||||
|
||||
```bash
|
||||
$ go test -cover ./validator/...
|
||||
|
||||
PASS
|
||||
coverage: 100.0% of statements
|
||||
ok project/validator 0.003s
|
||||
```
|
||||
|
||||
✓ カバレッジ: 100%
|
||||
|
||||
## TDD 完了!
|
||||
```
|
||||
|
||||
## テストパターン
|
||||
|
||||
### テーブル駆動テスト
|
||||
```go
|
||||
tests := []struct {
|
||||
name string
|
||||
input InputType
|
||||
want OutputType
|
||||
wantErr bool
|
||||
}{
|
||||
{"case 1", input1, want1, false},
|
||||
{"case 2", input2, want2, true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
got, err := Function(tt.input)
|
||||
// assertions
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### 並列テスト
|
||||
```go
|
||||
for _, tt := range tests {
|
||||
tt := tt // Capture
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
t.Parallel()
|
||||
// test body
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### テストヘルパー
|
||||
```go
|
||||
func setupTestDB(t *testing.T) *sql.DB {
|
||||
t.Helper()
|
||||
db := createDB()
|
||||
t.Cleanup(func() { db.Close() })
|
||||
return db
|
||||
}
|
||||
```
|
||||
|
||||
## カバレッジコマンド
|
||||
|
||||
```bash
|
||||
# 基本的なカバレッジ
|
||||
go test -cover ./...
|
||||
|
||||
# カバレッジプロファイル
|
||||
go test -coverprofile=coverage.out ./...
|
||||
|
||||
# ブラウザで表示
|
||||
go tool cover -html=coverage.out
|
||||
|
||||
# 関数ごとのカバレッジ
|
||||
go tool cover -func=coverage.out
|
||||
|
||||
# レース検出付き
|
||||
go test -race -cover ./...
|
||||
```
|
||||
|
||||
## カバレッジ目標
|
||||
|
||||
| コードタイプ | 目標 |
|
||||
|-----------|--------|
|
||||
| 重要なビジネスロジック | 100% |
|
||||
| パブリックAPI | 90%+ |
|
||||
| 一般的なコード | 80%+ |
|
||||
| 生成されたコード | 除外 |
|
||||
|
||||
## TDD ベストプラクティス
|
||||
|
||||
**推奨事項:**
|
||||
- 実装前にテストを最初に書く
|
||||
- 各変更後にテストを実行
|
||||
- 包括的なカバレッジのためにテーブル駆動テストを使用
|
||||
- 実装の詳細ではなく動作をテスト
|
||||
- エッジケースを含める(空、nil、最大値)
|
||||
|
||||
**避けるべき事項:**
|
||||
- テストの前に実装を書く
|
||||
- REDフェーズをスキップする
|
||||
- プライベート関数を直接テスト
|
||||
- テストで`time.Sleep`を使用
|
||||
- 不安定なテストを無視する
|
||||
|
||||
## 関連コマンド
|
||||
|
||||
- `/go-build` - ビルドエラーの修正
|
||||
- `/go-review` - 実装後のコードレビュー
|
||||
- `/verify` - 完全な検証ループの実行
|
||||
|
||||
## 関連
|
||||
|
||||
- スキル: `skills/golang-testing/`
|
||||
- スキル: `skills/tdd-workflow/`
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
name: instinct-export
|
||||
description: チームメイトや他のプロジェクトと共有するためにインスティンクトをエクスポート
|
||||
command: /instinct-export
|
||||
---
|
||||
|
||||
# インスティンクトエクスポートコマンド
|
||||
|
||||
インスティンクトを共有可能な形式でエクスポートします。以下の用途に最適です:
|
||||
- チームメイトとの共有
|
||||
- 新しいマシンへの転送
|
||||
- プロジェクト規約への貢献
|
||||
|
||||
## 使用方法
|
||||
|
||||
```
|
||||
/instinct-export # すべての個人インスティンクトをエクスポート
|
||||
/instinct-export --domain testing # テスト関連のインスティンクトのみをエクスポート
|
||||
/instinct-export --min-confidence 0.7 # 高信頼度のインスティンクトのみをエクスポート
|
||||
/instinct-export --output team-instincts.yaml
|
||||
```
|
||||
|
||||
## 実行内容
|
||||
|
||||
1. `~/.claude/homunculus/instincts/personal/` からインスティンクトを読み込む
|
||||
2. フラグに基づいてフィルタリング
|
||||
3. 機密情報を除外:
|
||||
- セッションIDを削除
|
||||
- ファイルパスを削除（パターンのみ保持）
|
||||
- 「先週」より古いタイムスタンプを削除
|
||||
4. エクスポートファイルを生成
|
||||
|
||||
## 出力形式
|
||||
|
||||
YAMLファイルを作成します:
|
||||
|
||||
```yaml
|
||||
# Instincts Export
|
||||
# Generated: 2025-01-22
|
||||
# Source: personal
|
||||
# Count: 12 instincts
|
||||
|
||||
version: "2.0"
|
||||
exported_by: "continuous-learning-v2"
|
||||
export_date: "2025-01-22T10:30:00Z"
|
||||
|
||||
instincts:
|
||||
- id: prefer-functional-style
|
||||
trigger: "when writing new functions"
|
||||
action: "Use functional patterns over classes"
|
||||
confidence: 0.8
|
||||
domain: code-style
|
||||
observations: 8
|
||||
|
||||
- id: test-first-workflow
|
||||
trigger: "when adding new functionality"
|
||||
action: "Write test first, then implementation"
|
||||
confidence: 0.9
|
||||
domain: testing
|
||||
observations: 12
|
||||
|
||||
- id: grep-before-edit
|
||||
trigger: "when modifying code"
|
||||
action: "Search with Grep, confirm with Read, then Edit"
|
||||
confidence: 0.7
|
||||
domain: workflow
|
||||
observations: 6
|
||||
```
|
||||
|
||||
## プライバシーに関する考慮事項
|
||||
|
||||
エクスポートに含まれる内容:
|
||||
- ✅ トリガーパターン
|
||||
- ✅ アクション
|
||||
- ✅ 信頼度スコア
|
||||
- ✅ ドメイン
|
||||
- ✅ 観察回数
|
||||
|
||||
エクスポートに含まれない内容:
|
||||
- ❌ 実際のコードスニペット
|
||||
- ❌ ファイルパス
|
||||
- ❌ セッション記録
|
||||
- ❌ 個人識別情報
|
||||
|
||||
## フラグ
|
||||
|
||||
- `--domain <name>`: 指定されたドメインのみをエクスポート
|
||||
- `--min-confidence <n>`: 最小信頼度閾値（デフォルト: 0.3）
|
||||
- `--output <file>`: 出力ファイルパス（デフォルト: instincts-export-YYYYMMDD.yaml）
|
||||
- `--format <yaml|json|md>`: 出力形式（デフォルト: yaml）
|
||||
- `--include-evidence`: 証拠テキストを含める（デフォルト: 除外）
|
||||
@@ -1,142 +0,0 @@
|
||||
---
|
||||
name: instinct-import
|
||||
description: チームメイト、Skill Creator、その他のソースからインスティンクトをインポート
|
||||
command: true
|
||||
---
|
||||
|
||||
# インスティンクトインポートコマンド
|
||||
|
||||
## 実装
|
||||
|
||||
プラグインルートパスを使用してインスティンクトCLIを実行します:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" import <file-or-url> [--dry-run] [--force] [--min-confidence 0.7]
|
||||
```
|
||||
|
||||
または、`CLAUDE_PLUGIN_ROOT` が設定されていない場合（手動インストール）:
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <file-or-url>
|
||||
```
|
||||
|
||||
以下のソースからインスティンクトをインポートできます:
|
||||
- チームメイトのエクスポート
|
||||
- Skill Creator（リポジトリ分析）
|
||||
- コミュニティコレクション
|
||||
- 以前のマシンのバックアップ
|
||||
|
||||
## 使用方法
|
||||
|
||||
```
|
||||
/instinct-import team-instincts.yaml
|
||||
/instinct-import https://github.com/org/repo/instincts.yaml
|
||||
/instinct-import --from-skill-creator acme/webapp
|
||||
```
|
||||
|
||||
## 実行内容
|
||||
|
||||
1. インスティンクトファイルを取得（ローカルパスまたはURL）
|
||||
2. 形式を解析して検証
|
||||
3. 既存のインスティンクトとの重複をチェック
|
||||
4. 新しいインスティンクトをマージまたは追加
|
||||
5. `~/.claude/homunculus/instincts/inherited/` に保存
|
||||
|
||||
## インポートプロセス
|
||||
|
||||
```
|
||||
📥 Importing instincts from: team-instincts.yaml
|
||||
================================================
|
||||
|
||||
Found 12 instincts to import.
|
||||
|
||||
Analyzing conflicts...
|
||||
|
||||
## New Instincts (8)
|
||||
These will be added:
|
||||
✓ use-zod-validation (confidence: 0.7)
|
||||
✓ prefer-named-exports (confidence: 0.65)
|
||||
✓ test-async-functions (confidence: 0.8)
|
||||
...
|
||||
|
||||
## Duplicate Instincts (3)
|
||||
Already have similar instincts:
|
||||
⚠️ prefer-functional-style
|
||||
Local: 0.8 confidence, 12 observations
|
||||
Import: 0.7 confidence
|
||||
→ Keep local (higher confidence)
|
||||
|
||||
⚠️ test-first-workflow
|
||||
Local: 0.75 confidence
|
||||
Import: 0.9 confidence
|
||||
→ Update to import (higher confidence)
|
||||
|
||||
## Conflicting Instincts (1)
|
||||
These contradict local instincts:
|
||||
❌ use-classes-for-services
|
||||
Conflicts with: avoid-classes
|
||||
→ Skip (requires manual resolution)
|
||||
|
||||
---
|
||||
Import 8 new, update 1, skip 3?
|
||||
```
|
||||
|
||||
## マージ戦略
|
||||
|
||||
### 重複の場合
|
||||
既存のインスティンクトと一致するインスティンクトをインポートする場合:
|
||||
- **高い信頼度が優先**: より高い信頼度を持つ方を保持
|
||||
- **証拠をマージ**: 観察回数を結合
|
||||
- **タイムスタンプを更新**: 最近検証されたものとしてマーク
|
||||
|
||||
### 競合の場合
|
||||
既存のインスティンクトと矛盾するインスティンクトをインポートする場合:
|
||||
- **デフォルトでスキップ**: 競合するインスティンクトはインポートしない
|
||||
- **レビュー用にフラグ**: 両方を注意が必要としてマーク
|
||||
- **手動解決**: ユーザーがどちらを保持するか決定
|
||||
|
||||
## ソーストラッキング
|
||||
|
||||
インポートされたインスティンクトは以下のようにマークされます:
|
||||
```yaml
|
||||
source: "inherited"
|
||||
imported_from: "team-instincts.yaml"
|
||||
imported_at: "2025-01-22T10:30:00Z"
|
||||
original_source: "session-observation" # or "repo-analysis"
|
||||
```
|
||||
|
||||
## Skill Creator統合
|
||||
|
||||
Skill Creatorからインポートする場合:
|
||||
|
||||
```
|
||||
/instinct-import --from-skill-creator acme/webapp
|
||||
```
|
||||
|
||||
これにより、リポジトリ分析から生成されたインスティンクトを取得します:
|
||||
- ソース: `repo-analysis`
|
||||
- 初期信頼度が高い（0.7以上）
|
||||
- ソースリポジトリにリンク
|
||||
|
||||
## フラグ
|
||||
|
||||
- `--dry-run`: インポートせずにプレビュー
|
||||
- `--force`: 競合があってもインポート
|
||||
- `--merge-strategy <higher|local|import>`: 重複の処理方法
|
||||
- `--from-skill-creator <owner/repo>`: Skill Creator分析からインポート
|
||||
- `--min-confidence <n>`: 閾値以上のインスティンクトのみをインポート
|
||||
|
||||
## 出力
|
||||
|
||||
インポート後:
|
||||
```
|
||||
✅ Import complete!
|
||||
|
||||
Added: 8 instincts
|
||||
Updated: 1 instinct
|
||||
Skipped: 3 instincts (2 duplicates, 1 conflict)
|
||||
|
||||
New instincts saved to: ~/.claude/homunculus/instincts/inherited/
|
||||
|
||||
Run /instinct-status to see all instincts.
|
||||
```
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
name: instinct-status
|
||||
description: すべての学習済みインスティンクトと信頼度レベルを表示
|
||||
command: true
|
||||
---
|
||||
|
||||
# インスティンクトステータスコマンド
|
||||
|
||||
すべての学習済みインスティンクトを信頼度スコアとともに、ドメインごとにグループ化して表示します。
|
||||
|
||||
## 実装
|
||||
|
||||
プラグインルートパスを使用してインスティンクトCLIを実行します:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" status
|
||||
```
|
||||
|
||||
または、`CLAUDE_PLUGIN_ROOT` が設定されていない場合（手動インストール）の場合は:
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py status
|
||||
```
|
||||
|
||||
## 使用方法
|
||||
|
||||
```
|
||||
/instinct-status
|
||||
/instinct-status --domain code-style
|
||||
/instinct-status --low-confidence
|
||||
```
|
||||
|
||||
## 実行内容
|
||||
|
||||
1. `~/.claude/homunculus/instincts/personal/` からすべてのインスティンクトファイルを読み込む
|
||||
2. `~/.claude/homunculus/instincts/inherited/` から継承されたインスティンクトを読み込む
|
||||
3. ドメインごとにグループ化し、信頼度バーとともに表示
|
||||
|
||||
## 出力形式
|
||||
|
||||
```
|
||||
📊 Instinct Status
|
||||
==================
|
||||
|
||||
## Code Style (4 instincts)
|
||||
|
||||
### prefer-functional-style
|
||||
Trigger: when writing new functions
|
||||
Action: Use functional patterns over classes
|
||||
Confidence: ████████░░ 80%
|
||||
Source: session-observation | Last updated: 2025-01-22
|
||||
|
||||
### use-path-aliases
|
||||
Trigger: when importing modules
|
||||
Action: Use @/ path aliases instead of relative imports
|
||||
Confidence: ██████░░░░ 60%
|
||||
Source: repo-analysis (github.com/acme/webapp)
|
||||
|
||||
## Testing (2 instincts)
|
||||
|
||||
### test-first-workflow
|
||||
Trigger: when adding new functionality
|
||||
Action: Write test first, then implementation
|
||||
Confidence: █████████░ 90%
|
||||
Source: session-observation
|
||||
|
||||
## Workflow (3 instincts)
|
||||
|
||||
### grep-before-edit
|
||||
Trigger: when modifying code
|
||||
Action: Search with Grep, confirm with Read, then Edit
|
||||
Confidence: ███████░░░ 70%
|
||||
Source: session-observation
|
||||
|
||||
---
|
||||
Total: 9 instincts (4 personal, 5 inherited)
|
||||
Observer: Running (last analysis: 5 min ago)
|
||||
```
|
||||
|
||||
## フラグ
|
||||
|
||||
- `--domain <name>`: ドメインでフィルタリング（code-style、testing、gitなど）
|
||||
- `--low-confidence`: 信頼度 < 0.5のインスティンクトのみを表示
|
||||
- `--high-confidence`: 信頼度 >= 0.7のインスティンクトのみを表示
|
||||
- `--source <type>`: ソースでフィルタリング（session-observation、repo-analysis、inherited）
|
||||
- `--json`: プログラムで使用するためにJSON形式で出力
|
||||
@@ -1,70 +0,0 @@
|
||||
# /learn - 再利用可能なパターンの抽出
|
||||
|
||||
現在のセッションを分析し、スキルとして保存する価値のあるパターンを抽出します。
|
||||
|
||||
## トリガー
|
||||
|
||||
非自明な問題を解決したときに、セッション中の任意の時点で `/learn` を実行します。
|
||||
|
||||
## 抽出する内容
|
||||
|
||||
以下を探します:
|
||||
|
||||
1. **エラー解決パターン**
|
||||
- どのようなエラーが発生したか
|
||||
- 根本原因は何か
|
||||
- 何が修正したか
|
||||
- 類似のエラーに対して再利用可能か
|
||||
|
||||
2. **デバッグ技術**
|
||||
- 自明ではないデバッグ手順
|
||||
- うまく機能したツールの組み合わせ
|
||||
- 診断パターン
|
||||
|
||||
3. **回避策**
|
||||
- ライブラリの癖
|
||||
- APIの制限
|
||||
- バージョン固有の修正
|
||||
|
||||
4. **プロジェクト固有のパターン**
|
||||
- 発見されたコードベースの規約
|
||||
- 行われたアーキテクチャの決定
|
||||
- 統合パターン
|
||||
|
||||
## 出力形式
|
||||
|
||||
`~/.claude/skills/learned/[パターン名].md` にスキルファイルを作成します:
|
||||
|
||||
```markdown
|
||||
# [説明的なパターン名]
|
||||
|
||||
**抽出日:** [日付]
|
||||
**コンテキスト:** [いつ適用されるかの簡単な説明]
|
||||
|
||||
## 問題
|
||||
[解決する問題 - 具体的に]
|
||||
|
||||
## 解決策
|
||||
[パターン/技術/回避策]
|
||||
|
||||
## 例
|
||||
[該当する場合、コード例]
|
||||
|
||||
## 使用タイミング
|
||||
[トリガー条件 - このスキルを有効にすべき状況]
|
||||
```
|
||||
|
||||
## プロセス
|
||||
|
||||
1. セッションで抽出可能なパターンをレビュー
|
||||
2. 最も価値がある/再利用可能な洞察を特定
|
||||
3. スキルファイルを下書き
|
||||
4. 保存前にユーザーに確認を求める
|
||||
5. `~/.claude/skills/learned/` に保存
|
||||
|
||||
## 注意事項
|
||||
|
||||
- 些細な修正（タイプミス、単純な構文エラー）は抽出しない
|
||||
- 一度限りの問題（特定のAPIの障害など）は抽出しない
|
||||
- 将来のセッションで時間を節約できるパターンに焦点を当てる
|
||||
- スキルは集中させる - 1つのスキルに1つのパターン
|
||||
@@ -1,158 +0,0 @@
|
||||
# Backend - バックエンド中心の開発
|
||||
|
||||
バックエンド中心のワークフロー(調査 → アイデア創出 → 計画 → 実装 → 最適化 → レビュー)、Codex主導。
|
||||
|
||||
## 使用方法
|
||||
|
||||
```bash
|
||||
/backend <バックエンドタスクの説明>
|
||||
```
|
||||
|
||||
## コンテキスト
|
||||
|
||||
- バックエンドタスク: $ARGUMENTS
|
||||
- Codex主導、Geminiは補助的な参照用
|
||||
- 適用範囲: API設計、アルゴリズム実装、データベース最適化、ビジネスロジック
|
||||
|
||||
## 役割
|
||||
|
||||
あなたは**バックエンドオーケストレーター**として、サーバーサイドタスクのためのマルチモデル連携を調整します(調査 → アイデア創出 → 計画 → 実装 → 最適化 → レビュー)。
|
||||
|
||||
**連携モデル**:
|
||||
- **Codex** – バックエンドロジック、アルゴリズム(**バックエンドの権威、信頼できる**)
|
||||
- **Gemini** – フロントエンドの視点(**バックエンドの意見は参考のみ**)
|
||||
- **Claude(自身)** – オーケストレーション、計画、実装、配信
|
||||
|
||||
---
|
||||
|
||||
## マルチモデル呼び出し仕様
|
||||
|
||||
**呼び出し構文**:
|
||||
|
||||
```
|
||||
# 新規セッション呼び出し
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
|
||||
Context: <前のフェーズからのプロジェクトコンテキストと分析>
|
||||
</TASK>
|
||||
OUTPUT: 期待される出力形式
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
|
||||
# セッション再開呼び出し
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
|
||||
Context: <前のフェーズからのプロジェクトコンテキストと分析>
|
||||
</TASK>
|
||||
OUTPUT: 期待される出力形式
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
```
|
||||
|
||||
**ロールプロンプト**:
|
||||
|
||||
| フェーズ | Codex |
|
||||
|-------|-------|
|
||||
| 分析 | `~/.claude/.ccg/prompts/codex/analyzer.md` |
|
||||
| 計画 | `~/.claude/.ccg/prompts/codex/architect.md` |
|
||||
| レビュー | `~/.claude/.ccg/prompts/codex/reviewer.md` |
|
||||
|
||||
**セッション再利用**: 各呼び出しは`SESSION_ID: xxx`を返します。後続のフェーズでは`resume xxx`を使用してください。フェーズ2で`CODEX_SESSION`を保存し、フェーズ3と5で`resume`を使用します。
|
||||
|
||||
---
|
||||
|
||||
## コミュニケーションガイドライン
|
||||
|
||||
1. レスポンスの開始時にモードラベル`[Mode: X]`を付ける、初期は`[Mode: Research]`
|
||||
2. 厳格な順序に従う: `Research → Ideation → Plan → Execute → Optimize → Review`
|
||||
3. 必要に応じて`AskUserQuestion`ツールを使用してユーザーとやり取りする(例: 確認/選択/承認)
|
||||
|
||||
---
|
||||
|
||||
## コアワークフロー
|
||||
|
||||
### フェーズ 0: プロンプト強化(オプション)
|
||||
|
||||
`[Mode: Prepare]` - ace-tool MCPが利用可能な場合、`mcp__ace-tool__enhance_prompt`を呼び出し、**後続のCodex呼び出しのために元の$ARGUMENTSを強化結果で置き換える**
|
||||
|
||||
### フェーズ 1: 調査
|
||||
|
||||
`[Mode: Research]` - 要件の理解とコンテキストの収集
|
||||
|
||||
1. **コード取得**(ace-tool MCPが利用可能な場合): `mcp__ace-tool__search_context`を呼び出して既存のAPI、データモデル、サービスアーキテクチャを取得
|
||||
2. 要件の完全性スコア(0-10): >=7で継続、<7で停止して補足
|
||||
|
||||
### フェーズ 2: アイデア創出
|
||||
|
||||
`[Mode: Ideation]` - Codex主導の分析
|
||||
|
||||
**Codexを呼び出す必要があります**(上記の呼び出し仕様に従う):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md`
|
||||
- Requirement: 強化された要件(または強化されていない場合は$ARGUMENTS)
|
||||
- Context: フェーズ1からのプロジェクトコンテキスト
|
||||
- OUTPUT: 技術的な実現可能性分析、推奨ソリューション(少なくとも2つ)、リスク評価
|
||||
|
||||
**SESSION_ID**(`CODEX_SESSION`)を保存して後続のフェーズで再利用します。
|
||||
|
||||
ソリューション(少なくとも2つ)を出力し、ユーザーの選択を待ちます。
|
||||
|
||||
### フェーズ 3: 計画
|
||||
|
||||
`[Mode: Plan]` - Codex主導の計画
|
||||
|
||||
**Codexを呼び出す必要があります**(`resume <CODEX_SESSION>`を使用してセッションを再利用):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md`
|
||||
- Requirement: ユーザーが選択したソリューション
|
||||
- Context: フェーズ2からの分析結果
|
||||
- OUTPUT: ファイル構造、関数/クラス設計、依存関係
|
||||
|
||||
Claudeが計画を統合し、ユーザーの承認後に`.claude/plan/task-name.md`に保存します。
|
||||
|
||||
### フェーズ 4: 実装
|
||||
|
||||
`[Mode: Execute]` - コード開発
|
||||
|
||||
- 承認された計画に厳密に従う
|
||||
- 既存プロジェクトのコード標準に従う
|
||||
- エラーハンドリング、セキュリティ、パフォーマンス最適化を保証
|
||||
|
||||
### フェーズ 5: 最適化
|
||||
|
||||
`[Mode: Optimize]` - Codex主導のレビュー
|
||||
|
||||
**Codexを呼び出す必要があります**(上記の呼び出し仕様に従う):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md`
|
||||
- Requirement: 以下のバックエンドコード変更をレビュー
|
||||
- Context: git diffまたはコード内容
|
||||
- OUTPUT: セキュリティ、パフォーマンス、エラーハンドリング、APIコンプライアンスの問題リスト
|
||||
|
||||
レビューフィードバックを統合し、ユーザー確認後に最適化を実行します。
|
||||
|
||||
### フェーズ 6: 品質レビュー
|
||||
|
||||
`[Mode: Review]` - 最終評価
|
||||
|
||||
- 計画に対する完成度をチェック
|
||||
- テストを実行して機能を検証
|
||||
- 問題と推奨事項を報告
|
||||
|
||||
---
|
||||
|
||||
## 重要なルール
|
||||
|
||||
1. **Codexのバックエンド意見は信頼できる**
|
||||
2. **Geminiのバックエンド意見は参考のみ**
|
||||
3. 外部モデルは**ファイルシステムへの書き込みアクセスがゼロ**
|
||||
4. Claudeがすべてのコード書き込みとファイル操作を処理
|
||||
@@ -1,310 +0,0 @@
|
||||
# Execute - マルチモデル協調実装
|
||||
|
||||
マルチモデル協調実装 - 計画からプロトタイプを取得 → Claudeがリファクタリングして実装 → マルチモデル監査と配信。
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## コアプロトコル
|
||||
|
||||
- **言語プロトコル**: ツール/モデルとやり取りする際は**英語**を使用し、ユーザーとはユーザーの言語でコミュニケーション
|
||||
- **コード主権**: 外部モデルは**ファイルシステムへの書き込みアクセスがゼロ**、すべての変更はClaudeが実行
|
||||
- **ダーティプロトタイプのリファクタリング**: Codex/Geminiの統一差分を「ダーティプロトタイプ」として扱い、本番グレードのコードにリファクタリングする必要がある
|
||||
- **損失制限メカニズム**: 現在のフェーズの出力が検証されるまで次のフェーズに進まない
|
||||
- **前提条件**: `/ccg:plan`の出力に対してユーザーが明示的に「Y」と返信した後のみ実行(欠落している場合は最初に確認が必要)
|
||||
|
||||
---
|
||||
|
||||
## マルチモデル呼び出し仕様
|
||||
|
||||
**呼び出し構文**(並列: `run_in_background: true`を使用):
|
||||
|
||||
```
|
||||
# セッション再開呼び出し(推奨) - 実装プロトタイプ
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <タスクの説明>
|
||||
Context: <計画内容 + 対象ファイル>
|
||||
</TASK>
|
||||
OUTPUT: 統一差分パッチのみ。実際の変更を厳格に禁止。
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
|
||||
# 新規セッション呼び出し - 実装プロトタイプ
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <タスクの説明>
|
||||
Context: <計画内容 + 対象ファイル>
|
||||
</TASK>
|
||||
OUTPUT: 統一差分パッチのみ。実際の変更を厳格に禁止。
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
```
|
||||
|
||||
**監査呼び出し構文**(コードレビュー/監査):
|
||||
|
||||
```
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Scope: 最終的なコード変更を監査。
|
||||
Inputs:
|
||||
- 適用されたパッチ(git diff / 最終的な統一差分)
|
||||
- 変更されたファイル(必要に応じて関連する抜粋)
|
||||
Constraints:
|
||||
- ファイルを変更しない。
|
||||
- ファイルシステムアクセスを前提とするツールコマンドを出力しない。
|
||||
</TASK>
|
||||
OUTPUT:
|
||||
1) 優先順位付けされた問題リスト(重大度、ファイル、根拠)
|
||||
2) 具体的な修正; コード変更が必要な場合は、フェンスされたコードブロックに統一差分パッチを含める。
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
```
|
||||
|
||||
**モデルパラメータの注意事項**:
|
||||
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini`を使用する場合、`--gemini-model gemini-3-pro-preview`で置き換える(末尾のスペースに注意); codexの場合は空文字列を使用
|
||||
|
||||
**ロールプロンプト**:
|
||||
|
||||
| フェーズ | Codex | Gemini |
|
||||
|-------|-------|--------|
|
||||
| 実装 | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/frontend.md` |
|
||||
| レビュー | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
|
||||
|
||||
**セッション再利用**: `/ccg:plan`がSESSION_IDを提供した場合、`resume <SESSION_ID>`を使用してコンテキストを再利用します。
|
||||
|
||||
**バックグラウンドタスクの待機**(最大タイムアウト600000ms = 10分):
|
||||
|
||||
```
|
||||
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
|
||||
```
|
||||
|
||||
**重要**:
|
||||
- `timeout: 600000`を指定する必要があります。指定しないとデフォルトの30秒で早期タイムアウトが発生します
|
||||
- 10分後もまだ完了していない場合、`TaskOutput`でポーリングを継続し、**プロセスを強制終了しない**
|
||||
- タイムアウトにより待機がスキップされた場合、**`AskUserQuestion`を呼び出してユーザーに待機を継続するか、タスクを強制終了するかを尋ねる必要があります**
|
||||
|
||||
---
|
||||
|
||||
## 実行ワークフロー
|
||||
|
||||
**実行タスク**: $ARGUMENTS
|
||||
|
||||
### フェーズ 0: 計画の読み取り
|
||||
|
||||
`[Mode: Prepare]`
|
||||
|
||||
1. **入力タイプの識別**:
|
||||
- 計画ファイルパス(例: `.claude/plan/xxx.md`)
|
||||
- 直接的なタスク説明
|
||||
|
||||
2. **計画内容の読み取り**:
|
||||
- 計画ファイルパスが提供された場合、読み取りと解析
|
||||
- 抽出: タスクタイプ、実装ステップ、キーファイル、SESSION_ID
|
||||
|
||||
3. **実行前の確認**:
|
||||
- 入力が「直接的なタスク説明」または計画に`SESSION_ID` / キーファイルが欠落している場合: 最初にユーザーに確認
|
||||
- ユーザーが計画に「Y」と返信したことを確認できない場合: 進む前に再度確認する必要がある
|
||||
|
||||
4. **タスクタイプのルーティング**:
|
||||
|
||||
| タスクタイプ | 検出 | ルート |
|
||||
|-----------|-----------|-------|
|
||||
| **フロントエンド** | ページ、コンポーネント、UI、スタイル、レイアウト | Gemini |
|
||||
| **バックエンド** | API、インターフェース、データベース、ロジック、アルゴリズム | Codex |
|
||||
| **フルスタック** | フロントエンドとバックエンドの両方を含む | Codex ∥ Gemini 並列 |
|
||||
|
||||
---
|
||||
|
||||
### フェーズ 1: クイックコンテキスト取得
|
||||
|
||||
`[Mode: Retrieval]`
|
||||
|
||||
**MCPツールを使用したクイックコンテキスト取得が必須です。ファイルを1つずつ手動で読まないでください**
|
||||
|
||||
計画の「キーファイル」リストに基づいて、`mcp__ace-tool__search_context`を呼び出します:
|
||||
|
||||
```
|
||||
mcp__ace-tool__search_context({
|
||||
query: "<計画内容に基づくセマンティッククエリ、キーファイル、モジュール、関数名を含む>",
|
||||
project_root_path: "$PWD"
|
||||
})
|
||||
```
|
||||
|
||||
**取得戦略**:
|
||||
- 計画の「キーファイル」テーブルから対象パスを抽出
|
||||
- カバー範囲のセマンティッククエリを構築: エントリファイル、依存モジュール、関連する型定義
|
||||
- 結果が不十分な場合、1-2回の再帰的取得を追加
|
||||
- **決して**Bash + find/lsを使用してプロジェクト構造を手動で探索しない
|
||||
|
||||
**取得後**:
|
||||
- 取得したコードスニペットを整理
|
||||
- 実装のための完全なコンテキストを確認
|
||||
- フェーズ3に進む
|
||||
|
||||
---
|
||||
|
||||
### フェーズ 3: プロトタイプの取得
|
||||
|
||||
`[Mode: Prototype]`
|
||||
|
||||
**タスクタイプに基づいてルーティング**:
|
||||
|
||||
#### ルート A: フロントエンド/UI/スタイル → Gemini
|
||||
|
||||
**制限**: コンテキスト < 32kトークン
|
||||
|
||||
1. Geminiを呼び出す(`~/.claude/.ccg/prompts/gemini/frontend.md`を使用)
|
||||
2. 入力: 計画内容 + 取得したコンテキスト + 対象ファイル
|
||||
3. OUTPUT: `統一差分パッチのみ。実際の変更を厳格に禁止。`
|
||||
4. **Geminiはフロントエンドデザインの権威であり、そのCSS/React/Vueプロトタイプは最終的なビジュアルベースライン**
|
||||
5. **警告**: Geminiのバックエンドロジック提案を無視
|
||||
6. 計画に`GEMINI_SESSION`が含まれている場合: `resume <GEMINI_SESSION>`を優先
|
||||
|
||||
#### ルート B: バックエンド/ロジック/アルゴリズム → Codex
|
||||
|
||||
1. Codexを呼び出す(`~/.claude/.ccg/prompts/codex/architect.md`を使用)
|
||||
2. 入力: 計画内容 + 取得したコンテキスト + 対象ファイル
|
||||
3. OUTPUT: `統一差分パッチのみ。実際の変更を厳格に禁止。`
|
||||
4. **Codexはバックエンドロジックの権威であり、その論理的推論とデバッグ機能を活用**
|
||||
5. 計画に`CODEX_SESSION`が含まれている場合: `resume <CODEX_SESSION>`を優先
|
||||
|
||||
#### ルート C: フルスタック → 並列呼び出し
|
||||
|
||||
1. **並列呼び出し**(`run_in_background: true`):
|
||||
- Gemini: フロントエンド部分を処理
|
||||
- Codex: バックエンド部分を処理
|
||||
2. `TaskOutput`で両方のモデルの完全な結果を待つ
|
||||
3. それぞれ計画から対応する`SESSION_ID`を使用して`resume`(欠落している場合は新しいセッションを作成)
|
||||
|
||||
**上記の`マルチモデル呼び出し仕様`の`重要`指示に従ってください**
|
||||
|
||||
---
|
||||
|
||||
### フェーズ 4: コード実装
|
||||
|
||||
`[Mode: Implement]`
|
||||
|
||||
**コード主権者としてのClaudeが以下のステップを実行**:
|
||||
|
||||
1. **差分の読み取り**: Codex/Geminiが返した統一差分パッチを解析
|
||||
|
||||
2. **メンタルサンドボックス**:
|
||||
- 対象ファイルへの差分の適用をシミュレート
|
||||
- 論理的一貫性をチェック
|
||||
- 潜在的な競合や副作用を特定
|
||||
|
||||
3. **リファクタリングとクリーンアップ**:
|
||||
- 「ダーティプロトタイプ」を**高い可読性、保守性、エンタープライズグレードのコード**にリファクタリング
|
||||
- 冗長なコードを削除
|
||||
- プロジェクトの既存コード標準への準拠を保証
|
||||
- **必要でない限りコメント/ドキュメントを生成しない**、コードは自己説明的であるべき
|
||||
|
||||
4. **最小限のスコープ**:
|
||||
- 変更は要件の範囲内のみに限定
|
||||
- 副作用の**必須レビュー**
|
||||
- 対象を絞った修正を実施
|
||||
|
||||
5. **変更の適用**:
|
||||
- Edit/Writeツールを使用して実際の変更を実行
|
||||
- **必要なコードのみを変更**、ユーザーの他の既存機能に影響を与えない
|
||||
|
||||
6. **自己検証**(強く推奨):
|
||||
- プロジェクトの既存のlint / typecheck / testsを実行(最小限の関連スコープを優先)
|
||||
- 失敗した場合: 最初にリグレッションを修正し、その後フェーズ5に進む
|
||||
|
||||
---
|
||||
|
||||
### フェーズ 5: 監査と配信
|
||||
|
||||
`[Mode: Audit]`
|
||||
|
||||
#### 5.1 自動監査
|
||||
|
||||
**変更が有効になった後、すぐにCodexとGeminiを並列呼び出ししてコードレビューを実施する必要があります**:
|
||||
|
||||
1. **Codexレビュー**(`run_in_background: true`):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md`
|
||||
- 入力: 変更された差分 + 対象ファイル
|
||||
- フォーカス: セキュリティ、パフォーマンス、エラーハンドリング、ロジックの正確性
|
||||
|
||||
2. **Geminiレビュー**(`run_in_background: true`):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md`
|
||||
- 入力: 変更された差分 + 対象ファイル
|
||||
- フォーカス: アクセシビリティ、デザインの一貫性、ユーザーエクスペリエンス
|
||||
|
||||
`TaskOutput`で両方のモデルの完全なレビュー結果を待ちます。コンテキストの一貫性のため、フェーズ3のセッション(`resume <SESSION_ID>`)の再利用を優先します。
|
||||
|
||||
#### 5.2 統合と修正
|
||||
|
||||
1. Codex + Geminiレビューフィードバックを統合
|
||||
2. 信頼ルールに基づいて重み付け: バックエンドはCodexに従い、フロントエンドはGeminiに従う
|
||||
3. 必要な修正を実行
|
||||
4. 必要に応じてフェーズ5.1を繰り返す(リスクが許容可能になるまで)
|
||||
|
||||
#### 5.3 配信確認
|
||||
|
||||
監査が通過した後、ユーザーに報告:
|
||||
|
||||
```markdown
|
||||
## 実装完了
|
||||
|
||||
### 変更の概要
|
||||
| ファイル | 操作 | 説明 |
|
||||
|------|-----------|-------------|
|
||||
| path/to/file.ts | 変更 | 説明 |
|
||||
|
||||
### 監査結果
|
||||
- Codex: <合格/N個の問題を発見>
|
||||
- Gemini: <合格/N個の問題を発見>
|
||||
|
||||
### 推奨事項
|
||||
1. [ ] <推奨されるテスト手順>
|
||||
2. [ ] <推奨される検証手順>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 重要なルール
|
||||
|
||||
1. **コード主権** – すべてのファイル変更はClaudeが実行、外部モデルは書き込みアクセスがゼロ
|
||||
2. **ダーティプロトタイプのリファクタリング** – Codex/Geminiの出力はドラフトとして扱い、リファクタリングする必要がある
|
||||
3. **信頼ルール** – バックエンドはCodexに従い、フロントエンドはGeminiに従う
|
||||
4. **最小限の変更** – 必要なコードのみを変更、副作用なし
|
||||
5. **必須監査** – 変更後にマルチモデルコードレビューを実施する必要がある
|
||||
|
||||
---
|
||||
|
||||
## 使用方法
|
||||
|
||||
```bash
|
||||
# 計画ファイルを実行
|
||||
/ccg:execute .claude/plan/feature-name.md
|
||||
|
||||
# タスクを直接実行(コンテキストで既に議論された計画の場合)
|
||||
/ccg:execute 前の計画に基づいてユーザー認証を実装
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## /ccg:planとの関係
|
||||
|
||||
1. `/ccg:plan`が計画 + SESSION_IDを生成
|
||||
2. ユーザーが「Y」で確認
|
||||
3. `/ccg:execute`が計画を読み取り、SESSION_IDを再利用し、実装を実行
|
||||
@@ -1,158 +0,0 @@
|
||||
# Frontend - フロントエンド中心の開発
|
||||
|
||||
フロントエンド中心のワークフロー(調査 → アイデア創出 → 計画 → 実装 → 最適化 → レビュー)、Gemini主導。
|
||||
|
||||
## 使用方法
|
||||
|
||||
```bash
|
||||
/frontend <UIタスクの説明>
|
||||
```
|
||||
|
||||
## コンテキスト
|
||||
|
||||
- フロントエンドタスク: $ARGUMENTS
|
||||
- Gemini主導、Codexは補助的な参照用
|
||||
- 適用範囲: コンポーネント設計、レスポンシブレイアウト、UIアニメーション、スタイル最適化
|
||||
|
||||
## 役割
|
||||
|
||||
あなたは**フロントエンドオーケストレーター**として、UI/UXタスクのためのマルチモデル連携を調整します(調査 → アイデア創出 → 計画 → 実装 → 最適化 → レビュー)。
|
||||
|
||||
**連携モデル**:
|
||||
- **Gemini** – フロントエンドUI/UX(**フロントエンドの権威、信頼できる**)
|
||||
- **Codex** – バックエンドの視点(**フロントエンドの意見は参考のみ**)
|
||||
- **Claude(自身)** – オーケストレーション、計画、実装、配信
|
||||
|
||||
---
|
||||
|
||||
## マルチモデル呼び出し仕様
|
||||
|
||||
**呼び出し構文**:
|
||||
|
||||
```
|
||||
# 新規セッション呼び出し
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
|
||||
Context: <前のフェーズからのプロジェクトコンテキストと分析>
|
||||
</TASK>
|
||||
OUTPUT: 期待される出力形式
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
|
||||
# セッション再開呼び出し
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
|
||||
Context: <前のフェーズからのプロジェクトコンテキストと分析>
|
||||
</TASK>
|
||||
OUTPUT: 期待される出力形式
|
||||
EOF",
|
||||
run_in_background: false,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
```
|
||||
|
||||
**ロールプロンプト**:
|
||||
|
||||
| フェーズ | Gemini |
|
||||
|-------|--------|
|
||||
| 分析 | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
|
||||
| 計画 | `~/.claude/.ccg/prompts/gemini/architect.md` |
|
||||
| レビュー | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
|
||||
|
||||
**セッション再利用**: 各呼び出しは`SESSION_ID: xxx`を返します。後続のフェーズでは`resume xxx`を使用してください。フェーズ2で`GEMINI_SESSION`を保存し、フェーズ3と5で`resume`を使用します。
|
||||
|
||||
---
|
||||
|
||||
## コミュニケーションガイドライン
|
||||
|
||||
1. レスポンスの開始時にモードラベル`[Mode: X]`を付ける、初期は`[Mode: Research]`
|
||||
2. 厳格な順序に従う: `Research → Ideation → Plan → Execute → Optimize → Review`
|
||||
3. 必要に応じて`AskUserQuestion`ツールを使用してユーザーとやり取りする(例: 確認/選択/承認)
|
||||
|
||||
---
|
||||
|
||||
## コアワークフロー
|
||||
|
||||
### フェーズ 0: プロンプト強化(オプション)
|
||||
|
||||
`[Mode: Prepare]` - ace-tool MCPが利用可能な場合、`mcp__ace-tool__enhance_prompt`を呼び出し、**後続のGemini呼び出しのために元の$ARGUMENTSを強化結果で置き換える**
|
||||
|
||||
### フェーズ 1: 調査
|
||||
|
||||
`[Mode: Research]` - 要件の理解とコンテキストの収集
|
||||
|
||||
1. **コード取得**(ace-tool MCPが利用可能な場合): `mcp__ace-tool__search_context`を呼び出して既存のコンポーネント、スタイル、デザインシステムを取得
|
||||
2. 要件の完全性スコア(0-10): >=7で継続、<7で停止して補足
|
||||
|
||||
### フェーズ 2: アイデア創出
|
||||
|
||||
`[Mode: Ideation]` - Gemini主導の分析
|
||||
|
||||
**Geminiを呼び出す必要があります**(上記の呼び出し仕様に従う):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md`
|
||||
- Requirement: 強化された要件(または強化されていない場合は$ARGUMENTS)
|
||||
- Context: フェーズ1からのプロジェクトコンテキスト
|
||||
- OUTPUT: UIの実現可能性分析、推奨ソリューション(少なくとも2つ)、UX評価
|
||||
|
||||
**SESSION_ID**(`GEMINI_SESSION`)を保存して後続のフェーズで再利用します。
|
||||
|
||||
ソリューション(少なくとも2つ)を出力し、ユーザーの選択を待ちます。
|
||||
|
||||
### フェーズ 3: 計画
|
||||
|
||||
`[Mode: Plan]` - Gemini主導の計画
|
||||
|
||||
**Geminiを呼び出す必要があります**(`resume <GEMINI_SESSION>`を使用してセッションを再利用):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md`
|
||||
- Requirement: ユーザーが選択したソリューション
|
||||
- Context: フェーズ2からの分析結果
|
||||
- OUTPUT: コンポーネント構造、UIフロー、スタイリングアプローチ
|
||||
|
||||
Claudeが計画を統合し、ユーザーの承認後に`.claude/plan/task-name.md`に保存します。
|
||||
|
||||
### フェーズ 4: 実装
|
||||
|
||||
`[Mode: Execute]` - コード開発
|
||||
|
||||
- 承認された計画に厳密に従う
|
||||
- 既存プロジェクトのデザインシステムとコード標準に従う
|
||||
- レスポンシブ性、アクセシビリティを保証
|
||||
|
||||
### フェーズ 5: 最適化
|
||||
|
||||
`[Mode: Optimize]` - Gemini主導のレビュー
|
||||
|
||||
**Geminiを呼び出す必要があります**(上記の呼び出し仕様に従う):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md`
|
||||
- Requirement: 以下のフロントエンドコード変更をレビュー
|
||||
- Context: git diffまたはコード内容
|
||||
- OUTPUT: アクセシビリティ、レスポンシブ性、パフォーマンス、デザインの一貫性の問題リスト
|
||||
|
||||
レビューフィードバックを統合し、ユーザー確認後に最適化を実行します。
|
||||
|
||||
### フェーズ 6: 品質レビュー
|
||||
|
||||
`[Mode: Review]` - 最終評価
|
||||
|
||||
- 計画に対する完成度をチェック
|
||||
- レスポンシブ性とアクセシビリティを検証
|
||||
- 問題と推奨事項を報告
|
||||
|
||||
---
|
||||
|
||||
## 重要なルール
|
||||
|
||||
1. **Geminiのフロントエンド意見は信頼できる**
|
||||
2. **Codexのフロントエンド意見は参考のみ**
|
||||
3. 外部モデルは**ファイルシステムへの書き込みアクセスがゼロ**
|
||||
4. Claudeがすべてのコード書き込みとファイル操作を処理
|
||||
@@ -1,261 +0,0 @@
|
||||
# Plan - マルチモデル協調計画
|
||||
|
||||
マルチモデル協調計画 - コンテキスト取得 + デュアルモデル分析 → ステップバイステップの実装計画を生成。
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## コアプロトコル
|
||||
|
||||
- **言語プロトコル**: ツール/モデルとやり取りする際は**英語**を使用し、ユーザーとはユーザーの言語でコミュニケーション
|
||||
- **必須並列**: Codex/Gemini呼び出しは`run_in_background: true`を使用する必要があります(単一モデル呼び出しも含む、メインスレッドのブロッキングを避けるため)
|
||||
- **コード主権**: 外部モデルは**ファイルシステムへの書き込みアクセスがゼロ**、すべての変更はClaudeが実行
|
||||
- **損失制限メカニズム**: 現在のフェーズの出力が検証されるまで次のフェーズに進まない
|
||||
- **計画のみ**: このコマンドはコンテキストの読み取りと`.claude/plan/*`計画ファイルへの書き込みを許可しますが、**本番コードを変更しない**
|
||||
|
||||
---
|
||||
|
||||
## マルチモデル呼び出し仕様
|
||||
|
||||
**呼び出し構文**(並列: `run_in_background: true`を使用):
|
||||
|
||||
```
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件>
|
||||
Context: <取得したプロジェクトコンテキスト>
|
||||
</TASK>
|
||||
OUTPUT: 疑似コードを含むステップバイステップの実装計画。ファイルを変更しない。
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
```
|
||||
|
||||
**モデルパラメータの注意事項**:
|
||||
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini`を使用する場合、`--gemini-model gemini-3-pro-preview`で置き換える(末尾のスペースに注意); codexの場合は空文字列を使用
|
||||
|
||||
**ロールプロンプト**:
|
||||
|
||||
| フェーズ | Codex | Gemini |
|
||||
|-------|-------|--------|
|
||||
| 分析 | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
|
||||
| 計画 | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` |
|
||||
|
||||
**セッション再利用**: 各呼び出しは`SESSION_ID: xxx`を返します(通常ラッパーによって出力される)、**保存する必要があります**後続の`/ccg:execute`使用のため。
|
||||
|
||||
**バックグラウンドタスクの待機**(最大タイムアウト600000ms = 10分):
|
||||
|
||||
```
|
||||
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
|
||||
```
|
||||
|
||||
**重要**:
|
||||
- `timeout: 600000`を指定する必要があります。指定しないとデフォルトの30秒で早期タイムアウトが発生します
|
||||
- 10分後もまだ完了していない場合、`TaskOutput`でポーリングを継続し、**プロセスを強制終了しない**
|
||||
- タイムアウトにより待機がスキップされた場合、**`AskUserQuestion`を呼び出してユーザーに待機を継続するか、タスクを強制終了するかを尋ねる必要があります**
|
||||
|
||||
---
|
||||
|
||||
## 実行ワークフロー
|
||||
|
||||
**計画タスク**: $ARGUMENTS
|
||||
|
||||
### フェーズ 1: 完全なコンテキスト取得
|
||||
|
||||
`[Mode: Research]`
|
||||
|
||||
#### 1.1 プロンプト強化(最初に実行する必要があります)
|
||||
|
||||
**`mcp__ace-tool__enhance_prompt`ツールを呼び出す必要があります**:
|
||||
|
||||
```
|
||||
mcp__ace-tool__enhance_prompt({
|
||||
prompt: "$ARGUMENTS",
|
||||
conversation_history: "<直近5-10の会話ターン>",
|
||||
project_root_path: "$PWD"
|
||||
})
|
||||
```
|
||||
|
||||
強化されたプロンプトを待ち、**後続のすべてのフェーズのために元の$ARGUMENTSを強化結果で置き換える**。
|
||||
|
||||
#### 1.2 コンテキスト取得
|
||||
|
||||
**`mcp__ace-tool__search_context`ツールを呼び出す**:
|
||||
|
||||
```
|
||||
mcp__ace-tool__search_context({
|
||||
query: "<強化された要件に基づくセマンティッククエリ>",
|
||||
project_root_path: "$PWD"
|
||||
})
|
||||
```
|
||||
|
||||
- 自然言語を使用してセマンティッククエリを構築(Where/What/How)
|
||||
- **仮定に基づいて回答しない**
|
||||
- MCPが利用できない場合: Glob + Grepにフォールバックしてファイル検出とキーシンボル位置を特定
|
||||
|
||||
#### 1.3 完全性チェック
|
||||
|
||||
- 関連するクラス、関数、変数の**完全な定義とシグネチャ**を取得する必要がある
|
||||
- コンテキストが不十分な場合、**再帰的取得**をトリガー
|
||||
- 出力を優先: エントリファイル + 行番号 + キーシンボル名; 曖昧さを解決するために必要な場合のみ最小限のコードスニペットを追加
|
||||
|
||||
#### 1.4 要件の整合性
|
||||
|
||||
- 要件にまだ曖昧さがある場合、**必ず**ユーザーに誘導質問を出力
|
||||
- 要件の境界が明確になるまで(欠落なし、冗長性なし)
|
||||
|
||||
### フェーズ 2: マルチモデル協調分析
|
||||
|
||||
`[Mode: Analysis]`
|
||||
|
||||
#### 2.1 入力の配分
|
||||
|
||||
**CodexとGeminiを並列呼び出し**(`run_in_background: true`):
|
||||
|
||||
**元の要件**(事前設定された意見なし)を両方のモデルに配分:
|
||||
|
||||
1. **Codexバックエンド分析**:
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md`
|
||||
- フォーカス: 技術的な実現可能性、アーキテクチャへの影響、パフォーマンスの考慮事項、潜在的なリスク
|
||||
- OUTPUT: 多角的なソリューション + 長所/短所の分析
|
||||
|
||||
2. **Geminiフロントエンド分析**:
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md`
|
||||
- フォーカス: UI/UXへの影響、ユーザーエクスペリエンス、ビジュアルデザイン
|
||||
- OUTPUT: 多角的なソリューション + 長所/短所の分析
|
||||
|
||||
`TaskOutput`で両方のモデルの完全な結果を待ちます。**SESSION_ID**(`CODEX_SESSION`と`GEMINI_SESSION`)を保存します。
|
||||
|
||||
#### 2.2 クロスバリデーション
|
||||
|
||||
視点を統合し、最適化のために反復:
|
||||
|
||||
1. **合意を特定**(強いシグナル)
|
||||
2. **相違を特定**(重み付けが必要)
|
||||
3. **補完的な強み**: バックエンドロジックはCodexに従い、フロントエンドデザインはGeminiに従う
|
||||
4. **論理的推論**: ソリューションの論理的なギャップを排除
|
||||
|
||||
#### 2.3 (オプションだが推奨) デュアルモデル計画ドラフト
|
||||
|
||||
Claudeの統合計画での欠落リスクを減らすために、両方のモデルに並列で「計画ドラフト」を出力させることができます(ただし、ファイルを変更することは**許可されていません**):
|
||||
|
||||
1. **Codex計画ドラフト**(バックエンド権威):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md`
|
||||
- OUTPUT: ステップバイステップの計画 + 疑似コード(フォーカス: データフロー/エッジケース/エラーハンドリング/テスト戦略)
|
||||
|
||||
2. **Gemini計画ドラフト**(フロントエンド権威):
|
||||
- ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md`
|
||||
- OUTPUT: ステップバイステップの計画 + 疑似コード(フォーカス: 情報アーキテクチャ/インタラクション/アクセシビリティ/ビジュアル一貫性)
|
||||
|
||||
`TaskOutput`で両方のモデルの完全な結果を待ち、提案の主要な相違点を記録します。
|
||||
|
||||
#### 2.4 実装計画の生成(Claude最終バージョン)
|
||||
|
||||
両方の分析を統合し、**ステップバイステップの実装計画**を生成:
|
||||
|
||||
```markdown
|
||||
## 実装計画: <タスク名>
|
||||
|
||||
### タスクタイプ
|
||||
- [ ] フロントエンド(→ Gemini)
|
||||
- [ ] バックエンド(→ Codex)
|
||||
- [ ] フルスタック(→ 並列)
|
||||
|
||||
### 技術的ソリューション
|
||||
<Codex + Gemini分析から統合された最適なソリューション>
|
||||
|
||||
### 実装ステップ
|
||||
1. <ステップ1> - 期待される成果物
|
||||
2. <ステップ2> - 期待される成果物
|
||||
...
|
||||
|
||||
### キーファイル
|
||||
| ファイル | 操作 | 説明 |
|
||||
|------|-----------|-------------|
|
||||
| path/to/file.ts:L10-L50 | 変更 | 説明 |
|
||||
|
||||
### リスクと緩和策
|
||||
| リスク | 緩和策 |
|
||||
|------|------------|
|
||||
|
||||
### SESSION_ID(/ccg:execute使用のため)
|
||||
- CODEX_SESSION: <session_id>
|
||||
- GEMINI_SESSION: <session_id>
|
||||
```
|
||||
|
||||
### フェーズ 2 終了: 計画の配信(実装ではない)
|
||||
|
||||
**`/ccg:plan`の責任はここで終了します。以下のアクションを実行する必要があります**:
|
||||
|
||||
1. 完全な実装計画をユーザーに提示(疑似コードを含む)
|
||||
2. 計画を`.claude/plan/<feature-name>.md`に保存(要件から機能名を抽出、例: `user-auth`、`payment-module`)
|
||||
3. **太字テキスト**でプロンプトを出力(**保存された実際のファイルパスを使用する必要があります**):
|
||||
|
||||
---
|
||||
**計画が生成され、`.claude/plan/actual-feature-name.md`に保存されました**
|
||||
|
||||
**上記の計画をレビューしてください。以下のことができます:**
|
||||
- **計画を変更**: 調整が必要なことを教えてください、計画を更新します
|
||||
- **計画を実行**: 以下のコマンドを新しいセッションにコピー
|
||||
|
||||
```
|
||||
/ccg:execute .claude/plan/actual-feature-name.md
|
||||
```
|
||||
---
|
||||
|
||||
**注意**: 上記の`actual-feature-name.md`は実際に保存されたファイル名で置き換える必要があります!
|
||||
|
||||
4. **現在のレスポンスを直ちに終了**(ここで停止。これ以上のツール呼び出しはありません。)
|
||||
|
||||
**絶対に禁止**:
|
||||
- ユーザーに「Y/N」を尋ねてから自動実行(実行は`/ccg:execute`の責任)
|
||||
- 本番コードへの書き込み操作
|
||||
- `/ccg:execute`または任意の実装アクションを自動的に呼び出す
|
||||
- ユーザーが明示的に変更を要求していない場合にモデル呼び出しを継続してトリガー
|
||||
|
||||
---
|
||||
|
||||
## 計画の保存
|
||||
|
||||
計画が完了した後、計画を以下に保存:
|
||||
|
||||
- **最初の計画**: `.claude/plan/<feature-name>.md`
|
||||
- **反復バージョン**: `.claude/plan/<feature-name>-v2.md`、`.claude/plan/<feature-name>-v3.md`...
|
||||
|
||||
計画ファイルの書き込みは、計画をユーザーに提示する前に完了する必要があります。
|
||||
|
||||
---
|
||||
|
||||
## 計画変更フロー
|
||||
|
||||
ユーザーが計画の変更を要求した場合:
|
||||
|
||||
1. ユーザーフィードバックに基づいて計画内容を調整
|
||||
2. `.claude/plan/<feature-name>.md`ファイルを更新
|
||||
3. 変更された計画を再提示
|
||||
4. ユーザーにレビューまたは実行を再度促す
|
||||
|
||||
---
|
||||
|
||||
## 次のステップ
|
||||
|
||||
ユーザーが承認した後、**手動で**実行:
|
||||
|
||||
```bash
|
||||
/ccg:execute .claude/plan/<feature-name>.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 重要なルール
|
||||
|
||||
1. **計画のみ、実装なし** – このコマンドはコード変更を実行しません
|
||||
2. **Y/Nプロンプトなし** – 計画を提示するだけで、ユーザーが次のステップを決定します
|
||||
3. **信頼ルール** – バックエンドはCodexに従い、フロントエンドはGeminiに従う
|
||||
4. 外部モデルは**ファイルシステムへの書き込みアクセスがゼロ**
|
||||
5. **SESSION_IDの引き継ぎ** – 計画には最後に`CODEX_SESSION` / `GEMINI_SESSION`を含める必要があります(`/ccg:execute resume <SESSION_ID>`使用のため)
|
||||
@@ -1,183 +0,0 @@
|
||||
# Workflow - マルチモデル協調開発
|
||||
|
||||
マルチモデル協調開発ワークフロー(調査 → アイデア創出 → 計画 → 実装 → 最適化 → レビュー)、インテリジェントルーティング: フロントエンド → Gemini、バックエンド → Codex。
|
||||
|
||||
品質ゲート、MCPサービス、マルチモデル連携を備えた構造化開発ワークフロー。
|
||||
|
||||
## 使用方法
|
||||
|
||||
```bash
|
||||
/workflow <タスクの説明>
|
||||
```
|
||||
|
||||
## コンテキスト
|
||||
|
||||
- 開発するタスク: $ARGUMENTS
|
||||
- 品質ゲートを備えた構造化された6フェーズワークフロー
|
||||
- マルチモデル連携: Codex(バックエンド) + Gemini(フロントエンド) + Claude(オーケストレーション)
|
||||
- MCPサービス統合(ace-tool)による機能強化
|
||||
|
||||
## 役割
|
||||
|
||||
あなたは**オーケストレーター**として、マルチモデル協調システムを調整します(調査 → アイデア創出 → 計画 → 実装 → 最適化 → レビュー)。経験豊富な開発者向けに簡潔かつ専門的にコミュニケーションします。
|
||||
|
||||
**連携モデル**:
|
||||
- **ace-tool MCP** – コード取得 + プロンプト強化
|
||||
- **Codex** – バックエンドロジック、アルゴリズム、デバッグ(**バックエンドの権威、信頼できる**)
|
||||
- **Gemini** – フロントエンドUI/UX、ビジュアルデザイン(**フロントエンドエキスパート、バックエンドの意見は参考のみ**)
|
||||
- **Claude(自身)** – オーケストレーション、計画、実装、配信
|
||||
|
||||
---
|
||||
|
||||
## マルチモデル呼び出し仕様
|
||||
|
||||
**呼び出し構文**(並列: `run_in_background: true`、順次: `false`):
|
||||
|
||||
```
|
||||
# 新規セッション呼び出し
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
|
||||
Context: <前のフェーズからのプロジェクトコンテキストと分析>
|
||||
</TASK>
|
||||
OUTPUT: 期待される出力形式
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
|
||||
# セッション再開呼び出し
|
||||
Bash({
|
||||
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
|
||||
ROLE_FILE: <ロールプロンプトパス>
|
||||
<TASK>
|
||||
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
|
||||
Context: <前のフェーズからのプロジェクトコンテキストと分析>
|
||||
</TASK>
|
||||
OUTPUT: 期待される出力形式
|
||||
EOF",
|
||||
run_in_background: true,
|
||||
timeout: 3600000,
|
||||
description: "簡潔な説明"
|
||||
})
|
||||
```
|
||||
|
||||
**モデルパラメータの注意事項**:
|
||||
- `{{GEMINI_MODEL_FLAG}}`: `--backend gemini`を使用する場合、`--gemini-model gemini-3-pro-preview`で置き換える(末尾のスペースに注意); codexの場合は空文字列を使用
|
||||
|
||||
**ロールプロンプト**:
|
||||
|
||||
| フェーズ | Codex | Gemini |
|
||||
|-------|-------|--------|
|
||||
| 分析 | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` |
|
||||
| 計画 | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` |
|
||||
| レビュー | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` |
|
||||
|
||||
**セッション再利用**: 各呼び出しは`SESSION_ID: xxx`を返し、後続のフェーズでは`resume xxx`サブコマンドを使用します(注意: `resume`、`--resume`ではない)。
|
||||
|
||||
**並列呼び出し**: `run_in_background: true`で開始し、`TaskOutput`で結果を待ちます。**次のフェーズに進む前にすべてのモデルが結果を返すまで待つ必要があります**。
|
||||
|
||||
**バックグラウンドタスクの待機**(最大タイムアウト600000ms = 10分を使用):
|
||||
|
||||
```
|
||||
TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
|
||||
```
|
||||
|
||||
**重要**:
|
||||
- `timeout: 600000`を指定する必要があります。指定しないとデフォルトの30秒で早期タイムアウトが発生します。
|
||||
- 10分後もまだ完了していない場合、`TaskOutput`でポーリングを継続し、**プロセスを強制終了しない**。
|
||||
- タイムアウトにより待機がスキップされた場合、**`AskUserQuestion`を呼び出してユーザーに待機を継続するか、タスクを強制終了するかを尋ねる必要があります。直接強制終了しない。**
|
||||
|
||||
---
|
||||
|
||||
## コミュニケーションガイドライン
|
||||
|
||||
1. レスポンスの開始時にモードラベル`[Mode: X]`を付ける、初期は`[Mode: Research]`。
|
||||
2. 厳格な順序に従う: `Research → Ideation → Plan → Execute → Optimize → Review`。
|
||||
3. 各フェーズ完了後にユーザー確認を要求。
|
||||
4. スコア < 7またはユーザーが承認しない場合は強制停止。
|
||||
5. 必要に応じて`AskUserQuestion`ツールを使用してユーザーとやり取りする(例: 確認/選択/承認)。
|
||||
|
||||
---
|
||||
|
||||
## 実行ワークフロー
|
||||
|
||||
**タスクの説明**: $ARGUMENTS
|
||||
|
||||
### フェーズ 1: 調査と分析
|
||||
|
||||
`[Mode: Research]` - 要件の理解とコンテキストの収集:
|
||||
|
||||
1. **プロンプト強化**: `mcp__ace-tool__enhance_prompt`を呼び出し、**後続のすべてのCodex/Gemini呼び出しのために元の$ARGUMENTSを強化結果で置き換える**
|
||||
2. **コンテキスト取得**: `mcp__ace-tool__search_context`を呼び出す
|
||||
3. **要件完全性スコア**(0-10):
|
||||
- 目標の明確性(0-3)、期待される結果(0-3)、スコープの境界(0-2)、制約(0-2)
|
||||
- ≥7: 継続 | <7: 停止、明確化の質問を尋ねる
|
||||
|
||||
### フェーズ 2: ソリューションのアイデア創出
|
||||
|
||||
`[Mode: Ideation]` - マルチモデル並列分析:
|
||||
|
||||
**並列呼び出し**(`run_in_background: true`):
|
||||
- Codex: アナライザープロンプトを使用、技術的な実現可能性、ソリューション、リスクを出力
|
||||
- Gemini: アナライザープロンプトを使用、UIの実現可能性、ソリューション、UX評価を出力
|
||||
|
||||
`TaskOutput`で結果を待ちます。**SESSION_ID**(`CODEX_SESSION`と`GEMINI_SESSION`)を保存します。
|
||||
|
||||
**上記の`マルチモデル呼び出し仕様`の`重要`指示に従ってください**
|
||||
|
||||
両方の分析を統合し、ソリューション比較(少なくとも2つのオプション)を出力し、ユーザーの選択を待ちます。
|
||||
|
||||
### フェーズ 3: 詳細な計画
|
||||
|
||||
`[Mode: Plan]` - マルチモデル協調計画:
|
||||
|
||||
**並列呼び出し**(`resume <SESSION_ID>`でセッションを再開):
|
||||
- Codex: アーキテクトプロンプト + `resume $CODEX_SESSION`を使用、バックエンドアーキテクチャを出力
|
||||
- Gemini: アーキテクトプロンプト + `resume $GEMINI_SESSION`を使用、フロントエンドアーキテクチャを出力
|
||||
|
||||
`TaskOutput`で結果を待ちます。
|
||||
|
||||
**上記の`マルチモデル呼び出し仕様`の`重要`指示に従ってください**
|
||||
|
||||
**Claude統合**: Codexのバックエンド計画 + Geminiのフロントエンド計画を採用し、ユーザーの承認後に`.claude/plan/task-name.md`に保存します。
|
||||
|
||||
### フェーズ 4: 実装
|
||||
|
||||
`[Mode: Execute]` - コード開発:
|
||||
|
||||
- 承認された計画に厳密に従う
|
||||
- 既存プロジェクトのコード標準に従う
|
||||
- 主要なマイルストーンでフィードバックを要求
|
||||
|
||||
### フェーズ 5: コード最適化
|
||||
|
||||
`[Mode: Optimize]` - マルチモデル並列レビュー:
|
||||
|
||||
**並列呼び出し**:
|
||||
- Codex: レビュアープロンプトを使用、セキュリティ、パフォーマンス、エラーハンドリングに焦点
|
||||
- Gemini: レビュアープロンプトを使用、アクセシビリティ、デザインの一貫性に焦点
|
||||
|
||||
`TaskOutput`で結果を待ちます。レビューフィードバックを統合し、ユーザー確認後に最適化を実行します。
|
||||
|
||||
**上記の`マルチモデル呼び出し仕様`の`重要`指示に従ってください**
|
||||
|
||||
### フェーズ 6: 品質レビュー
|
||||
|
||||
`[Mode: Review]` - 最終評価:
|
||||
|
||||
- 計画に対する完成度をチェック
|
||||
- テストを実行して機能を検証
|
||||
- 問題と推奨事項を報告
|
||||
- 最終的なユーザー確認を要求
|
||||
|
||||
---
|
||||
|
||||
## 重要なルール
|
||||
|
||||
1. フェーズの順序はスキップできません(ユーザーが明示的に指示しない限り)
|
||||
2. 外部モデルは**ファイルシステムへの書き込みアクセスがゼロ**、すべての変更はClaudeが実行
|
||||
3. スコア < 7またはユーザーが承認しない場合は**強制停止**
|
||||
@@ -1,172 +0,0 @@
|
||||
# Orchestrateコマンド
|
||||
|
||||
複雑なタスクのための連続的なエージェントワークフロー。
|
||||
|
||||
## 使用方法
|
||||
|
||||
`/orchestrate [ワークフロータイプ] [タスク説明]`
|
||||
|
||||
## ワークフロータイプ
|
||||
|
||||
### feature
|
||||
完全な機能実装ワークフロー:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
```
|
||||
|
||||
### bugfix
|
||||
バグ調査と修正ワークフロー:
|
||||
```
|
||||
explorer -> tdd-guide -> code-reviewer
|
||||
```
|
||||
|
||||
### refactor
|
||||
安全なリファクタリングワークフロー:
|
||||
```
|
||||
architect -> code-reviewer -> tdd-guide
|
||||
```
|
||||
|
||||
### security
|
||||
セキュリティ重視のレビュー:
|
||||
```
|
||||
security-reviewer -> code-reviewer -> architect
|
||||
```
|
||||
|
||||
## 実行パターン
|
||||
|
||||
ワークフロー内の各エージェントに対して:
|
||||
|
||||
1. 前のエージェントからのコンテキストで**エージェントを呼び出す**
|
||||
2. 出力を構造化されたハンドオフドキュメントとして**収集**
|
||||
3. チェーン内の**次のエージェントに渡す**
|
||||
4. 結果を最終レポートに**集約**
|
||||
|
||||
## ハンドオフドキュメント形式
|
||||
|
||||
エージェント間でハンドオフドキュメントを作成します:
|
||||
|
||||
```markdown
|
||||
## HANDOFF: [前のエージェント] -> [次のエージェント]
|
||||
|
||||
### コンテキスト
|
||||
[実行された内容の要約]
|
||||
|
||||
### 発見事項
|
||||
[重要な発見または決定]
|
||||
|
||||
### 変更されたファイル
|
||||
[変更されたファイルのリスト]
|
||||
|
||||
### 未解決の質問
|
||||
[次のエージェントのための未解決項目]
|
||||
|
||||
### 推奨事項
|
||||
[推奨される次のステップ]
|
||||
```
|
||||
|
||||
## 例: 機能ワークフロー
|
||||
|
||||
```
|
||||
/orchestrate feature "Add user authentication"
|
||||
```
|
||||
|
||||
以下を実行します:
|
||||
|
||||
1. **Plannerエージェント**
|
||||
- 要件を分析
|
||||
- 実装計画を作成
|
||||
- 依存関係を特定
|
||||
- 出力: `HANDOFF: planner -> tdd-guide`
|
||||
|
||||
2. **TDD Guideエージェント**
|
||||
- プランナーのハンドオフを読み込む
|
||||
- 最初にテストを記述
|
||||
- テストに合格するように実装
|
||||
- 出力: `HANDOFF: tdd-guide -> code-reviewer`
|
||||
|
||||
3. **Code Reviewerエージェント**
|
||||
- 実装をレビュー
|
||||
- 問題をチェック
|
||||
- 改善を提案
|
||||
- 出力: `HANDOFF: code-reviewer -> security-reviewer`
|
||||
|
||||
4. **Security Reviewerエージェント**
|
||||
- セキュリティ監査
|
||||
- 脆弱性チェック
|
||||
- 最終承認
|
||||
- 出力: 最終レポート
|
||||
|
||||
## 最終レポート形式
|
||||
|
||||
```
|
||||
ORCHESTRATION REPORT
|
||||
====================
|
||||
Workflow: feature
|
||||
Task: Add user authentication
|
||||
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
|
||||
SUMMARY
|
||||
-------
|
||||
[1段落の要約]
|
||||
|
||||
AGENT OUTPUTS
|
||||
-------------
|
||||
Planner: [要約]
|
||||
TDD Guide: [要約]
|
||||
Code Reviewer: [要約]
|
||||
Security Reviewer: [要約]
|
||||
|
||||
FILES CHANGED
|
||||
-------------
|
||||
[変更されたすべてのファイルをリスト]
|
||||
|
||||
TEST RESULTS
|
||||
------------
|
||||
[テスト合格/不合格の要約]
|
||||
|
||||
SECURITY STATUS
|
||||
---------------
|
||||
[セキュリティの発見事項]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[リリース可 / 要修正 / ブロック中]
|
||||
```
|
||||
|
||||
## 並行実行
|
||||
|
||||
独立したチェックの場合、エージェントを並行実行します:
|
||||
|
||||
```markdown
|
||||
### 並行フェーズ
|
||||
同時に実行:
|
||||
- code-reviewer (品質)
|
||||
- security-reviewer (セキュリティ)
|
||||
- architect (設計)
|
||||
|
||||
### 結果のマージ
|
||||
出力を単一のレポートに結合
|
||||
```
|
||||
|
||||
## 引数
|
||||
|
||||
$ARGUMENTS:
|
||||
- `feature <説明>` - 完全な機能ワークフロー
|
||||
- `bugfix <説明>` - バグ修正ワークフロー
|
||||
- `refactor <説明>` - リファクタリングワークフロー
|
||||
- `security <説明>` - セキュリティレビューワークフロー
|
||||
- `custom <エージェント> <説明>` - カスタムエージェントシーケンス
|
||||
|
||||
## カスタムワークフローの例
|
||||
|
||||
```
|
||||
/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"
|
||||
```
|
||||
|
||||
## ヒント
|
||||
|
||||
1. 複雑な機能には**plannerから始める**
|
||||
2. マージ前に**常にcode-reviewerを含める**
|
||||
3. 認証/決済/個人情報には**security-reviewerを使用**
|
||||
4. **ハンドオフを簡潔に保つ** - 次のエージェントが必要とするものに焦点を当てる
|
||||
5. 必要に応じて**エージェント間で検証を実行**
|
||||
@@ -1,272 +0,0 @@
|
||||
# PM2 初期化
|
||||
|
||||
プロジェクトを自動分析し、PM2サービスコマンドを生成します。
|
||||
|
||||
**コマンド**: `$ARGUMENTS`
|
||||
|
||||
---
|
||||
|
||||
## ワークフロー
|
||||
|
||||
1. PM2をチェック(欠落している場合は`npm install -g pm2`でインストール)
|
||||
2. プロジェクトをスキャンしてサービスを識別(フロントエンド/バックエンド/データベース)
|
||||
3. 設定ファイルと個別のコマンドファイルを生成
|
||||
|
||||
---
|
||||
|
||||
## サービス検出
|
||||
|
||||
| タイプ | 検出 | デフォルトポート |
|
||||
|------|-----------|--------------|
|
||||
| Vite | vite.config.* | 5173 |
|
||||
| Next.js | next.config.* | 3000 |
|
||||
| Nuxt | nuxt.config.* | 3000 |
|
||||
| CRA | package.jsonにreact-scripts | 3000 |
|
||||
| Express/Node | server/backend/apiディレクトリ + package.json | 3000 |
|
||||
| FastAPI/Flask | requirements.txt / pyproject.toml | 8000 |
|
||||
| Go | go.mod / main.go | 8080 |
|
||||
|
||||
**ポート検出優先順位**: ユーザー指定 > .env > 設定ファイル > スクリプト引数 > デフォルトポート
|
||||
|
||||
---
|
||||
|
||||
## 生成されるファイル
|
||||
|
||||
```
|
||||
project/
|
||||
├── ecosystem.config.cjs # PM2設定
|
||||
├── {backend}/start.cjs # Pythonラッパー(該当する場合)
|
||||
└── .claude/
|
||||
├── commands/
|
||||
│ ├── pm2-all.md # すべて起動 + monit
|
||||
│ ├── pm2-all-stop.md # すべて停止
|
||||
│ ├── pm2-all-restart.md # すべて再起動
|
||||
│ ├── pm2-{port}.md # 単一起動 + ログ
|
||||
│ ├── pm2-{port}-stop.md # 単一停止
|
||||
│ ├── pm2-{port}-restart.md # 単一再起動
|
||||
│ ├── pm2-logs.md # すべてのログを表示
|
||||
│ └── pm2-status.md # ステータスを表示
|
||||
└── scripts/
|
||||
├── pm2-logs-{port}.ps1 # 単一サービスログ
|
||||
└── pm2-monit.ps1 # PM2モニター
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Windows設定(重要)
|
||||
|
||||
### ecosystem.config.cjs
|
||||
|
||||
**`.cjs`拡張子を使用する必要があります**
|
||||
|
||||
```javascript
|
||||
module.exports = {
|
||||
apps: [
|
||||
// Node.js (Vite/Next/Nuxt)
|
||||
{
|
||||
name: 'project-3000',
|
||||
cwd: './packages/web',
|
||||
script: 'node_modules/vite/bin/vite.js',
|
||||
args: '--port 3000',
|
||||
interpreter: 'C:/Program Files/nodejs/node.exe',
|
||||
env: { NODE_ENV: 'development' }
|
||||
},
|
||||
// Python
|
||||
{
|
||||
name: 'project-8000',
|
||||
cwd: './backend',
|
||||
script: 'start.cjs',
|
||||
interpreter: 'C:/Program Files/nodejs/node.exe',
|
||||
env: { PYTHONUNBUFFERED: '1' }
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**フレームワークスクリプトパス:**
|
||||
|
||||
| フレームワーク | script | args |
|
||||
|-----------|--------|------|
|
||||
| Vite | `node_modules/vite/bin/vite.js` | `--port {port}` |
|
||||
| Next.js | `node_modules/next/dist/bin/next` | `dev -p {port}` |
|
||||
| Nuxt | `node_modules/nuxt/bin/nuxt.mjs` | `dev --port {port}` |
|
||||
| Express | `src/index.js`または`server.js` | - |
|
||||
|
||||
### Pythonラッパースクリプト(start.cjs)
|
||||
|
||||
```javascript
|
||||
const { spawn } = require('child_process');
|
||||
const proc = spawn('python', ['-m', 'uvicorn', 'app.main:app', '--host', '0.0.0.0', '--port', '8000', '--reload'], {
|
||||
cwd: __dirname, stdio: 'inherit', windowsHide: true
|
||||
});
|
||||
proc.on('close', (code) => process.exit(code));
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## コマンドファイルテンプレート(最小限の内容)
|
||||
|
||||
### pm2-all.md(すべて起動 + monit)
|
||||
````markdown
|
||||
すべてのサービスを起動し、PM2モニターを開きます。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 monit"
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-all-stop.md
|
||||
````markdown
|
||||
すべてのサービスを停止します。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 stop all
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-all-restart.md
|
||||
````markdown
|
||||
すべてのサービスを再起動します。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 restart all
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-{port}.md(単一起動 + ログ)
|
||||
````markdown
|
||||
{name}({port})を起動し、ログを開きます。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs --only {name} && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 logs {name}"
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-{port}-stop.md
|
||||
````markdown
|
||||
{name}({port})を停止します。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 stop {name}
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-{port}-restart.md
|
||||
````markdown
|
||||
{name}({port})を再起動します。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 restart {name}
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-logs.md
|
||||
````markdown
|
||||
すべてのPM2ログを表示します。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 logs
|
||||
```
|
||||
````
|
||||
|
||||
### pm2-status.md
|
||||
````markdown
|
||||
PM2ステータスを表示します。
|
||||
```bash
|
||||
cd "{PROJECT_ROOT}" && pm2 status
|
||||
```
|
||||
````
|
||||
|
||||
### PowerShellスクリプト(pm2-logs-{port}.ps1)
|
||||
```powershell
|
||||
Set-Location "{PROJECT_ROOT}"
|
||||
pm2 logs {name}
|
||||
```
|
||||
|
||||
### PowerShellスクリプト(pm2-monit.ps1)
|
||||
```powershell
|
||||
Set-Location "{PROJECT_ROOT}"
|
||||
pm2 monit
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 重要なルール
|
||||
|
||||
1. **設定ファイル**: `ecosystem.config.cjs`(.jsではない)
|
||||
2. **Node.js**: binパスを直接指定 + インタープリター
|
||||
3. **Python**: Node.jsラッパースクリプト + `windowsHide: true`
|
||||
4. **新しいウィンドウを開く**: `start wt.exe -d "{path}" pwsh -NoExit -c "command"`
|
||||
5. **最小限の内容**: 各コマンドファイルには1-2行の説明 + bashブロックのみ
|
||||
6. **直接実行**: AI解析不要、bashコマンドを実行するだけ
|
||||
|
||||
---
|
||||
|
||||
## 実行
|
||||
|
||||
`$ARGUMENTS`に基づいて初期化を実行:
|
||||
|
||||
1. プロジェクトのサービスをスキャン
|
||||
2. `ecosystem.config.cjs`を生成
|
||||
3. Pythonサービス用の`{backend}/start.cjs`を生成(該当する場合)
|
||||
4. `.claude/commands/`にコマンドファイルを生成
|
||||
5. `.claude/scripts/`にスクリプトファイルを生成
|
||||
6. **プロジェクトのCLAUDE.md**をPM2情報で更新(下記参照)
|
||||
7. ターミナルコマンドを含む**完了サマリーを表示**
|
||||
|
||||
---
|
||||
|
||||
## 初期化後: CLAUDE.mdの更新
|
||||
|
||||
ファイル生成後、プロジェクトの`CLAUDE.md`にPM2セクションを追加(存在しない場合は作成):
|
||||
|
||||
````markdown
|
||||
## PM2サービス
|
||||
|
||||
| ポート | 名前 | タイプ |
|
||||
|------|------|------|
|
||||
| {port} | {name} | {type} |
|
||||
|
||||
**ターミナルコマンド:**
|
||||
```bash
|
||||
pm2 start ecosystem.config.cjs # 初回
|
||||
pm2 start all # 初回以降
|
||||
pm2 stop all / pm2 restart all
|
||||
pm2 start {name} / pm2 stop {name}
|
||||
pm2 logs / pm2 status / pm2 monit
|
||||
pm2 save # プロセスリストを保存
|
||||
pm2 resurrect # 保存したリストを復元
|
||||
```
|
||||
````
|
||||
|
||||
**CLAUDE.md更新のルール:**
|
||||
- PM2セクションが存在する場合、置き換える
|
||||
- 存在しない場合、末尾に追加
|
||||
- 内容は最小限かつ必須のもののみ
|
||||
|
||||
---
|
||||
|
||||
## 初期化後: サマリーの表示
|
||||
|
||||
すべてのファイル生成後、以下を出力:
|
||||
|
||||
```
|
||||
## PM2初期化完了
|
||||
|
||||
**サービス:**
|
||||
|
||||
| ポート | 名前 | タイプ |
|
||||
|------|------|------|
|
||||
| {port} | {name} | {type} |
|
||||
|
||||
**Claudeコマンド:** /pm2-all, /pm2-all-stop, /pm2-{port}, /pm2-{port}-stop, /pm2-logs, /pm2-status
|
||||
|
||||
**ターミナルコマンド:**
|
||||
## 初回(設定ファイル使用)
|
||||
pm2 start ecosystem.config.cjs && pm2 save
|
||||
|
||||
## 初回以降(簡略化)
|
||||
pm2 start all # すべて起動
|
||||
pm2 stop all # すべて停止
|
||||
pm2 restart all # すべて再起動
|
||||
pm2 start {name} # 単一起動
|
||||
pm2 stop {name} # 単一停止
|
||||
pm2 logs # ログを表示
|
||||
pm2 monit # モニターパネル
|
||||
pm2 resurrect # 保存したプロセスを復元
|
||||
|
||||
**ヒント:** 初回起動後に`pm2 save`を実行すると、簡略化されたコマンドが使用できます。
|
||||
```
|
||||
@@ -1,297 +0,0 @@
|
||||
---
|
||||
description: PEP 8準拠、型ヒント、セキュリティ、Pythonic慣用句についての包括的なPythonコードレビュー。python-reviewerエージェントを呼び出します。
|
||||
---
|
||||
|
||||
# Python Code Review
|
||||
|
||||
このコマンドは、Python固有の包括的なコードレビューのために**python-reviewer**エージェントを呼び出します。
|
||||
|
||||
## このコマンドの機能
|
||||
|
||||
1. **Python変更の特定**: `git diff`で変更された`.py`ファイルを検出
|
||||
2. **静的解析の実行**: `ruff`、`mypy`、`pylint`、`black --check`を実行
|
||||
3. **セキュリティスキャン**: SQLインジェクション、コマンドインジェクション、安全でないデシリアライゼーションをチェック
|
||||
4. **型安全性のレビュー**: 型ヒントとmypyエラーを分析
|
||||
5. **Pythonicコードチェック**: コードがPEP 8とPythonベストプラクティスに従っていることを確認
|
||||
6. **レポート生成**: 問題を重要度別に分類
|
||||
|
||||
## 使用するタイミング
|
||||
|
||||
以下の場合に`/python-review`を使用します:
|
||||
- Pythonコードを作成または変更した後
|
||||
- Python変更をコミットする前
|
||||
- Pythonコードを含むプルリクエストのレビュー時
|
||||
- 新しいPythonコードベースへのオンボーディング時
|
||||
- Pythonicパターンと慣用句の学習時
|
||||
|
||||
## レビューカテゴリ
|
||||
|
||||
### CRITICAL(必須修正)
|
||||
- SQL/コマンドインジェクションの脆弱性
|
||||
- 安全でないeval/execの使用
|
||||
- Pickleの安全でないデシリアライゼーション
|
||||
- ハードコードされた資格情報
|
||||
- YAMLの安全でないロード
|
||||
- エラーを隠す素のexcept句
|
||||
|
||||
### HIGH(修正推奨)
|
||||
- 公開関数での型ヒントの欠落
|
||||
- 可変デフォルト引数
|
||||
- 例外を静かに飲み込む
|
||||
- リソースにコンテキストマネージャーを使用していない
|
||||
- 内包表記の代わりにCスタイルループ
|
||||
- isinstance()の代わりにtype()を使用
|
||||
- ロックなしの競合状態
|
||||
|
||||
### MEDIUM(検討)
|
||||
- PEP 8フォーマット違反
|
||||
- 公開関数でのdocstringの欠落
|
||||
- loggingの代わりにprint文
|
||||
- 非効率的な文字列操作
|
||||
- 名前付き定数のないマジックナンバー
|
||||
- フォーマットにf-stringsを使用していない
|
||||
- 不要なリスト作成
|
||||
|
||||
## 実行される自動チェック
|
||||
|
||||
```bash
|
||||
# 型チェック
|
||||
mypy .
|
||||
|
||||
# リンティングとフォーマット
|
||||
ruff check .
|
||||
black --check .
|
||||
isort --check-only .
|
||||
|
||||
# セキュリティスキャン
|
||||
bandit -r .
|
||||
|
||||
# 依存関係監査
|
||||
pip-audit
|
||||
safety check
|
||||
|
||||
# テスト
|
||||
pytest --cov=app --cov-report=term-missing
|
||||
```
|
||||
|
||||
## 使用例
|
||||
|
||||
```text
|
||||
User: /python-review
|
||||
|
||||
Agent:
|
||||
# Pythonコードレビューレポート
|
||||
|
||||
## レビューされたファイル
|
||||
- app/routes/user.py (変更)
|
||||
- app/services/auth.py (変更)
|
||||
|
||||
## 静的解析結果
|
||||
✓ ruff: 問題なし
|
||||
✓ mypy: エラーなし
|
||||
⚠️ black: 2ファイルが再フォーマット必要
|
||||
✓ bandit: セキュリティ問題なし
|
||||
|
||||
## 発見された問題
|
||||
|
||||
[CRITICAL] SQLインジェクション脆弱性
|
||||
File: app/routes/user.py:42
|
||||
Issue: ユーザー入力が直接SQLクエリに挿入されている
|
||||
```python
|
||||
query = f"SELECT * FROM users WHERE id = {user_id}" # 悪い
|
||||
```
|
||||
Fix: パラメータ化クエリを使用
|
||||
```python
|
||||
query = "SELECT * FROM users WHERE id = %s" # 良い
|
||||
cursor.execute(query, (user_id,))
|
||||
```
|
||||
|
||||
[HIGH] 可変デフォルト引数
|
||||
File: app/services/auth.py:18
|
||||
Issue: 可変デフォルト引数が共有状態を引き起こす
|
||||
```python
|
||||
def process_items(items=[]): # 悪い
|
||||
items.append("new")
|
||||
return items
|
||||
```
|
||||
Fix: デフォルトにNoneを使用
|
||||
```python
|
||||
def process_items(items=None): # 良い
|
||||
if items is None:
|
||||
items = []
|
||||
items.append("new")
|
||||
return items
|
||||
```
|
||||
|
||||
[MEDIUM] 型ヒントの欠落
|
||||
File: app/services/auth.py:25
|
||||
Issue: 型アノテーションのない公開関数
|
||||
```python
|
||||
def get_user(user_id): # 悪い
|
||||
return db.find(user_id)
|
||||
```
|
||||
Fix: 型ヒントを追加
|
||||
```python
|
||||
def get_user(user_id: str) -> Optional[User]: # 良い
|
||||
return db.find(user_id)
|
||||
```
|
||||
|
||||
[MEDIUM] コンテキストマネージャーを使用していない
|
||||
File: app/routes/user.py:55
|
||||
Issue: 例外時にファイルがクローズされない
|
||||
```python
|
||||
f = open("config.json") # 悪い
|
||||
data = f.read()
|
||||
f.close()
|
||||
```
|
||||
Fix: コンテキストマネージャーを使用
|
||||
```python
|
||||
with open("config.json") as f: # 良い
|
||||
data = f.read()
|
||||
```
|
||||
|
||||
## サマリー
|
||||
- CRITICAL: 1
|
||||
- HIGH: 1
|
||||
- MEDIUM: 2
|
||||
|
||||
推奨: ❌ CRITICAL問題が修正されるまでマージをブロック
|
||||
|
||||
## フォーマット必要
|
||||
実行: `black app/routes/user.py app/services/auth.py`
|
||||
```
|
||||
|
||||
## 承認基準
|
||||
|
||||
| ステータス | 条件 |
|
||||
|--------|-----------|
|
||||
| ✅ 承認 | CRITICALまたはHIGH問題なし |
|
||||
| ⚠️ 警告 | MEDIUM問題のみ(注意してマージ) |
|
||||
| ❌ ブロック | CRITICALまたはHIGH問題が発見された |
|
||||
|
||||
## 他のコマンドとの統合
|
||||
|
||||
- まず`/python-test`を使用してテストが合格することを確認
|
||||
- `/code-review`をPython固有でない問題に使用
|
||||
- `/python-review`をコミット前に使用
|
||||
- `/build-fix`を静的解析ツールが失敗した場合に使用
|
||||
|
||||
## フレームワーク固有のレビュー
|
||||
|
||||
### Djangoプロジェクト
|
||||
レビューアは以下をチェックします:
|
||||
- N+1クエリ問題(`select_related`と`prefetch_related`を使用)
|
||||
- モデル変更のマイグレーション欠落
|
||||
- ORMで可能な場合の生SQLの使用
|
||||
- 複数ステップ操作での`transaction.atomic()`の欠落
|
||||
|
||||
### FastAPIプロジェクト
|
||||
レビューアは以下をチェックします:
|
||||
- CORSの誤設定
|
||||
- リクエスト検証のためのPydanticモデル
|
||||
- レスポンスモデルの正確性
|
||||
- 適切なasync/awaitの使用
|
||||
- 依存性注入パターン
|
||||
|
||||
### Flaskプロジェクト
|
||||
レビューアは以下をチェックします:
|
||||
- コンテキスト管理(appコンテキスト、requestコンテキスト)
|
||||
- 適切なエラーハンドリング
|
||||
- Blueprintの構成
|
||||
- 設定管理
|
||||
|
||||
## 関連
|
||||
|
||||
- Agent: `agents/python-reviewer.md`
|
||||
- Skills: `skills/python-patterns/`, `skills/python-testing/`
|
||||
|
||||
## 一般的な修正
|
||||
|
||||
### 型ヒントの追加
|
||||
```python
|
||||
# 変更前
|
||||
def calculate(x, y):
|
||||
return x + y
|
||||
|
||||
# 変更後
|
||||
from typing import Union
|
||||
|
||||
def calculate(x: Union[int, float], y: Union[int, float]) -> Union[int, float]:
|
||||
return x + y
|
||||
```
|
||||
|
||||
### コンテキストマネージャーの使用
|
||||
```python
|
||||
# 変更前
|
||||
f = open("file.txt")
|
||||
data = f.read()
|
||||
f.close()
|
||||
|
||||
# 変更後
|
||||
with open("file.txt") as f:
|
||||
data = f.read()
|
||||
```
|
||||
|
||||
### リスト内包表記の使用
|
||||
```python
|
||||
# 変更前
|
||||
result = []
|
||||
for item in items:
|
||||
if item.active:
|
||||
result.append(item.name)
|
||||
|
||||
# 変更後
|
||||
result = [item.name for item in items if item.active]
|
||||
```
|
||||
|
||||
### 可変デフォルトの修正
|
||||
```python
|
||||
# 変更前
|
||||
def append(value, items=[]):
|
||||
items.append(value)
|
||||
return items
|
||||
|
||||
# 変更後
|
||||
def append(value, items=None):
|
||||
if items is None:
|
||||
items = []
|
||||
items.append(value)
|
||||
return items
|
||||
```
|
||||
|
||||
### f-stringsの使用(Python 3.6+)
|
||||
```python
|
||||
# 変更前
|
||||
name = "Alice"
|
||||
greeting = "Hello, " + name + "!"
|
||||
greeting2 = "Hello, {}".format(name)
|
||||
|
||||
# 変更後
|
||||
greeting = f"Hello, {name}!"
|
||||
```
|
||||
|
||||
### ループ内の文字列連結の修正
|
||||
```python
|
||||
# 変更前
|
||||
result = ""
|
||||
for item in items:
|
||||
result += str(item)
|
||||
|
||||
# 変更後
|
||||
result = "".join(str(item) for item in items)
|
||||
```
|
||||
|
||||
## Pythonバージョン互換性
|
||||
|
||||
レビューアは、コードが新しいPythonバージョンの機能を使用する場合に通知します:
|
||||
|
||||
| 機能 | 最小Python |
|
||||
|---------|----------------|
|
||||
| 型ヒント | 3.5+ |
|
||||
| f-strings | 3.6+ |
|
||||
| セイウチ演算子(`:=`) | 3.8+ |
|
||||
| 位置専用パラメータ | 3.8+ |
|
||||
| Match文 | 3.10+ |
|
||||
| 型ユニオン(`x | None`) | 3.10+ |
|
||||
|
||||
プロジェクトの`pyproject.toml`または`setup.py`が正しい最小Pythonバージョンを指定していることを確認してください。
|
||||
@@ -1,28 +0,0 @@
|
||||
# Refactor Clean
|
||||
|
||||
テスト検証でデッドコードを安全に特定して削除します:
|
||||
|
||||
1. デッドコード分析ツールを実行:
|
||||
- knip: 未使用のエクスポートとファイルを検出
|
||||
- depcheck: 未使用の依存関係を検出
|
||||
- ts-prune: 未使用のTypeScriptエクスポートを検出
|
||||
|
||||
2. .reports/dead-code-analysis.mdに包括的なレポートを生成
|
||||
|
||||
3. 発見を重要度別に分類:
|
||||
- SAFE: テストファイル、未使用のユーティリティ
|
||||
- CAUTION: APIルート、コンポーネント
|
||||
- DANGER: 設定ファイル、メインエントリーポイント
|
||||
|
||||
4. 安全な削除のみを提案
|
||||
|
||||
5. 各削除の前に:
|
||||
- 完全なテストスイートを実行
|
||||
- テストが合格することを確認
|
||||
- 変更を適用
|
||||
- テストを再実行
|
||||
- テストが失敗した場合はロールバック
|
||||
|
||||
6. クリーンアップされたアイテムのサマリーを表示
|
||||
|
||||
まずテストを実行せずにコードを削除しないでください!
|
||||
@@ -1,305 +0,0 @@
|
||||
# Sessionsコマンド
|
||||
|
||||
Claude Codeセッション履歴を管理 - `~/.claude/sessions/` に保存されたセッションのリスト表示、読み込み、エイリアス設定、編集を行います。
|
||||
|
||||
## 使用方法
|
||||
|
||||
`/sessions [list|load|alias|info|help] [オプション]`
|
||||
|
||||
## アクション
|
||||
|
||||
### セッションのリスト表示
|
||||
|
||||
メタデータ、フィルタリング、ページネーション付きですべてのセッションを表示します。
|
||||
|
||||
```bash
|
||||
/sessions # すべてのセッションをリスト表示（デフォルト）
|
||||
/sessions list # 上記と同じ
|
||||
/sessions list --limit 10 # 10件のセッションを表示
|
||||
/sessions list --date 2026-02-01 # 日付でフィルタリング
|
||||
/sessions list --search abc # セッションIDで検索
|
||||
```
|
||||
|
||||
**スクリプト:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require('./scripts/lib/session-manager');
|
||||
const aa = require('./scripts/lib/session-aliases');
|
||||
|
||||
const result = sm.getAllSessions({ limit: 20 });
|
||||
const aliases = aa.listAliases();
|
||||
const aliasMap = {};
|
||||
for (const a of aliases) aliasMap[a.sessionPath] = a.name;
|
||||
|
||||
console.log('Sessions (showing ' + result.sessions.length + ' of ' + result.total + '):');
|
||||
console.log('');
|
||||
console.log('ID Date Time Size Lines Alias');
|
||||
console.log('────────────────────────────────────────────────────');
|
||||
|
||||
for (const s of result.sessions) {
|
||||
const alias = aliasMap[s.filename] || '';
|
||||
const size = sm.getSessionSize(s.sessionPath);
|
||||
const stats = sm.getSessionStats(s.sessionPath);
|
||||
const id = s.shortId === 'no-id' ? '(none)' : s.shortId.slice(0, 8);
|
||||
const time = s.modifiedTime.toTimeString().slice(0, 5);
|
||||
|
||||
console.log(id.padEnd(8) + ' ' + s.date + ' ' + time + ' ' + size.padEnd(7) + ' ' + String(stats.lineCount).padEnd(5) + ' ' + alias);
|
||||
}
|
||||
"
|
||||
```
|
||||
|
||||
### セッションの読み込み
|
||||
|
||||
セッションの内容を読み込んで表示します（IDまたはエイリアスで指定）。
|
||||
|
||||
```bash
|
||||
/sessions load <id|alias> # セッションを読み込む
|
||||
/sessions load 2026-02-01 # 日付で指定（IDなしセッションの場合）
|
||||
/sessions load a1b2c3d4 # 短縮IDで指定
|
||||
/sessions load my-alias # エイリアス名で指定
|
||||
```
|
||||
|
||||
**スクリプト:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require('./scripts/lib/session-manager');
|
||||
const aa = require('./scripts/lib/session-aliases');
|
||||
const id = process.argv[1];
|
||||
|
||||
// First try to resolve as alias
|
||||
const resolved = aa.resolveAlias(id);
|
||||
const sessionId = resolved ? resolved.sessionPath : id;
|
||||
|
||||
const session = sm.getSessionById(sessionId, true);
|
||||
if (!session) {
|
||||
console.log('Session not found: ' + id);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const stats = sm.getSessionStats(session.sessionPath);
|
||||
const size = sm.getSessionSize(session.sessionPath);
|
||||
const aliases = aa.getAliasesForSession(session.filename);
|
||||
|
||||
console.log('Session: ' + session.filename);
|
||||
console.log('Path: ~/.claude/sessions/' + session.filename);
|
||||
console.log('');
|
||||
console.log('Statistics:');
|
||||
console.log(' Lines: ' + stats.lineCount);
|
||||
console.log(' Total items: ' + stats.totalItems);
|
||||
console.log(' Completed: ' + stats.completedItems);
|
||||
console.log(' In progress: ' + stats.inProgressItems);
|
||||
console.log(' Size: ' + size);
|
||||
console.log('');
|
||||
|
||||
if (aliases.length > 0) {
|
||||
console.log('Aliases: ' + aliases.map(a => a.name).join(', '));
|
||||
console.log('');
|
||||
}
|
||||
|
||||
if (session.metadata.title) {
|
||||
console.log('Title: ' + session.metadata.title);
|
||||
console.log('');
|
||||
}
|
||||
|
||||
if (session.metadata.started) {
|
||||
console.log('Started: ' + session.metadata.started);
|
||||
}
|
||||
|
||||
if (session.metadata.lastUpdated) {
|
||||
console.log('Last Updated: ' + session.metadata.lastUpdated);
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### エイリアスの作成
|
||||
|
||||
セッションに覚えやすいエイリアスを作成します。
|
||||
|
||||
```bash
|
||||
/sessions alias <id> <name> # エイリアスを作成
|
||||
/sessions alias 2026-02-01 today-work # "today-work"という名前のエイリアスを作成
|
||||
```
|
||||
|
||||
**スクリプト:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require('./scripts/lib/session-manager');
|
||||
const aa = require('./scripts/lib/session-aliases');
|
||||
|
||||
const sessionId = process.argv[1];
|
||||
const aliasName = process.argv[2];
|
||||
|
||||
if (!sessionId || !aliasName) {
|
||||
console.log('Usage: /sessions alias <id> <name>');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Get session filename
|
||||
const session = sm.getSessionById(sessionId);
|
||||
if (!session) {
|
||||
console.log('Session not found: ' + sessionId);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const result = aa.setAlias(aliasName, session.filename);
|
||||
if (result.success) {
|
||||
console.log('✓ Alias created: ' + aliasName + ' → ' + session.filename);
|
||||
} else {
|
||||
console.log('✗ Error: ' + result.error);
|
||||
process.exit(1);
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### エイリアスの削除
|
||||
|
||||
既存のエイリアスを削除します。
|
||||
|
||||
```bash
|
||||
/sessions alias --remove <name> # エイリアスを削除
|
||||
/sessions unalias <name> # 上記と同じ
|
||||
```
|
||||
|
||||
**スクリプト:**
|
||||
```bash
|
||||
node -e "
|
||||
const aa = require('./scripts/lib/session-aliases');
|
||||
|
||||
const aliasName = process.argv[1];
|
||||
if (!aliasName) {
|
||||
console.log('Usage: /sessions alias --remove <name>');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const result = aa.deleteAlias(aliasName);
|
||||
if (result.success) {
|
||||
console.log('✓ Alias removed: ' + aliasName);
|
||||
} else {
|
||||
console.log('✗ Error: ' + result.error);
|
||||
process.exit(1);
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### セッション情報
|
||||
|
||||
セッションの詳細情報を表示します。
|
||||
|
||||
```bash
|
||||
/sessions info <id|alias> # セッション詳細を表示
|
||||
```
|
||||
|
||||
**スクリプト:**
|
||||
```bash
|
||||
node -e "
|
||||
const sm = require('./scripts/lib/session-manager');
|
||||
const aa = require('./scripts/lib/session-aliases');
|
||||
|
||||
const id = process.argv[1];
|
||||
const resolved = aa.resolveAlias(id);
|
||||
const sessionId = resolved ? resolved.sessionPath : id;
|
||||
|
||||
const session = sm.getSessionById(sessionId, true);
|
||||
if (!session) {
|
||||
console.log('Session not found: ' + id);
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const stats = sm.getSessionStats(session.sessionPath);
|
||||
const size = sm.getSessionSize(session.sessionPath);
|
||||
const aliases = aa.getAliasesForSession(session.filename);
|
||||
|
||||
console.log('Session Information');
|
||||
console.log('════════════════════');
|
||||
console.log('ID: ' + (session.shortId === 'no-id' ? '(none)' : session.shortId));
|
||||
console.log('Filename: ' + session.filename);
|
||||
console.log('Date: ' + session.date);
|
||||
console.log('Modified: ' + session.modifiedTime.toISOString().slice(0, 19).replace('T', ' '));
|
||||
console.log('');
|
||||
console.log('Content:');
|
||||
console.log(' Lines: ' + stats.lineCount);
|
||||
console.log(' Total items: ' + stats.totalItems);
|
||||
console.log(' Completed: ' + stats.completedItems);
|
||||
console.log(' In progress: ' + stats.inProgressItems);
|
||||
console.log(' Size: ' + size);
|
||||
if (aliases.length > 0) {
|
||||
console.log('Aliases: ' + aliases.map(a => a.name).join(', '));
|
||||
}
|
||||
" "$ARGUMENTS"
|
||||
```
|
||||
|
||||
### エイリアスのリスト表示
|
||||
|
||||
すべてのセッションエイリアスを表示します。
|
||||
|
||||
```bash
|
||||
/sessions aliases # すべてのエイリアスをリスト表示
|
||||
```
|
||||
|
||||
**スクリプト:**
|
||||
```bash
|
||||
node -e "
|
||||
const aa = require('./scripts/lib/session-aliases');
|
||||
|
||||
const aliases = aa.listAliases();
|
||||
console.log('Session Aliases (' + aliases.length + '):');
|
||||
console.log('');
|
||||
|
||||
if (aliases.length === 0) {
|
||||
console.log('No aliases found.');
|
||||
} else {
|
||||
console.log('Name Session File Title');
|
||||
console.log('─────────────────────────────────────────────────────────────');
|
||||
for (const a of aliases) {
|
||||
const name = a.name.padEnd(12);
|
||||
const file = (a.sessionPath.length > 30 ? a.sessionPath.slice(0, 27) + '...' : a.sessionPath).padEnd(30);
|
||||
const title = a.title || '';
|
||||
console.log(name + ' ' + file + ' ' + title);
|
||||
}
|
||||
}
|
||||
"
|
||||
```
|
||||
|
||||
## 引数
|
||||
|
||||
$ARGUMENTS:
|
||||
- `list [オプション]` - セッションをリスト表示
|
||||
- `--limit <n>` - 表示する最大セッション数（デフォルト: 50）
|
||||
- `--date <YYYY-MM-DD>` - 日付でフィルタリング
|
||||
- `--search <パターン>` - セッションIDで検索
|
||||
- `load <id|alias>` - セッション内容を読み込む
|
||||
- `alias <id> <name>` - セッションのエイリアスを作成
|
||||
- `alias --remove <name>` - エイリアスを削除
|
||||
- `unalias <name>` - `--remove`と同じ
|
||||
- `info <id|alias>` - セッション統計を表示
|
||||
- `aliases` - すべてのエイリアスをリスト表示
|
||||
- `help` - このヘルプを表示
|
||||
|
||||
## 例
|
||||
|
||||
```bash
|
||||
# すべてのセッションをリスト表示
|
||||
/sessions list
|
||||
|
||||
# 今日のセッションにエイリアスを作成
|
||||
/sessions alias 2026-02-01 today
|
||||
|
||||
# エイリアスでセッションを読み込む
|
||||
/sessions load today
|
||||
|
||||
# セッション情報を表示
|
||||
/sessions info today
|
||||
|
||||
# エイリアスを削除
|
||||
/sessions alias --remove today
|
||||
|
||||
# すべてのエイリアスをリスト表示
|
||||
/sessions aliases
|
||||
```
|
||||
|
||||
## 備考
|
||||
|
||||
- セッションは `~/.claude/sessions/` にMarkdownファイルとして保存されます
|
||||
- エイリアスは `~/.claude/session-aliases.json` に保存されます
|
||||
- セッションIDは短縮できます（通常、最初の4〜8文字で一意になります）
|
||||
- 頻繁に参照するセッションにはエイリアスを使用してください
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
description: 優先するパッケージマネージャーを設定（npm/pnpm/yarn/bun）
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# パッケージマネージャーの設定
|
||||
|
||||
このプロジェクトまたはグローバルで優先するパッケージマネージャーを設定します。
|
||||
|
||||
## 使用方法
|
||||
|
||||
```bash
|
||||
# 現在のパッケージマネージャーを検出
|
||||
node scripts/setup-package-manager.js --detect
|
||||
|
||||
# グローバル設定を指定
|
||||
node scripts/setup-package-manager.js --global pnpm
|
||||
|
||||
# プロジェクト設定を指定
|
||||
node scripts/setup-package-manager.js --project bun
|
||||
|
||||
# 利用可能なパッケージマネージャーをリスト表示
|
||||
node scripts/setup-package-manager.js --list
|
||||
```
|
||||
|
||||
## 検出の優先順位
|
||||
|
||||
使用するパッケージマネージャーを決定する際、以下の順序でチェックされます:
|
||||
|
||||
1. **環境変数**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **プロジェクト設定**: `.claude/package-manager.json`
|
||||
3. **package.json**: `packageManager` フィールド
|
||||
4. **ロックファイル**: package-lock.json、yarn.lock、pnpm-lock.yaml、bun.lockbの存在
|
||||
5. **グローバル設定**: `~/.claude/package-manager.json`
|
||||
6. **フォールバック**: 最初に利用可能なパッケージマネージャー（pnpm > bun > yarn > npm）
|
||||
|
||||
## 設定ファイル
|
||||
|
||||
### グローバル設定
|
||||
```json
|
||||
// ~/.claude/package-manager.json
|
||||
{
|
||||
"packageManager": "pnpm"
|
||||
}
|
||||
```
|
||||
|
||||
### プロジェクト設定
|
||||
```json
|
||||
// .claude/package-manager.json
|
||||
{
|
||||
"packageManager": "bun"
|
||||
}
|
||||
```
|
||||
|
||||
### package.json
|
||||
```json
|
||||
{
|
||||
"packageManager": "pnpm@8.6.0"
|
||||
}
|
||||
```
|
||||
|
||||
## 環境変数
|
||||
|
||||
`CLAUDE_PACKAGE_MANAGER` を設定すると、他のすべての検出方法を上書きします:
|
||||
|
||||
```bash
|
||||
# Windows (PowerShell)
|
||||
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
|
||||
|
||||
# macOS/Linux
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
```
|
||||
|
||||
## 検出の実行
|
||||
|
||||
現在のパッケージマネージャー検出結果を確認するには、次を実行します:
|
||||
|
||||
```bash
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
@@ -1,174 +0,0 @@
|
||||
---
|
||||
name: skill-create
|
||||
description: ローカルのgit履歴を分析してコーディングパターンを抽出し、SKILL.mdファイルを生成します。Skill Creator GitHub Appのローカル版です。
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /skill-create - ローカルスキル生成
|
||||
|
||||
リポジトリのgit履歴を分析してコーディングパターンを抽出し、Claudeにチームのプラクティスを教えるSKILL.mdファイルを生成します。
|
||||
|
||||
## 使用方法
|
||||
|
||||
```bash
|
||||
/skill-create # 現在のリポジトリを分析
|
||||
/skill-create --commits 100 # 最後の100コミットを分析
|
||||
/skill-create --output ./skills # カスタム出力ディレクトリ
|
||||
/skill-create --instincts # continuous-learning-v2用のinstinctsも生成
|
||||
```
|
||||
|
||||
## 実行内容
|
||||
|
||||
1. **Git履歴の解析** - コミット、ファイル変更、パターンを分析
|
||||
2. **パターンの検出** - 繰り返されるワークフローと慣習を特定
|
||||
3. **SKILL.mdの生成** - 有効なClaude Codeスキルファイルを作成
|
||||
4. **オプションでInstinctsを作成** - continuous-learning-v2システム用
|
||||
|
||||
## 分析ステップ
|
||||
|
||||
### ステップ1: Gitデータの収集
|
||||
|
||||
```bash
|
||||
# ファイル変更を含む最近のコミットを取得
|
||||
git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
|
||||
|
||||
# ファイル別のコミット頻度を取得
|
||||
git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
|
||||
|
||||
# コミットメッセージのパターンを取得
|
||||
git log --oneline -n 200 | cut -d' ' -f2- | head -50
|
||||
```
|
||||
|
||||
### ステップ2: パターンの検出
|
||||
|
||||
以下のパターンタイプを探します:
|
||||
|
||||
| パターン | 検出方法 |
|
||||
|---------|-----------------|
|
||||
| **コミット規約** | コミットメッセージの正規表現(feat:, fix:, chore:) |
|
||||
| **ファイルの共変更** | 常に一緒に変更されるファイル |
|
||||
| **ワークフローシーケンス** | 繰り返されるファイル変更パターン |
|
||||
| **アーキテクチャ** | フォルダ構造と命名規則 |
|
||||
| **テストパターン** | テストファイルの場所、命名、カバレッジ |
|
||||
|
||||
### ステップ3: SKILL.mdの生成
|
||||
|
||||
出力フォーマット:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: {repo-name}-patterns
|
||||
description: {repo-name}から抽出されたコーディングパターン
|
||||
version: 1.0.0
|
||||
source: local-git-analysis
|
||||
analyzed_commits: {count}
|
||||
---
|
||||
|
||||
# {Repo Name} Patterns
|
||||
|
||||
## コミット規約
|
||||
{検出されたコミットメッセージパターン}
|
||||
|
||||
## コードアーキテクチャ
|
||||
{検出されたフォルダ構造と構成}
|
||||
|
||||
## ワークフロー
|
||||
{検出された繰り返しファイル変更パターン}
|
||||
|
||||
## テストパターン
|
||||
{検出されたテスト規約}
|
||||
```
|
||||
|
||||
### ステップ4: Instinctsの生成(--instinctsの場合)
|
||||
|
||||
continuous-learning-v2統合用:
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: {repo}-commit-convention
|
||||
trigger: "when writing a commit message"
|
||||
confidence: 0.8
|
||||
domain: git
|
||||
source: local-repo-analysis
|
||||
---
|
||||
|
||||
# Conventional Commitsを使用
|
||||
|
||||
## Action
|
||||
コミットにプレフィックス: feat:, fix:, chore:, docs:, test:, refactor:
|
||||
|
||||
## Evidence
|
||||
- {n}件のコミットを分析
|
||||
- {percentage}%がconventional commitフォーマットに従う
|
||||
```
|
||||
|
||||
## 出力例
|
||||
|
||||
TypeScriptプロジェクトで`/skill-create`を実行すると、以下のような出力が生成される可能性があります:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: my-app-patterns
|
||||
description: my-appリポジトリからのコーディングパターン
|
||||
version: 1.0.0
|
||||
source: local-git-analysis
|
||||
analyzed_commits: 150
|
||||
---
|
||||
|
||||
# My App Patterns
|
||||
|
||||
## コミット規約
|
||||
|
||||
このプロジェクトは**conventional commits**を使用します:
|
||||
- `feat:` - 新機能
|
||||
- `fix:` - バグ修正
|
||||
- `chore:` - メンテナンスタスク
|
||||
- `docs:` - ドキュメント更新
|
||||
|
||||
## コードアーキテクチャ
|
||||
|
||||
```
|
||||
src/
|
||||
├── components/ # Reactコンポーネント(PascalCase.tsx)
|
||||
├── hooks/ # カスタムフック(use*.ts)
|
||||
├── utils/ # ユーティリティ関数
|
||||
├── types/ # TypeScript型定義
|
||||
└── services/ # APIと外部サービス
|
||||
```
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### 新しいコンポーネントの追加
|
||||
1. `src/components/ComponentName.tsx`を作成
|
||||
2. `src/components/__tests__/ComponentName.test.tsx`にテストを追加
|
||||
3. `src/components/index.ts`からエクスポート
|
||||
|
||||
### データベースマイグレーション
|
||||
1. `src/db/schema.ts`を変更
|
||||
2. `pnpm db:generate`を実行
|
||||
3. `pnpm db:migrate`を実行
|
||||
|
||||
## テストパターン
|
||||
|
||||
- テストファイル: `__tests__/`ディレクトリまたは`.test.ts`サフィックス
|
||||
- カバレッジ目標: 80%以上
|
||||
- フレームワーク: Vitest
|
||||
```
|
||||
|
||||
## GitHub App統合
|
||||
|
||||
高度な機能(10k以上のコミット、チーム共有、自動PR)については、[Skill Creator GitHub App](https://github.com/apps/skill-creator)を使用してください:
|
||||
|
||||
- インストール: [github.com/apps/skill-creator](https://github.com/apps/skill-creator)
|
||||
- 任意のissueで`/skill-creator analyze`とコメント
|
||||
- 生成されたスキルを含むPRを受け取る
|
||||
|
||||
## 関連コマンド
|
||||
|
||||
- `/instinct-import` - 生成されたinstinctsをインポート
|
||||
- `/instinct-status` - 学習したinstinctsを表示
|
||||
- `/evolve` - instinctsをスキル/エージェントにクラスター化
|
||||
|
||||
---
|
||||
|
||||
*[Everything Claude Code](https://github.com/affaan-m/everything-claude-code)の一部*
|
||||
@@ -1,326 +0,0 @@
|
||||
---
|
||||
description: テスト駆動開発ワークフローを強制します。インターフェースをスキャフォールドし、最初にテストを生成し、次にテストに合格するための最小限のコードを実装します。80%以上のカバレッジを保証します。
|
||||
---
|
||||
|
||||
# TDDコマンド
|
||||
|
||||
このコマンドは**tdd-guide**エージェントを呼び出し、テスト駆動開発の手法を強制します。
|
||||
|
||||
## このコマンドの機能
|
||||
|
||||
1. **インターフェースのスキャフォールド** - まず型/インターフェースを定義
|
||||
2. **最初にテストを生成** - 失敗するテストを書く(RED)
|
||||
3. **最小限のコードを実装** - テストに合格するだけのコードを書く(GREEN)
|
||||
4. **リファクタリング** - テストを緑色に保ちながらコードを改善(REFACTOR)
|
||||
5. **カバレッジの検証** - 80%以上のテストカバレッジを保証
|
||||
|
||||
## 使用するタイミング
|
||||
|
||||
以下の場合に`/tdd`を使用します:
|
||||
- 新機能の実装時
|
||||
- 新しい関数/コンポーネントの追加時
|
||||
- バグ修正時(最初にバグを再現するテストを書く)
|
||||
- 既存コードのリファクタリング時
|
||||
- 重要なビジネスロジックの構築時
|
||||
|
||||
## 動作方法
|
||||
|
||||
tdd-guideエージェントは以下を実行します:
|
||||
|
||||
1. **インターフェースを定義**入力/出力の型を決定
|
||||
2. **失敗するテストを書く**(コードがまだ存在しないため)
|
||||
3. **テストを実行**し、正しい理由で失敗することを確認
|
||||
4. **最小限の実装を書く**テストに合格させる
|
||||
5. **テストを実行**し、合格することを確認
|
||||
6. **リファクタリング**テストを緑色に保ちながらコードを改善
|
||||
7. **カバレッジを確認**80%未満の場合はテストを追加
|
||||
|
||||
## TDDサイクル
|
||||
|
||||
```
|
||||
RED → GREEN → REFACTOR → REPEAT
|
||||
|
||||
RED: 失敗するテストを書く
|
||||
GREEN: 合格するための最小限のコードを書く
|
||||
REFACTOR: コードを改善し、テストを合格状態に保つ
|
||||
REPEAT: 次の機能/シナリオへ
|
||||
```
|
||||
|
||||
## 使用例
|
||||
|
||||
```
|
||||
User: /tdd マーケット流動性スコアを計算する関数が必要です
|
||||
|
||||
Agent (tdd-guide):
|
||||
# TDDセッション: マーケット流動性スコア計算機
|
||||
|
||||
## ステップ1: インターフェースの定義(SCAFFOLD)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export interface MarketData {
|
||||
totalVolume: number
|
||||
bidAskSpread: number
|
||||
activeTraders: number
|
||||
lastTradeTime: Date
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// TODO: Implementation
|
||||
throw new Error('Not implemented')
|
||||
}
|
||||
```
|
||||
|
||||
## ステップ2: 失敗するテストを書く(RED)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.test.ts
|
||||
import { calculateLiquidityScore } from './liquidity'
|
||||
|
||||
describe('calculateLiquidityScore', () => {
|
||||
it('should return high score for liquid market', () => {
|
||||
const market = {
|
||||
totalVolume: 100000,
|
||||
bidAskSpread: 0.01,
|
||||
activeTraders: 500,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeGreaterThan(80)
|
||||
expect(score).toBeLessThanOrEqual(100)
|
||||
})
|
||||
|
||||
it('should return low score for illiquid market', () => {
|
||||
const market = {
|
||||
totalVolume: 100,
|
||||
bidAskSpread: 0.5,
|
||||
activeTraders: 2,
|
||||
lastTradeTime: new Date(Date.now() - 86400000) // 1 day ago
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeLessThan(30)
|
||||
expect(score).toBeGreaterThanOrEqual(0)
|
||||
})
|
||||
|
||||
it('should handle edge case: zero volume', () => {
|
||||
const market = {
|
||||
totalVolume: 0,
|
||||
bidAskSpread: 0,
|
||||
activeTraders: 0,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBe(0)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## ステップ3: テストを実行 - 失敗を確認
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
FAIL lib/liquidity.test.ts
|
||||
✕ should return high score for liquid market (2 ms)
|
||||
Error: Not implemented
|
||||
|
||||
1 test failed, 0 passed
|
||||
```
|
||||
|
||||
✅ テストは期待通りに失敗しました。実装の準備ができました。
|
||||
|
||||
## ステップ4: 最小限のコードを実装(GREEN)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// Handle zero volume edge case
|
||||
if (market.totalVolume === 0) {
|
||||
return 0
|
||||
}
|
||||
|
||||
// Calculate component scores (0-100 scale)
|
||||
const volumeScore = Math.min(market.totalVolume / 1000, 100)
|
||||
const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
|
||||
const traderScore = Math.min(market.activeTraders / 10, 100)
|
||||
|
||||
// Recent activity bonus
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)
|
||||
|
||||
// Weighted average
|
||||
const score = (
|
||||
volumeScore * 0.4 +
|
||||
spreadScore * 0.3 +
|
||||
traderScore * 0.2 +
|
||||
recencyScore * 0.1
|
||||
)
|
||||
|
||||
return Math.min(Math.max(score, 0), 100) // Clamp to 0-100
|
||||
}
|
||||
```
|
||||
|
||||
## ステップ5: テストを実行 - 合格を確認
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ should return high score for liquid market (3 ms)
|
||||
✓ should return low score for illiquid market (2 ms)
|
||||
✓ should handle edge case: zero volume (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
✅ すべてのテストが合格しました!
|
||||
|
||||
## ステップ6: リファクタリング(IMPROVE)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts - 定数と可読性を向上させてリファクタリング
|
||||
const WEIGHTS = {
|
||||
VOLUME: 0.4,
|
||||
SPREAD: 0.3,
|
||||
TRADERS: 0.2,
|
||||
RECENCY: 0.1,
|
||||
} as const
|
||||
|
||||
const SCALE_FACTORS = {
|
||||
VOLUME: 1000,
|
||||
SPREAD: 1000,
|
||||
TRADERS: 10,
|
||||
RECENCY_PENALTY: 10,
|
||||
} as const
|
||||
|
||||
function clamp(value: number, min: number, max: number): number {
|
||||
return Math.min(Math.max(value, min), max)
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
if (market.totalVolume === 0) return 0
|
||||
|
||||
const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
|
||||
const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
|
||||
const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
|
||||
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)
|
||||
|
||||
const weightedScore =
|
||||
volumeScore * WEIGHTS.VOLUME +
|
||||
spreadScore * WEIGHTS.SPREAD +
|
||||
traderScore * WEIGHTS.TRADERS +
|
||||
recencyScore * WEIGHTS.RECENCY
|
||||
|
||||
return clamp(weightedScore, 0, 100)
|
||||
}
|
||||
```
|
||||
|
||||
## ステップ7: テストがまだ合格することを確認
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ should return high score for liquid market (3 ms)
|
||||
✓ should return low score for illiquid market (2 ms)
|
||||
✓ should handle edge case: zero volume (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
✅ リファクタリング完了、テストはまだ合格しています!
|
||||
|
||||
## ステップ8: カバレッジの確認
|
||||
|
||||
```bash
|
||||
npm test -- --coverage lib/liquidity.test.ts
|
||||
|
||||
File | % Stmts | % Branch | % Funcs | % Lines
|
||||
---------------|---------|----------|---------|--------
|
||||
liquidity.ts | 100 | 100 | 100 | 100
|
||||
|
||||
Coverage: 100% ✅ (Target: 80%)
|
||||
```
|
||||
|
||||
✅ TDDセッション完了!
|
||||
```
|
||||
|
||||
## TDDベストプラクティス
|
||||
|
||||
**すべきこと:**
|
||||
- ✅ 実装の前にまずテストを書く
|
||||
- ✅ テストを実行し、実装前に失敗することを確認
|
||||
- ✅ テストに合格するための最小限のコードを書く
|
||||
- ✅ テストが緑色になってからのみリファクタリング
|
||||
- ✅ エッジケースとエラーシナリオを追加
|
||||
- ✅ 80%以上のカバレッジを目指す(重要なコードは100%)
|
||||
|
||||
**してはいけないこと:**
|
||||
- ❌ テストの前に実装を書く
|
||||
- ❌ 各変更後のテスト実行をスキップ
|
||||
- ❌ 一度に多くのコードを書く
|
||||
- ❌ 失敗するテストを無視
|
||||
- ❌ 実装の詳細をテスト(動作をテスト)
|
||||
- ❌ すべてをモック化(統合テストを優先)
|
||||
|
||||
## 含めるべきテストタイプ
|
||||
|
||||
**単体テスト**(関数レベル):
|
||||
- ハッピーパスシナリオ
|
||||
- エッジケース(空、null、最大値)
|
||||
- エラー条件
|
||||
- 境界値
|
||||
|
||||
**統合テスト**(コンポーネントレベル):
|
||||
- APIエンドポイント
|
||||
- データベース操作
|
||||
- 外部サービス呼び出し
|
||||
- hooksを使用したReactコンポーネント
|
||||
|
||||
**E2Eテスト**(`/e2e`コマンドを使用):
|
||||
- 重要なユーザーフロー
|
||||
- 複数ステップのプロセス
|
||||
- フルスタック統合
|
||||
|
||||
## カバレッジ要件
|
||||
|
||||
- **すべてのコードに80%以上**
|
||||
- **以下には100%必須**:
|
||||
- 財務計算
|
||||
- 認証ロジック
|
||||
- セキュリティクリティカルなコード
|
||||
- コアビジネスロジック
|
||||
|
||||
## 重要事項
|
||||
|
||||
**必須**: テストは実装の前に書く必要があります。TDDサイクルは:
|
||||
|
||||
1. **RED** - 失敗するテストを書く
|
||||
2. **GREEN** - 合格する実装を書く
|
||||
3. **REFACTOR** - コードを改善
|
||||
|
||||
REDフェーズをスキップしてはいけません。テストの前にコードを書いてはいけません。
|
||||
|
||||
## 他のコマンドとの統合
|
||||
|
||||
- まず`/plan`を使用して何を構築するかを理解
|
||||
- `/tdd`を使用してテスト付きで実装
|
||||
- `/build-and-fix`をビルドエラー発生時に使用
|
||||
- `/code-review`で実装をレビュー
|
||||
- `/test-coverage`でカバレッジを検証
|
||||
|
||||
## 関連エージェント
|
||||
|
||||
このコマンドは以下の場所にある`tdd-guide`エージェントを呼び出します:
|
||||
`~/.claude/agents/tdd-guide.md`
|
||||
|
||||
また、以下の場所にある`tdd-workflow`スキルを参照できます:
|
||||
`~/.claude/skills/tdd-workflow/`
|
||||
@@ -1,27 +0,0 @@
|
||||
# テストカバレッジ
|
||||
|
||||
テストカバレッジを分析し、不足しているテストを生成します。
|
||||
|
||||
1. カバレッジ付きでテストを実行: npm test --coverage または pnpm test --coverage
|
||||
|
||||
2. カバレッジレポートを分析 (coverage/coverage-summary.json)
|
||||
|
||||
3. カバレッジが80%の閾値を下回るファイルを特定
|
||||
|
||||
4. カバレッジ不足の各ファイルに対して:
|
||||
- テストされていないコードパスを分析
|
||||
- 関数の単体テストを生成
|
||||
- APIの統合テストを生成
|
||||
- 重要なフローのE2Eテストを生成
|
||||
|
||||
5. 新しいテストが合格することを検証
|
||||
|
||||
6. カバレッジメトリクスの前後比較を表示
|
||||
|
||||
7. プロジェクト全体で80%以上のカバレッジを確保
|
||||
|
||||
重点項目:
|
||||
- ハッピーパスシナリオ
|
||||
- エラーハンドリング
|
||||
- エッジケース（null、undefined、空）
|
||||
- 境界条件
|
||||
@@ -1,17 +0,0 @@
|
||||
# コードマップの更新
|
||||
|
||||
コードベース構造を分析してアーキテクチャドキュメントを更新します。
|
||||
|
||||
1. すべてのソースファイルのインポート、エクスポート、依存関係をスキャン
|
||||
2. 以下の形式でトークン効率の良いコードマップを生成:
|
||||
- codemaps/architecture.md - 全体的なアーキテクチャ
|
||||
- codemaps/backend.md - バックエンド構造
|
||||
- codemaps/frontend.md - フロントエンド構造
|
||||
- codemaps/data.md - データモデルとスキーマ
|
||||
|
||||
3. 前バージョンとの差分パーセンテージを計算
|
||||
4. 変更が30%を超える場合、更新前にユーザーの承認を要求
|
||||
5. 各コードマップに鮮度タイムスタンプを追加
|
||||
6. レポートを .reports/codemap-diff.txt に保存
|
||||
|
||||
TypeScript/Node.jsを使用して分析します。実装の詳細ではなく、高レベルの構造に焦点を当ててください。
|
||||
@@ -1,31 +0,0 @@
|
||||
# Update Documentation
|
||||
|
||||
信頼できる情報源からドキュメントを同期:
|
||||
|
||||
1. package.jsonのscriptsセクションを読み取る
|
||||
- スクリプト参照テーブルを生成
|
||||
- コメントからの説明を含める
|
||||
|
||||
2. .env.exampleを読み取る
|
||||
- すべての環境変数を抽出
|
||||
- 目的とフォーマットを文書化
|
||||
|
||||
3. docs/CONTRIB.mdを生成:
|
||||
- 開発ワークフロー
|
||||
- 利用可能なスクリプト
|
||||
- 環境セットアップ
|
||||
- テスト手順
|
||||
|
||||
4. docs/RUNBOOK.mdを生成:
|
||||
- デプロイ手順
|
||||
- 監視とアラート
|
||||
- 一般的な問題と修正
|
||||
- ロールバック手順
|
||||
|
||||
5. 古いドキュメントを特定:
|
||||
- 90日以上変更されていないドキュメントを検出
|
||||
- 手動レビュー用にリスト化
|
||||
|
||||
6. 差分サマリーを表示
|
||||
|
||||
信頼できる唯一の情報源: package.jsonと.env.example
|
||||
@@ -1,59 +0,0 @@
|
||||
# 検証コマンド
|
||||
|
||||
現在のコードベースの状態に対して包括的な検証を実行します。
|
||||
|
||||
## 手順
|
||||
|
||||
この正確な順序で検証を実行してください:
|
||||
|
||||
1. **ビルドチェック**
|
||||
- このプロジェクトのビルドコマンドを実行
|
||||
- 失敗した場合、エラーを報告して**停止**
|
||||
|
||||
2. **型チェック**
|
||||
- TypeScript/型チェッカーを実行
|
||||
- すべてのエラーをファイル:行番号とともに報告
|
||||
|
||||
3. **Lintチェック**
|
||||
- Linterを実行
|
||||
- 警告とエラーを報告
|
||||
|
||||
4. **テストスイート**
|
||||
- すべてのテストを実行
|
||||
- 合格/不合格の数を報告
|
||||
- カバレッジのパーセンテージを報告
|
||||
|
||||
5. **Console.log監査**
|
||||
- ソースファイルでconsole.logを検索
|
||||
- 場所を報告
|
||||
|
||||
6. **Git状態**
|
||||
- コミットされていない変更を表示
|
||||
- 最後のコミット以降に変更されたファイルを表示
|
||||
|
||||
## 出力
|
||||
|
||||
簡潔な検証レポートを生成します:
|
||||
|
||||
```
|
||||
VERIFICATION: [PASS/FAIL]
|
||||
|
||||
Build: [OK/FAIL]
|
||||
Types: [OK/X errors]
|
||||
Lint: [OK/X issues]
|
||||
Tests: [X/Y passed, Z% coverage]
|
||||
Secrets: [OK/X found]
|
||||
Logs: [OK/X console.logs]
|
||||
|
||||
Ready for PR: [YES/NO]
|
||||
```
|
||||
|
||||
重大な問題がある場合は、修正案とともにリストアップします。
|
||||
|
||||
## 引数
|
||||
|
||||
$ARGUMENTS は以下のいずれか:
|
||||
- `quick` - ビルド + 型チェックのみ
|
||||
- `full` - すべてのチェック（デフォルト）
|
||||
- `pre-commit` - コミットに関連するチェック
|
||||
- `pre-pr` - 完全なチェック + セキュリティスキャン
|
||||
Reference in New Issue
Block a user