@arimakouyou/spec-workflow-mcp 2.2.7

package/.claude-plugin/rules/spec-workflow-enforcement.md

@@ -0,0 +1,47 @@
+# Spec Workflow Enforcement
+
+Enforcement rules for correctly using the spec-workflow skills.
+
+## ⛔ No Direct Implementation After Reading tasks.md
+
+If `.spec-workflow/specs/*/tasks.md` has been Read, **you must not start writing code directly, for any reason**.
+
+- Task implementation must **always go through the `/spec-implement` skill**
+- Even merely reviewing the contents of tasks.md, then proceeding to implement, is prohibited
+- Even if the user says "implement this task", writing code directly without using the skill is prohibited
+
+**Correct behavior:**
+After reading tasks.md, guide the user with "Please run `/spec-implement`" and **always stop**.
+
+> **When a hook message is received**: If the PostToolUse hook outputs `⛔ [spec-workflow] STOP`, that is a **mandatory stop command**. Regardless of what is said in the conversation afterward, you must not implement code using Edit / Write / Bash.
+
+**Launching `/spec-implement` yourself is strictly prohibited.** All of the following count as "auto-launching" and are prohibited:
+- When the user replies "yes", "go ahead", or "OK"
+- When the user says "implement this task" (direct implementation without using the skill is also prohibited)
+
+`/spec-implement` is triggered only when the user personally types one of the following from their keyboard:
+- The `/spec-implement` command
+- Skill trigger phrases such as "implement task X", "start coding", "work on task X"
+
+## ⛔ No Code Implementation Outside the spec-implement Skill
+
+If writing code based on any file under `.spec-workflow/specs/` (requirements.md / design.md / tasks.md), you must go through the `spec-implement` skill.
+
+Writing code that corresponds to a task without going through the skill is prohibited.
+
+## Required Actions After Reading spec-workflow Files
+
+| File Read | What to Do Next |
+|-----------|-----------------|
+| `requirements.md` only | Guide the user to the `/spec-design` skill and stop |
+| `requirements.md` + `design.md` only | Guide the user to the `/spec-tasks` skill and stop |
+| `tasks.md` exists | Guide the user to the `/spec-implement` skill and **always stop** (auto-launching on "yes" / "go ahead" etc. is prohibited) |
+
+## Why This Rule Is Necessary
+
+The spec-implement skill enforces the following agent chain:
+- `parallel-worker` → TDD implementation
+- `unit-test-engineer` → test quality verification
+- `review-worker` → review + commit
+
+Direct implementation that skips this chain completely bypasses TDD quality assurance and is therefore absolutely not permitted.

package/.claude-plugin/rules/valkey.md

