---
name: beacon-review-uc
description: プロダクト全体UXレビューにおいて、1つのユースケースを対話駆動で精査する。ペルソナ・フロー・ギャップを順に詰め、findings を子タスクとして起票する。/beacon-review から呼ばれる。
version: 0.1.0
triggers:
  - /beacon-review-uc
  - UC を精査したい
  - 次のユースケース見たい
---

# Beacon Review - UC Review

> 1つのユースケースを対話駆動で精査し、findings をタスク化する。

## 文章の書き方 (Beacon 全体の哲学)

Beacon に書き込む全ての文章 (task / マイルストーン / Operation / コミット / PR / レビュー / ドキュメント / ノート / セッションログ / リリース / デプロイ) は、**非開発者を含む読み手** が読めるように書く。これは Skill ごとの方針ではなく Beacon プロジェクト全体の哲学。

### 守ること

1. **読み手目線 1 行から始める**: 「何が嬉しいか」「何が困るか」をユーザー体験の言葉で。技術用語ではなく価値で書く
2. **横文字 3 段階**:
   - そのまま OK: 固有名詞 (`Firestore` / `pipx` / `MCP` / `Tauri` / `WebSocket`)
   - 初出時に日本語注: 技術概念 (`allowlist (= 許可リスト)` / `opt-in (= 個別許可)` / `subcollection (= 子コレクション)`)
   - 日本語化が望ましい: 一般概念 (configure → 設定 / receiver → 受信側 / audit → 監査 / hit → 一致 / install → 設置 / merge → 取り込み / deploy → 配置)
3. **ID 参照には文脈**: `e-XXXX` / `UC?` / `ms-XX` は初出に必ず『何の話か』1 行添える。例 ✗「e-1140 の AC のうち」→ ✓「e-1140 (自動応答の受信側挙動を hook で扱う) の受入条件のうち」
4. **尻切れトンボ禁止**: 主語と述語を省略しない、論理関係を明示

### Self-review (生成直後に必ず)

文章を書いた直後、自分で読み返して以下を自問:
- (a) 読み手 (非開発者を含む) は 1 度読んで意味が取れるか?
- (b) 一般概念の横文字 (configure / receiver / audit / hit / install / merge / deploy 等) が残ってないか?
- (c) ID 参照に『何の話か』1 行添えたか?
- 違反していたら書き直し。enforce ではないが必須の self-check。

### 詳細

詳しい原則と例 (病理の typology / 例外ケース / 良い例・悪い例) は CORE doc `entry-writing-principle` (doc_id `F3ZkqT0pKS6JpR8dn70n`) 参照。ただし本 Skill では上記 4 項目を **常に top of mind** で適用する (CORE 参照は補足、principal は本文埋め込み)。

---

## 前提条件

- レビュー対象MSが existing で active
- 未完了の UC レビュータスクが少なくとも1つある

## 方法論の参照（必読）

```
Read("~/.claude/skills/beacon-review/methodology.md")
```

methodology は UC レビューの具体的な作法を定義する。本Skillはそのフローを実行するだけ。

## Step 1: 対象UCの選択

```bash
beacon task list --ms <レビューMS-id> --json
```

未完了の UC レビュータスクから 1 つを選ぶ。複数あればユーザーに確認、1つしかなければ自動選択。

ユーザーへの提示:
```
これから UCn "<title>" を精査します。よろしいですか？
```

## Step 2: ペルソナの定義

UCに該当するペルソナをユーザーと一緒に明確化する。

```
このUCのペルソナを定義しましょう。

- 誰が？（職種・スキルレベル・属性）
- どんな状況で？
- 何を期待して？

例があれば挙げてください。なければ私が提案します。
```

ユーザーとの対話で確定（推測でも良いが、ユーザー承認は取る）。

## Step 3: フロー追跡

ペルソナがこの UC をどう実行するか、ステップごとに追跡する。

```
このUCで、ユーザーは具体的にどんな操作をしますか？
- ターミナル操作？ Claude Code内？ Web UI?
- どのディレクトリで？
- 各ステップで何が起きる？

実装/ドキュメントを見ながら一緒にトレースしましょう。
```

並列でコードや既存Skill ファイルを Read し、現状の動作を確認する。

## Step 4: ギャップ発見

methodology の「ギャップ発見チェックリスト」を順に確認:

1. **ターミナル戻り**: ユーザーをターミナルに戻していないか？（CORE doc ux-principle-no-terminal）
2. **質問数**: 不要な質問・確認が多くないか？
3. **デフォルト**: 推定で進められる箇所が手動になってないか？
4. **専門用語**: Beacon独自用語が説明なく出てないか？（一般用語OK）
5. **並列表示**: Web UI/Tauri との連携が成立しているか？
6. **cwd 対応**: Skillが正しい cwd で動作するか？
7. **データ整合性**: 同時書き込み・stale state リスクは？
8. **AI提案**: 「次にすべき」を AI が適切に提案する設計か？
9. **エラーリカバリ**: 失敗時の復帰経路は？
10. **share/引継ぎ**: 別マシン・別ユーザーへの伝達経路は？

各観点でユーザーと議論し、発見をリストアップ。

## Step 5: findings をタスク化

発見したギャップを1件ずつタスクとして起票:

```bash
beacon task add "UCn-X<番号>: <一行説明>" -m <レビューMS-id> \
  --priority <high/middle/low> \
  --why "<なぜ問題か、ペルソナへの影響>" \
  --ac "<どうなれば解消されたか>"
```

各 finding は **後から実装する人が読んで意図がわかる解像度**で書く。

## Step 6: UC タスクを done に

このUCのレビューが完了した:

```bash
beacon task done <UCタスク-id> --reason "Findings X件を起票完了"
```

## Step 7: 次への案内

```
UCn のレビュー完了。X件のfindings を起票しました。

次のステップ:
  - 次の未完了UCあり → /beacon-review-uc を再実行
  - 全UC完了 → /beacon-review-meta へ進む
  - 一旦休む → セッション継続OK（状態は保存済み）
```

## 制約

- methodology に従う（ペルソナ → フロー → ギャップ の順序を崩さない）
- ユーザーとの対話を必ず行う（AI が一方的に「これがギャップ」と断定しない）
- findings は actionable な粒度で（曖昧すぎず、細かすぎず）
- このUCで発見したテーマが他UCにも波及しそうな場合はメタ的に記録（後でメタレビューで活用）
