wicked-garden 12.27.0

package/skills/product/refs/acceptance.md

@@ -0,0 +1,79 @@
+# Acceptance Criteria Rubric (Given/When/Then)
+
+Apply this inline. Generate testable acceptance criteria from requirements/design.
+`product:acceptance` **defines criteria** (what done looks like); to **run** tests
+against them, use `/wicked-testing:execution`. (For full requirements-graph AC nodes,
+see the `acceptance-criteria` skill.)
+
+## Process
+
+1. **Identify scenarios** — happy path, error conditions, edge cases, non-functional.
+2. **Write criteria** — Given {context}, When {action}, Then {outcome}.
+3. **Prioritize** — P0 (must-have) vs P1 (nice-to-have).
+4. **Validate** — testability + completeness (each AC is unambiguous and verifiable).
+5. **Specify test data** — what data is needed to exercise each AC.
+6. **QE handoff notes** — special considerations for test implementation.
+
+Apply parameters: `--story US-ID`, `--feature name`, `--format gherkin|table|markdown`.
+
+## Output
+
+```markdown
+## Acceptance Criteria
+### US1: {Story Title}
+**Happy Path (P0)**: AC1: Given {context}, When {action}, Then {outcome}
+**Error Conditions (P0)**: AC2: Given {error}, When {action}, Then {handling}
+**Edge Cases (P1)**: AC3: Given {edge}, When {action}, Then {behavior}
+**Non-Functional (P1)**: AC4: Given {load}, When {action}, Then {performance}
+**Test Data Required**: {data}
+**QE Handoff Notes**: {special considerations}
+```
+
+## Optional: `--scenarios` (wicked-testing tie-in)
+
+When `--scenarios` is passed, convert each story's AC into wicked-scenarios stubs.
+
+**Priority -> difficulty**: P0 -> basic/intermediate; P1 -> intermediate/advanced.
+
+**AC type -> category / tools**:
+| AC Type | Category | Tools |
+|---------|----------|-------|
+| Happy Path | api | curl, hurl |
+| Error Conditions | api | curl |
+| Edge Cases | api | curl, hurl |
+| Non-Functional (perf) | perf | k6, hey |
+| Non-Functional (a11y) | a11y | pa11y |
+| Non-Functional (browser/UX) | browser | playwright, agent-browser |
+
+**Conversion rules**: Given -> Setup / prerequisite state; When -> request or browser
+action; Then -> expected response code / body / behavior. Test data -> env vars or
+Setup commands. If an AC can't be made CLI-executable (manual judgment), note it as
+a comment.
+
+**Stub format**:
+````markdown
+---
+name: {story-kebab}-acceptance
+description: "Acceptance scenarios for {story title}"
+category: {mapped category}
+tools:
+  required: [{primary tool}]
+  optional: [{secondary tools}]
+difficulty: {mapped difficulty}
+timeout: 60
+---
+
+## Steps
+### Step 1: {AC1 Given/When/Then summary} ({tool})
+```bash
+{executable CLI command derived from the AC}
+```
+**Expect**: {Then condition as exit-code / output expectation}
+````
+
+## Handoff
+
+AC feed into `/wicked-testing:plan` (generate scenarios, create cases, validate
+coverage). Persist via `TaskCreate`/`TaskUpdate` with `metadata={event_type:"task",
+chain_id:"{project}.clarify", source_agent:"requirements-analyst", phase:"clarify"}`
+for traceability.

package/skills/product/refs/align.md