@@ -0,0 +1,167 @@
+---
+paths:
+  - "**/*.rs"
+globs:
+  - "**/Cargo.toml"
+---
+
+# Valkey (redis-rs) Best Practices
+
+Valkey は Redis 互換のインメモリデータストア。Rust クライアントには `redis-rs` を使用する。
+
+## 依存関係
+
+```toml
+[dependencies]
+redis = { version = "0.27", features = ["tokio-comp", "connection-manager"] }
+```
+
+- `tokio-comp` feature で非同期サポートを有効化する
+- クラスター使用時は `cluster-async` feature を追加する
+
+## 接続管理
+
+- 非同期接続には `MultiplexedConnection` を使う (クローン可能、スレッドセーフ)
+- 接続プールは通常不要。`MultiplexedConnection` が内部で多重化する
+- 自動再接続には `ConnectionManager` (`connection-manager` feature) を使う
+- ブロッキングコマンド (`BLPOP`, `BRPOP` 等) は専用の接続で実行する
+
+```rust
+use redis::Client;
+
+let client = Client::open("redis://127.0.0.1:6379/")?;
+let conn = client.get_multiplexed_async_connection().await?;
+
+// conn は Clone 可能なので AppState に格納して共有できる
+#[derive(Clone)]
+struct AppState {
+    db_pool: DbPool,
+    valkey: redis::aio::MultiplexedConnection,
+}
+```
+
+## ConnectionManager による自動再接続
+
+```rust
+use redis::aio::ConnectionManager;
+
+let client = Client::open("redis://127.0.0.1:6379/")?;
+let conn = ConnectionManager::new(client).await?;
+// conn は Clone 可能、接続断時に自動再接続する
+```
+
+## コマンド実行
+
+- `AsyncCommands` トレイトを import して高レベル API を使う
+- 型パラメータで戻り値の型を指定する
+- 存在しないキーの取得には `Option<T>` を使う
+
+```rust
+use redis::AsyncCommands;
+
+// SET / GET
+let _: () = conn.set("key", "value").await?;
+let val: String = conn.get("key").await?;
+
+// Option で存在チェック
+let maybe: Option<String> = conn.get("maybe_missing").await?;
+
+// 有効期限付き SET
+let _: () = conn.set_ex("session:abc", session_data, 3600).await?;
+
+// ハッシュ操作
+let _: () = conn.hset("user:1", "name", "Alice").await?;
+let name: String = conn.hget("user:1", "name").await?;
+
+// DEL
+let _: () = conn.del("key").await?;
+```
+
+## パイプライン
+
+- 複数コマンドを一度に送信してネットワークラウンドトリップを削減する
+- バッチ処理やキャッシュのウォームアップに使う
+
+```rust
+let (k1, k2): (i32, i32) = redis::pipe()
+    .set("key_1", 42).ignore()
+    .set("key_2", 43).ignore()
+    .get("key_1")
+    .get("key_2")
+    .query_async(&mut conn)
+    .await?;
+```
+
+## キー設計
+
+- プレフィックスとコロン区切りで名前空間を作る: `{entity}:{id}:{attribute}`
+- 例: `user:123:profile`, `session:abc123`, `cache:posts:page:1`
+- キー名は短く、しかし読みやすく
+- TTL (有効期限) を必ず設定する。期限なしキーはメモリリークの原因になる
+
+## キャッシュパターン
+
+- Cache-Aside パターンを基本とする
+- キャッシュミス時にDBから取得してキャッシュに書き込む
+- 更新時はキャッシュを削除する (更新ではなく削除が安全)
+
+```rust
+async fn get_user_cached(
+    conn: &mut impl AsyncCommands,
+    db: &mut AsyncPgConnection,
+    user_id: i64,
+) -> Result<User, AppError> {
+    let cache_key = format!("user:{user_id}");
+
+    // キャッシュ確認
+    if let Some(cached) = conn.get::<_, Option<String>>(&cache_key).await? {
+        return Ok(serde_json::from_str(&cached)?);
+    }
+
+    // DB から取得
+    let user = users::table
+        .find(user_id)
+        .select(User::as_select())
+        .first(db)
+        .await?;
+
+    // キャッシュに保存 (TTL 付き)
+    let serialized = serde_json::to_string(&user)?;
+    let _: () = conn.set_ex(&cache_key, &serialized, 300).await?;
+
+    Ok(user)
+}
+
+async fn update_user(/* ... */) -> Result<User, AppError> {
+    // DB 更新
+    let user = diesel::update(users::table.find(user_id))
+        .set(&changes)
+        .get_result::<User>(db)
+        .await?;
+
+    // キャッシュ削除 (更新ではなく削除)
+    let _: () = conn.del(format!("user:{user_id}")).await?;
+
+    Ok(user)
+}
+```
+
+## セッション管理
+
+- セッションデータは Valkey のハッシュ型で格納する
+- セッション ID はランダム生成し、推測不可能にする
+- TTL を必ず設定する (例: 24時間)
+
+## エラーハンドリング
+
+- `redis::RedisError` を `AppError` に変換する `From` 実装を用意する
+- 接続エラー時はリトライロジックを入れる (`ConnectionManager` 使用時は自動)
+- Valkey ダウン時にもアプリケーションが degraded mode で動作できるようにする
+
+## やってはいけないこと
+
+- `KEYS *` を本番で使わない → `SCAN` を使う
+- 大きな値 (> 1MB) を単一キーに保存しない
+- Lua スクリプトで長時間ブロックしない
+- TTL なしでキャッシュを保存しない
+- `FLUSHALL` / `FLUSHDB` を本番で使わない

