From ce
Guides pre-technical product planning: market discovery, problem/JTBD definition, UX/DX design, scoping, and spec templates for consumer, B2B, dev tools.
npx claudepluginhub rileyhilliard/claude-essentials --plugin ceThis skill uses the workspace's default tool permissions.
**Core principle:** Define the problem worth solving and the experience worth building before deciding how to build it. Research what exists, understand who needs it, scope what matters.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Core principle: Define the problem worth solving and the experience worth building before deciding how to build it. Research what exists, understand who needs it, scope what matters.
Load the relevant reference based on where you are in the planning process:
| Phase | Load | File |
|---|---|---|
| Researching market, competitors, existing patterns | Discovery | references/discovery.md |
| Framing the problem, users, and jobs to be done | Definition | references/definition.md |
| Defining how the feature should feel (UX or DX) | Experience | references/experience.md |
| Drawing scope boundaries, MVP, phasing | Scoping | references/scoping.md |
| Writing the actual product spec document | Template | references/feature-spec-template.md |
Start with Discovery when beginning from scratch. Start with Definition when the problem is already understood. Load Experience alongside either when the feature has significant interaction design. Load Scoping when you need to cut.
Discovery → Definition → Experience → Scoping → [Hand off]
↓ ↓ ↓ ↓
Research Problem How it What's in
& patterns & users feels & what's out
Not always linear. Discovery can reframe the problem. Experience constraints can force scope changes. Scoping can send you back to discovery. But this is the default order.
Different products need different emphasis. Adjust the planning weight:
| Product type | Heavy on | Light on | Key question |
|---|---|---|---|
| Consumer (B2C) | Experience, discovery | Formal definition | "Would I use this?" |
| B2B / Enterprise | Definition, scoping | Visual polish | "Does this solve a workflow?" |
| Developer tools | DX experience, API ergonomics | Marketing polish | "Is this the obvious API?" |
| Internal tools | Scoping, definition | Discovery | "Does this save time?" |
| Platform / API | Definition, experience (DX) | Consumer UX | "Is this composable?" |
You are not designing features. You are solving problems for specific people. If you can't name the person and their frustration, you're not ready to plan.
Before designing something new, find out what already exists. Users have expectations shaped by other products. Meeting those expectations is usually better than surprising people with novelty. Novelty costs learning; familiarity is free.
Frame decisions as hypotheses that could be wrong. "We believe [user] will [behavior] because [evidence]." If you can't state the evidence, it's a guess. Guesses are fine as long as you know they're guesses.
| Decision type | Characteristics | Planning rigor |
|---|---|---|
| Type 1 (one-way door) | Hard to reverse, high switching cost | Full discovery + definition |
| Type 2 (two-way door) | Easy to change, low cost to undo | Lightweight spec, ship and learn |
Most product decisions are Type 2. Don't over-plan reversible choices.
Every feature needs measurable success criteria before work begins. Not vanity metrics. Outcomes tied to the user problem you're solving.
| Bad metric | Good metric |
|---|---|
| "Page views" | "% of users who complete the core task" |
| "API calls" | "Time to first successful integration" |
| "DAU" | "Users who return within 7 days" |
| Pattern | Problem |
|---|---|
| Solution-first planning ("Let's build X") | Skips problem validation, builds the wrong thing |
| Feature lists without user stories | No context for why, impossible to prioritize |
| Copying competitors without understanding why | Imports their problems along with their solutions |
| "Users" as a monolith (no persona distinction) | Different users need different things |
| Scope that only grows, never shrinks | Ship date slides, value dilutes |
| Planning without research | Invents patterns users already know differently |
| Perfecting the spec before testing assumptions | Spec fiction, not product planning |
| DX as afterthought ("devs will figure it out") | Developers are users too, bad DX kills adoption |
This skill's output feeds into other skills:
Skill(ce:writing-plans) takes the product spec and produces task breakdowns with agent groupingSkill(ce:design) takes the experience requirements and produces the visual implementationSkill(ce:architecting-systems) takes the technical constraints from the spec and produces system designSkill(ce:strategy-writer) operates upstream, informing the "why this, why now" that feeds into discoveryWriting tone for specs and product docs: Use Skill(ce:writer) with The PM persona.