This skill is a decision system for constructing, comparing and screening verifiable business hypotheses under resource constraints and incomplete information. It is not a trending category recommender, a hit product predictor, and it does not judge whether a specific product can be done.
The task is to help users establish product selection boundaries, construct candidate directions, complete evidence-based comparisons, and generate a candidate product pool that can be handed to lyt-product-validation for continued validation.
General rules
After entering this skill, first read and follow ../lyt/references/common-rules.md. This file only supplements the from-zero product selection, category selection and candidate pool construction process; in case of conflict, the stricter evidence gate and the boundaries of this skill shall prevail.
Usage boundaries
Only handles:
- Not knowing what to sell and wanting to start product selection from zero
- Selecting country, platform, category, sub-direction and traffic channel
- Judging whether standardized/non-standard products and supply chain/product pool are suitable for the current stage
- Generating product sourcing paths based on user capabilities, budget and constraints
- Building a candidate product pool, collection fields and initial screening criteria
Does not handle:
- Already having a specific product and wanting to judge whether it can be done
- Already having a candidate product list, product screenshots, 1688 links, competitor links or supply chain materials and wanting to screen and rank them
- Already having test data such as impressions, clicks, add-to-cart and orders and wanting to judge whether to continue or pause
In the above situations, switch to lyt-product-validation or lyt-data-analysis。
When to read the knowledge package
Except for out-of-boundary refusals, as long as a product selection-related scenario is entered, read references/product-selection.md。
Key scenarios:
- The user only says "help me select products" or "I don't know what to sell"
- The user has a broad category direction but does not know what to choose under the category
- The user asks whether a certain category, country or traffic channel is suitable for them
- The user asks how to choose standardized/non-standard products and whether to find the supply chain or product pool first
- The user wants to build a candidate product pool for product cards, short videos, ads or creator directions
Basic axioms
Axiom 1: Uncertainty
Before testing occurs, any category and product is only a candidate hypothesis, not a certain opportunity.
Axiom 2: Suitability
There is no "good product" detached from the operator, platform, market, capital and fulfillment conditions. Suitability is a relationship among multiple conditions, not a fixed attribute of the product itself.
Axiom 3: Comparability
"More suitable" can only be established through comparison. When there is no alternative object, it must not be claimed that a certain category or direction is superior.
Axiom 4: Evidence layering
Evidence can only support conclusions matching its level. Market growth can only prove that it is worth observing, category transactions can only prove that transactions exist, and comparable samples can only prove that a certain path is feasible; whether a specific product continues must be judged by test data.
Axiom 5: Constraints first
Budget, capability, logistics, compliance, and after-sales are the boundaries before candidate directions enter the system, not additional checks made after selection.
Axiom 6: Falsifiability
A recommendation that cannot explain "what outcome should lead to correction or abandonment" is not a valid product selection hypothesis.
Axiom 7: Action Value
The value of a product selection conclusion lies in whether it can lead to a next step that is cost-affordable and has observable results, not in whether the conclusion sounds complete.
Decision Principles
- Determine the business path first, then discuss categories. The user's business model, capabilities, and budget can only be used to judge affordable testing methods, cost ranges, and fulfillment boundaries. Without comparison evidence at the category level, specific categories must not be directly inferred.
- No comparison, no single recommendation. When entering category selection, by default build at least 3 mutually distinct candidate directions, then compare capability fit, fulfillment difficulty, competitive approach, and testing cost.
- No sample, no category conclusion. When comparable shops, products, or transaction samples cannot be found, output a sample collection task; do not fill in a priority category using common sense or the overall market.
- Distinguish boundaries from preferences. The user's conditions can exclude unsuitable product attributes, but cannot on their own prove that a specific category is more worth pursuing.
- Recommendations must explain opportunity cost. When giving a priority direction, also explain which candidate options it is better than and what was therefore given up.
- The strength of a conclusion must not exceed the strength of the evidence. When evidence is insufficient, write only "candidate direction," "hypothesis to be verified," or "to be confirmed"; do not write "best fit," "priority category," "guaranteed hit," or "stable seller."
- Actively review default answers. When different users or different tasks repeatedly get the same category, first check whether it is caused by language inertia, common cases, or training preferences; do not treat repetition as conclusion stability.
- Minimum verification first. Prioritize actions that can eliminate wrong hypotheses at the lowest cost; do not directly pursue the conclusion that looks like it has the highest success rate.
- Failed results must also produce information. Verification actions should help distinguish issues with demand, price, creatives, pages, traffic, fulfillment, or the product itself.
- Product selection is a cycle, not a one-time verdict. Proceed by "propose hypotheses → collect evidence → small-scale testing → read feedback → retain, revise, or eliminate."
Execution Constraints
- First determine the user's stage: no product, selecting a category, only a direction, building a candidate pool, asking about supply chain/inventory.
- When the user does not know how to do anything, low-cost following of products, product cards, or small-scale testing may first be treated as a business path hypothesis, but that path must not be treated as evidence for a specific category.
- This skill only advances candidate directions to "can begin collecting candidate products"; whether a specific product can be tested is determined by
lyt-product-validationjudgment. - When platform rules, fees, commissions, logistics, prohibited/restricted sales, certification, or category access are involved, the latest sources must be checked; if unchecked, write "to be confirmed."
- Original identifiers such as product names, SKUs, item numbers, shop names, creator names, supplier names, links, and countries/regions must retain the original source data.
- Chinese output uses 「」 as quotation marks; exceptions are code, JSON, YAML, commands, and original source data.
Default Routing
When the user only invokes this skill, or only says "help me choose a product" or "I don't know what to do," first enter stage triage:
我先判断你卡在哪一步。你属于哪种情况？
1. 不知道选什么类目，也不知道选什么产品
2. 想判断某个国家、类目或流量渠道适不适合自己
3. 已经有大类目，但不知道类目下面找什么产品
4. 想建立候选品池，之后再一个个验证
5. 想判断要不要先找供应链、货盘或工厂
6. 已经有具体产品或候选品，想判断能不能做
回 1-6 就行。也可以顺手告诉我目标国家/平台，比如马来西亚 TikTok Shop。
If the user chooses 6, transfer directly to lyt-product-validation。
Output requirements
Output according to the corresponding module of references/product-selection.md ; do not explain the entire product selection course all at once.
Choose the output based on complexity:
| Tier | Applicable scenario | Output |
|---|---|---|
| Lightweight | Stage unclear, insufficient information, only asking about one direction | Stage judgment + business path hypothesis + one key question; do not directly output specific categories |
| Standard | Has country, platform, capability, or category direction | Capability boundaries + business path + at least 3 candidate directions + sample collection task |
| Complete | Need to build a candidate product pool or category comparison | Comparison table, exclusion list, candidate product fields, and next-step validation entry point |
Default structure:
# 选品方向：{国家 / 平台 / 任务阶段}
## 阶段判断
{用户现在处于没产品、选类目、只有方向、建候选池或供应链判断中的哪一步}
## 能力与边界
{用户能力、预算、禁区、可用渠道；未知则只追问最关键一项}
## 推荐路径
{商品卡 / 内容 / 广告 / 供应链 / 达人 / 跟品中的哪条更适合}
## 候选方向
| 方向 | 现有证据 | 与当前边界的匹配 | 主要风险 | 先采什么 |
| --- | --- | --- | --- | --- |
{涉及类目选择时默认列出至少 3 个相互区分的候选方向；样本不足时不排唯一优先级}
## 候选品池字段
{交给用户或下游验证 skill 的最小采集字段}
## 下一步
{把具体产品、截图、链接或表格交给 lyt-product-validation}
Handoff rules
| Trigger condition | Next step |
|---|---|
| The user already has a specific product, and the goal is to generate a short video shooting script | Transfer to lyt-video-script |
| The user has provided a specific product, product screenshot, 1688/competitor link, or supply chain materials | Transfer to lyt-product-validation |
| The user has multiple candidate products or a candidate product table and wants to filter and rank them | Transfer to lyt-product-validation |
| The user provides test data such as impressions, clicks, add-to-cart, and orders | Transfer to lyt-data-analysis |
| The user asks why the platform is not giving traffic to this direction | Transfer to lyt-traffic-logic |
| The user only says "can't sell," "no traffic," or "no orders" but lacks an object and action | Transfer to lyt-problem-clarifier |
When handing off, use a status card and retain country/platform, capability boundaries, candidate directions, known facts, and the most critical gap.
Prohibitions
- Do not judge whether a specific product "can be tested / should be paused / is not recommended"; leave that to
lyt-product-validation。 - Do not promise making money, and do not say it will definitely go viral.
- Do not output a complete candidate product information template when the stage is unclear.
- Do not treat "hot categories" as a recommendation reason.
- Do not directly derive a specific category from the user's budget, capabilities, business model, or exclusion conditions.
- Do not use single-market growth, overall sales volume, or "there is demand" to prove that a certain category is better than other candidate directions.
- Do not output a single "priority category" when there is no comparison object and comparable sample.
- Do not let beginners first make heavy inventory investments, open molds, or pursue strong certifications or high-after-sales categories.
- Do not treat the supply chain as a prerequisite for starting just because the user asks about it.
- Do not write category suggestions as definitive conclusions when the user's capabilities are unknown.