package/.claude-plugin/skills/integration-test/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: integration-test
+description: "Parallelizes integration test creation in Agent Teams. Workers (alpha/bravo) implement tests, and Pentagon performs quality review. Use for tasks related to integration test, Axum, Diesel, testcontainers, Agent Teams, and pentagon."
+argument-hint: "<domain>[,<domain>...] [--dry-run] [--base-branch <branch>]"
+user-invokable: true
+---
+
+# integration-test
+
+A skill that uses Agent Teams to create integration tests under `tests/integration/` in parallel.
+Workers (alpha/bravo) implement the tests, and Pentagon reviews them at the quality gate.
+
+Tech stack: Axum + Diesel + diesel-async + Valkey (redis-rs) + testcontainers-rs
+
+## Execution Environment Rules
+
+| Rule | Description |
+|--------|------|
+| **No self-created branches/worktrees** | Do not directly run `git checkout -b` / `git worktree add` |
+| **When `--base-branch` is not specified** | Work in the current directory on the current branch |
+| **When `--base-branch` is specified** | Create a worktree via the `create-git-worktree` skill |
+
+## Design Policy
+
+| Dependency Type | Policy |
+|----------|------|
+| **DB (PostgreSQL)** | Use a real PostgreSQL container via testcontainers-rs (no mocking) |
+| **External HTTP APIs** | Swap in test doubles via trait-based DI |
+| **Valkey / Cache** | testcontainers-rs or trait DI override |
+
+## Team Composition (always 3 roles)
+
+| Role | Agent | Responsibility |
+|------|------------|------|
+| **Command** (Leader) | Main agent | Commander and strategy planner |
+| **Workers** (alpha/bravo) | Sub-agent x 1-2 | Test implementation |
+| **Pentagon** (Reviewer) | Sub-agent | Quality review and judgment |
+
+## Arguments
+
+`$ARGS` is specified as a comma-separated list of domain names (e.g., `users,posts`).
+
+| Argument | Required | Description |
+|------|:----:|------|
+| `$ARGS` | YES | `{domain}[,{domain}...]` (comma-separated) |
+| `--dry-run` | - | Print the assignment plan and exit |
+| `--base-branch <branch>` | - | Branch to derive the worktree from |
+| `--api <method>` | - | Only target a specific HTTP method |
+
+### Usage Examples
+
+```bash
+# Parallel execution (2 targets)
+/integration-test users,posts
+
+# dry-run (show plan only)
+/integration-test users,posts --dry-run
+
+# Single target (alpha 1 + Pentagon 1)
+/integration-test sessions
+
+# Specific method only
+/integration-test users --api GET
+```
+
+---
+
+## Flow Overview
+
+```
+/integration-test users,posts
+    |
+    +-- [P0] Parse & Analyze
+    |     +-- Parse arguments (comma-separated)
+    |     +-- For each target: trace handler → repository → model
+    |     +-- Worker assignment plan
+    |     +-- --dry-run: show plan only and exit
+    |
+    +-- [P1] Setup Team
+    |     +-- Pre-check test helpers and shared fixtures
+    |     +-- Create whiteboard
+    |
+    +-- [P2] Launch Agents
+    |     +-- Launch Workers (alpha/bravo) x 1-2
+    |     +-- Launch Pentagon x 1
+    |     +-- Assign initial tasks
+    |
+    +-- [P3] Monitor & Facilitate
+    |     +-- Worker completes -> Request Pentagon review
+    |     +-- PASS -> Update whiteboard, assign next task
+    |     +-- FAIL -> Send back to Worker (max 3 times)
+    |
+    +-- [P4] Final Verification
+    |     +-- Run cargo test across all test files
+    |     +-- rustfmt + clippy
+    |
+    +-- [P5] Cleanup & Report
+          +-- Aggregate results
+          +-- Clean up whiteboard
+          +-- Output final report
+```
+
+---
+
+## Executor Instructions
+
+**You (Command) manage the team following the steps below.**
+
+### P0: Parse & Analyze
+
+1. Split `$ARGS` by comma to build the target list
+2. **For each target**:
+   - Identify handler: trace routes and handlers from `src/handlers/{domain}.rs`
+   - Identify repository: analyze query logic from `src/db/repository/{domain}.rs`
+   - Identify model: check Diesel models from `src/models/{domain}.rs`
+   - Identify external dependencies: find trait-based dependencies (e.g., external API clients)
+3. **Worker assignment**: assign to Workers per test file
+
+   | # of Targets | # of Workers | Assignment Method |
+   |:------:|:---------:|---------|
+   | 1 | 1 | All to alpha |
+   | 2 | 2 | One each to alpha / bravo |
+   | 3+ | 2 | Round-robin |
+
+4. **On `--dry-run`**: output the following and exit
+
+```
+[dry-run] Assignment plan:
+  alpha: {domain_a} -> tests/integration/test_{domain_a}.rs
+    - {method} {path}
+  bravo: {domain_b} -> tests/integration/test_{domain_b}.rs
+    - {method} {path}
+  pentagon: quality review
+```
+
+### P1: Setup Team
+
+1. Check and update shared test helpers (`tests/integration/helpers/`)
+2. Create whiteboard: Write following [whiteboard-template.md](references/whiteboard-template.md)
+   - **Always set Key Questions** (1-3 items)
+
+### P2: Launch Agents
+
+Launch Workers and Pentagon as sub-agents. Specify the agent definition under `.claude/agents/` via `subagent_type`.
+
+**Launch Pentagon** (launch first to put it in a review-request waiting state):
+```
+Agent(
+  subagent_type: "integ-test-auditor",
+  prompt: "Whiteboard: {whiteboard_path}\nPlease wait for a review request from Command."
+)
+```
+
+**Launch Workers** (fill in variables from [worker-prompt.md](references/worker-prompt.md)):
+```
+Agent(
+  subagent_type: "integ-test-worker",
+  prompt: "Worker name: {worker_name}\nDomain: {domain}\nTest file: tests/integration/test_{domain}.rs\nTarget endpoints:\n{endpoint_list}\nWhiteboard: {whiteboard_path}"
+)
+```
+
+If there are 2 or more targets, launch alpha/bravo in parallel.
+
+### P3: Monitor & Facilitate
+
+Main loop: monitor until all tasks are complete.
+
+**When a Worker completes**:
+1. Copy Worker Findings to the whiteboard
+2. Request a review from Pentagon
+
+**When Pentagon returns PASS**:
+1. Update the Quality Gate Results on the whiteboard
+2. Assign the next unassigned task to a Worker if one exists
+
+**When Pentagon returns FAIL**:
+1. Count the number of reviews (per test file)
+2. Under 3 times: re-run the Worker with a prompt including the review comments
+3. 3rd time: mark as complete with remaining issues noted on the whiteboard
+
+### P4: Final Verification
+
+```bash
+# Run across all test files
+cargo test --test test_{domain} -- --nocapture
+
+# Code quality
+cargo fmt --all -- --check
+cargo clippy --quiet --all-targets -- -D warnings
+```
+
+If verification fails, Command fixes it directly.
+
+### P5: Cleanup & Report
+
+1. Move the whiteboard to `.claude/_docs/deleted/`
+2. Output the final report:
+
+```
+integration-test parallel implementation complete
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Targets: {targets}
+
+Generated files:
+  {file_list}
+
+Test results:
+  {test_summary}
+
+Quality gate:
+  {quality_gate_results}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+## References
+
+| Document | Purpose |
+|------------|------|
+| [quality-gate.md](references/quality-gate.md) | Pentagon's judgment criteria |
+| [test-case-design.md](references/test-case-design.md) | 5 test case classifications |
+| [test-patterns.md](references/test-patterns.md) | Test implementation patterns |
+| [fixture-catalog.md](references/fixture-catalog.md) | Shared helpers and fixture catalog |
+| [external-api-mock.md](references/external-api-mock.md) | External API mock patterns |
+| [worker-prompt.md](references/worker-prompt.md) | Worker prompt template |
+| [auditor-prompt.md](references/auditor-prompt.md) | Pentagon prompt template |
+| [whiteboard-template.md](references/whiteboard-template.md) | Whiteboard template |
+| [parallel-execution.md](references/parallel-execution.md) | Parallel execution flow details |

package/.claude-plugin/skills/integration-test/references/auditor-prompt.md

@@ -0,0 +1,78 @@
+# Pentagon プロンプトテンプレート
+
+Pentagon（Reviewer）起動時に展開するプロンプト。
+`{変数}` は Command が起動時に埋め込む。
+
+---
+
+```
+あなたは integration-test の品質レビュアー「Pentagon」です。
+
+## 役割
+Worker が作成したインテグレーションテストの品質を判定する。
+判定基準は references/quality-gate.md に従う。
+
+## 事前読み込み
+以下のファイルを起動時に Read する:
+1. references/quality-gate.md（判定基準）
+2. references/test-case-design.md（5 分類体系）
+3. {whiteboard_path}（ホワイトボード）
+
+## レビュー依頼の受信
+
+Command からレビュー依頼を受け取ったら以下の手順で審査する:
+
+### 1. テストファイルを Read
+対象のテストファイルと、関連する本番コード（handler, repository, model, dto）を Read する。
+
+### 2. 判定基準に従いチェック
+
+A. 5 分類カバレッジ
+- 各エンドポイントに対して 5 分類が網羅されているか
+- test-case-design.md の必須テストケースが含まれているか
+
+B. 振る舞い契約の検証
+- HTTP ステータスコード、レスポンスボディ、DB 状態変更が検証されているか
+
+C. コード品質
+- Given-When-Then 構造、命名、独立性
+
+D. Hermetic & Deterministic
+- testcontainers or トランザクション分離、trait DI、時刻制御
+
+E. Rust 固有
+- #[tokio::test]、clippy、rustfmt
+
+### 3. 判定結果を報告
+
+以下のフォーマットで報告する:
+
+```
+[Pentagon Review] {test_file}
+
+判定: PASS / FAIL
+
+A. 5分類カバレッジ: PASS / FAIL
+   {詳細}
+
+B. 振る舞い契約: PASS / FAIL
+   {詳細}
+
+C. コード品質: PASS / FAIL
+   {詳細}
+
+D. Hermetic: PASS / FAIL
+   {詳細}
+
+E. Rust 固有: PASS / FAIL
+   {詳細}
+
+修正指示:（FAIL の場合のみ）
+  1. {具体的な修正内容}
+```
+
+## レビューサイクル
+- 最大 3 回のレビューサイクル
+- 3 回目で FAIL の場合は残存指摘付きで完了扱いとし、Command に報告する
+- PASS の場合はホワイトボードの Quality Gate Results 更新を Command に依頼する
+```

package/.claude-plugin/skills/integration-test/references/external-api-mock.md

@@ -0,0 +1,98 @@
+# 外部 API モックパターン
+
+trait ベースの DI で外部 API クライアントをテストダブルに差し替えるパターン。
+
+## 推奨パターン: trait DI override
+
+```rust
+// 本番コード: trait 定義
+#[async_trait]
+pub trait PaymentGateway: Send + Sync {
+    async fn charge(&self, amount: u64) -> Result<PaymentResult, PaymentError>;
+}
+
+// 本番実装
+pub struct StripeGateway { /* ... */ }
+
+#[async_trait]
+impl PaymentGateway for StripeGateway {
+    async fn charge(&self, amount: u64) -> Result<PaymentResult, PaymentError> {
+        // 実際の API 呼び出し
+    }
+}
+```
+
+## テスト用テストダブル
+
+### Stub（固定値を返す）
+
+```rust
+pub struct StubPaymentGateway {
+    pub result: Result<PaymentResult, PaymentError>,
+}
+
+#[async_trait]
+impl PaymentGateway for StubPaymentGateway {
+    async fn charge(&self, _amount: u64) -> Result<PaymentResult, PaymentError> {
+        self.result.clone()
+    }
+}
+```
+
+### Spy（呼び出し記録 + 固定値）
+
+```rust
+pub struct SpyPaymentGateway {
+    pub calls: Arc<Mutex<Vec<u64>>>,
+    pub result: Result<PaymentResult, PaymentError>,
+}
+
+#[async_trait]
+impl PaymentGateway for SpyPaymentGateway {
+    async fn charge(&self, amount: u64) -> Result<PaymentResult, PaymentError> {
+        self.calls.lock().unwrap().push(amount);
+        self.result.clone()
+    }
+}
+```
+
+### 失敗する外部 API
+
+```rust
+pub struct FailingPaymentGateway;
+
+#[async_trait]
+impl PaymentGateway for FailingPaymentGateway {
+    async fn charge(&self, _amount: u64) -> Result<PaymentResult, PaymentError> {
+        Err(PaymentError::ServiceUnavailable)
+    }
+}
+```
+
+## TestContext への組み込み
+
+```rust
+impl TestContext {
+    pub async fn with_failing_external_api() -> Self {
+        let (container, url) = create_pg_container().await;
+        run_migrations(&url).await;
+        let db_pool = create_pool(&url);
+
+        // 失敗する外部 API を注入
+        let state = AppState {
+            db_pool: db_pool.clone(),
+            payment: Arc::new(FailingPaymentGateway) as Arc<dyn PaymentGateway>,
+            // ...
+        };
+
+        let app = routes().with_state(state);
+        Self { app, db_pool, _pg_container: container, /* ... */ }
+    }
+}
+```
+
+## 禁止事項
+
+- `#[cfg(test)]` で本番コードの振る舞いを変えない
+- mockall で具象型を直接 mock しない → 必ず trait を経由する
+- テスト内で `std::env::set_var` で環境変数を書き換えない（テスト間で干渉する）