Turn User Reviews Into a Better Product Prototype With Claude

You do not need to copy an existing product to learn from its users. In one focused session, you can turn a small, traceable set of reviews into a prioritized improvement plan and one original prototype slice that is ready for a human review.

This guide adapts the evidence discipline described in Jake Schincariol's open-source Replica skill pack, especially its replica-entrepreneur workflow. We reviewed the repository as research. We did not install or run it, and we do not claim that its scripts or end-to-end workflow have been independently validated by NEXAIUM.

What you will produce

By the end, you will have:

• a review evidence table with a source link for every row
• a short list of supported themes, including thin or uncertain themes
• one prioritized improvement brief
• one small, original prototype slice using fresh copy and visuals
• an acceptance checklist and a decision on what to test next

The output is a prototype, not a production-ready application. It does not prove demand, security, accessibility, legal compliance, or commercial viability.

Before you begin

You need Claude or Claude Code, a folder for the work, and review text you are permitted to use. Collect reviews manually from public pages, official feeds, or material a customer has supplied. Respect each source's terms. Do not bypass logins or paywalls, bulk scrape a site, paste personal data, or reuse a competitor's code, interface copy, logos, screenshots, or other protected assets.

If you choose to install a third-party Claude Code plugin, inspect it first. Anthropic's current documentation says plugins can place instructions in Claude's context and can execute code with your user permissions. The repository author publishes the pack under the MIT License, which permits reuse subject to preserving its copyright and permission notice in copies or substantial portions. This guide summarizes ideas and does not redistribute the repository's skills or code.

For a practical input-safety check, read Never Paste These 8 Things Into an AI Chat before preparing your review table.

The evidence-to-prototype flow

Keep every transition visible. Claude can organize evidence and help produce a prototype, but you decide whether the evidence is representative and whether the proposed change is worth testing.

Step 1: Build a review evidence table

Start with a bounded sample. A useful first pass may contain 15 to 30 recent reviews from two or more relevant sources. A small sample is enough to generate hypotheses, but not enough to call a pattern universal.

Create a table with these columns:

Remove names, emails, account details, and other personal information. Preserve the meaning of the review and keep the source link. If you cannot verify a row, exclude it from counts.

Prompt 1: Extract evidence without inventing it

You are helping me analyze user feedback. Work only from the review rows I provide.

For each row:
1. Preserve the source URL, date, and row ID.
2. Extract one concise problem signal using neutral language.
3. Label the signal as complaint, request, workaround, praise-with-friction, or unclear.
4. Separate what the reviewer explicitly states from any inference.
5. Flag missing context, possible duplicates, personal data, and claims that cannot be verified from the row.

Do not invent quotes, users, ratings, counts, causes, or product behavior. Do not treat a review as a testimonial. Return a Markdown table with columns: ID, explicit evidence, signal type, neutral problem statement, inference, confidence, and verification flag.

Here are the rows:
[PASTE YOUR REVIEW TABLE]

Gate 1: every included problem statement must trace back to a row and URL. If it cannot, delete it.

Step 2: Form themes and show uncertainty

Group similar signals, but do not flatten different problems into one broad category. Record how many distinct reviews and sources support each theme. Mark a theme as thin when it depends on one source or only a few reviews. The Replica author recommends larger, multi-source samples for stronger conclusions. That is an author recommendation, not a guarantee that the sample will be representative.

Prompt 2: Cluster and prioritize transparently

Using only the verified evidence table below, group problem signals into specific themes.

For each theme, report:
- theme name
- the job the user is trying to complete
- supporting row IDs
- number of distinct reviews
- number of distinct sources
- severity: low, medium, or high, with a one-sentence rationale
- uncertainty or conflicting evidence
- whether the theme is supported, thin, or unresolved

Then score each supported or thin theme from 1 to 5 on:
- evidence strength
- user harm or friction
- fit with my intended user
- feasibility for a small prototype

Show the four scores separately. Do not calculate a false-precision market score. Do not infer market size, willingness to pay, or demand. Recommend at most three themes for human review and explain the tradeoff.

