Ce Strategy
Run a structured strategy interview before and during compound-engineering phases so your product thesis, problem, and sections in strategy-template.md are sharp enough to build on.
Overview
ce-strategy is an agent skill most often used in Validate (also Idea research, Build PM) that runs a structured strategy interview mapped to strategy-template.md sections.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-strategyWhat is this skill?
- Section-by-section interview aligned one-to-one with strategy-template.md for Phase 1 and Phase 2
- Ask-don’t-prescribe flow with named anti-pattern pushback without leaking pattern labels to the user
- Quote-user-back challenge style and 1–3 sentence answer discipline to surface vague thinking
- Push back once or twice then capture draft with revisit notes to avoid interview spirals
- Opening questions and quality bars per section (e.g. Target Problem) for repeatable strategy capture
- One-to-one mapping between interview sections and strategy-template.md sections
- Overall rules cap answers at 1–3 sentences and allow at most two pushbacks per weak section
Adoption & trust: 1.4k installs on skills.sh; 20.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to build or plan in phases but your problem statement, approach, and persona still sound generic or unfalsifiable.
Who is it for?
Solo builders using compound-engineering who need a disciplined interview before Phase 1 and section refreshes in Phase 2.
Skip if: Teams that already have an approved strategy doc and only need execution checklists without revisiting assumptions.
When should I use this skill?
At the start of compound-engineering Phase 1 and when revisiting each strategy section in Phase 2.
What do I get? / Deliverables
You leave with section-level strategy answers captured in your own words—ready to paste into strategy-template.md and hand off to implementation or planning skills.
- Section-level strategy answers in the user’s language for strategy-template.md
- Draft notes flagging sections worth revisiting after weak answers
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Strategy framing belongs on the validate shelf because it forces problem clarity and scope before you commit engineering effort. Scope is where solo builders decide what to build and why; this skill is the canonical interview ritual for that decision.
Where it fits
Sharpen the core problem narrative before you compare competitors or pick a niche.
Walk strategy-template sections in Phase 1 so scope matches a specific hard problem, not a feature list.
Revisit one strategy section in Phase 2 when the agent draft exposes a weak persona or metric.
Confirm problem and approach language before you prototype flows that test the wrong hypothesis.
How it compares
Use instead of unstructured brainstorming when you need template-aligned strategy sections with explicit quality bars.
Common Questions / FAQ
Who is ce-strategy for?
Solo and indie builders running the compound-engineering plugin who want agent-guided strategy interviews tied to strategy-template.md, not ad-hoc product copy.
When should I use ce-strategy?
At validate scope when defining the product thesis; in idea research when the problem is still vague; and in build PM when revisiting sections per Phase 2 before committing to the next build slice.
Is ce-strategy safe to install?
It is interview-only text guidance with no shell or network requirements; review the Security Audits panel on this Prism page before installing in your agent environment.
SKILL.md
READMESKILL.md - Ce Strategy
# Strategy Interview Loaded by `SKILL.md` at the start of Phase 1 and revisited per-section in Phase 2. Every section below maps one-to-one to a section in `strategy-template.md`. For each section: ask the opening question, evaluate the answer against the quality bar, push back when it falls into a named anti-pattern, and capture the final answer in the user's own language. ## Overall Rules 1. **Ask, don't prescribe.** Do not offer menu options for open answers (problem, approach, persona). Use free-form responses. Reserve multi-select for routing decisions. 2. **Push back once, maybe twice.** If the first answer is weak, name the specific issue and ask a sharper question. If the second answer is still weak, capture what the user has given and note in the draft that the section is worth revisiting. Do not let the interview spiral. 3. **Quote the user back at them.** When challenging an answer, use the user's own words verbatim. Paraphrasing softens the challenge and is easier to dismiss. 4. **Keep each answer to 1-3 sentences.** Longer answers are usually hiding something vague. If the user writes a paragraph, ask them to pick the sentence that matters most. 5. **Don't leak the anti-pattern names.** The user does not need to hear "that's a vanity metric" - just ask the sharper question that follows. --- ## 1. Target Problem **Opening question:** "What's the core problem this product solves - and what makes that problem hard?" Strong answers name a specific situation the target user is in, identify what makes the situation hard *right now* (a crux, a constraint, something that isn't easy to route around), and are falsifiable - you could imagine the problem being absent and know the difference. **Anti-patterns and pushback:** - **Goal stated as problem** ("the problem is we need to grow revenue") -> "That's a goal, not a problem. What's in the world that's making that goal hard to achieve? Whose situation are you changing?" - **Vague wish** ("people need better tools for X") -> "Whose situation specifically? Doing what? What do they try today, and why doesn't it work?" - **Symptom, not cause** ("users churn after 30 days") -> "That's a symptom. What's happening in their world that makes them stop caring? What's the underlying condition?" - **Too broad** ("communication at work is broken") -> "That's a civilization-scale problem. Narrow it to a situation you can actually affect - which users, doing what, when does it hurt most?" - **Feature-shaped** ("there's no good way to do [specific workflow] with AI") -> "That's a missing feature, not the underlying problem. What outcome do users want that the feature would give them?" **Capture:** One or two sentences naming the user's situation and the crux. No solution language. --- ## 2. Our Approach **Opening question:** "Given that problem, what's your approach - the commitment or principle that makes it tractable?" This is the guiding choice: how the product competes or operates, so that many downstream decisions become easier. It is not the product and it is not a feature list. Strong answers are a choice (implying alternatives explicitly *not* pursued), are general enough to direct many decisions but specific enough to rule things out, and sound more like "we win by [doing X differently]" than "we do [a list of things]". **Anti-patterns and pushback:** - **Fluff / values** ("we're customer-obsessed and move fast") -> "Those are values, not an approach. What are you doing *differently* from the other products users could pick? If the answer applies to any company, it's not your approach." - **Feature list** ("we're building AI-powered X, Y, and Z") -> "That's a feature list. What's the underlying bet that makes you pick those features over others? What principle is guiding what you ship?" - **Product description as approach** ("we use AI to draft replies") -> "That's what the product does, but what's the *choice* inside it? Every competitor will say the same thing.