@careerchain/stdd 0.1.0

package/assets/.claude/skills/auto-implement/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: auto-implement
+description: |-
+  GitHub issue を起点として、Spec 作成→PLAN 作成→実装（STDD）→QA→コードレビュー→Figma 更新→PR 作成までを専門エージェント（Spec Writer / Implementer / QA Engineer / Code Reviewer 等）にオーケストレーションして自動実行する。
+when_to_use: |-
+  「auto implement」「自動実装」「issue から実装」「issue 番号を指定して実装」「Agent Teams で実装」「issue を元に PR まで」「#123 を実装して」など、GitHub issue を起点とした包括的な自動実装の依頼があったとき。
+allowed-tools: Bash, Read, Write, Edit, Grep, Glob, Agent
+---
+
+# issue 起点の自動実装オーケストレーション
+
+GitHub issueを受け取り、Spec作成→実装→QA→コードレビュー→PR作成までを自動で実行するオーケストレーションスキル。
+
+## 引数
+
+**形式**: `#<issue番号> [--mode <full|spec-only|impl-only|quick>]`
+
+## Step 1: 引数パース
+
+引数から以下を抽出:
+
+- **issue番号**: `#123` 形式（必須）
+- **実行モード**: `--mode` オプション（任意）
+
+issue番号が指定されていない場合はエラーメッセージを表示して終了。
+
+## Step 2: issue情報の取得
+
+GitHub MCP toolsまたは `gh issue view` を使ってissue情報を取得する。
+
+取得する情報:
+
+- タイトル
+- 本文（description）
+- ラベル
+- コメント
+
+## Step 3: 実行モード判定
+
+`--mode` が指定されている場合はそのモードを使用。未指定の場合は以下のロジックで自動判定:
+
+| 条件                                                                                        | モード      |
+| ------------------------------------------------------------------------------------------- | ----------- |
+| ラベルに `bug` を含む                                                                       | `impl-only` |
+| ラベルに `documentation` を含む、またはタイトルに「Spec」「リバースエンジニアリング」を含む | `spec-only` |
+| タイトルに「typo」「修正」を含む、またはissue本文が短い（200文字以下）                      | `quick`     |
+| 上記いずれにも該当しない                                                                    | `full`      |
+
+判定結果を表示し、**`--mode` が未指定の場合はユーザーに確認を求める**:
+
+```
+実行モード: <mode>（自動判定理由: <reason>）
+
+このモードで実行してよろしいですか？（y/n、または別のモードを指定: full / spec-only / impl-only / quick）
+```
+
+承認されるまで次のステップに進まないこと。
+
+## Step 4: ブランチ作成・Worktree準備
+
+`.stdd.config.yml` の `project.primary_branch` を統合先ブランチとして読み取る。
+
+```bash
+# <primary_branch> は .stdd.config.yml の project.primary_branch
+git fetch origin <primary_branch>
+```
+
+issueタイトルからブランチ名を生成（`<branch_prefix><kebab-case-summary>`。`branch_prefix` は `.stdd.config.yml` の `workflow.branch_prefix`、既定 `claude/`）。
+Worktree作成スクリプトを実行:
+
+```bash
+./scripts/create-worktree.sh -b claude/<branch-name> -i <instance-id>
+```
+
+devcontainerを起動:
+
+```bash
+devcontainer up --workspace-folder ../worktree-<instance-id> --override-config ../worktree-<instance-id>/.devcontainer/devcontainer.override.json
+```
+
+以降の作業はすべてworktree内のdevcontainerで実行する。
+
+## Step 4.5: issueをIn Progressに移動
+
+GitHub Projectのステータス更新の手順は [references/github-project.md](references/github-project.md) を参照。
+`project` スコープが必要。トークンにスコープがない場合はスキップしてStep 5に進む。
+
+## Step 5: フェーズ実行
+
+このスキルは **Team Lead（オーケストレーター）** として動作し、専門エージェントにタスクを依頼しながら開発フロー全体を統括する。
+
+### チーム編成
+
+```
+Team Lead（オーケストレーター）      ← このスキル自身
+ ├→ Spec Writer          : REQUIREMENTS.md + TECH_DESIGN.md 作成
+ ├→ Spec Reviewer        : Spec の品質・整合性・漏れをレビュー
+ ├→ Plan Writer          : タスク分解・実装計画（PLANドキュメント）を作成
+ ├→ Implementer          : テスト作成 → 実装（STDDフロー）
+ ├→ Test Reviewer        : テスト戦略準拠・形骸的テスト検出・テストコード品質レビュー
+ ├→ Build Error Resolver : ビルド・型エラーの段階的修正（エラー発生時に自動起動）
+ ├→ QA Engineer          : Playwright MCP動作確認・テスト実行・整合性チェック・simplify
+ ├→ Code Reviewer        : PRレビュー・コード品質・セキュリティチェック
+ ├→ Penetration Tester   : 攻撃者視点での脆弱性検証・エクスプロイト試行
+ └→ Figma Updater        : UIキャプチャ→Figmaファイル更新（Team Leadが直接実行）
+```
+
+**Team Leadの役割**:
+
+- 各フェーズで対応するエージェントに作業を依頼する
+- エージェントの成果物を受け取り、次のフェーズに引き渡す
+- 問題が発生した場合は適切なエージェントに修正を依頼し、最大3回の修正ループを管理する
+- 全フェーズの完了後にPRを作成し、ユーザーに報告する
+
+各フェーズの詳細な手順は [references/phases.md](references/phases.md) を参照。
+モードに応じて以下のフェーズを順次実行する:
+
+| Phase     | 名称                   | full | spec-only | impl-only | quick |
+| --------- | ---------------------- | ---- | --------- | --------- | ----- |
+| Phase 1   | Spec作成               | ✓    | ✓         |           |       |
+| Phase 1.5 | PLAN作成               | ✓    |           | ✓         |       |
+| Phase 2   | 実装                   | ✓    |           | ✓         | ✓     |
+| Phase 2.5 | テストレビュー         | ✓    |           | ✓         |       |
+| Phase 3   | QA                     | ✓    |           | ✓         |       |
+| Phase 4   | コードレビュー         | ✓    |           | ✓         |       |
+| Phase 4.3 | ペネトレーションテスト | ✓    |           | ✓         |       |
+| Phase 4.5 | Figma更新              | ✓    |           | ✓         |       |
+| Phase 5   | PR作成                 | ✓    | ✓         | ✓         | ✓     |
+
+## Step 6: 完了報告
+
+以下の形式で結果を報告:
+
+```
+## 実行完了
+
+- **Issue**: #<issue番号> <タイトル>
+- **モード**: <mode>
+- **ブランチ**: <branch-name>
+- **PR**: <PR URL>
+
+### フェーズ実行結果
+| フェーズ | 状態 | 備考 |
+|---------|------|------|
+| Spec作成 | OK / SKIP | |
+| Specレビュー | OK / SKIP | |
+| PLAN作成 | OK / SKIP | |
+| テスト作成 | OK / SKIP | |
+| テストレビュー | OK / SKIP | |
+| 実装 | OK / SKIP | |
+| QA | OK / SKIP | |
+| コードレビュー | OK / SKIP | |
+| ペネトレーションテスト | OK / SKIP | |
+| Figma更新 | OK / SKIP | |
+| PR作成 | OK | |
+```
+
+## エラーハンドリング
+
+- 各フェーズで3回の修正ループを超えた場合、そのフェーズで停止し、現状をコミット・pushしてdraft PRを作成する
+- PR descriptionに未解決の問題を記載し、手動対応を依頼する
+
+## 注意事項
+
+- Agent Teamsの実験的機能を使用（`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`）
+- コスト管理のため、各Teammateは該当フェーズでのみ起動する
+- Worktreeベースの開発フローに従う
+- CLAUDE.mdのすべてのルールを遵守する

