Menü
リリース前の手動テストチェックリストIssueを作成する。指定バージョンタグからの変更を分析し、手動確認が必要な項目をGitHub Issueとして起票する。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
アプリ全体を探索し、潜在的なバグ・改善点・UX課題を調査してIssueに起票する。重点ポイントを指定可能。
featureブランチの変更をCodexプラグイン（/codex:review）にレビュー依頼し、指摘がなくなるまで修正を繰り返す。
PRレビューのフィードバックを確認し、対応の必要性を検討する。レビュー結果への対応方針を提案する。
リリース後の作業を実行する。GitHub Release作成（または更新）と次期バージョンに向けた課題整理を行う。
リリース準備を行う。指定バージョンタグから最新mainまでの変更内容を確認し、適切なバージョン番号を提案する。
GitHub Issueの対応を開始する。Issue番号またはフィルタ条件を指定して、Issue対応フローに従い順次対応を進める。
| name | manual-test-checklist |
| description | リリース前の手動テストチェックリストIssueを作成する。指定バージョンタグからの変更を分析し、手動確認が必要な項目をGitHub Issueとして起票する。 |
| argument-hint | [比較元バージョンタグ e.g. 0.0.12（省略時は直前のタグを自動検出）] |
比較元バージョンタグから最新 main までのコード変更を分析し、手動での動作確認が必要な項目を GitHub Issue として起票する。
原則: 手動でしか確認できない変更（視覚的変更、ブラウザ動作、レスポンシブ等）を漏れなくチェックリスト化する。
digraph manual_test {
rankdir=TB;
"1. 情報収集" [shape=box];
"2. 変更分析・グルーピング" [shape=box];
"3. テスト除外判定" [shape=box];
"4. チェックリスト生成" [shape=box];
"5. ユーザー確認" [shape=diamond];
"6. Issue 起票" [shape=box];
"1. 情報収集" -> "2. 変更分析・グルーピング";
"2. 変更分析・グルーピング" -> "3. テスト除外判定";
"3. テスト除外判定" -> "4. チェックリスト生成";
"4. チェックリスト生成" -> "5. ユーザー確認";
"5. ユーザー確認" -> "6. Issue 起票" [label="承認"];
"5. ユーザー確認" -> "4. チェックリスト生成" [label="修正依頼"];
}
$ARGUMENTS が指定されている場合はそのタグを使用する。省略された場合は直前のタグを自動検出する:
BASE_TAG=$(git describe --tags --abbrev=0)
echo "比較元タグ: $BASE_TAG"
以降のステップでは、決定したタグを <BASE_TAG> として参照する。
以下を並列で収集する:
# 変更ファイル一覧（プロダクションコードのみ）
git diff --name-only <BASE_TAG>...main -- 'src/'
# 変更統計
git diff --stat <BASE_TAG>...main -- 'src/' | tail -1
# コミット一覧
git log <BASE_TAG>...main --oneline
# マージ済み PR 一覧（Issue番号の紐づけ用）
git log <BASE_TAG>...main --merges --oneline
# 関連 Issue/PR
gh pr list --state merged --limit 50 --json number,title,headRefName,baseRefName --search "base:main"
変更ファイルを以下の単位でグルーピングする:
各グループについて:
重要度判定基準:
| 重要度 | 基準 |
|---|---|
| Critical | レイアウト全体の大規模変更、ビルド設定変更、ページ構造変更 |
| High | 主要コンポーネントの動作変更、ユーザーに見えるUI変更、ページ追加・削除 |
| Medium | 軽微なスタイル変更、エッジケース修正、アクセシビリティ改善 |
| Low | スタイリング微調整、パフォーマンス改善、内部リファクタ |
以下に該当する変更は常に手動テスト必須:
| カテゴリ | 例 | 理由 |
|---|---|---|
| UI/レイアウト・視覚的変更 | CSS/SCSS変更、コンポーネント表示 | 視覚的確認が必要 |
| レスポンシブデザイン | ブレークポイント変更、メディアクエリ | 実際のリサイズ操作が必要 |
| ページ遷移・ナビゲーション | リンク変更、ルーティング | ブラウザでの遷移確認が必要 |
| インタラクション | メニュー開閉、スクロール、アニメーション | 操作体験の確認が必要 |
| SEO・メタデータ | OGP、サイトマップ、robots.txt | 出力HTMLの確認が必要 |
| 画像・アセット | 画像最適化、ファビコン | 視覚的確認が必要 |
| ビルド出力 | Astro設定変更、インテグレーション | ビルド結果の確認が必要 |
type, interface のみ）console.log の追加/削除サブエージェントを活用して並列分析する。 機能グループごとにサブエージェント（subagent_type: "Explore"）を起動し、各グループの変更内容を詳細に分析してチェック項目を洗い出す。
各サブエージェントには以下を指示する:
git diff <BASE_TAG>...main -- <path>）を分析オーケストレータ（メインClaude）は:
チェック項目の書き方:
(#xxx) を付与する生成したチェックリストをユーザーに提示し、以下を確認する:
承認を得てから Issue 起票に進む。
Issue 本文を構築し gh issue create で起票する。テンプレート内の <TAG>, <COMMITS>, <FILES> 等のプレースホルダは、Step 1〜4 で収集した実際の値に置き換えること。
ラベル: プロジェクトで利用可能なラベルは gh label list で確認する。
Issue フォーマット:
## リリース前動作確認
**対象変更範囲**: `<TAG>` → `main` (<COMMITS> commits, <FILES> production files changed)
### 自動検証結果
- スクリプトリント: **passed / failed**
- スタイルリント: **passed / failed**
- ビルド: **passed / failed**
---
## セクション 1: [機能名] (Critical)
> #Issue番号 — 変更の概要説明
### 1.1 [サブカテゴリ]
- [ ] 操作の説明 → 期待結果 (#関連Issue)
- [ ] 操作の説明 → 期待結果 (#関連Issue)
---
## セクション N: [機能名] (Low)
...
---
> **凡例**
>
> - ⬜ `[ ]` = 手動での動作確認が必要
> - ✅ `[x]` = 確認完了
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue 起票時の注意:
Issue 起票前に以下を実行し、結果を Issue 冒頭に記載する:
# スクリプトリント
pnpm lint:scripts
# スタイルリント
pnpm lint:styles
# ビルド
pnpm build
| ケース | 対応 |
|---|---|
| 変更ファイルが5件未満 | セクション分けせず、単一リストで簡潔に起票する |
| 変更ファイルが200件超 | 機能グループごとに git diff を分割して読み、コンテキスト超過を避ける |
| 機能が完全に削除された | 「削除された機能の要素が表示されないこと」を確認項目にする |
| 全変更が除外された | Issue 起票は不要。ユーザーに「全変更が自動テストでカバー済み」と報告する |