@@ -0,0 +1,67 @@
+# Stakeholder Alignment Rubric
+
+Apply this inline. Surface concerns across divergent stakeholder positions, map them
+to trade-offs, and build consensus. (Not requirements elicitation — `refs/elicit.md`;
+not UX — `refs/ux.md`.)
+
+## Process
+
+1. **Identify stakeholders** — primary (direct users/customers), secondary (teams
+   impacted: eng, QE, ops, support), influencers (leadership, partners, compliance).
+   Map interest + influence.
+2. **Surface concerns per group** — needs, concerns, constraints, success criteria.
+3. **Analyze alignment**:
+   - **ALIGNED** — areas of agreement
+   - **CONFLICTED** — where interests diverge (with options + recommendation)
+   - **UNCLEAR** — items needing clarification
+4. **Facilitate resolution** — make trade-offs explicit, highlight shared goals,
+   propose compromise options, escalate when needed.
+5. **Document** — decisions, accepted trade-offs, open items, owners + deadlines.
+
+## Facilitation checklist
+
+- [ ] All stakeholders identified
+- [ ] Concerns surfaced and documented
+- [ ] Conflicts made explicit
+- [ ] Trade-offs clarified
+- [ ] Consensus areas identified
+- [ ] Open items tracked (owner + deadline)
+- [ ] Communication plan defined
+
+## Questions to ask
+
+Who needs to be in this decision? What concerns haven't been voiced? Where are
+interests misaligned? What trade-offs are we making? Who might block/resist? What
+information is missing? How do we communicate the decision?
+
+## Output
+
+```markdown
+## Stakeholder Alignment Analysis
+### Status: ALIGNED | PARTIAL | CONFLICTED
+
+### Stakeholder Map
+| Stakeholder | Interest | Influence | Key Concerns |
+|-------------|----------|-----------|--------------|
+
+### Alignment Status
+**ALIGNED**: …
+**CONFLICTED**:
+- {conflict} — Positions: {A wants X, B wants Y} — Trade-offs: … — Recommendation: …
+**UNCLEAR**: {needs discussion}
+
+### Trade-offs Accepted
+| Trade-off | Chosen Path | Alternative | Rationale |
+
+### Decisions Required
+| Decision | Options | Stakeholders | Deadline |
+
+### Next Steps
+1. {action} — {owner} — {deadline}
+```
+
+## When conflicts arise
+
+Make trade-offs explicit · find shared goals · propose compromise · escalate if
+needed · document the decision. Persist status via `TaskCreate`/`TaskUpdate`
+(`metadata.event_type="task"`); store stakeholder patterns via `wicked-brain:memory`.

package/skills/product/refs/analyze.md

@@ -0,0 +1,77 @@
+# Customer Feedback Analysis Rubric (analyze — pipeline 2/3)
+
+Apply this inline. Analyze aggregated feedback for themes, sentiment, and trends.
+Pipeline: listen -> **analyze** -> synthesize. This is the shared customer-voice
+signal-analysis rubric (also referenced by `listen`/`synthesize`).
+
+## 1. Load input
+
+```bash
+PRODUCT_ROOT=$(sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/_run.py" scripts/resolve_path.py wicked-garden:product)
+ls "${PRODUCT_ROOT}/voice/feedback/"
+```
+If no data, tell the user to run `/wicked-garden:product:listen` first and stop.
+
+## Sentiment
+
+Classes: Positive, Negative, Neutral, Mixed. Intensity: STRONG / MODERATE / MILD.
+Keyword anchors — strong+: love, amazing, perfect; moderate+: good, helpful, useful;
+strong-: hate, terrible, broken, unusable; moderate-: frustrating, confusing, slow.
+
+## Theme extraction
+
+Cluster into themes — Product (features, bugs, performance, UX) · Experience
+(onboarding, support, docs) · Business (pricing, packaging, competition). Rank by
+**frequency x impact**. Keep to the top 3-5 (more is overload).
+
+## Trend detection
+
+Emerging (new) · Growing (increasing) · Stable · Declining · Resolved (was a
+problem, now fixed). Use time-series + growth direction.
+
+## Segment analysis
+
+Enterprise vs SMB · new vs power users · industry · geography. Note who is hurting most.
+
+## Priority signals
+
+What indicates urgency — churn risk, blockers, competitive gaps.
+
+## Techniques
+
+```bash
+# keyword clustering
+grep -i "frustrat\|annoying\|broken" "${PRODUCT_ROOT}/voice/feedback"/* | grep -oE '\w{4,}' | sort | uniq -c | sort -rn | head -20
+# time-series
+ls "${PRODUCT_ROOT}/voice/feedback" | grep -oE '[0-9]{4}-[0-9]{2}' | sort | uniq -c
+```
+
+## Rules
+
+Objective + data-driven; cite sample sizes (N=X); distinguish correlation from
+causation; acknowledge data limits; confidence HIGH/MED/LOW; include representative
+verbatim quotes; cite sources (ticket IDs, survey dates); distinguish frequency from severity.
+
+## Output
+
+```markdown
+## Feedback Analysis Report
+### Summary — Period {…} · Items {count} · Overall Sentiment {score} ({trend})
+
+### Top Themes
+| Theme | Frequency | Sentiment | Trend |
+|-------|-----------|-----------|-------|
+
+### Theme Deep Dive
+#### {Theme} — {count} ({%}) · Sentiment {…} · Trend {…}
+> "{quote 1}" / "{quote 2}"
+Key drivers: … · Recommendation: …
+
+### Sentiment Drivers — positive: … / negative: …
+### Trends — | Metric | This | Last | Change |
+### Segment Insights — | Segment | Sentiment | Top Theme | Notable |
+### Recommendations — {priority}: {action} (evidence, impact)
+
+### Next Steps
+Run `/wicked-garden:product:synthesize` to generate prioritized recommendations.
+```

