affaan-m/ECC

product-lens

Use this skill to validate the "why" before building, run product diagnostics, and pressure-test product direction before the request becomes an implementation contract.

88Collecting

See how to use it View GitHub source

npx skills add https://github.com/affaan-m/ECC --skill "skills/product-lens"

Automated source guide

Source checked Jul 28, 2026·Refresh due Oct 26, 2026

Reorganized from the pinned upstream SKILL.md

Turn product-lens's source instructions into a guide you can follow

According to the pinned SKILL.md from affaan-m/ECC: This lane owns product diagnosis, not implementation-ready specification writing.

npx skills add https://github.com/affaan-m/ECC --skill "skills/product-lens"

Check the pinned source

Best fit

Before starting any feature — validate the "why"
Weekly product review — are we building the right thing?
When stuck choosing between features

Bring this context

Before starting any feature — validate the "why"
Weekly product review — are we building the right thing?
When stuck choosing between features

Expected outputs

All modes output actionable docs, not essays. Every recommendation has a specific next step.

Key source sections

Read product-lens through these 5 source sections

Sections are extracted automatically from the pinned SKILL.md and link back to the source.

Mode 2: Founder Review

Reviews your current project through a founder lens:

SKILL.md · Mode 2: Founder Review

Reviews your current project through a founder lens:

When to Use

Before starting any feature — validate the "why"

SKILL.md · When to Use

Before starting any feature — validate the "why"Weekly product review — are we building the right thing?When stuck choosing between features

How It Works

Like YC office hours but automated. Asks the hard questions:

SKILL.md · How It Works

Like YC office hours but automated. Asks the hard questions:Output: a PRODUCT-BRIEF.md with answers, risks, and a go/no-go recommendation.If the result is "yes, build this," the next lane is product-capability, not more founder-theater.

Mode 1: Product Diagnostic

Like YC office hours but automated. Asks the hard questions:

SKILL.md · Mode 1: Product Diagnostic

Mode 3: User Journey Audit

Maps the actual user experience:

SKILL.md · Mode 3: User Journey Audit

Maps the actual user experience:

SkillSignal prompt templates

Provide the task, context, and acceptance criteria

These prompts were written by SkillSignal from the source structure; they are not upstream text.

Task-start prompt

Confirm source fit, inputs, and outputs before acting.

Use product-lens to help me with: [specific task]. Context: [files, data, or background]. Constraints: [environment, scope, and prohibited actions]. Before acting, check the pinned SKILL.md and explain which sections apply, what inputs are still missing, and what you will deliver.

Source-guided execution

Make the Agent explicitly follow the key extracted sections.

Apply the pinned product-lens source to [task]. Pay particular attention to these source sections: “Mode 2: Founder Review”, “When to Use”, “How It Works”, “Mode 1: Product Diagnostic”, “Mode 3: User Journey Audit”. Preserve the important decision at each step. Mark facts not covered by the source as “needs confirmation” instead of inventing them. Then verify the result against my acceptance criteria: [criteria].

Result-review prompt

Check omissions, permissions, and source drift before delivery.

Review the current product-lens result: (1) does it satisfy the original task; (2) were any applicable steps or limits in the pinned SKILL.md missed; (3) did it perform any unauthorized file, command, network, or data action; and (4) which conclusions remain unverified? List issues first, then fix only what the source or user authorization supports.

Output checklist

Verify each item before delivery

The task matches the purpose documented in the SKILL.md.

The source section “Mode 2: Founder Review” has been checked.

The source section “When to Use” has been checked.

The source section “How It Works” has been checked.

The source section “Mode 1: Product Diagnostic” has been checked.

Inputs, constraints, and acceptance criteria are explicit.

Unverified facts, compatibility, and outcome claims are clearly marked.

Any file, command, network, or data action has been reviewed.

Choose a different workflow

When another Skill is the better fit

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

A separate implementation from coreyhaines31/marketingskills; compare its source, maintenance signals, and permission requirements.

Open source detail

testing-anti-patterns

Use BEFORE writing/changing tests, adding mocks, or test-only methods on production classes — vs mocking-the-mock, production pollution, partial mocks, and overfit/tautological assertions

A separate implementation from event4u-app/agent-config; compare its source, maintenance signals, and permission requirements.

Open source detail

design-review

Use when the user says "review the design", "check the UI", or wants a comprehensive UI/UX review. Uses a 7-phase methodology covering interaction, responsiveness, accessibility, and more.

