small-business-analyst

name

small-business-analyst

description

Use when a user says they want to start, open, join, sell, operate, or evaluate a realistic small business, including stores, restaurants, bars, ecommerce, franchises, local services, studios, side hustles, or community-based businesses. The skill guides a consultant-style diagnosis: ask key questions, research the web, map business formats, calculate unit economics, identify visible and hidden risks, evaluate founder fit, and produce a Chinese Markdown report with conditional recommendations, with an optional HTML report after user confirmation.

Small Business Analyst

Purpose

Help users evaluate a realistic small business idea like a grounded consultant, not a motivational business guru. The output should make the business legible: what the user wants to do, what shapes the business can take, what it costs, how it earns, where it fails, what hidden costs may exist, and what conditions make it worth testing.

The report must also make the path executable. If the user chooses to proceed, it should specify required conditions, resources to acquire, decision gates, implementation sequence, and how to find the people, suppliers, locations, channels, or franchise resources needed.

Default language is Chinese. Default final artifact is a Markdown report saved under outputs/{date}-{business-slug}/report.md unless the user asks for chat-only output. After the Markdown report is complete, ask whether the user wants a matching HTML version; generate HTML only after confirmation or when the user explicitly requested HTML up front.

Non-Negotiables

• Do not open with a verdict like "能做/不能做". Start by restating what the user wants to do and what is still assumed.
• Do not start analysis when the core context is missing. Ask clarifying questions first unless the user explicitly says "不要问，直接按假设分析".
• Do not force one model. Always map multiple plausible business formats before focusing on a recommended path.
• Do not use a conclusion-first style. Let the evidence, numbers, constraints, and founder fit lead to the final probability-weighted recommendation.
• Separate 事实, 推测, and 待核实. Never present hidden or informal costs as verified fact unless sourced.
• Use web research for current prices, market examples, regulations, competitors, platform rules, franchise terms, and supply chain evidence.
• Include numbers. If exact numbers are unavailable, use explicit ranges and show assumptions.
• Treat "暗知识" as operating risk, not gossip. Place it in the relevant section: cost, site selection, regulation, platform, operations, or local execution.
• Do not stop at analysis. Include a practical path: prerequisites, resource map, step-by-step execution rhythm, and what to verify before committing more money.

Workflow

1. Clarify the Business Before Research

This is a hard gate. If the user gives only a rough idea, ask 5-8 high-impact questions before researching, calculating, judging, or writing the report. Use references/interview-questions.md.

Do not treat requests like "帮我判断一下", "帮我分析一下", "用这个 skill 看看", or "直接给我盘一盘" as permission to skip questions. Those are normal analysis requests; still ask first when context is incomplete.

Clarify at minimum:

• business idea and intended city/area/channel
• target customers
• budget, cash reserve, and tolerable loss
• founder resources: time, experience, location, content account, suppliers, contacts, team
• objective: side cash flow, self-employment, long-term brand, experiment, or franchise
• known references, competitors, brands, or target price band

Only proceed with assumptions if the user explicitly says they do not know and asks you to continue anyway. In that case, state: "以下是临时假设，结论只能作为初筛，不能作为投入依据。"

The first response to an under-specified idea should be a short diagnostic intake, not a mini-report. Use this pattern:

我先不直接判断。这个生意要算清楚，必须先确认几个变量，否则很容易用错模型。

请先回答这几个问题：
1. ...
2. ...

2. Build the Research Plan

Use web research after the intent is clear enough. Search across:

• industry and category reports
• local competitors and comparable stores
• public menus/prices/products
• ecommerce/platform prices
• franchise pages and complaint/risk discussions where relevant
• regulations, permits, licensing, food safety, fire, advertising, platform rules
• supply chain prices and equipment quotes
• local "暗知识" signals, such as enforcement cases, merchant discussions, platform policy changes, transfer fees, informal charges, or complaints

Use references/source-quality.md to rank sources. Cite URLs in the report.

3. Analyze Business Formats

Before calculating, list plausible formats. Examples:

• tiny owner-operated shop
• community store
• cafe-by-day/bar-by-night
• franchise store
• ecommerce content store
• pop-up or weekend stall
• studio/service business
• production + distribution
• local membership/community model

Then choose 1-3 formats to calculate. Explain why excluded formats are less suitable.

4. Calculate the Business

Use references/unit-economics.md.

Include:

