docs: separate product lens from capability planning

WORKING-CONTEXT.md

@@ -154,3 +154,4 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
 - 2026-04-05: Ported the safe localized README switcher fixes from PR `#1209` directly into `main` rather than merging the docs PR wholesale. The navigation now consistently includes `Português (Brasil)` and `Türkçe` across the localized README switchers, while newer localized body copy stays intact.
 - 2026-04-05: Salvaged the reusable Hermes-generated operator workflow lane without replaying the whole branch. Added six ECC-native top-level skills instead of the old nested `skills/hermes-generated/*` tree: `automation-audit-ops`, `email-ops`, `finance-billing-ops`, `messages-ops`, `research-ops`, and `terminal-ops`. `research-ops` now wraps the existing research stack, while the other five extend `operator-workflows` without introducing any external runtime assumptions.
 - 2026-04-05: Added `skills/product-capability` plus `docs/examples/product-capability-template.md` as the canonical PRD-to-SRS lane for issue `#1185`. This is the ECC-native capability-contract step between vague product intent and implementation, and it lives in `business-content` rather than spawning a parallel planning subsystem.
+- 2026-04-05: Tightened `product-lens` so it no longer overlaps the new capability-contract lane. `product-lens` now explicitly owns product diagnosis / brief validation, while `product-capability` owns implementation-ready capability plans and SRS-style constraints.

skills/product-lens/SKILL.md

@@ -1,18 +1,22 @@
 ---
 name: product-lens
-description: Use this skill to validate the "why" before building, run product diagnostics, and convert vague ideas into specs.
+description: Use this skill to validate the "why" before building, run product diagnostics, and pressure-test product direction before the request becomes an implementation contract.
 origin: ECC
 ---
 
 # 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 spec
+- When converting a vague idea into a product brief before engineering planning starts
 
 ## How It Works
 
@@ -32,6 +36,8 @@ 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 2: Founder Review
 
 Reviews your current project through a founder lens:
@@ -83,3 +89,4 @@ 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