A separate implementation from event4u-app/agent-config; compare its source, maintenance signals, and permission requirements.

Open source detail

FAQ

What does product-lens do?

This lane owns product diagnosis, not implementation-ready specification writing.

How do I start using product-lens?

The catalog detected this source-specific install command: npx skills add https://github.com/affaan-m/ECC --skill "skills/product-lens". Inspect the command and pinned source before running it.

Which Agent platforms does it declare?

No dedicated Agent platform is declared in the pinned source record.

Repository stars

234,327

Repository forks

35,711

Quality

88/100

Source repository last pushed

2026-07-27

Quality breakdown

Based on traceable docs and repository signals; stars are not treated as quality.

88/100

Documentation26/30

Specificity25/25

Maintenance20/20

Trust signals17/25

Compare before choosing

Related Agent Skills and source variants

These links are selected from shared tasks, functions, stacks, platforms, and same-name variants. Compare the source owner, documentation, permissions, and maintenance signals.

ab-testing by coreyhaines31

testing-anti-patterns by event4u-app

Use BEFORE writing/changing tests, adding mocks, or test-only methods on production classes — vs mocking-the-mock, production pollution, partial mocks, and overfit/tautological assertions

design-review by event4u-app

Use when the user says "review the design", "check the UI", or wants a comprehensive UI/UX review. Uses a 7-phase methodology covering interaction, responsiveness, accessibility, and more.

pest-testing by event4u-app

Use when writing, generating, or improving Pest tests for Laravel — clear intent, good coverage, maintainable structure, and alignment with project testing conventions.

requesting-code-review by event4u-app

Use when asking for a review or creating a PR — self-review first, frame the right context, test plan included — even when the user just says 'open a PR' or 'ready to merge'.

View original Skill.mdThis page is parsed directly from the repository SKILL.md without editorial rewriting. Collected: Jul 28, 2026 · about 2 min

Product Lens — Think Before You Build

This lane owns product diagnosis, not implementation-ready specification writing.

If the user needs a durable PRD-to-SRS or capability-contract artifact, hand off to product-capability.

When to Use

Before starting any feature — validate the "why"
Weekly product review — are we building the right thing?
When stuck choosing between features
Before a launch — sanity check the user journey
When converting a vague idea into a product brief before engineering planning starts

How It Works

Mode 1: Product Diagnostic

Like YC office hours but automated. Asks the hard questions:

1. Who is this for? (specific person, not "developers")
2. What's the pain? (quantify: how often, how bad, what do they do today?)
3. Why now? (what changed that makes this possible/necessary?)
4. What's the 10-star version? (if money/time were unlimited)
5. What's the MVP? (smallest thing that proves the thesis)
6. What's the anti-goal? (what are you explicitly NOT building?)
7. How do you know it's working? (metric, not vibes)

Output: a PRODUCT-BRIEF.md with answers, risks, and a go/no-go recommendation.

If the result is "yes, build this," the next lane is product-capability, not more founder-theater.

Mode 2: Founder Review

Reviews your current project through a founder lens:

1. Read README, CLAUDE.md, package.json, recent commits
2. Infer: what is this trying to be?
3. Score: product-market fit signals (0-10)
   - Usage growth trajectory
   - Retention indicators (repeat contributors, return users)
   - Revenue signals (pricing page, billing code, Stripe integration)
   - Competitive moat (what's hard to copy?)
4. Identify: the one thing that would 10x this
5. Flag: things you're building that don't matter

Mode 3: User Journey Audit

Maps the actual user experience:

1. Clone/install the product as a new user
2. Document every friction point (confusing steps, errors, missing docs)
3. Time each step
4. Compare to competitor onboarding
5. Score: time-to-value (how long until the user gets their first win?)
6. Recommend: top 3 fixes for onboarding

Mode 4: Feature Prioritization

When you have 10 ideas and need to pick 2:

1. List all candidate features
2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)
3. Rank by ICE score
4. Apply constraints: runway, team size, dependencies
5. Output: prioritized roadmap with rationale

Output

All modes output actionable docs, not essays. Every recommendation has a specific next step.

Integration

Pair with:

/browser-qa to verify the user journey audit findings
/design-system audit for visual polish assessment
/canary-watch for post-launch monitoring
product-capability when the product brief needs to become an implementation-ready capability plan

Source repo: affaan-m/ECC
Skill path: skills/product-lens/SKILL.md
Commit SHA: 4e973d3eaf92
Repository license: MIT
Data collected: Jul 28, 2026