package/assets/.claude/skills/auto-implement/references/github-project.md

@@ -0,0 +1,54 @@
+# GitHub Projectステータス更新
+
+`auto-implement` skill のStep 4.5 / Phase 5 から参照される、GitHub Projectのステータスを変更する手順。
+
+## 1. issueに対応するProject Item IDを取得
+
+```bash
+gh api graphql -f query='
+mutation {
+  addProjectV2ItemById(input: {
+    projectId: "PVT_kwDODMaq2s4BOnqv"
+    contentId: "<ISSUE_NODE_ID>"
+  }) {
+    item { id }
+  }
+}'
+```
+
+ISSUE_NODE_IDは以下で取得:
+
+```bash
+gh issue view <番号> --json id -q '.id'
+```
+
+既にProjectに追加済みの場合も同じmutationで既存Item IDが返る。
+
+## 2. ステータスを更新
+
+```bash
+gh api graphql -f query='
+mutation {
+  updateProjectV2ItemFieldValue(input: {
+    projectId: "PVT_kwDODMaq2s4BOnqv"
+    itemId: "<ITEM_ID>"
+    fieldId: "PVTSSF_lADODMaq2s4BOnqvzg9RK3M"
+    value: { singleSelectOptionId: "<OPTION_ID>" }
+  }) {
+    projectV2Item { id }
+  }
+}'
+```
+
+### Option IDマッピング
+
+| ステータス  | OPTION_ID  |
+| ----------- | ---------- |
+| In progress | `47fc9ee4` |
+| In review   | `df73e18b` |
+
+## 注意
+
+- `project` スコープが必要
+- スコープがない場合はステータス更新をスキップしてフローを継続する
+- 失敗してもPR作成や実装フローはブロックしない