Evidence table:
[PASTE THE VERIFIED TABLE]

Intended user and product boundary:
[DESCRIBE WHO THIS IS FOR AND WHAT YOU WILL NOT BUILD]

Gate 2: choose one theme only when its source rows support the problem and the prototype can test a meaningful part of it.

Step 3: Write one improvement brief

The brief is the boundary between research and building. It should describe the user's problem without prescribing a full product.

Prompt 3: Turn one theme into a testable brief

Create a one-page improvement brief from the selected review theme and nothing else.

Include:
1. Target user and situation
2. Evidence-backed problem statement
3. Supporting review row IDs and source links
4. What is known, inferred, and still unknown
5. Improvement hypothesis written as: If we change [specific interaction], then [observable user behavior] may improve because [evidence-based reason]
6. One prototype slice small enough to build in a focused session
7. In scope and out of scope
8. Originality boundary: fresh copy, fresh visual language, no competitor assets, no copied code, no confusing brand references
9. Three to five acceptance criteria that can be observed in the prototype
10. Questions that require user testing rather than AI judgment

Do not claim the idea will increase revenue, conversion, retention, or satisfaction. Do not describe the prototype as production ready.

Selected theme and evidence:
[PASTE THE THEME AND SOURCE ROWS]

Step 4: Build one original prototype slice

Use a local, reversible environment. Do not connect real accounts, production data, payment systems, private APIs, or live credentials. If Claude proposes a package, integration, or command, review it before approval and verify current documentation.

Prompt 4: Build the prototype safely

Build a small local prototype from the approved improvement brief below.

Constraints:
- Produce only the single flow named in the brief.
- Use fictional sample data with no real personal information.
- Write all interface copy from scratch.
- Use an original layout and visual system. Do not imitate a named product's trade dress, branding, assets, screenshots, or source code.
- Do not connect external services, scrape websites, use secrets, make purchases, deploy, or modify production systems.
- Before editing files, list the files you expect to create or change and the local run command for my approval.
- Include the default, empty, error, and success states that matter to this flow.
- Use semantic controls, visible focus states, form labels, keyboard navigation, and descriptive status messages.
- Add a short README section that states this is a prototype and lists known limitations.

Stop after the local prototype and a test checklist. Do not deploy it.

Approved brief:
[PASTE THE IMPROVEMENT BRIEF]

Gate 3: inspect the proposed file changes and commands before allowing the build. Stop if the plan needs credentials, live data, automated scraping, paid actions, or deployment.

Worked example: a clearer scheduling change flow

This example is illustrative and hypothetical. The reviews, counts, and product are invented for teaching and are not benchmarks or market evidence.

Imagine a fictional scheduling tool called Northstar Slots. In a 20-review practice dataset, five hypothetical rows mention uncertainty about time zones and three mention difficulty finding the reschedule or cancel action. The evidence table keeps every row separate and labels the sample as synthetic.

The chosen hypothesis is: if the confirmation screen shows both participants' time zones and places clear reschedule and cancel controls beside the appointment details, users may understand the next step with less uncertainty.

The prototype slice contains one confirmation screen, a time-zone preview, a reschedule dialog, a cancellation confirmation, and error states for a stale time slot. It uses a new name, fresh copy, fictional data, and an original layout. It does not recreate any real scheduling product.

Acceptance criteria:

• A user can identify the organizer and attendee time zones without opening another screen.
• A keyboard user can reach and operate reschedule and cancel controls.
• The destructive action requires a clear confirmation.
• A stale or unavailable slot produces a useful recovery path.
• No text, logo, image, code, or distinctive layout comes from another product.

What this example teaches: reviews become traceable problem signals, one supported problem becomes a bounded hypothesis, and the hypothesis becomes a small artifact that a person can test. The prototype does not prove that the change will improve retention or revenue.

Step 5: Run the acceptance gate

Prompt 5: Critique the artifact against the brief

Review this local prototype against the approved brief and acceptance criteria.

