Menu
画面レイアウト系タスクのE2Eテスト後にスクリーンショットを取得し、PRにキャプチャと「なぜこのレイアウトが要件を満たしているか」の判断根拠をコメントする。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | layout-review |
| description | 画面レイアウト系タスクのE2Eテスト後にスクリーンショットを取得し、PRにキャプチャと「なぜこのレイアウトが要件を満たしているか」の判断根拠をコメントする。 |
| when_to_use | 画面レイアウト系タスクの実装完了後、E2Eテスト実施時に自動的に実行する。「レイアウトレビュー」「layout-review」「キャプチャ貼って」などの発言時にも使用。 |
| context | fork |
| agent | frontend-engineer |
引数: $ARGUMENTS（PR番号。例: 123）
画面レイアウト系タスクでは、レイアウトの正しさは感性的な判断が伴うため、第三者（レビュワー・ユーザー）が「なぜこのレイアウトでOKと判断したのか」を検証できるようにする。
E2Eテスト実施時にスクリーンショットを取得し、PRコメントとしてキャプチャ画像と判断根拠を投稿する。
gh pr view $ARGUMENTS
gh pr diff $ARGUMENTS
以下の観点でスクリーンショット取得計画を策定する:
Playwright MCPを使って以下を実行する:
スクリーンショットは Playwright MCP の browser_take_screenshot で取得する。
取得したスクリーンショットを以下のディレクトリに保存する:
docs/screenshots/pr-{PR番号}/
├── mobile-{ページ名}-{状態}.png
└── desktop-{ページ名}-{状態}.png
mkdir -p docs/screenshots/pr-$ARGUMENTS
Playwright MCPから取得したbase64画像データをファイルに保存する。
wireframe.md の仕様と実際のスクリーンショットを照合し、以下の観点で判断根拠を言語化する:
スクリーンショットをコミット・プッシュした後、GitHub raw URLを使ってPRコメントを投稿する。
# スクリーンショットをステージング・コミット・プッシュ
git add docs/screenshots/pr-$ARGUMENTS/
git commit -m "docs: PR#$ARGUMENTS レイアウトレビュー用スクリーンショットを追加"
git push
# リポジトリ情報を取得
REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
BRANCH=$(git branch --show-current)
# PRコメントを投稿
gh pr comment $ARGUMENTS --body "$(cat <<'EOF'
## レイアウトレビュー
### スクリーンショット
#### モバイル表示（375px）
#### PC表示（1280px）
### レイアウト判断根拠
| 観点 | 判定 | 根拠 |
|------|------|------|
| 構造的一致 | OK/NG | wireframe.md の仕様と照合した結果の説明 |
| レスポンシブ対応 | OK/NG | モバイルファースト設計の準拠状況 |
| 視覚的階層 | OK/NG | 見出し・本文・ボタンの優先度が明確か |
| 間隔とアラインメント | OK/NG | 余白の一貫性、要素の配置 |
| 操作性 | OK/NG | タップターゲットのサイズ、操作しやすさ |
| アクセシビリティ | OK/NG | コントラスト、フォントサイズ、セマンティックHTML |
### 総合判定
{このレイアウトが要件を満たしていると判断した理由の総括}
### 参照した仕様
- wireframe.md: {該当セクション名}
- routing.md: {該当ページのパス}
---
This layout review was generated by Claude Code (frontend-engineer agent)
EOF
)"
注意: 上記はテンプレートであり、実際のコメントでは各項目を具体的な内容に置き換えること。
@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操作フロー。