메뉴
Develops a business plan covering revenue model, market size, go-to-market strategy, and financial projections. Use when defining how a product will make money, estimating market potential, or planning finances before building.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Generates a single-file HTML prototype directly in Claude Code. One-pass approach: gather context, agree on a brief, generate the interactive prototype, iterate. Use for new products (after planning), new features for existing products, or redesigns. Pulls design context from planning documents or Figma designs.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
Generates a single-file HTML landing page with conversion-optimized structure and copy. Reads StoryBrand deliverable as the copy foundation. Use when the user needs a marketing landing page for their product.
Guides design intent exploration and reference gathering before opening any design tool. Use when starting high-fidelity UI work, establishing visual direction, or when the product needs intentional design decisions rather than defaults.
Strategic checkpoint primitive – invoke at high-leverage moments to consult the Opus 4.7 advisor agent for a short course correction. Use early in a task (before substantive work), before declaring done, when stuck, or when changing approach. Quotes Anthropic's advisor-tool docs verbatim for timing and treatment.
Generates and maintains a comprehensive CLAUDE.md file for any project. Use when setting up a new project, when the project has evolved significantly, or when switching tech stacks.
| name | ux-business-plan |
| description | Develops a business plan covering revenue model, market size, go-to-market strategy, and financial projections. Use when defining how a product will make money, estimating market potential, or planning finances before building. |
| disable-model-invocation | true |
| model | claude-opus-4-7 |
| effort | high |
| license | MIT |
Before doing the work below, read .design-engineer-plugin/config.yaml project.context.existing_business_plan. If it indicates the project already has a business plan / revenue model (in repo, or via an off-repo reference such as Notion / Confluence captured in off_repo_references), OR project.context.shipped_ui: true indicates an established product where regenerating from scratch isn't appropriate, AND the user did not explicitly request rerunning this skill, do not regenerate.
Instead:
Business model, market research, and financial planning are important steps that founders often postpone until launch. That approach backfires. Better to tackle them early, even imperfectly.
Until you crunch the numbers, every idea feels "definitely profitable." Even a rough plan is better than none. A real accountant can be hired later, after you have launched your MVP and attracted initial users or investors.
If AskUserQuestion is available, use it for all prompts below.
If not, present each question as a numbered list and wait for a reply before proceeding. For multiSelect questions, accept comma-separated numbers (e.g. 1, 3). Never skip or auto-answer without explicit user consent.
Announce your execution plan: Before doing anything, state what you will do in this activity: "Here's what I'm going to do: 1) assess how far along you are with business planning, 2) share my initial read on the business model, 3) ask 7–10 strategic questions covering revenue model, market size, go-to-market, and financials, 4) draft the business plan together, 5) iterate until you approve it, 6) save the final deliverable." This is a commitment device – harder to skip steps you just announced.
Conditional teaching: Ask the user if they are familiar with business planning for products and why it matters early. If yes, give a one-sentence refresher. If no, explain it in simple terms with a concrete example tied to their product idea. Use the "Why This Matters" section above as a starting point, but make it conversational and product-specific.
Required: ALWAYS ask the question, ALWAYS give the refresher when the user says yes. Never skip this step because the user "is a designer" or "already demonstrated familiarity earlier." Users want a memory refresh on every activity, including ones they know. Phrases like "I'll skip the explainer (you're a designer)" are forbidden — they signal the model has decided ON BEHALF OF the user that a refresher isn't needed. The user, not the model, decides what's redundant. The refresher takes one sentence; the cost is trivial; the value to a tired user mid-session is high.
Output presentation rule: Present output incrementally – one section at a time. After each section, discuss with the user, get their input, then move to the next. Never dump an entire deliverable at once.
Challenge ideas: After the user shares an idea or decision, challenge it – surface blind spots, edge cases, future implications. Then let the user decide with full perspective. This is not about being negative – it's about pressure-testing ideas so the user makes better decisions.
BLOCKING REQUIREMENT: Wait for the user to acknowledge the plan before proceeding to Step 1.
question: "How far along are you with the business side of your product?"
header: "Business Planning Status"
options:
- label: "Have not thought about it yet"
description: "I have been focused on the product idea and user needs"
- label: "I have a rough idea of the business model"
description: "I know generally how I want to make money but nothing documented"
- label: "I have competitive pricing data"
description: "I know what competitors charge and have some market context"
- label: "I have an existing business plan to update"
description: "I have a document that needs revision based on new insights"
multiSelect: false # User must choose one current state
If the user has existing business documents or competitive analysis, ask them to share before proceeding.
BLOCKING REQUIREMENT: Wait for the user's answer before proceeding to Step 2.
Before asking questions, share your brief initial thoughts about the business plan based on what you know about the project so far. Keep it to 2-3 sentences per thought. Be honest -- flag what is speculation versus data-driven.
Ask 7-10 context-based strategic questions. Adapt your questions to what you already know about the project. Make sure your questions cover these key concepts:
Ask in small batches (2-3 at a time). Wait for answers before continuing.
BLOCKING REQUIREMENT: Wait for the user's answers before proceeding. Do not generate the deliverable until at least 7 questions have been asked and answered.
Based on all gathered information, draft the business plan following the structure in business-plan-template.md.
Present the draft and ask for feedback.
When using AI to help with market research or financial projections, always apply skepticism:
Teach the user this discipline explicitly. The main goal of every AI assistant is to answer you, even when it does not know the right answer. Always verify.
Continue refining based on the user's feedback. For each iteration:
Repeat until the user explicitly approves the business plan.
Before writing the deliverable, ensure the parent directory exists: run mkdir -p .design-engineer-plugin/design/foundation (Bash). The plugin uses lazy folder scaffolding – folders are created by the skill that needs them, not upfront.
Save the final business plan to .design-engineer-plugin/design/foundation/business-plan.md.
The document should follow the complete structure from business-plan-template.md.
After completing the business plan, check if any new assumptions surfaced. If so, Read .design-engineer-plugin/design/foundation/assumptions.md and append the new assumptions with a note: 'Added from business plan on [date].' The assumptions document is a living deliverable that accumulates insights across the pipeline.
.design-engineer-plugin/design/foundation/assumptions.md first. Do not quote assumptions from memory.Before generating any text for the deliverable, read anti-slop-writing.md and apply its rules. Scan your output before presenting it to the user.
This skill enforces User > Docs > AI at every step:
After the business plan is finalized, suggest:
ux-mvp-requirements – Define the minimum viable feature set informed by business constraintsux-storybrand – Align messaging with the business model and value propositionWhenever you push back on the user's answer (calling it incomplete, too vague, off-target, missing a framework, etc.) OR invoke a named framework or method, you MUST cite the source in the same response. Format:
Source:
<relative path to reference file from this skill's directory>– "<1-line quote of the passage that backs the judgment>"
The user is the designer; they are steering. Without the citation, they are working blindfolded. Cite every time, even when the source feels obvious to you – it is not obvious to them.
If the source is in a deliverable (not a skill reference file), cite the deliverable file path the same way. If the source is a generic principle from your training that has no specific file, name the principle explicitly and acknowledge there is no plugin-internal reference: "This is a general design principle, not from a specific reference in this plugin."