For each criterion, return pass, fail, or not tested, with observable evidence. Also inspect:
- traceability from the chosen review rows to the prototype decision
- unsupported claims or invented evidence
- copied or confusingly similar brand elements
- privacy and sample-data safety
- keyboard access, labels, focus visibility, and status messages
- default, empty, error, and success states
- any hidden dependency, network call, credential, purchase, or deployment action
- limitations that must appear in the README

Do not change files during this review. Separate verified findings from recommendations. End with one of three decisions: ready for user testing, revise the prototype, or stop and rescope.

Brief:
[PASTE THE BRIEF]

Acceptance criteria:
[PASTE THE CRITERIA]

Files or screenshots to inspect:
[PROVIDE LOCAL FILES OR SCREENSHOTS]

Optional: use the Replica plugin after review

The Replica repository identifies itself as an MIT-licensed Claude Code plugin containing 11 skills. At source commit `77c9436fb3d18c3d58169efb8caf4fe906b0dc51`, its manifest and marketplace both use the name replica-skill.

The full pack, in one compact map

This is the repository author's intended sequence. NEXAIUM read the source files but did not run the skills or validate their outputs.

For the outcome in this guide, start with your permitted review set, use replica-entrepreneur if you trust and install the plugin, turn one supported theme into a bounded brief, and build only a local prototype. Stop before backend, launch, payment, and deployment work.

Anthropic's current plugin installation documentation confirms that a third-party GitHub marketplace can be added with /plugin marketplace add owner/repo, then a plugin can be opened for review and installed with /plugin install plugin@marketplace. Its plugins overview explains that plugin skills are namespaced as /plugin-name:skill-name.

For this repository, the expected sequence is:

/plugin marketplace add Jakeschincariol/replica-skill
/plugin install replica-skill@replica-skill

After installation and a session reload if required, the relevant namespaced skill should be /replica-skill:replica-entrepreneur. Verify the loaded component inventory with the plugin details screen or claude plugin details replica-skill before use. We verified the command format and namespacing in Anthropic documentation, but we did not execute this repository or confirm its runtime behavior.

A concrete invocation can be written like this in a Claude Code session:

/replica-skill:replica-entrepreneur Analyze only the review rows in replica/reviews.csv. Preserve every source URL, do not scrape or invent evidence, mark thin themes, and produce the repository's documented outputs: replica/feedback.md, replica/fixes.md, and proposed new rows for replica/features.csv. State the sample size and separate observed complaints from inferences. Do not build, connect services, purchase anything, or deploy.

Those output paths and the review-evidence rules come from the repository's replica-entrepreneur/SKILL.md. They are expected source-defined outputs, not results NEXAIUM has reproduced. Inspect every generated file before using it in a product decision.

Before installation, inspect the repository contents and decide whether you trust the instructions and executable files. Anthropic's plugin security guidance warns that plugins can execute code with your user privileges and can change through updates. The installation command above uses the repository's current source; it does not pin the research commit cited here. Check the version and components actually installed before use, and review changes before accepting updates.

Final checklist

• Every review row has a source URL or is clearly marked synthetic.
• Personal information and secrets are absent.
• Counts come from the actual table, not Claude's estimate.
• Thin and conflicting themes are visible.
• One improvement was chosen with an explicit reason.
• The brief separates evidence, inference, and unknowns.
• The prototype is local, bounded, and uses fictional data.
• Copy, visuals, layout, and code are original.
• No scraping, private API, purchase, or deployment occurred.
• Accessibility basics and error states were checked.
• The result is described as a prototype, not a finished product.
• A human decides whether it is ready for user testing.

For a broader research and drafting process, use The 3-Step AI Workflow. If you need to improve the instructions you give Claude, explore Professional Prompts for Claude.

Capability limits

Claude can organize review text, expose gaps, draft a brief, and help build a local prototype. It can still misclassify feedback, overgeneralize a biased sample, write insecure code, miss accessibility issues, or create a polished artifact that has not been validated with users. Review evidence, commands, dependencies, and outputs yourself. Bring in product, security, accessibility, privacy, or legal expertise when the risk warrants it.

Verified on October 11, 2026. Repository behavior and Claude Code commands may change, so check the current source and official documentation before installation.