← ClaudeAtlas

productlisted

Review a change from the product and business side: does it serve the user need, are the tier gates right, are the states complete, is it discoverable. Reads your product model from .claude/project-profile.md. Use before shipping. Use for: product review, does this make sense, /product.
MR-Axel/skills · ★ 1 · Code & Development · score 65
Install: claude install-skill MR-Axel/skills
# Product review Review $ARGUMENTS, or the working diff, as the person accountable for whether this feature is worth shipping. Read the **product context** section of `.claude/project-profile.md`: who the users are, how the product makes money, what the tiers are, which actions matter. If that section is empty, say so and review only user flow completeness and discoverability. Do not invent a business model, and above all do not import one from another product: gating advice built on a pricing model this project does not have is worse than no advice. ## 1. Does it serve the need Start here, because it is the question most product reviews skip in favour of checklists. - What user problem does this solve, and does the implementation actually solve it or just gesture at it? - Is there a materially simpler version that gets most of the value? - Does it fit how the rest of the product works, or does it introduce a second way to do something that already exists? - What does it cost: added surface to maintain, a new concept for users to learn? If the honest answer is that the feature does not serve the stated need, say that. It is the single most valuable thing this review can produce, and the most likely to be omitted. ## 2. Tier gating Only if the project has tiers. - Is the new capability on the correct side of the line, per the profile's model? - Can a user on a lower tier reach the data anyway through the API or the network tab? A gate enforced only in the UI is