| name | review-feature |
| description | 機能開発完了後の総合レビュー。機能面・UI/UX・セキュリティの3観点で、ドキュメントに基づくPlaywright MCP動作確認とAPIセキュリティテストを実施する。 |
| argument-hint | [機能名 or docsパス（例: classroom, docs/classroom）] |
/review-feature - 機能レビュースキル
機能開発完了後に実施する総合レビュー。以下の3観点からレビューを行う:
- 機能面: docs に定義された仕様通りに動作するか
- UI/UX: 初心者が迷わないか、経験者に邪魔にならないか
- セキュリティ: API レベルの情報漏洩、認可チェック
Phase 0: 対象機能の特定とドキュメント確認
0a. 対象機能の特定
$ARGUMENTS から対象機能を特定する。
classroom → docs/classroom/docs/classroom → docs/classroom/- 引数なし → ユーザーに確認
0b. ドキュメントの存在確認
対象機能の docs/<feature>/ ディレクトリを確認する。
ドキュメントが存在しない場合:
-
ユーザーに報告し、まずドキュメントを作成することを提案する:
docs/<feature>/ にドキュメントが見つかりません。
レビューにはドキュメントが前提条件です。
以下の手順で進めることを提案します:
1. 機能のドキュメントを作成する（README.md, user-stories.md, ui-ux.md, architecture.md）
2. ドキュメントのみの PR を作成し、内容が期待通りかをレビューしていただく
3. PR マージ後に、あらためて /review-feature を実行する
ドキュメントの作成を開始しますか？
-
ユーザーが承認したら、コードベースを調査してドキュメントを作成する
-
ドキュメント PR を作成してマージを依頼する
-
レビューは実施しない — マージ後にあらためて /review-feature を実行してもらう
ドキュメントが存在する場合: Phase 1 へ進む。
0c. ペルソナの確認
docs/<feature>/ 内に personas（ペルソナ）の定義があるか確認する。
ペルソナが定義されていない場合:
ユーザーにインタビューする:
この機能の主なユーザーは誰ですか？ペルソナを定義してレビューの基準にします。
例（classroom の場合）:
- 先生: Google Classroom は使えるが Smalruby ははじめて
- 生徒: Smalruby は使えるがクラス機能ははじめて
各ペルソナについて以下を教えてください:
1. ロール（先生、生徒、管理者など）
2. 前提知識（何は使えて、何がはじめてか）
3. 主な利用シナリオ
インタビュー結果を docs/<feature>/ に追記し、コミットする（レビューブランチに含める）。
ペルソナが定義されている場合: そのまま使用する。
Phase 1: ユーザーインタビュー
以下の項目をユーザーに確認する。すべてを一度に聞く（1回のメッセージにまとめる）。
1a. レビュー観点の選択
どの観点でレビューしますか？（複数選択可、おすすめは「すべて」）
A. 機能面 — docs の仕様通りに動作するかを確認
B. UI/UX — ペルソナの視点で使いやすさを確認（Playwright MCP で実際に操作）
C. セキュリティ — API の認可チェック、情報漏洩テスト
選択肢: A / B / C / すべて
1b. テスト環境
テスト環境はどちらを使いますか？
a) 本番 (https://smalruby.app) — ログインが必要な場面で依頼します
b) ローカル (http://localhost:8601) — DEV_BYPASS_TOKEN で認証をスキップします
選択肢: a / b
1c. 結果の出力形式
レビュー結果をどの形式で出力しますか？（おすすめは「両方」）
a) GitHub Issue に起票する
b) Markdown ファイルとして出力する（docs/reviews/<feature>-<date>.md）
c) 両方
選択肢: a / b / c
1d. 重点的に確認したい箇所（任意）
特に重点的に確認したい箇所はありますか？（任意、なければ Enter）
例: 「提出フローが心配」「セッション切れの挙動」「新しく追加した課題配信」
Phase 2: コンテキストの読み込み
Phase 1 の回答に基づいて、必要なコンテキストファイルを読み込む。
| 選択 | 読み込むファイル |
|---|
| A (機能面) | .claude/skills/review-feature/context-functional.md |
| B (UI/UX) | .claude/skills/review-feature/context-ui-ux.md |
| C (セキュリティ) | .claude/skills/review-feature/context-security.md |
| すべて | 上記3つすべて |
各コンテキストファイルを読み込み、その指示に従ってレビューを実行する。
対象機能のドキュメントも読み込む:
docs/<feature>/README.mddocs/<feature>/user-stories.mddocs/<feature>/ui-ux.mddocs/<feature>/architecture.mddocs/<feature>/source-code.mddocs/<feature>/testing.md- その他
docs/<feature>/ 内のファイル
Phase 3: レビュー実行
選択された各観点のコンテキストファイルの指示に従い、順番にレビューを実行する。
実行順序: 機能面 → UI/UX → セキュリティ
各観点のレビューが完了したら、発見事項を蓄積する。
テスト環境の設定
本番環境 (smalruby.app) の場合:
ローカル環境 (localhost:8601) の場合:
docker compose up app が起動していることを確認（起動していなければ起動を依頼）http://localhost:8601?no_beforeunload=1 を使用- 先生ログインは
?classrole=teacher&devlogin=<DEV_BYPASS_TOKEN> でバイパス
- DEV_BYPASS_TOKEN は
infra/smalruby-classroom/.env.stg から読み取る
Phase 4: レビュー結果のまとめ
レビューレポートのテンプレート
# 機能レビュー: <機能名>
**レビュー日**: YYYY-MM-DD
**レビュー観点**: 機能面 / UI/UX / セキュリティ
**テスト環境**: 本番 (smalruby.app) / ローカル (localhost:8601)
**ペルソナ**: <ペルソナ一覧>
## サマリー
| 観点 | 発見数 | Critical | Warning | Info |
|------|--------|----------|---------|------|
| 機能面 | N | N | N | N |
| UI/UX | N | N | N | N |
| セキュリティ | N | N | N | N |
## 発見事項
### 機能面
#### [Critical/Warning/Info] <タイトル>
- **場所**: <画面名 or API エンドポイント>
- **期待**: <docs に書かれた期待動作>
- **実際**: <実際の動作>
- **スクリーンショット**: (あれば)
- **再現手順**: <手順>
### UI/UX
#### [Critical/Warning/Info] <タイトル>
- **ペルソナ**: <影響を受けるペルソナ>
- **場所**: <画面名>
- **問題**: <具体的な問題>
- **改善案**: <提案>
### セキュリティ
#### [Critical/Warning/Info] <タイトル>
- **カテゴリ**: 認可 / 情報漏洩 / 入力検証 / CORS / レート制限
- **場所**: <API エンドポイント or コード箇所>
- **問題**: <具体的な問題>
- **再現手順**: <curl コマンド等>
- **修正案**: <提案>
## 推奨アクション
1. [Critical] ...
2. [Warning] ...
3. [Info] ...
重要度の定義
| レベル | 定義 |
|---|
| Critical | リリースブロッカー。セキュリティ脆弱性、データ漏洩、主要フローが動かない |
| Warning | リリース前に対応すべき。UX の問題、仕様との不一致、エッジケース |
| Info | 改善提案。あると良い改善、ベストプラクティスからの逸脱 |
Phase 5: 結果の出力
Phase 1c の回答に基づいて出力する。
a) GitHub Issue の場合
レビューレポートを /tmp/review-body.md に書き出し、Issue を作成する:
gh issue create \
--repo smalruby/smalruby3-editor \
--title "review: <機能名> 機能レビュー (<date>)" \
--body-file /tmp/review-body.md \
--label "review"
rm /tmp/review-body.md
review ラベルが存在しない場合は先に作成する:
gh label create review --repo smalruby/smalruby3-editor --description "Feature review" --color "7057ff" 2>/dev/null || true
b) Markdown ファイルの場合
mkdir -p docs/reviews
docs/reviews/<feature>-<YYYY-MM-DD>.md にレビューレポートを書き出す。
c) 両方の場合
a) と b) の両方を実行する。
Phase 6: 最終報告
ユーザーに日本語でレビュー結果を報告する:
## レビュー完了: <機能名>
### サマリー
- Critical: N件
- Warning: N件
- Info: N件
### 主な発見事項
1. [Critical] ...
2. [Warning] ...
### 出力
- GitHub Issue: <URL>
- レビューファイル: docs/reviews/<feature>-<date>.md
Critical の発見事項がある場合は、優先的に対応することをおすすめします。
エラーハンドリング
- Playwright MCP 接続エラー: ブラウザが起動しているか確認を促す
- API 接続エラー: 環境変数やサービスの起動状態を確認する
- ドキュメント不足: Phase 0b のフローに従う
- テスト中のエラー: エラーの内容を記録し、レビュー項目として報告する（レビュー自体は続行）