package/skills/product/refs/elicit.md

@@ -0,0 +1,67 @@
+# Requirements Elicitation Rubric (user stories + AC)
+
+Apply this inline. Turn a vague idea / stakeholder ask into structured user stories
+with acceptance criteria. For a full requirements **graph** (complexity >=3 or
+compliance), use the `requirements-analysis` / `requirements-graph` skills instead.
+
+## Process
+
+1. **Understand context** — read outcome doc / brief / existing requirements / related issues.
+2. **Identify gaps** — who are the users/personas? what are they achieving? why does it
+   matter? what constraints? what could go wrong?
+3. **Ask questions** — surface anything needing stakeholder input.
+4. **Write user stories** — `As a {persona}, I want {capability}, so that {benefit}`.
+5. **Assign priority** — P0 (must-have / launch blocker), P1 (important / near-term),
+   P2 (nice-to-have / deferrable).
+6. **Assign complexity** — S (hours), M (1-2 days), L (3-5 days), XL (week+).
+7. **Define dependencies** — story-to-story or system (use story IDs / component names).
+8. **Define acceptance criteria** — Given / When / Then per story.
+9. **Recommend** next steps for refinement.
+
+## Story quality (INVEST)
+
+- **Independent** — standalone value
+- **Negotiable** — not an over-specified contract
+- **Valuable** — benefit stated
+- **Estimable** — enough clarity to size
+- **Small** — completable in an iteration
+- **Testable** — completion is verifiable
+
+## Completeness check
+
+Happy-path scenarios · error conditions · edge cases · non-functional requirements
+· dependencies · assumptions. Flag every ambiguity.
+
+## Traceability
+
+Assign each requirement a unique ID `REQ-{domain}-{number}` (e.g. `REQ-AUTH-001`).
+Note Upstream (business goal / user need this traces to) and Downstream (design
+decisions, AC, tests that should verify it).
+
+## Output
+
+```markdown
+## Requirements Elicitation Results
+
+### User Stories Defined: {count}   Acceptance Criteria: {count}   Open Questions: {count}
+
+---
+### US1: {Story Title}
+**As a** {persona} **I want** {capability} **So that** {benefit}
+**Priority**: P0|P1|P2   **Complexity**: S|M|L|XL   **Dependencies**: {IDs or None}
+**Acceptance Criteria**:
+1. Given {context}, When {action}, Then {outcome}
+
+---
+### Open Questions
+1. {question requiring stakeholder input}
+
+### Recommendations
+- {next step}
+```
+
+## Persistence (optional)
+
+When a clarify task is active, append the elicited stories to the task via
+`TaskUpdate` (`metadata.event_type="task"`) for traceability; store recurring
+requirement patterns via `wicked-brain:memory`.

package/skills/product/refs/listen.md

