BeerSalon

@issue_note.txt の課題No、または Evernote 共有リンク（ノート下書き）をもとに、GitHub Issueを作成する。対応種別に応じてfeature/bugfixテンプレートを使い分ける。

PRをMerge commit方式でマージし、リモート・ローカル両方のfeatureブランチを削除して司令塔ベースブランチを最新化する。マージのタイミングはユーザーが決める。

Issue起点の実装計画を作成する。Issueの内容とプロジェクトの設計ドキュメントを照合し、影響範囲・実装方針・テスト方針を含む計画を出力する。

Playwright MCPを使って、既に起動済みのlocalhost環境に対してE2E観点の動作確認を行うための運用ルール。

PRのコードレビューを実施し、レビュー結果をPRコメントとして投稿する。アーキテクチャ観点でのコードレビュー。

ブランチ・Git運用ルール。feature ブランチ作成、コミット、プッシュ、PR作成の手順。品質チェック後のGit操作フロー。

ready ラベル付き Issue を古い順に1件ずつ直列で消化する半自動ループ。各Issueを /impl の手順で実装し、品質ゲート（pr-review が Low 以下 + E2E green + CI green）を満たせば /merge 相当で自動マージする。条件を満たさないものは needs-merge / blocked で人に戻す。実装ロジック本体は /impl が持つ。

Issue起点の実装フロー。ブランチ作成→実装→テスト→品質チェック→コミット→PR作成→完了報告を一貫して実行する。事前に /plan で計画承認済みであることが前提。

PRをMerge commit方式でマージし、リモート・ローカル両方のfeatureブランチを削除して司令塔developを最新化する。マージのタイミングはユーザーが決める。

複数Issueを一括投入し、各タスクを /impl の手順でworktree並列実装する司令塔バッチ。実装ロジック本体は /impl が持つ。

Issue起点の実装計画を作成する。Issueの内容と設計ドキュメントを照合し、影響範囲・実装方針・テスト方針を含む計画を出力する。

実装完了後にユーザーの理解を確認する対話スキル。Claudeが何をやったのか・なぜそうしたのかを、ユーザー自身の言葉で説明させることで理解を定着させる。Spring Boot（Java）との対比で技術概念を翻訳する機能も持つ。/impl の完了報告後に自動発動する。

ブランチ・Git運用ルール。feature ブランチ作成、コミット、プッシュ、PR作成の手順。品質チェック後のGit操作フロー。

設計ドキュメント同期チェック。ソースコード変更時にrouting.md/wireframe.md/database.md/README.mdを更新する。

Always use when user asks to create, generate, draw, or design a diagram, flowchart, architecture diagram, ER diagram, sequence diagram, class diagram, network diagram, mockup, wireframe, or UI sketch, or mentions draw.io, drawio, drawoi, .drawio files, or diagram export to PNG/SVG/PDF.

BeerSalonプロジェクトの仕様・設計・ドメインに関する質問にbeersalon-domain-expertが回答する。

画面レイアウト系タスクのE2Eテスト後にスクリーンショットを取得し、PRにキャプチャと「なぜこのレイアウトが要件を満たしているか」の判断根拠をコメントする。

PRのレビュー指摘に対してコード修正を行い、対応内容を返信コメントで報告する。frontend-engineerエージェントによる自動修正。

pnpm run dev実行後にページが開けない問題を診断。ポート競合、Supabase接続不良、環境変数不備、node_modules不在をチェック。

ページは開けるがコンパイルが遅く画面遷移が重い問題を診断。キャッシュ、Prisma、TypeScript、依存関係をチェック。

開発環境の問題を症状に応じて適切な専門診断スキルに振り分けるか、直接診断を行う。

git statusなどgitコマンドが重い問題を診断。.gitignore、追跡ファイル、リポジトリサイズ、Git設定をチェック。

PRのコードレビューを実施し、レビュー結果をPRコメントとして投稿する。system-architectエージェントによるアーキテクチャ観点のレビュー。

Playwright MCPを使って、既に起動済みのlocalhost環境に対してE2E観点の動作確認を行うための運用ルール。

大規模機能の要件深掘り。基本確認（rules/requirements-check.md）に加え、エッジケース・バリデーション・受入条件を洗い出す。

作業完了時の品質チェックと報告義務。format → lint → Playwright検証を実行し、修正内容・理由・変更ファイル・受入条件の充足を報告する。

テストユーザーの作成・管理ルール。email-pass.txtへの記録とGit管理除外。

Pencil MCP運用ルール。デザイン生成時の.penファイル操作とファイル命名規則。

prompt_to_claude.txtの使い方。create_prompt.shでプロンプトを対話形式で作成する手順。