# Test Plan

> PRのTest planチェックリストからローカル実行用テスト手順書を生成しPRコメントに投稿

- Skill: `ousiass/test-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ousiass/test-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ousiass/test-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ousiass (https://skillmd.com/u/ousiass)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ousiass/test-plan

---


# Test Plan Generator

PRのbodyに書かれたTest planチェックリストを読み取り、PRの差分とリポジトリ構成を分析して、ローカル環境での具体的なテスト実行手順書を生成し、PRコメントとして投稿する。

**対象読者: 非エンジニアを含む全メンバー。** 専門用語を避け、コマンドはコピペで完結させ、操作は「どこをクリックして何が表示されればOK」のレベルで書く。

## 引数

- 第1引数: PR番号（必須）
- 第2引数: `owner/repo`（任意、省略時はカレントリポジトリ）

例: `/test-plan 176`, `/test-plan 176 NonEntropyJapan/Kaikei-Support`

## ワークフロー

### Phase 1: 情報収集

以下を**並列**で取得する:

1. **PR情報**: `gh pr view <番号> --json title,body,files,baseRefName,headRefName`
2. **PR差分**: `gh pr diff <番号>`
3. **リポジトリ構成**: ルートディレクトリの内容を確認

第2引数がある場合は各 gh コマンドに `--repo <owner/repo>` を付与する。

### Phase 2: 解析

#### 2a. テスト項目の抽出

PRのbodyからTest planセクション（表記揺れを許容）を探し、チェックリストを抽出する。

- `- [ ]` 未完了項目 → 手順書の対象
- `- [x]` 完了済み項目 → 「自動テストで確認済み」と1行で記載し、手順は省略

チェックリストが見つからない場合はユーザーに報告して終了。

#### 2b. 環境起動方法の特定

リポジトリ構成とPR差分から、ローカル起動方法を判定する。主な手がかり:

1. `docker-compose.yml` / `compose.yml` がある → `docker compose up -d`
2. `supabase/` ディレクトリがある → `supabase start`
3. `Makefile` がある → Makefileの内容を確認してdev/start系ターゲットを探す
4. `package.json` の scripts を確認 → `npm run dev` 等

backend / frontend が分離している場合はそれぞれの起動方法を記載する。

#### 2c. 環境変数の特定

PR差分に `.env.example` や環境変数の追加・変更がある場合、新規に必要な環境変数をリストアップする。

#### 2d. テスト手順の生成

**各テスト項目について**、PR差分の関連コードを読み、以下を生成:

- **手順**: 番号付きステップで具体的な操作を記述
  - APIエンドポイントの変更 → curl コマンドやHTTPリクエスト例
  - UI変更 → ブラウザでの操作手順
  - Webhook/外部連携 → テスト用リクエストの送り方
- **確認ポイント**: 何が起きれば成功か
- **関連ファイル**: 差分の中で該当するファイルパス

変換の例:

| テスト項目 | 差分から読み取れること | 生成する手順 |
|---|---|---|
| 承認依頼 → ボタン付きメッセージ送信確認 | `lib/slack.ts` で `chat.postMessage` + Block Kit、`routes/workflows/submit.ts` でワークフロー提出時に通知 | 1. フロントから経費申請を提出（http://localhost:3000）<br>2. Slackチャンネルを確認<br>確認: ✅承認 / ❌却下 ボタン付きメッセージが届く |
| ボタン押下 → 承認処理 → メッセージ更新確認 | `routes/slack/interactions.ts` で `action_id` を処理、SlackユーザーID → 従業員特定 → WorkflowApproval作成 | 1. Slackで✅承認ボタンをクリック<br>2. DBの WorkflowApproval テーブルを確認<br>確認: メッセージが「承認済み」に更新される |

### Phase 3: 手順書の組み立て

以下のフォーマットで手順書を組み立てる。

#### 書き方のルール

- **専門用語は使わない。** やむを得ず使う場合は直後にカッコで補足する
  - 悪い例: `supabase start でローカルDBを起動`
  - 良い例: `supabase start（データベースをPC上で起動するコマンド）`
- **コマンドはコピペで完結させる。** 「`<YOUR_TOKEN>` を置き換えてください」のような穴埋めが必要な場合は、何をどこで取得するかを具体的に書く
  - 悪い例: `SLACK_BOT_TOKEN=<your-token>`
  - 良い例: `SLACK_BOT_TOKEN=ここにトークンを貼り付け`（取得方法: Slack管理画面 → OAuth & Permissions → Bot User OAuth Token をコピー）
- **操作は「どこを → どうする → 何が起きる」の3点セットで書く**
  - 悪い例: `承認依頼を送信して確認`
  - 良い例: `画面左の「経費申請」メニューをクリック → 金額に「1000」と入力して「送信」ボタンを押す → 「申請を受け付けました」と表示される`
- **成功/失敗を明確に書く。** 「問題なければOK」は禁止。具体的に何が見えれば成功かを書く
  - 悪い例: `メッセージが届くことを確認`
  - 良い例: `Slackの #approval チャンネルに「承認依頼: 経費申請 ¥1,000」というメッセージが届き、「✅承認」「❌却下」の2つのボタンが表示されていればOK`
- **困ったときの対処も書く。** 各ステップで「うまくいかない場合」のヒントを添える
  - 例: `※ 画面が表示されない場合 → ターミナルに戻り、エラーメッセージが出ていないか確認してください`

#### 出力テンプレート

```markdown
## テスト手順書

> PR: #<番号> <タイトル>

### 準備するもの
- <必要なツール（インストール手順のリンク付き）>

### 事前準備: 環境変数の設定
<新規に必要な環境変数がある場合のみ。取得場所と設定方法をステップで記載>

### 手順1: アプリをPC上で起動する

<判定した起動手順。各コマンドに「何をしているか」の説明を添える>

※ うまくいかない場合 → <よくあるトラブルと対処>

---

### テスト項目

#### テスト1: <テスト項目名>
**やること:**
1. <どこを> → <どうする>
2. ...

**成功の目安:** <具体的に何が見えればOK>

※ うまくいかない場合 → <ヒント>

#### テスト2: <テスト項目名>
...

---

### 自動テスト（開発者向け）
<テストコマンドがある場合。非エンジニアはスキップ可と明記>

### 後片付け: アプリを停止する
<停止コマンドと「何をしているか」の説明>
```

### Phase 4: 投稿

生成した手順書を `gh pr comment <番号> --body "..."` でPRコメントとして投稿する。確認は不要、そのまま投稿してよい。

## 注意事項

- テスト項目が外部サービス連携（Slack, 決済等）を含む場合、モックやテスト環境での代替手段を提案
- 手順書は実行者がコードを読まなくても手順通りに進められるレベルの具体性を目指す
- 差分が大きい場合はAgentツールを使って並列に解析する