@@ -0,0 +1,58 @@
+# Customer Feedback Aggregation Rubric (listen — pipeline 1/3)
+
+Apply this inline. Aggregate customer feedback from discovered sources. Pipeline:
+**listen -> analyze -> synthesize**. (Shared customer-voice rubric: `refs/analyze.md`
+covers sentiment/theme/trend classification.)
+
+## 1. Discover sources
+
+```bash
+PRODUCT_ROOT=$(sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/_run.py" scripts/resolve_path.py wicked-garden:product)
+ls "${PRODUCT_ROOT}/voice/feedback/" 2>/dev/null
+find . -name "*feedback*" -o -name "*survey*" -o -name "*tickets*" 2>/dev/null | head -10
+gh issue list --label "customer-reported" 2>/dev/null | head -5
+```
+
+Typical sources: support tickets, feature requests/votes, survey responses, social
+mentions, NPS comments, direct customer quotes.
+
+## 2. For each source
+
+1. Extract feedback items.
+2. Normalize to a standard record: `ID, source, date, author, content, sentiment, tags, priority`.
+3. Tag sentiment (positive / negative / neutral) and category.
+4. Prioritize by impact (critical / high / medium / low).
+
+Apply parameters: time window (`--days` / `--since`), filters (`--tags`,
+`--capability`), `--limit`.
+
+## Output
+
+```markdown
+## Listening Report: {timeframe}
+
+### Sources Discovered
+| Source | Items | Status |
+|--------|-------|--------|
+| {source} | {count} | Active |
+
+### Quick Stats
+- Total Items: {count}
+- Sentiment: {%pos} positive, {%neg} negative, {%neu} neutral
+- Top Tags: {tag} ({count}), …
+- Critical Items: {count}
+
+### Recent Highlights
+#### 1. {Title} — {source} — {date}
+**Sentiment**: {…} | **Priority**: {…}
+> "{excerpt}"
+
+### Next Steps
+Run `/wicked-garden:product:analyze` to extract themes and trends.
+```
+
+## Storage
+
+Feedback stored at `{PRODUCT_ROOT}/voice/feedback/{source}/{YYYY-MM}/{id}.md`.
+Log critical items via `TaskCreate` (`metadata.event_type="task"`); recall past
+insights via `wicked-brain:memory`.

package/skills/product/refs/mockup.md

@@ -0,0 +1,77 @@
+# Mockup / Wireframe Rubric
+
+Apply this inline. Produce wireframes, mockups, or component specs at the right
+fidelity — quick ASCII for ideation, HTML/CSS for stakeholder review, annotated
+spec for developer handoff. (Not production design — that's the figma plugin. For
+imagery generation, see the `imagery` skill.)
+
+## Fidelity selection
+
+| Purpose | Fidelity | Format |
+|---------|----------|--------|
+| Quick ideation | Low | ASCII wireframe |
+| Flow discussion | Low | ASCII + annotations |
+| Stakeholder review | High | HTML/CSS preview |
+| Developer handoff | Medium | Component spec (Markdown) |
+
+Auto-select: `--fidelity low` / bare description -> ascii; `--fidelity high` /
+stakeholder context -> html; file-path target -> spec (current + improvements).
+
+## Process
+
+1. Clarify scope (component or page? fidelity?).
+2. Check existing — search for similar components to reuse/adapt; recall design tokens.
+3. Draft ASCII first (validate layout).
+4. Elevate to HTML/CSS or spec if the fidelity requires it.
+5. Annotate all states + responsive + a11y.
+6. Flag open questions.
+
+## ASCII wireframe
+
+```
+┌─────────────────────────────────────────────┐
+│ [Logo]              [Nav]  [Nav]  [CTA]      │
+├─────────────────────────────────────────────┤
+│   Hero Headline                              │
+│   [Primary CTA]  [Secondary CTA]             │
+├─────────────────────────────────────────────┤
+│  ┌────────┐  ┌────────┐  ┌────────┐          │
+│  │ Card 1 │  │ Card 2 │  │ Card 3 │          │
+│  └────────┘  └────────┘  └────────┘          │
+└─────────────────────────────────────────────┘
+```
+
+## HTML/CSS preview
+
+Clean minimal HTML, embedded styles, design tokens in `:root` (`--color-primary`,
+`--space-4`, `--radius`, `--text-base`), `box-sizing: border-box`, system-ui font.
+
+## Component spec
+
+```markdown
+## Component: {Name}
+### Anatomy — Container (surface bg, radius, padding), Heading, Body, Action
+### States
+| State | Change |
+|-------|--------|
+| Default | base | Hover | elevation/scale | Focus | 2px outline offset |
+| Disabled | opacity 0.5, not-allowed | Error | error border + icon |
+### Spacing — internal padding {token}, gap {token}
+### Responsive — Mobile stack / Tablet 2-col / Desktop 3-col
+### Accessibility — semantic element + aria-labelledby; keyboard nav; visible focus; alt text
+```
+
+## Output
+
+```markdown
+## Mockup: {component or page}
+**Fidelity**: {Low|Medium|High}   **Format**: {ASCII|HTML|Spec}
+
+### Wireframe / Preview
+{ASCII, HTML block, or spec}
+
+### Annotations — {state/behavior}, {responsive}, {a11y}
+### Design Decisions — {decision + rationale}
+### Open Questions — {for product/stakeholder}
+### Next Steps — [ ] validate flow · [ ] visual-consistency review · [ ] a11y check
+```

