product-lens
by affaan-mproduct-lens is a decision-support skill for validating the why before building, pressure-testing product direction, and turning vague requests into sharper briefs. Use product-lens when you need a quick product diagnosis, not a full spec, and want a clearer go/no-go answer before engineering planning.
This skill scores 68/100, which means it is list-worthy but best presented with caveats: it gives agents a clear product-diagnosis workflow for validating the “why” before building, yet it has limited supporting artifacts and some test-like signals that reduce install confidence. Directory users can reasonably install it if they want a structured product-critique lane rather than a full specification workflow.
- Clear triggerability for early product decisions: before starting a feature, weekly review, launch sanity checks, or vague ideas.
- Concrete diagnostic questions and outputs, including a PRODUCT-BRIEF.md and go/no-go recommendation.
- Explicit handoff boundary to product-capability, which reduces workflow ambiguity for agents.
- No install command, scripts, or support files, so adoption depends almost entirely on the SKILL.md instructions.
- Experimental/test-like signals and no extra references/resources mean users should expect a lightweight workflow, not a fully instrumented skill.
Overview of product-lens skill
product-lens is a decision-support skill for slowing down feature work before it becomes implementation. The product-lens skill helps you validate the “why,” pressure-test a product idea, and turn a vague request into a sharper product brief before engineering planning starts.
Use product-lens when you need product diagnosis, not a full spec. It is a good fit for founders, PMs, and builders who need to decide whether an idea is worth pursuing, what problem it really solves, and what the smallest credible version looks like.
What product-lens is best for
The main job of product-lens for Decision Support is to ask the questions teams skip when they jump straight to execution: who it is for, what pain exists, why now, and how success will be measured. It is most useful before feature commits, during weekly product review, or when a concept feels exciting but unproven.
Where it differs from a normal prompt
A generic prompt can brainstorm features. product-lens is narrower: it drives a diagnostic conversation and produces a PRODUCT-BRIEF.md with risks, go/no-go guidance, and a clearer next step. That makes it more useful when you need a repeatable review workflow instead of one-off advice.
When product-lens is not the right lane
If you already want a durable PRD-to-SRS artifact or a capability contract, this skill intentionally hands off to product-capability. Use product-lens first to test the idea, not to finalize delivery details.
How to Use product-lens skill
Install product-lens
Use the repository’s install command from the skill file: npx skills add affaan-m/everything-claude-code --skill product-lens. That is the product-lens install step; after installation, treat it as a workflow skill, not a standalone app.
Feed it a real product question
The best product-lens usage starts with a specific decision. Give it a rough goal, the user it serves, the current behavior or workaround, and what choice you are stuck on. For example, “We want to reduce onboarding drop-off for first-time sellers, but we do not know whether the problem is pricing, setup complexity, or trust.” That is far better than “improve onboarding.”
Read these files first
Start with SKILL.md to understand the workflow, then inspect README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders if they exist. In this repo, the main source is the skill file itself, so the fastest product-lens guide is to read the diagnostic questions and the two modes before running it on a real project.
Use the skill as a product brief engine
The practical flow is: describe the opportunity, let the skill interrogate the assumptions, capture the missing facts, then review the generated PRODUCT-BRIEF.md for a go/no-go answer. If the output still feels abstract, tighten the input around one user segment and one painful workflow, then rerun the skill with those constraints.
product-lens skill FAQ
Is product-lens good for beginners?
Yes, if the goal is to think clearly before building. The skill is simple to start using, but it works best when you can supply a concrete problem, a target user, and a basic sense of the current workflow.
How is product-lens different from a generic AI prompt?
A generic prompt may give broad product advice. product-lens is designed to force decision-quality inputs and outputs: it asks for pain, timing, anti-goals, and success metrics, which makes it better for product review and product-lens for Decision Support than casual brainstorming.
When should I avoid using it?
Do not use it when the team already has a validated brief and needs delivery artifacts, implementation detail, or API-level contracts. In that case, the repo itself says to hand off to product-capability.
What input makes product-lens work best?
The strongest inputs include a named user, a specific pain point, what users do today, why the timing matters, and what would count as success. If you can describe the choice you need to make, the skill can usually pressure-test it well.
How to Improve product-lens skill
Give sharper constraints
The biggest quality gain comes from narrowing scope. Instead of “improve retention,” try “reduce week-one churn for solo creators using the free plan.” Constraints help product-lens surface the right tradeoffs and avoid generic advice.
Provide evidence, not just ideas
If you have it, include user quotes, support tickets, funnel drop-off, sales objections, or launch feedback. product-lens works best when it can judge a real signal rather than an abstract hunch, and that improves the quality of the recommendation.
Ask for a decision, not a brainstorm
The skill is strongest when you want a go/no-go recommendation, a risk review, or a sharper MVP thesis. If you only ask for feature ideas, you will get less value than if you ask, “What should we validate first and what should we avoid building?”
Iterate after the first pass
Use the first product-lens usage result to refine the brief, then rerun it with the missing details it exposed. The best outcomes usually come from one short diagnostic loop, not a single perfect prompt.