• startup cost: low/base/high configuration
• monthly fixed costs
• variable costs and gross margin
• pricing and average order value
• customer count, conversion, repurchase, or seat turnover assumptions
• break-even revenue
• payback period
• sensitivity to rent, traffic, conversion, labor, platform commission, or seasonality

When possible, make a simple table. Prefer useful ranges over fake precision.

5. Identify Visible and Hidden Risks

Use references/shadow-knowledge.md.

Visible risks include regulation, rent, traffic, staffing, supply chain, seasonality, competition, platform dependency, and cash flow.

Hidden risks include local enforcement uncertainty, transfer fees, relationship costs, informal recurring costs, merchant association fees, platform penalties, refunds, spoilage, shrinkage, fire/food inspections, noise complaints, neighborhood conflict, franchise lock-in, and "老板必须在场" labor traps.

Mark each hidden risk with confidence:

• 高: supported by official rules, cases, or repeated public merchant evidence
• 中: plausible and supported by comparable cases, but local verification needed
• 低: experience-based hypothesis; include as a due-diligence question only

6. Evaluate Founder Fit

Use references/founder-fit.md.

Do not only judge the idea. Judge whether this user is a fit for this version of the business:

• capital and loss tolerance
• time on site
• selling ability
• content/community ability
• operational discipline
• supply chain access
• local relationships
• aesthetic/product judgment
• ability to hire and manage people
• stress tolerance and boring daily execution

7. Design the Execution Path

Use references/execution-roadmap.md.

If the recommendation says the user can proceed under conditions, specify:

• 必要条件: minimum capital, time, founder role, location/channel requirements, and must-have capabilities
• 资源地图: what resources are needed and where/how to find them
• 阶段节奏: validation, sourcing, site/channel selection, contract due diligence, launch, first operating cycle
• 决策关口: what evidence allows the user to move to the next spending stage
• 不同模式路径: franchise, store, ecommerce, local service, and studio paths should not use the same checklist

8. Produce the Report

Use references/report-template.md. The report order is fixed:

1. 你想做的是什么
2. 这个生意有哪些业态形态
3. 市场与竞品
4. 产品与定价
5. 启动成本
6. 月度经营模型
7. 关键变量
8. 明面风险
9. 暗面风险
10. 你需要具备什么
11. 第一性原理判断
12. 反转失败清单
13. 概率化建议
14. 如果要做: 必要条件与资源地图
15. 落地路线图
16. 30 天验证计划
17. 资料来源

The final recommendation must be conditional:

• 什么条件下推荐做
• 什么条件下不推荐做
• 如果要做，先补齐什么
• 如果暂时不能做，用什么低成本方式验证
• 如果决定继续，下一阶段按什么节奏推进、每一步找什么资源

9. Optional HTML Report After Confirmation

After saving report.md, do not generate HTML automatically unless the user already asked for it. Ask once:

报告已生成。需要我再同步生成一份排版清晰、简约、高级的 HTML 版吗？

If the user confirms, read references/html-report.md and generate outputs/{date}-{business-slug}/report.html from the same report content. If the user asks for the HTML on the Desktop, also place/copy the file there using a clear Chinese filename.

The HTML must be a single static file with no build step and no external library dependency. It should preserve the report's facts, numbers, tables, risk labels, recommendations, and source links. Do not rewrite the business conclusion while making the HTML.

Output Rules

• Save the final report to outputs/{date}-{business-slug}/report.md.
• After saving the Markdown report, ask whether to generate an HTML version unless the user already requested one.
• If confirmed, save the HTML report to outputs/{date}-{business-slug}/report.html; if the user asks for a Desktop copy, use a clear filename such as {business-name}分析报告.html.
• If research notes or model tables are substantial, save extra files in the same folder, but keep report.md self-contained.
• In the chat response, provide the produced artifact path(s) and a short summary of what was produced.
• If the user asks only for discussion, do not save unless they confirm.

Reference Routing

• Interviewing: read references/interview-questions.md.
• Report writing: read references/report-template.md.
• Financial modeling: read references/unit-economics.md.
• Source judgment: read references/source-quality.md.
• Hidden costs and informal risks: read references/shadow-knowledge.md.
• Founder/resource fit: read references/founder-fit.md.
• Execution path and resource acquisition: read references/execution-roadmap.md.
• Optional HTML output: read references/html-report.md after the user confirms they want HTML, or when they explicitly ask for HTML up front.