package/skills/product/refs/screenshot.md

@@ -0,0 +1,59 @@
+# Screenshot UI Review Rubric (multimodal)
+
+Apply this inline. Review UI design from screenshot images using Claude's vision —
+no source code required. `Read` the image file(s) directly (the Read tool renders
+PNG/JPG/JPEG/WEBP/GIF visually). Optional second image = design reference for
+comparison.
+
+## Read the image(s)
+
+```
+Read(file_path="{image-path}")
+Read(file_path="{reference-path}")   # optional comparison target
+```
+
+## Evaluate
+
+**Layout and spacing** — whitespace consistent and intentional? elements align to a
+grid? content grouped logically?
+
+**Color and contrast** — cohesive limited palette? sufficient text/background
+contrast? semantic color (error/success/warning)?
+
+**Typography** — clear heading hierarchy? readable sizes + line spacing? consistent
+font family?
+
+**Component consistency** — similar elements styled identically? interactive
+elements visually distinct? states (selected/active) clearly shown?
+
+## Comparison mode (if a reference is provided)
+
+Spacing fidelity (built matches spec proportions?), color accuracy (same palette?),
+typography match (weights/sizes/hierarchy), and missing/added elements.
+
+## Output
+
+```markdown
+## Screenshot Review: {filename}
+
+**Viewport**: {desktop|tablet|mobile|unknown}
+**Overall**: {Polished | Minor Issues | Needs Work | Major Problems}
+
+### Visual Design
+**Spacing**: {…}   **Color**: {…}   **Typography**: {…}   **Components**: {…}
+
+### Issues
+{findings with location descriptions}
+
+### Comparison {if reference provided}
+{fidelity assessment}
+
+### Recommendations
+{prioritized fixes}
+```
+
+## Capturing first (optional)
+
+If you need to capture from a URL, use an available browser-automation tool
+(Playwright/Puppeteer/MCP browser) or `wicked-browse screenshot {url} --output …`
+(incl. `--width 375` for mobile), then `Read` the saved file.

package/skills/product/refs/strategy.md

