bobtabo · Aug 21, 2026 · Aug 12, 2026 · Aug 12, 2026 · Aug 12, 2026 · Aug 13, 2026
diff --git a/.claude/skills/backend-ci-trigger/SKILL.md b/.claude/skills/backend-ci-trigger/SKILL.md
@@ -0,0 +1,91 @@
+---
+name: backend-ci-trigger
+description: >-
+  featureブランチでバックエンドの変更をpushしたあと、対応するCIが自動実行
+  されないため手動でCIを発火・確認する際に使う。「CIを回して」「CIの結果を
+  確認して」等の指示で使う。
+allowed-tools: Bash(gh:*)
+---
+
+# backend-ci-trigger
+
+各バックエンドCI（`.github/workflows/*-ci.yml`）は次の2点により、featureブランチへの
+pushでは**自動実行されない**。
+
+1. `paths` トリガーが対応するバックエンドディレクトリのみに限定されている
+2. `branches-ignore: ['feature/issue-*']` により、`feature/issue-*` へのpush自体が
+   トリガー対象外
+
+そのため `feature/issue-N` ブランチ上でCI結果を確認したい場合は、`workflow_dispatch`
+で手動発火する。`feature/issue-*` **以外**のブランチ（develop/main に限らない）への
+pushでは、該当pathsに応じて自動実行される。
+
+`workflow_dispatch` は、対象のワークフローファイルがdefaultブランチ（`main`）に
+既に存在している場合のみ使える。new-backend-scaffold Skillで新規追加したワークフロー
+ファイルは、`main` へマージされるまで `gh workflow run` で手動発火できない
+（GitHubがdispatch可否をdefaultブランチ上の定義で判定するため）。この場合は、
+develop→main同期後に確認するか、ワークフローファイルのみ先にdevelopおよびmainへ
+反映しておく。
+
+## ワークフロー対応表
+
+| ワークフローファイル | 対象パス |
+|---|---|
+| `go-gin-ci.yml` | `backends/go-gin/**` |
+| `java-springboot-ci.yml` | `backends/java-springboot/**` |
+| `php-cakephp-ci.yml` | `backends/php-cakephp/**` |
+| `php-codeigniter-ci.yml` | `backends/php-codeigniter/**` |
+| `php-fuelphp-ci.yml` | `backends/php-fuelphp/**` |
+| `python-django-ci.yml` | `backends/python-django/**` |
+| `ruby-rails-ci.yml` | `backends/ruby-rails/**` |
+
+`gh workflow run` にはワークフロー表示名（日本語・括弧付き）ではなく、上記の
+ファイル名を使う（曖昧さがなく確実）。
+
+## 発火対象の判断
+
+変更したファイルパスから、対応するバックエンドのワークフローを特定する。
+複数バックエンドにまたがる変更（例: 共通ドキュメントやCI設定自体の変更）は、
+影響するワークフローをそれぞれ個別に発火する（一括発火するコマンドは無い）。
+
+```bash
+BASE=develop   # git-flowでこのfeatureブランチの派生元とした基準ブランチに合わせる
+git diff --name-only "$BASE"...
+```
+
+- `backends/<name>/**` に一致する変更 → 出力パスの `<name>` 部分を上表と
+  突き合わせ、対応するワークフローのみ発火する。
+- `.github/workflows/**`、`docker/**`、リポジトリ直下の設定ファイル等、
+  特定のバックエンドに閉じない変更（＝上記以外の変更）が1件でも含まれる場合は、
+  影響範囲を個別に切り分けず、上表の7ワークフロー全てを発火するフォールバックを
+  取る。
+
+## 手動発火と結果確認
+
+```bash
+WORKFLOW=go-gin-ci.yml   # 対象ワークフローファイル名（上表を参照して置き換える）
+N=34                      # このfeatureブランチに対応するIssue番号に置き換える
+
+gh workflow run "$WORKFLOW" --repo bobtabo/authorization-showcase --ref "feature/issue-$N"
+
+# 実行中/直近のrunを確認
+gh run list --repo bobtabo/authorization-showcase \
+  --workflow="$WORKFLOW" --branch="feature/issue-$N" --limit 1
+
+# 完了まで待ってログを見る（run idを直近実行結果から取得する）
+RUN_ID=$(gh run list --repo bobtabo/authorization-showcase \
+  --workflow="$WORKFLOW" --branch="feature/issue-$N" --limit 1 \
+  --json databaseId -q '.[0].databaseId')
+gh run watch --repo bobtabo/authorization-showcase "$RUN_ID"
+gh run view --repo bobtabo/authorization-showcase "$RUN_ID" --log
+```
+
+## 注意
+
+- 全バックエンドCIは同一のngrokトンネル/LocalStackを共有しており、
+  `concurrency: group: shared-authserver-tunnel, cancel-in-progress: false`
+  で直列実行される。複数ワークフローを続けて発火すると、後発のものは前段の
+  完了待ちで少し時間がかかる。
+- develop/main へのマージ前にfeatureブランチ側でCIグリーンを確認したい場合は、
+  このSkillで対象ワークフローを手動発火してから確認する（git-flow SkillでPRを
+  作成しても、featureブランチ自体のpushではCIは動かない点に注意）。
diff --git a/.claude/skills/backend-dispatch/SKILL.md b/.claude/skills/backend-dispatch/SKILL.md
@@ -0,0 +1,58 @@
+---
+name: backend-dispatch
+description: >-
+  「Goのバックエンドで◯◯を直して」のように言語名だけで指示された際に、正しい
+  backends/ 配下のディレクトリと docker/bin/docker-*.sh のラッパースクリプトに
+  振り分ける際に使う。曖昧なPHP指示（CakePHP/CodeIgniter/FuelPHPのどれか不明）の
+  ときにも使う。
+allowed-tools: Bash(docker:*), Bash(git:*)
+---
+
+# backend-dispatch
+
+このリポジトリは同一の認可サーバーAPI（JWT発行／検証）を7言語・FWで実装するショーケース。
+どのバックエンドを指しているかを機械的に確定させ、実行は必ずDockerラッパースクリプト
+経由で行う。
+
+## 対応表
+
+| 呼ばれ方の例 | ソースディレクトリ | Docker操作 | execで入るシェル |
+|---|---|---|---|
+| Go, Gin | `backends/go-gin/` | `docker/bin/docker-go.sh` | `sh` |
+| Java, Spring Boot | `backends/java-springboot/` | `docker/bin/docker-java.sh` | `bash` |
+| CakePHP, Cake | `backends/php-cakephp/` | `docker/bin/docker-php-cake.sh` | `bash` |
+| CodeIgniter, CI | `backends/php-codeigniter/` | `docker/bin/docker-php-codeigniter.sh` | `bash` |
+| FuelPHP, Fuel | `backends/php-fuelphp/` | `docker/bin/docker-php-fuel.sh` | `bash` |
+| Python, Django | `backends/python-django/` | `docker/bin/docker-python.sh` | `bash` |
+| Ruby, Rails | `backends/ruby-rails/` | `docker/bin/docker-ruby.sh` | `bash` |
+
+- 「PHPのバックエンドで」のように3フレームワークのどれか特定できない指示を受けた場合は、
+  推測で決めずに CakePHP / CodeIgniter / FuelPHP のどれかをユーザーに確認する。
+- 「全バックエンドで」「7言語すべてで」という指示は、上記7ディレクトリ全てに同じ変更を
+  展開する。一括Docker操作は `docker/bin/docker-backends.sh {up|down}` を使う
+  （docker-ops Skill参照）。
+
+## 実行方針
+
+- **ソース編集**: `backends/<dir>/` はDockerコンテナへbind mountされているため、
+  ホスト側で直接編集してよい（Edit/Writeツールで通常通り編集する）。
+- **テスト・ビルド・CLI実行**: 必ずコンテナ内で行う。ホストに言語ランタイムが
+  入っていても、ホストで直接 `go test` 等を実行しない。
+  ```bash
+  X=go   # 対応表の値に置き換える: go/java/php-cake/php-codeigniter/php-fuel/python/ruby
+  "docker/bin/docker-$X.sh" exec
+  # コンテナ内シェルに入った状態で、通常のテスト/ビルドコマンドを実行する
+  ```
+  非対話的に1コマンドだけ実行したい場合は、対応する `docker/local/app-<x>/docker-compose.yml`
+  を直接指定する（`docker exec <コンテナ名>` のようにコンテナ名を直書きしない。
+  プロジェクト名・サービス名がバックエンドごとに異なるため取り違えやすい）:
+  ```bash
+  X=go            # 対応表の値に置き換える
+  SERVICE=go      # execで指定するサービス名: go=go, java=java, php系=php, python=python, ruby=rb-rails
+  CMD="go test ./..."   # 実行したいコマンド
+
+  docker compose -p "showcase-$X" -f "docker/local/app-$X/docker-compose.yml" \
+    exec -T --user 1000 "$SERVICE" $CMD
+  ```
+  `-T` は必須（付けないとTTY割り当てを試みて、非対話環境では失敗しうる）。
+- コンテナが起動していない場合の対処は docker-ops Skillを参照。
diff --git a/.claude/skills/demo-recording/SKILL.md b/.claude/skills/demo-recording/SKILL.md
@@ -0,0 +1,47 @@
+---
+name: demo-recording
+description: >-
+  e2e/ ディレクトリで Playwright を使った動作デモGIFを録画する際に使う。
+  「デモGIFを録って」「動作を録画して」等の指示で使う。
+allowed-tools: Bash(npm:*), Bash(cd:*)
+---
+
+# demo-recording
+
+`e2e/` はE2Eテストではなく、動作デモGIF録画専用のディレクトリ（`frontend/` とは分離、
+CIには組み込まれない・手動実行のみ）。
+
+## 前提
+
+- `ffmpeg` がインストール済み（`brew install ffmpeg`）
+- `frontend/` の開発サーバーが `http://localhost:5173` で起動していること
+  （フロントの起動は別途 `npm run dev` を `frontend/` で実行しておく。このSkillの
+  対象外）
+
+## 手順
+
+Playwrightブラウザのインストールは、`package-lock.json` で解決されたバージョン
+（本リポジトリでは `playwright@1.61.1`）を使うため、必ず `npm install` の**後**に
+行う（`npm install` 前に `npx playwright install` を実行すると、ローカルに無い
+`playwright` をレジストリから取得してしまい、バージョンがずれる）。再現性を
+厳密にしたい場合は `npm install` の代わりに `npm ci` を使う。
+
+```bash
+cd e2e
+npm install
+npm exec -- playwright install chromium   # 初回のみ。ブラウザバイナリを取得
+npm run record     # playwright test --project=chromium を実行。output/*.webm を生成
+npm run to-gif      # scripts/to-gif.sh でwebm→GIF変換。docs/gif/*.gif を生成
+```
+
+## 新規デモシナリオの追加
+
+新しいシナリオを録画したい場合は `e2e/scenarios/` に `*.spec.ts` を追加する
+（既存の `e2e/scenarios/jwt-flow.spec.ts` を参考にする）。シナリオ追加後に
+上記の `npm run record` → `npm run to-gif` を実行する。
+
+## 生成物の扱い
+
+- `e2e/output/`（録画中間ファイルの `.webm`）は `.gitignore` 対象。コミットしない。
+- `docs/gif/*.gif`（変換後のGIF）はREADME等に埋め込んで使うため、リポジトリに
+  含める（コミット対象）。
diff --git a/.claude/skills/docker-ops/SKILL.md b/.claude/skills/docker-ops/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: docker-ops
+description: >-
+  docker/bin/docker-*.sh の使い方（env/up/down/exec 等）でコンテナを起動・停止・
+  操作する際、またはコンテナが起動しない等のトラブル対応をする際に使う。
+allowed-tools: Bash(docker:*), Bash(cd:*), Bash(find:*)
+---
+
+# docker-ops
+
+`docker/bin/*.sh` は各バックエンド・共通インフラのDocker操作を統一するラッパー
+スクリプト。コンテナの起動・停止・破棄（`up`/`down`/`start`/`stop`）は必ずこれらを
+経由する（`guard-bash.sh` が `docker stop` / `docker compose stop|kill|down` 等の
+直接実行をブロックし、本Skillのラッパー使用へ誘導する）。
+
+一方、起動済みコンテナに対する非対話の単発コマンド実行（`exec`）は
+`guard-bash.sh` のブロック対象外であり、`docker compose -p showcase-<x> -f
+docker/local/app-<x>/docker-compose.yml exec -T --user 1000 <service> <コマンド>`
+を直接使ってよい（`-T`必須。無いとTTY割り当てを試みて非対話環境で失敗しうる。
+backend-dispatch Skill参照）。
+
+## 前提（初回のみ）
+
+```bash
+cd docker
+find ./bin -type f -exec chmod 755 {} +
+bin/docker-common.sh env   # 証明書・.envのセットアップ
+```
+
+## 起動順序
+
+Docker ネットワーク `showcase` と nginx-proxy を作る `common` を先に起動し、
+その後で各バックエンドを起動する。順序を逆にすると起動に失敗する。
+
+```bash
+cd docker
+bin/docker-common.sh up          # 1. 共通コンテナ（nginx-proxy, showcaseネットワーク作成）
+bin/docker-backends.sh up        # 2. 全バックエンド一括起動
+# もしくは個別に:
+bin/docker-go.sh up
+bin/docker-java.sh up
+bin/docker-php-cake.sh up
+bin/docker-php-codeigniter.sh up
+bin/docker-php-fuel.sh up
+bin/docker-python.sh up
+bin/docker-ruby.sh up
+```
+
+各 `docker-<x>.sh up` は `.env` が無ければ `.env.example` から自動生成してから
+`docker compose -p showcase-<x> up -d --build --force-recreate` を実行する。
+
+## コンテナに入る／破棄する
+
+```bash
+X=go   # 対応表（backend-dispatch Skill参照）の値に置き換える
+"docker/bin/docker-$X.sh" exec   # コンテナ内シェルに入る（Goはsh、他はbash）
+"docker/bin/docker-$X.sh" down   # そのバックエンドのコンテナ・イメージ・ボリュームを破棄
+docker/bin/docker-backends.sh down   # 全バックエンド一括破棄
+```
+
+`common` の操作は `up` / `down` に加えて `start` / `stop`（コンテナ破棄せず
+起動・停止のみ）も使える:
+
+```bash
+docker/bin/docker-common.sh start
+docker/bin/docker-common.sh stop
+```
+
+## 破壊的操作への注意
+
+- `down` は対象コンテナに加えて **イメージ・ボリュームも削除**する
+  （`--rmi all --volumes`）。
+- `docker-common.sh down` はさらに `docker/local/common/data/` と
+  `docker/local/common/logs/` ディレクトリも削除する。
+- 上記のためユーザーの明示的な指示なしに `down` を実行しない。コンテナの
+  再起動だけで済む場合は `common` は `stop`→`start`、各バックエンドは
+  `up`（`--force-recreate` で再作成される）を使う。
+
+## トラブルシュート
+
+- **バックエンドコンテナが起動しない**: `common` が起動しておらず `showcase`
+  ネットワークが無い可能性が高い。`docker/bin/docker-common.sh up` を先に実行する。
+- **状態確認**: `docker ps` でコンテナ名 `showcase-<x>_<service>`
+  （例: `showcase-go_go`, `showcase-go_nginx`）が上がっているか確認する。
+- **.env が古い/壊れている**: バックエンド側の `.env` は `docker/local/app-<x>/.env`
+  にあり、削除して `docker/bin/docker-<x>.sh up` を再実行すれば
+  `.env.example` から再生成される。
+- どのバックエンドがどのディレクトリ・スクリプトに対応するかは backend-dispatch
+  Skillを参照。
diff --git a/.claude/skills/git-flow/SKILL.md b/.claude/skills/git-flow/SKILL.md
@@ -0,0 +1,92 @@
+---
+name: git-flow
+description: >-
+  対応するGitHub Issueからfeatureブランチを作成し、developへのPRを作成する際に使う。
+  「Issueブランチを作って」「#Nのブランチを切って」「PRを出して」等の指示で使う。
+  develop→mainの同期PRはこのSkillの対象外。
+allowed-tools: Bash(git:*), Bash(gh:*)
+---
+
+# git-flow
+
+このリポジトリ（bobtabo/authorization-showcase）のブランチ運用を統一する手順書。
+
+## 前提
+
+- 対応するGitHub Issue（番号 N）が既に存在すること。Issue番号を伴わないブランチ名
+  （例: `feature/xxx-yyy`）は作らない。Issueがまだ無い場合は、既存Issueの書式
+  （`[showcase] <type>: <日本語要約>`、`## 背景` → `## タスク` の構成）に合わせて
+  先にIssueを作成してから本Skillを使う。
+- 派生元ブランチは既定で `develop`。呼び出し時に別ブランチが明示された場合は
+  そちらを派生元として使う（例: hotfixを `main` から切る等、たまにある例外に対応）。
+
+## 1. featureブランチ作成
+
+```bash
+set -euo pipefail
+BASE=develop   # 明示指定があればそちらに置き換える
+N=34           # 対応するIssue番号に置き換える（実行前に書き換える。以下このSKILL.mdでは
+               # <N> を「この値に置き換える」プレースホルダーとして表記する）
+
+git checkout "$BASE"
+git pull --ff-only origin "$BASE"
+gh issue view "$N" --repo bobtabo/authorization-showcase --json title -q .title
+git checkout -b "feature/issue-$N"
+```
+
+`set -euo pipefail` により、Issueが存在せず `gh issue view` が失敗した場合は
+`git checkout -b` を実行せずに停止する。`git pull` は `--ff-only` とし、
+ローカルとリモートが分岐している場合は自動マージせず停止する。
+
+## 2. developへのPR作成
+
+- base: `develop` / head: `feature/issue-$N`（派生元を変えた場合もbaseは`develop`）
+- タイトル: `$TYPE(#$N): $SUMMARY`
+  （`TYPE`: feat/fix/docs/chore/refactor 等、conventional commit風。Issueのtypeを踏襲する）
+- 本文: Summary / Changes / Closes(またはRefs) / 署名の4点を含める。Issueの一部のみ
+  対応する場合（Issueの残タスクが残る場合）は `Closes #$N` ではなく `Refs #$N` とし、
+  Issueを自動クローズさせない。
+
+- コマンド（`N`/`TYPE`/`SUMMARY`/`CHANGES`/`LINK` に実際の値を設定してから実行する。
+  この節のブロックは手順1とは別のシェルプロセスで実行される想定のため、`N`を
+  再設定する。heredocはクォートしない `<<EOF` にして変数展開させる。
+  プレースホルダーのまま送信しない）:
+
+  ```bash
+  set -euo pipefail
+  N=34                             # 手順1で使った値と同じIssue番号
+  TYPE=feat                       # feat/fix/docs/chore/refactor 等
+  SUMMARY="日本語要約"
+  CHANGES="- 変更ファイル/内容"    # 複数行なら改行を含めて組み立てる
+  LINK="Closes #$N"                # 部分対応の場合は "Refs #$N" にする
+
+  git push -u origin "feature/issue-$N"
+  gh pr create --repo bobtabo/authorization-showcase \
+    --base develop --head "feature/issue-$N" \
+    --title "${TYPE}(#${N}): ${SUMMARY}" --body "$(cat <<EOF
+  ## Summary
+
+  Issue #$N 対応。$SUMMARY
+
+  ## Changes
+  $CHANGES
+
+  $LINK
+
+  🤖 Generated with [Claude Code](https://claude.com/claude-code)
+  EOF
+  )"
+  ```
+
+## 禁止事項
+
+- `develop` / `main` への直接push（featureブランチ経由のPRを必ず通す）
+- `develop` → `main` のマージはこのSkillでは行わない（「develop → main 同期」PRとして別途手動で作成する）
+
+## 既知の制約
+
+- 本SkillはSKILL.mdという「明示的に呼び出したときの手順書」であり、`allowed-tools` や
+  現状の `.claude/hooks/guard-bash.sh` は `develop` / `main` への直接pushを機械的には
+  ブロックしない（`guard-bash.sh` が対象とするのは `push --force` / `reset --hard` 等の
+  破壊的操作のみ）。保護ブランチへのpushを権限層で強制したい場合は、`guard-bash.sh` の
+  拡張または GitHub 側のブランチ保護ルールの設定を別Issueとして検討する。