package/assets/.claude/skills/auto-implement/references/phases.md

@@ -0,0 +1,244 @@
+# Auto Implement - Phase詳細
+
+各フェーズの詳細な手順。SKILL.mdから参照される。
+
+## Reviewer エージェント運用の前提（必読）
+
+`spec-reviewer` / `test-reviewer` / `code-reviewer` は **独立した Evaluator** として懐疑的にチューニングされている。Team Lead は以下を順守すること:
+
+- **Reviewer の判定は原則そのまま受け入れる**: NEEDS CHANGES / ⚠️ 要修正 / ❌ Blocked を「厳しすぎる」と判断して無視しない。各 Reviewer は Hard Threshold を1項目でも下回ったら必ず NEEDS CHANGES 以下を出すよう設計されている。
+- **差し戻し時は Reviewer 出力をそのまま渡す**: Reviewer 出力末尾の「Generator への差し戻し指示」セクションを、対象 Generator（spec-writer / implementer）にそのまま引き渡す。Team Lead が要約・再解釈しない。
+- **再レビューは差分のみではなく全体を見させる**: 修正後の Spec/テスト/コード全体を Reviewer に渡し、修正により別の Hard Threshold を割っていないか確認させる。
+- **3回ループ超過時**: 後述の各 Phase のループ上限（最大3回）を超えた場合、現状をコミット・push して draft PR を作成する。PR description には **どの Reviewer がどの Hard Threshold で停止させたか** を明記する。
+
+## Phase 1: Spec作成（`full`, `spec-only`のみ）
+
+**Spec Writerに依頼**して、issueの情報をもとにSpecドキュメントを作成する。
+
+1. `docs/` 配下に該当機能のディレクトリを作成（存在しない場合）
+2. `REQUIREMENTS.md` を作成:
+   - ビジネス要件の整理
+   - ユーザージャーニーの定義
+   - 受入基準の明確化
+3. ワイヤーフレーム（WF）を生成（UI を持つ機能の場合）:
+   - `generating-wireframes` スキルに従い `docs/<app>/<feature-path>/wireframes/` に HTML WF を生成
+   - REQUIREMENTS.md「3. UI/UX デザイン」から `./wireframes/index.html` にリンク
+   - UI を持たない機能（バッチ・API のみ等）はスキップ
+4. `TECH_DESIGN.md` を作成:
+   - 技術設計方針
+   - ファイル構成
+   - テスト戦略（テストケース一覧）
+5. 必要に応じて `SCREEN_ITEMS_DEFINITION.md` を作成
+
+作成したSpecをコミット。
+
+**Spec Reviewerに依頼**して、作成されたSpecをレビューする。
+
+チェック項目:
+
+- 要件の網羅性（issueの要求がすべてカバーされているか）
+- 技術設計の実現可能性
+- テスト戦略の十分性
+- 既存実装との整合性
+
+### 判定と差し戻しループ
+
+Spec Reviewer の **Hard Threshold（SSOT 違反 0件）** を1件でも下回った場合は必ず ⚠️ 要修正 となる。
+
+- **⚠️ 要修正**: Spec Reviewer 出力末尾の「Generator への差し戻し指示」をそのまま spec-writer に渡して修正させ、再度 Spec Reviewer に依頼する。**最大3回**ループ。
+- **✅ 承認**: 次の Phase に進む。
+- **3回ループ後も未解消**: 現状をコミットして次の Phase に進むが、未解消の指摘は PR description に明記する。
+
+HIGH/MEDIUM の指摘がある場合は Hard Threshold とは別に判断する。Team Lead は HIGH が複数残っていれば実質的に差し戻す方向で扱う。
+
+## Phase 1.5: PLANドキュメント作成（`full`, `impl-only`）
+
+**Plan Writerに依頼**して、Specドキュメントに基づきPLANドキュメントを作成する。
+
+1. REQUIREMENTS.mdのUser JourneyとPriorityを確認
+2. TECH_DESIGN.mdのTest Strategyに基づきタスクを分解
+3. テスト→実装の順序でタスクリストを作成
+4. ファイル構成（新規/既存修正/既存維持）を明記
+5. PLANドキュメントをコミット
+
+配置先: `docs/<app>/<feature-path>/plans/[yyyy-mm-dd].md`
+
+## Phase 2: 実装（`full`, `impl-only`, `quick`）
+
+**Implementerに依頼**して、PLANドキュメント（存在する場合）に従いSTDDフローで実装する。
+
+1. **テスト作成**（`quick`モードではスキップ可）:
+   - PLANドキュメントのタスクリストに従いテストを作成（Unit → Integration → E2E）
+   - テストが失敗すること（Red状態）を確認
+   - テストをコミット
+
+   **`quick`モード以外では、テストをコミットした時点で一旦Phase 2の作業を中断し、Phase 2.5（テストレビュー）に進む**。Phase 2.5で承認されてから次の「実装」ステップに戻る。
+
+2. **実装**:
+   - PLANドキュメントのタスクリストに従い実装
+   - テストがパスすること（Green状態）を確認
+   - 実装をコミット
+
+3. **型チェック**: `.stdd.config.yml` の `commands.typecheck` を実行する。
+
+   ```bash
+   # 例（実際の値は .stdd.config.yml に従う）
+   <commands.typecheck>
+   ```
+
+4. **ビルドエラー解決**（型チェック/ビルドでエラーが発生した場合）:
+   **Build Error Resolverに依頼**して、ビルド・型エラーを段階的に修正する。
+   - エラーを1つずつ修正し、修正ごとに型チェックを再実行
+   - 修正が新たなエラーを生まないことを確認
+   - 最大3回の修正ループ後もエラーが残る場合はImplementerに差し戻し
+
+## Phase 2.5: テストレビュー（`full`, `impl-only`のみ）
+
+**Phase 2のステップ1（テスト作成）が完了し、テストがコミットされた直後、ステップ2（実装）を開始する前にこのPhaseを実行する。** 実装前にテスト自体の妥当性を検証することで、誤ったテストに基づく無駄な実装を防ぐ。
+
+### スキップ条件
+
+- `quick`モード（テスト作成自体をスキップしているため）
+- PLANドキュメントが存在しない（`impl-only` でPLANを飛ばしたケース等）かつテストコード変更がない場合
+
+### 実行手順
+
+**Test Reviewerに依頼**して、作成されたテストをレビューする。
+
+レビュー観点:
+
+1. **Spec準拠**: TECH_DESIGN.mdのテスト戦略（ジャーニー別テストレベル分類・テスト総数・内訳）に作成テストが則っているか
+2. **形骸的テストの検出**: トートロジー、モック戻り値のassert、内容を検証しないアサーション等、意味のないテストがないか
+   - ただしE2EテストでUI要素（role, aria-label, data-testid, 可視テキスト等）に依拠した検証は許容
+3. **一般的なテスト品質**: AAA構造、独立性、命名、Flaky耐性、アサーションの具体性
+
+### 判定結果の扱い
+
+Test Reviewer の **Hard Threshold**（HIGH 0件 / MEDIUM ≤2件 / 形骸的テスト 0件 / TECH_DESIGN.md整合 / P0 E2E完全カバー / 受入基準テスト網羅）を1項目でも下回った場合は必ず NEEDS CHANGES 以下となる。
+
+- **PASS**: Phase 2のステップ2（実装）に戻って作業を継続。
+- **NEEDS CHANGES**: Test Reviewer 出力末尾の「Generator への差し戻し指示」をそのまま implementer に渡してテストを修正させる → テストを再コミット → Test Reviewer に再レビュー依頼。**最大3回**ループ。
+- **CRITICAL ISSUES**: Spec の受入基準がまったく検証されていない等の重大な問題。implementer に差し戻し、場合によっては Phase 1 の spec-writer にもテスト戦略の見直しを依頼する。
+
+3回の修正ループ後も問題が解消されない場合は、現状のテストをコミットして Phase 2 のステップ2に進み、未解消の Hard Threshold 違反項目を PR description に明記する。
+
+## Phase 3: QA（`full`, `impl-only`のみ）
+
+**QA Engineerに依頼**して、品質を確認する。
+
+1. **ユニットテスト実行**: `.stdd.config.yml` の `apps[]` を読み、各アプリについて `apps[].path` ディレクトリで `commands.test` を実行する（apps[] の数だけ繰り返す）。
+
+   ```bash
+   # 例（実際の値は .stdd.config.yml に従う）
+   cd <apps[].path> && <commands.test>
+   ```
+
+2. **E2Eテスト実行**（関連テストがある場合）:
+
+   ```bash
+   cd e2e && npm run test
+   ```
+
+3. **整合性チェック**: `verifying-consistency` skill と同等のチェックを実施
+
+4. **コード品質チェック**: `simplify` skill と同等のレビューを実施
+
+問題がある場合:
+
+- **ビルド・型エラー**: Build Error Resolverに修正を依頼
+- **テスト失敗・ロジックの問題**: Implementerに修正を依頼
+- 修正→QAを最大3回繰り返す
+
+## Phase 4: コードレビュー（`full`, `impl-only`のみ）
+
+**Code Reviewerに依頼**して、コード品質をレビューする。
+
+チェック項目:
+
+- `CLAUDE.md` のコーディング規約準拠（存在する場合のみ。snake_case禁止、!演算子禁止、asキャスト禁止等）
+- セキュリティ（OWASP Top 10）
+- パフォーマンス
+- レスポンシブ対応
+- 適切なエラーハンドリング
+
+### 判定と差し戻しループ
+
+Code Reviewer の **Hard Threshold**（Critical 0件 / High 0件 / Medium ≤2件 / OWASP Critical/High 0件 / `CLAUDE.md` 絶対ルール違反 0件（存在する場合のみ評価） / `.claude/docs/coding-conventions.md` 全項目準拠（存在する場合のみ評価））を1項目でも下回った場合は必ず NEEDS CHANGES 以下となる。
+
+- **✅ PASS**: 次の Phase に進む。
+- **⚠️ NEEDS CHANGES**: Code Reviewer 出力末尾の「Generator への差し戻し指示」をそのまま implementer に渡して修正させ、再度 Code Reviewer に依頼。**最大3回**ループ。
+- **❌ Blocked**: セキュリティ脆弱性が実証可能 or アーキテクチャ崩壊レベル。即座に implementer に最優先で修正を依頼。3回ループで解消しなければ draft PR を作成し、PR description で **Blocked 理由** を明示する。
+
+3回の修正ループ後も問題が解消されない場合は、現状をコミットして次の Phase に進むが、未解消の Hard Threshold 違反項目を PR description に明記する。
+
+## Phase 4.3: ペネトレーションテスト（`full`, `impl-only`のみ）
+
+**このPhaseはPhase 4（コードレビュー）の後に実行する。**
+
+### スキップ条件
+
+変更ファイルがすべて以下に該当する場合はスキップしてPhase 4.5に進む:
+
+- `.md` / `.txt` 等のドキュメントファイルのみ
+- `.claude/` 配下の設定・エージェント定義のみ
+- CSS/Tailwindクラスのスタイル変更のみ（Server Actions/APIルート/マイグレーションに影響なし）
+
+### 実行手順
+
+**Penetration Testerに依頼**して、攻撃者視点で変更箇所の脆弱性を検証する。
+
+1. **偵察**: 変更されたファイルから攻撃対象領域をマッピング
+2. **攻撃シナリオ設計**: 認証バイパス、認可エスカレーション、RLSバイパス、インジェクション、IDOR、ビジネスロジック悪用の観点で攻撃シナリオを設計
+3. **エクスプロイト実行**: 稼働中のローカル環境に対して実際に攻撃ペイロードを送信
+4. **結果報告**: 実証された脆弱性（PoC付き）と潜在的リスクを報告
+
+### 判定基準
+
+- **SECURE**: 次のPhaseに進む
+- **AT RISK**: Medium以上の潜在リスクをImplementerに修正依頼し、修正→再テストを最大3回繰り返す
+- **COMPROMISED**: 脆弱性が実証された。Implementerに即座に修正を依頼し、修正→再テストを最大3回繰り返す
+
+### Phase 4.5との関係
+
+Phase 4.3の判定がSECUREまたはAT RISK（修正済み）の場合のみPhase 4.5を実行する。COMPROMISEDが3回の修正ループ後も解消されない場合はPhase 4.5をスキップし、draft PRを作成する。
+
+## Phase 4.5: Figmaデザイン更新（`full`, `impl-only`のみ）
+
+UI変更を伴う実装の場合、対象のSpecドキュメント（REQUIREMENTS.md）に「Figmaデザイン」セクションが存在するかを確認し、存在する場合はFigmaファイルを更新する。
+
+**このPhaseはPhase 4.3（ペネトレーションテスト）完了後に実行する。**
+
+### 実行条件の判定
+
+1. 対象のREQUIREMENTS.mdを読み、`### Figmaデザイン` セクションの有無を確認
+2. セクションが存在し、FigmaファイルURLが記載されている場合 → **Figma更新を実行**
+3. セクションが存在しない場合 → **スキップ**（Phase 5に進む）
+
+### 更新手順
+
+1. **UIキャプチャ**: Playwright MCPを使用して、変更が反映された画面のスクリーンショットを取得
+   - REQUIREMENTS.mdの「Figmaデザイン」セクションに記載された各画面状態をキャプチャ
+   - 変更の影響がある画面のみ対象（全画面を再キャプチャする必要はない）
+   - ログインが必要な場合はCLAUDE.mdのテストユーザー情報を使用
+2. **Figmaファイル更新**: Figma MCPを使用して、キャプチャした画像でFigmaファイルの該当ノードを更新
+   - REQUIREMENTS.mdに記載されたnode-idに対応するノードを更新
+   - 新しい画面状態が追加された場合は、新しいノードとして追加
+3. **REQUIREMENTS.mdのリンク更新**: 新しいノードを追加した場合、Figmaデザインセクションにリンクを追記してコミット
+
+### エラー時の扱い
+
+- Figma MCPが利用できない場合やエラーが発生した場合は**スキップ**してPhase 5に進む
+- 完了報告の備考欄にスキップ理由を記載する
+- Figma更新の失敗はPR作成をブロックしない
+
+## Phase 5: PR作成（全モード）
+
+すべてのコミットをpushし、`create-pr` skill と同等のフローでPRを作成する。
+
+PRのdescriptionには以下を含める:
+
+- 対応issue番号（`Closes #<issue番号>`）
+- 実行モード
+- 各フェーズの実行結果サマリ
+
+PR作成後、GitHub Projectのステータスを「In review」に変更する（[references/github-project.md](github-project.md) の手順に従い、option IDに `"df73e18b"` を指定）。