@@ -0,0 +1,77 @@
+# Strategic Analysis Rubric (ROI · market · competitive · value)
+
+Apply this inline. Strategic business analysis across two lenses: **market**
+(ROI / TAM-SAM-SOM / SWOT / Five Forces) and **value** (value proposition / JTBD /
+differentiation — the value-strategist rubric).
+`--focus roi|market|competitive` -> market lens; `--focus value` -> value lens;
+`--quick` = go/no-go signal only.
+
+> **Dispatch only for `--focus all`.** When both lenses run, dispatch the
+> value-strategist agent for the value lens and run the **market lens inline** (apply
+> the market rubric below directly). For a single `--focus`, apply that lens inline.
+> Always render the final synthesis verdict inline (Proceed / Caution / Defer /
+> Do-Not-Proceed + confidence + assumptions + metrics); never delegate the synthesis.
+
+## Market lens — business case
+
+**Costs**: development (eng time x loaded rate, design, QA, deploy); ongoing (infra,
+maintenance, support, tech debt); opportunity cost.
+**Benefits**: revenue (new streams, churn reduction, pricing power); cost savings
+(automation, efficiency, error reduction); strategic value (positioning, platform
+effects); risk mitigation (security, compliance, reliability).
+**Math**:
+```
+Total Investment = Dev + Ongoing (3yr)
+Annual Benefit   = Revenue + Savings + Risk Value
+ROI    = (Total Benefits - Total Investment) / Total Investment x 100%
+Payback = Total Investment / Annual Benefit
+3-Year NPV = discounted benefits - investment
+```
+**Decision**: APPROVE (positive ROI, strong fit, manageable risk) / CONDITIONAL
+(positive with conditions, phase it) / REJECT (negative-or-unclear ROI, poor fit).
+**Confidence**: HIGH / MEDIUM / LOW.
+
+## Market lens — competitive
+
+- **Competitive set**: direct / indirect / substitutes (incl. do-nothing).
+- **Porter's Five Forces**: rivalry, supplier power, buyer power, threat of
+  substitutes, threat of new entrants -> overall attractiveness.
+- **SWOT**: Strengths/Weaknesses (internal), Opportunities/Threats (external).
+- **Positioning & white space**: plot on axes (price vs performance, ease vs power);
+  find underserved segments.
+- **Strategic stance**: head-to-head / differentiation / niche / blue ocean.
+- **Market timing**: maturity (emerging/growing/mature/declining) + TAM/SAM/SOM ->
+  TOO EARLY / RIGHT TIME / TOO LATE.
+
+## Value lens — value proposition
+
+- **JTBD**: functional (tasks), emotional (feelings), social (perception).
+- **Current solutions + pains**: what they use today; what's broken.
+- **Value Proposition Canvas**: customer profile (jobs/pains/gains) ↔ value map
+  (products, pain relievers, gain creators).
+- **Value statement**: `For {customer} who {need}, our {product} is a {category}
+  that {benefit}; unlike {alternative} we {differentiation}`.
+- **Differentiation axes**: performance / experience / price / niche / innovation.
+- **Defensibility (moats)**: network effects, switching costs, proprietary data, brand, ecosystem.
+- **Score /25**: clarity + relevance + differentiation + credibility + defensibility
+  (each 1-5). 20-25 Strong · 15-19 Solid · 10-14 Weak · <10 Not viable.
+
+## Pitfalls to avoid
+
+Sunk-cost fallacy; optimism bias (use conservative estimates); ignoring opportunity
+cost; inflated TAM ("everyone is a customer"); over-focus on direct competitors
+(substitutes/new entrants often matter more); vague benefits; cherry-picked data.
+
+## Output (synthesis, inline)
+
+```markdown
+## Strategy Analysis: {project}
+### Verdict: PROCEED | CAUTION | DEFER | DO-NOT-PROCEED   Confidence: HIGH|MED|LOW
+### Business Case — Investment ${…} · Annual Benefit ${…} · ROI {…}% · Payback {…}mo · 3yr NPV ${…}
+### Competitive — Position {LEADER|CHALLENGER|FOLLOWER|NICHE} · Stance {…} · Timing {…}
+### SWOT — S/W/O/T
+### Value — Score {X}/25 · Statement · Differentiation · Defensibility
+### Key Assumptions · Metrics to Track · Top Risks (risk/prob/impact/mitigation)
+### Immediate Actions
+1. {action} — {why}
+```

package/skills/product/refs/synthesize.md

@@ -0,0 +1,54 @@
+# Feedback Synthesis Rubric (synthesize — pipeline 3/3)
+
+Apply this inline. Translate feedback analysis into prioritized, evidence-backed
+action items. Pipeline: listen -> analyze -> **synthesize**. Run after
+`/wicked-garden:product:analyze` has produced themes/sentiment/trends.
+(Shared customer-voice rubric: `refs/analyze.md`.)
+
+## 1. Locate analysis input
+
+```bash
+PRODUCT_ROOT=$(sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/_run.py" scripts/resolve_path.py wicked-garden:product)
+ls "${PRODUCT_ROOT}/voice/analysis/"
+```
+If empty, tell the user to run `/wicked-garden:product:analyze` first and stop.
+
+## Prioritization model
+
+Rank each recommendation by **impact x frequency x trend x effort x
+risk-of-inaction**. Levels: critical / high / medium / low.
+
+- **Critical** — blocking customer work, churn risk
+- **High** — significant friction, competitive gap
+- **Medium** — enhancement, efficiency gain
+- **Low** — nice-to-have, edge case
+
+## For each recommendation
+
+Action · evidence (verbatim quotes + numbers + affected segment) · expected outcome
+· risk of inaction · effort (S/M/L/XL) · dependencies.
+
+Also identify: **quick wins** (low effort / high impact), **strategic initiatives**
+(high effort / high impact), and **metrics to track**.
+
+Apply filters: `--priority`, `--feature` scope, `--format brief|detailed`.
+
+## Output
+
+```markdown
+## Recommendations from Customer Voice
+
+### Priority Recommendations
+| Priority | Recommendation | Customer Impact | Evidence | Effort |
+|----------|----------------|-----------------|----------|--------|
+| Critical | {action} | {impact} | N={count}, Q="{quote}" | {S/M/L/XL} |
+
+### Quick Wins
+- {low-effort high-impact action}
+
+### Strategic Initiatives
+- {high-effort high-impact action} — dependencies: …
+
+### Metrics to Track
+- {metric} — current {…} -> target {…}
+```