Estimate market, segment, or opportunity size with transparent assumptions and uncertainty. Use for TAM/SAM/SOM, sizing scenarios, or comparing the scale of possible opportunities.
75
92%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Use $visualize-data when the sizing result needs a chart or figure.
Use $build-report to package the final estimate, assumptions, sensitivity, caveats, and source context whenever this skill is selected, unless the user explicitly requests an inline, chat-only, brief/no-artifact answer, asks not to create a report/file/artifact, or selects another primary artifact.
Use this skill to produce a defensible estimate of a market or opportunity from connected context, public sources, transparent assumptions, and auditable calculations. The job is to define the market, choose a sound sizing method, distinguish evidence from assumptions, test sensitivity, and state what would most improve confidence.
Use the relevant semantic layer as a starting map, not a boundary.
Before querying sources, building artifacts, or drawing conclusions, determine whether the answer requires a specific source of truth.
If a required source is unavailable, stop that path. Tell the user what source is needed, ask them to make it available or provide a reviewed fallback, and do not treat weaker substitutes as equivalent.
If the missing source is only optional enrichment, continue with the strongest available evidence and label the gap when it materially affects the answer.
Clarify with the user when a missing input would materially change the estimate or recommendation. Otherwise make a reasonable assumption, state it, and proceed.
Define the market or opportunity boundary before estimating:
Pick the simplest sound sizing approach for the question, then sketch the calculation chain and the major inputs the estimate will depend on.
A top-down model works when reliable aggregate market data exists; a bottom-up model works when the market can be built from observable units and assumptions; a value-based model works when the estimate should start from the value created rather than a published market total. Use a mixed approach only when cross-checking would materially improve confidence. If more than one approach fits, briefly explain which one you trust most and why.
Expect the first approach to change if source checks show that another model would be more defensible.
Choose sources based on the inputs the estimate depends on most.
Start with user-named sources when provided. Then use the strongest available evidence for each major input from the starting approach. Use ~~structured_data when an input should come from the user's data warehouse or another structured data source. Use context lanes such as ~~company_docs, ~~team_communication, or ~~dashboards_or_bi when an input needs business meaning, source-of-truth guidance, or assumptions that are not captured in structured data alone. When an input depends on the outside market, use public sources for benchmarks, population estimates, comparable markets, or proxy assumptions.
Use $gather-business-context to resolve context lanes when the right source of truth, business meaning, or assumption set is unclear.
If the strongest source is unavailable or thin, continue with a transparent proxy assumption only when the estimate is still useful. Label the gap and explain how it affects confidence.
Keep sourced facts, inferred estimates, and judgment calls distinct in the model. When exact data is unavailable, use a defensible proxy, explain why it is reasonable, and note the confidence level. Ground assumptions in evidence about how the market actually behaves, what can realistically change, and what determines the size of the opportunity.
Make the model easy to inspect and adjust.
The model should make these elements easy to audit or revise:
For each major input, make the source path visible: structured data, context lane, public source, user-provided input, or proxy assumption.
Keep derived values traceable to formulas or code rather than hardcoded outputs.
Use $jupyter-notebooks when code is needed for source harmonization, calculations, sensitivity analysis, or reusable modeling logic. Keep formulas, inputs, intermediate calculations, and sensitivity logic inspectable.
Use the $Spreadsheets skill when the user requests a spreadsheet, workbook, or Google Sheets deliverable, or when a market-sizing model would materially benefit from editable assumptions, sensitivity tables, charts, or polished workbook formatting.
Identify the assumptions that move the estimate most.
Show how the estimate changes when those assumptions move up or down. Prefer simple, decision-useful sensitivity analysis over exhaustive scenario sprawl.
Use ranges when uncertainty is material. Do not hide uncertainty behind a single point estimate when the inputs are thin.
End by handing the estimate, method, key assumptions, uncertainty, and next validation priorities to $build-report unless the user explicitly waives report creation or selects another primary artifact. This handoff is mandatory when no explicit human waiver was given; do not infer a waiver because the user asked for an estimate or did not use the word "report". This workflow owns the sizing model and conclusion; $build-report owns the reader-facing structure, visuals, evidence placement, and delivery surface.
Before handoff, make the market-sizing conclusion explicit:
If source coverage is thin, say which major inputs rely on proxy assumptions and what source would most improve them.
Use $validate-data when methodology, calculations, assumptions, caveats, or source support need review before sharing.
Do not render charts directly from this skill. If a sensitivity, scenario, funnel, or market-breakdown visual would clarify the estimate, pass that visual intent and supporting evidence to $build-report so $visualize-data owns chart selection and QA.
ff87d47
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.