Ywc Product Review

---
name: ywc-product-review
version: 1.0.0
description: (ywc) Use when the user wants a business/service perspective review of a project (user value, UX, growth, risk, market). Triggers: "product review", "service feedback", "비즈니스 관점 리뷰", "서비스 개선 포인트", "what should we improve", "プロダクトレビュー", "サービス改善", "ywc-product-review". Do not use for code-level review (use ywc-impl-review), security review (use ywc-security-audit), or UI/UX implementation review (use ywc-ui-ux-review).
category: review
phase: quality
requires: []
advisor_budget: 2
---

# Product Review

**Announce at start:** "I'm using the ywc-product-review skill to evaluate the project from 5 business/service perspectives."

Analyze a project from 5 business and service perspectives to generate a prioritized improvement report.

## Rationalization Defense

When tempted to skip a step, check this table first:

| Excuse | Reality |
|---|---|
| "User Value perspective is obvious, skip it" | All 5 perspectives must be addressed. Missing one creates a blind spot in the prioritized report. |
| "Feature recommendations should match what the user already wants" | Honest review means surfacing tradeoffs the user did not ask about. Soften tone, never soften findings. |
| "I'll mix multiple perspectives in one finding to save space" | Tag each finding with exactly one primary perspective. Multi-tag findings become impossible to triage. |
| "Priority is roughly High, do not specify P0/P1/P2" | Always emit explicit priority. Without it, the report becomes a wishlist instead of a plan. |
| "Risks are speculative, drop them from the report" | Risk is a perspective. Speculative risks are still findings — mark `unverified`, do not drop. |
| "I have no live access, infer growth metrics from code" | If a perspective cannot be assessed (no live data), state the gap. Do not fabricate. |
| "Running 5 perspectives sequentially is fine" | Phase 1 fan-out reduces total latency; each Sonnet subagent sees only one perspective's checklist, lowering per-call context and improving analysis depth. |

**Violating the letter of these rules is violating the spirit.** A product review with cherry-picked perspectives misses the most expensive problems.

## Perspectives

| Tag | Perspective | Reference |
|---|---|---|
| `[User Value]` | Job-to-be-Done, value proposition, unmet needs | `references/user-value.md` |
| `[UX Flow]` | Onboarding, drop-off points, core user journey | `references/ux-flow.md` |
| `[Growth]` | Retention, viral loops, activation, engagement | `references/growth.md` |
| `[Risk]` | User pain points, churn drivers, unsolved problems | `references/risk.md` |
| `[Market]` | Feature prioritization, market trends, competitive gaps | `references/market-timing.md` |

## Arguments

| Parameter | Format | Example | Description |
|-----------|--------|---------|-------------|
| `--format` | `--format markdown\|html` | `--format html` | Output format. Default `markdown`. With `html`, writes a self-contained HTML report to `claudedocs/`. See [html-output.md](../references/html-output.md) |

## Workflow

### Step 1: Gather Context

Read the following in order:
1. `README.md` (or equivalent top-level docs) — understand what the service does and who it targets
2. Key specification or design documents if referenced
3. Directory structure — identify key feature areas from folder/file names
4. Core entrypoint files — understand main flows and features implemented
5. `docs/ubiquitous-language.md` (if it exists) — domain vocabulary that names the key entities, user roles, and business actions; this sharpens the User Value and UX Flow perspectives

Focus on: what the service **does**, who it serves, and what the main user flows are.

### Step 2: Phase 1 — Parallel Perspective Review

Use the Task tool to spawn 5 Sonnet subagents in parallel — one per perspective. Pass each subagent a brief context summary (service name, target user, main flows) and the corresponding reference file to read:

| Subagent | Model | Reference |
|---|---|---|
| User Value | sonnet | `references/user-value.md` |
| UX Flow | sonnet | `references/ux-flow.md` |
| Growth | sonnet | `references/growth.md` |
| Risk | sonnet | `references/risk.md` |
| Market | sonnet | `references/market-timing.md` |

Each subagent classifies its findings:
- **High**: Directly blocks or degrades core user value, causes churn, or represents a significant missed opportunity
- **Medium**: Meaningfully improves experience, growth, or differentiation with moderate effort
- **Low**: Incremental improvement, nice-to-have, or long-term consideration

Each subagent returns two artifacts:
- **Confirmed findings** — perspective tag, problem statement, evidence, improvement suggestion
- **Advisor candidates** — cross-perspective conflicts where two reasonable positions exist (include conflicting finding excerpts + one-sentence reason for escalation)

### Step 2b: Aggregate Phase 1 Results

Combine findings from all 5 subagents. Deduplicate by evidence source. Select up to `advisor_budget` (default: 2) advisor candidates, prioritizing High over Medium findings.

### Step 3: Phase 2 — Advisor Pass

Follow the **Advisor Escalation Policy** section below. For each surviving candidate, spawn a short Opus subagent via the Task tool. Pass only the conflicting finding excerpts (≤100 lines total). Merge Phase 2 verdicts into the confirmed findings list.

### Step 4: Generate Report

Use `references/report-template.md` as the output structure.

- Group findings by priority tier (🔴 High → 🟡 Medium → 🟢 Low)
- Each finding must include: perspective tag, problem statement, evidence from codebase/docs, improvement suggestion
- End with a 3-item executive summary: biggest opportunity, most urgent issue, long-term direction

**Output format** — Default is a Markdown report. When the user passes `--format html` (parsed from `$ARGUMENTS`), emit the report as a self-contained HTML file in `claudedocs/` instead, following [html-output.md](../references/html-output.md): one tab per perspective, priority color coding, and a `Copy as Markdown` button. The Markdown surface is preserved inside the file, so downstream integration is unaffected.

## Advisor Escalation Policy

**Budget**: up to **2 Opus advisor calls per invocation**.

Escalate to an Opus advisor only when the executor genuinely cannot resolve ambiguity from the reference files alone. Escalation is reserved for two conditions:

| Condition | Example |
|---|---|
| **Cross-perspective priority conflict** | A finding is classified Critical under `[Risk]` but Low under `[Market]`, and the correct priority tier determines a concrete recommendation that contradicts the other perspective |
| **Architectural product trade-off** | A recommendation from one perspective (e.g., deepen a niche feature for `[User Value]`) would directly undermine another perspective (e.g., limit growth loop activation under `[Growth]`), and resolving the conflict requires product strategy judgment beyond the reference checklists |

For all other ambiguities — borderline High vs Medium severity, uncertain evidence strength, incomplete codebase — use conservative judgment (prefer the lower priority) and note the uncertainty inline in the report. Do not escalate these to Opus.

## Notes

- If the user provides specific docs or files, read those first before scanning the codebase
- If the codebase is large, focus on README, main entrypoints, and feature directories rather than implementation details
- Base all findings on observable evidence — avoid speculation without grounding in what you actually read
- Follow any additional instructions in `$ARGUMENTS`