product-review
Skill171 starsChanged 36 days agoMITView on GitHub
Review a plan, spec, or code change against the seven product-mode principles and report the gaps. Use when the user types /product-review.
13 other projects use a version of this.
Adopted by
Most recently taken up by
- tsaol/awesome-claudetheir own version, first seen Nov 15, 2026
- victor-falcon/skillstheir own version, first seen Nov 8, 2026
- Bobagi/claude-skillstheir own version, first seen Oct 29, 2026
- jarrheyd/skillstheir own version, first seen Oct 11, 2026
- salvatorebottiglieri/agentic-dev-kittheir own version, first seen Oct 9, 2026
- sendaifun/solana-newtheir own version, first seen Oct 9, 2026
Other versions13 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 13
- sendaifun/solana-new★ 178same name
- tsaol/awesome-claude★ 69same name
- victor-falcon/skills★ 16same name
- RizwanZafaris/product-manager-OS★ 4same name
- vishal-mandhane/divinity★ 3same name
- d-wwei/product-review★ 2same name
- Iteam-company/claude-code-boilerplates★ 2same name
- salvatorebottiglieri/agentic-dev-kit★ 2same name
- AlbertFD/AlbertFD-skills★ 1same name
- chawanjoey/claude-skills★ 1same name
3 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Use the text after the command:
- Distinctive: line 17
No text: review the plan in the current conversation.
- Distinctive: line 47
Every gap must point to specific evidence: a file and line, a quote from the plan, or a named absence ("no metric anywhere in the plan or …
- Distinctive: line 48
Never invent data, baselines, or user evidence to fill a gap.
- Very specific: line 49
Do not flag a principle as a gap only because it is not written in this artifact.
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Product review
Review the work against the seven product-mode principles. This is a review: do not edit code or files.
1. Find what to review
Use the text after the command:
- A file path: review that file (a plan, spec, or PR description).
- A PR number or branch: review its diff and description.
- Other text: review it as a plan.
- No text: review the plan in the current conversation. If there is none, review
git diff HEADplus untracked files. If that is empty too, ask what to review.
Then read the context the review needs: the relevant code, .product-mode/checklist/ and .product-mode/decisions/ entries on the same topic, and any linked spec. A filled checklist or decision entry is evidence; cite its path.
2. Decide how much rigor applies
Classify the work with the "When to Skip This Rigor" table in the project's product-mode guidelines:
| Change type | Principles to check |
| Typo, comment, obvious one-liner | None: say so and stop |
| Bug fix, small internal refactor | 2, 3, 5 |
| New user-facing feature | All seven |
| Architecture, pricing, public API, data model | All seven, plus one-way-door sign-off |
State the classification and why in one line. Skip the principles that do not apply.
3. Check each principle that applies
| # | Principle | The gap to look for |
| 1 | Frame the problem | No named user or problem; a symptom stated as the problem; prior art in the codebase ignored |
| 2 | Assumptions visible | Assumptions not listed or not marked validated / assumed / unknown; agreement treated as evidence; an unknown with no way to resolve it |
| 3 | Minimum viable change | Scope beyond the stated problem; speculative config or abstractions; unrelated edits |
| 4 | Tradeoffs named | A non-trivial choice with no stated cost, risk, or rejected alternative |
| 5 | Done by outcome | No acceptance criteria; criteria that only say "merged" or "tests pass"; no user-facing or operational check |
| 6 | Instrumented | No primary metric; an invented baseline; analytics deferred to "later"; no guardrail metric |
| 7 | Decision logged | A one-way-door choice with no sign-off; a non-trivial decision with no entry in .product-mode/decisions/; no revisit trigger |
Rules:
- Every gap must point to specific evidence: a file and line, a quote from the plan, or a named absence ("no metric anywhere in the plan or PR"). If you cannot point to evidence, it is not a gap.
- Never invent data, baselines, or user evidence to fill a gap.
- Do not flag a principle as a gap only because it is not written in this artifact. Check the conversation and
.product-mode/first.
4. Report
Lead with one line: Ready, Ready with gaps, or Not ready. "Not ready" means at least one gap makes the work wrong or risky to build or merge: wrong problem, an unapproved one-way door, or no way to tell whether it worked.
Then one row per principle checked:
| # | Principle | Status | Evidence | Smallest fix |
Status is pass, gap, or n/a. Order gaps first, most serious first. Keep each cell to one sentence.
End with the single most important next step. If it is a missing checklist or decision entry, suggest /preflight or /decision.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.