package/assets/.claude/skills/create-pr/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: create-pr
+description: |-
+  現在のブランチから主ブランチ（`.stdd.config.yml` の `project.primary_branch`）への Pull Request を作成する。差分情報の収集→変更内容の分析→PR description の自動生成→`gh pr create` 実行までを一括で行う。
+when_to_use: |-
+  「PR作成」「プルリクエスト」「pull request」「PR出して」「create PR」「マージリクエスト」など、ブランチを主ブランチにマージするための PR 作成依頼があったとき。
+allowed-tools: Bash, Read, Grep
+---
+
+# Pull Request 作成
+
+現在のブランチから主ブランチ（`.stdd.config.yml` の `project.primary_branch`）へのPRを作成する。差分を分析し、適切なtitle/descriptionを自動生成する。
+
+以降のコマンド例では `<primary_branch>` を `.stdd.config.yml` の `project.primary_branch` の値に置き換えて実行する。
+
+## 1. 差分情報の収集
+
+```bash
+# <primary_branch> は .stdd.config.yml の project.primary_branch
+git fetch origin <primary_branch>
+```
+
+以下を並列で実行:
+
+```bash
+git log --oneline origin/<primary_branch>...HEAD
+git diff origin/<primary_branch>...HEAD --name-only
+git diff origin/<primary_branch>...HEAD --stat
+git branch --show-current
+```
+
+必要に応じて変更内容の詳細も確認:
+
+```bash
+git diff origin/<primary_branch>...HEAD
+```
+
+## 2. 変更内容の分析
+
+1. **変更の種類を特定**: feat / fix / refactor / docs / test / style / perf / chore
+2. **影響範囲を特定**: `.stdd.config.yml` の各 `apps[].id` / supabase / e2e / docs（apps[] を読み、変更があったアプリを列挙する）
+3. **主要な変更点を抽出**: 新規ファイル、削除ファイル、大幅変更ファイル
+
+## 3. Issue情報の確認
+
+引数やコミットメッセージからissue番号（`#123`形式）を検出した場合:
+
+- PR descriptionの末尾に `Closes #123` を追記してissueを自動クローズする
+- 複数ある場合は `Closes #123, Closes #456` のように列挙する
+
+## 4. PRの作成
+
+`gh pr create` を使ってPRを作成する。
+
+### タイトル
+
+- 70文字以内
+- 変更の種類をprefixに付ける（例: `feat: ユーザー一覧のフィルター機能を追加`）
+
+### Description テンプレート
+
+```markdown
+## 概要
+
+[変更の目的・背景を1-2文で説明]
+
+## 変更内容
+
+- [変更点1]
+- [変更点2]
+- [変更点3]
+
+## 影響範囲
+
+- [ ] <apps[].id>   <!-- .stdd.config.yml の apps[] を読み、apps[] の数だけ列挙する -->
+- [ ] supabase
+- [ ] e2e
+- [ ] docs
+
+## 確認手順
+
+1. [確認手順1]
+2. [確認手順2]
+
+## 備考
+
+[レビュアーへの補足事項があれば記載。なければセクションごと削除]
+
+Closes #[issue番号]
+```
+
+### 作成コマンド
+
+bodyは一時ファイル経由で渡す（ヒアドキュメントは避ける）:
+
+```bash
+# <primary_branch> は .stdd.config.yml の project.primary_branch
+gh pr create --base <primary_branch> --title "タイトル" --body-file /tmp/pr-body.md
+```
+
+## 5. 完了
+
+作成したPRのURLを表示する。
+
+## 注意事項
+
+- 「何が変わったか」「なぜ変わったか」を日本語で端的に記述する
+- 技術的な詳細より変更の目的を重視する
+- 影響範囲のチェックボックスは該当するもののみチェックを入れる
+- 確認手順には実際にレビュアーが確認すべき操作を具体的に記載する
+- 機密情報（APIキー、パスワードなど）が含まれていないか確認する
+- リモートにpushされていない場合は先にpushする