SuperAPI AI Directory
Partner中文AI newsFavorites
Skillszach-feature-demand-validator

zach-feature-demand-validator

Marketing & growth

View repository

Updated 10-16 06:28

About this skill

Prerequisites

This public version of the Skill is self-contained and does not depend on any private workspace files, internal reference libraries, or brand-specific protocols.

Before starting execution, it is recommended to first read the reference materials included with this Skill:

  • references/judgment_criteria.md — Three-dimensional demand judgment criteria
  • references/report_template.md — Report structure
  • references/csv_schema.md — Delivered CSV structure
  • references/review_fallback_pack.md — Review evidence package format when Sorftime is unavailable

Positioning

Most of the time, product development for Amazon sellers is not disruptive innovation, but micro-innovation on top of existing supply:

  • Add a small feature
  • Add a small structure
  • Optimize a small experience

The danger point happens to be here as well. Many features look reasonable, but may just be the seller's own imagination, not something consumers actually care about.

The positioning of this Skill is not to help you invent a new species, but to judge:

Whether this micro-innovation is something users actually care about.

It cross-validates through three independent dimensions to avoid "opening a mold just because it feels like there is demand."

Dimension Preferred data source Alternative when Sorftime is unavailable
Review signals Sorftime product_reviews WebSearch + WebFetch actively scrape Amazon Review pages, or the user provides review_source_pack
Keyword signals Sorftime keyword_detail / keyword_trend / keyword_extends Google Trends (WebFetch) + Amazon Autocomplete (WebSearch) + third-party search volume estimates
Community signals WebSearch（Reddit + Quora） Continue executable (does not depend on Sorftime)

Upstream / Downstream

  • Upstream：zach-product-research、zach-competitor-deep-dive
  • Downstream：zach-new-product-listing-writer

Execution priority

Route A: Sorftime full version

Applicable condition: Sorftime MCP can be called in the current environment.

  1. Review dimension goes through Sorftime product_reviews
  2. Keyword dimension goes through Sorftime keyword tools
  3. Community dimension goes through WebSearch

Route B: Alternative version without Sorftime

Applicable condition: the current environment does not have Sorftime MCP.

  1. Review dimension: prioritize using WebSearch + WebFetch to actively scrape Amazon Reviews; if scraping fails, downgrade to user-provided review_source_pack
  2. Keyword dimension: use Google Trends + Amazon Autocomplete + third-party tools to obtain free search data
  3. Community dimension: continue using WebSearch

Note: The data accuracy of the alternative version is not as good as Sorftime (it cannot obtain precise weekly search volume and CPC), but all three dimensions have real data support, and there are no "blank dimensions." The report must indicate differences in data sources.

Input method

Business input

Supports two types:

Input method Example Processing logic
Category + feature description air fryer + steam feature First find whether products with this feature already exist on the market
ASIN + feature description B0XXXX + self-cleaning Validate directly around the specified product and adjacent competitors

Default site:US

Review fallback input

When Sorftime is unavailable, the user needs to provide a local review evidence package:

review_source_pack/
├── source_manifest.json
└── raw/
    ├── reviews.csv
    ├── reviews.txt
    └── reviews.html

For detailed format, see references/review_fallback_pack.md。

Execution flow

Step 0: Parse the task and construct keywords

  1. Confirm whether the input is "category + feature" or "ASIN + feature"
  2. Confirm the marketplace, default US
  3. Based on references/keyword_construction_guide.md construct 3-5 English keyword variants
  4. Determine whether to use the full Sorftime version or the Review fallback degraded version

Step 1: Review signal collection

1.1 Full Sorftime version

  1. If the user provides a category:
    • Call product_search to find products containing that feature
    • Prefer 3-5 ASINs with high monthly sales, many reviews, and feature keywords clearly in the title
  2. If the user provides an ASIN:
    • Use that ASIN directly
    • If necessary, call product_detail to confirm whether the feature actually exists
  3. For each target ASIN, call product_reviews
  4. Save the returned results as JSON, then call the script:

macOS / Linux:

python3 skills/zach-feature-demand-validator/scripts/parse_reviews.py \
  --input <reviews.json> \
  --asin <ASIN> \
  --keywords "steam,steamer,steaming" \
  --source-url "sorftime://product_reviews/<ASIN>" \
  --output <数据源目录>/01_review_信号_原始数据.csv

Windows:

py -3 skills/zach-feature-demand-validator/scripts/parse_reviews.py `
  --input <reviews.json> `
  --asin <ASIN> `
  --keywords "steam,steamer,steaming" `
  --source-url "sorftime://product_reviews/<ASIN>" `
  --output <数据源目录>\01_review_信号_原始数据.csv

1.2 Review collection when Sorftime is unavailable

Core principle: select ASINs in a targeted way by feature keywords, do not scrape randomly.

The point of Review collection is to verify "whether users care about this feature," so you must target two types of products:

  • Type A: products that already have the feature → look at users' real evaluations of this feature (did positive reviews mention it? did negative reviews say it is useless?)
  • Type B: competitors in the same category that do not have the feature → look at whether users complain that "this feature is missing"

Randomly scraping reviews of high-selling products will not hit feature-related content and has no analytical value.

Step 1: Use feature keywords to search for ASINs in a targeted way

  1. Use WebSearch to search amazon.com [品类] [功能关键词]
    • Example: verify "air fryer + steam" → search amazon.com air fryer steam
    • Extract 2-3 from the resultsalready have the featurereal ASINs (Type A)
  2. Then search amazon.com [品类] best seller, extract 2-3do not have the feature but sell wellASINs (Type B)
    • These are the control group, to see whether anyone in the reviews of mainstream products mentions "I wish it had this feature"
  3. ⛔ Strictly prohibited to use B0XXXXX and other placeholders; you must obtain real, verifiable 10-character ASINs
  4. Confirm each ASIN's product name and whether it has the target feature, and record them in the report

Step 2: Scrape Reviews

For each ASIN:

  • Use WebFetch to try to access https://www.amazon.com/product-reviews/<ASIN>/ref=cm_cr_dp_d_show_all_btm?reviewerType=all_reviews&sortBy=recent&pageNumber=1
  • If the Amazon page is accessible, extract the review content (title, body, star rating, date)
  • If blocked by anti-scraping measures, use WebSearch to search site:amazon.com "<ASIN>" reviews to obtain review summaries
  • You can also search third-party review aggregation sites (reviewmeta.com, fakespot.com)

Step 3: Data volume requirements

  • Type A (with the feature): at least 15-30 reviews per ASIN
  • Type B (without the feature): at least 15-30 reviews per ASIN
  • Total target no less than 80 reviews
  • If a single ASIN returns too few, add similar ASINs to make up the difference
  • Write the actual collection volume and A/B classification into the report

Step 4: Script parsing

Organize the collected reviews into standard JSON, then call the parse_reviews.py script (same as 1.1)

Fallback path: user provides review_source_pack

Only when neither WebSearch nor WebFetch can obtain sufficient review data should the user be asked to manually provide an evidence pack:

  1. Ask the user to provide review_source_pack/
  2. Check whether source_manifest.json contains ASIN, site, export time, source URL, export method
  3. Call the script to uniformly parse the raw evidence:
python3 skills/zach-feature-demand-validator/scripts/parse_review_source_pack.py \
  --pack <review_source_pack> \
  --keywords "steam,steamer,steaming" \
  --output <数据源目录>/01_review_信号_原始数据.csv

Supported raw file formats: CSV, TXT / Markdown, HTML

1.3 Review Determination

See references/judgment_criteria.mdfor the determination criteria; the core is still:

  • Feature mention rate
  • Number of demand expressions (such as wish it had）
  • Positive/negative feedback distribution

Step 2: Keyword Signal Collection

2.1 When Sorftime is available

Call the following in sequence for keyword variants:

  • keyword_detail
  • keyword_trend
  • keyword_extends

Then use the script to export a standard CSV:

python3 skills/zach-feature-demand-validator/scripts/generate_keyword_csv.py \
  --type detail \
  --data <detail.json> \
  --source-ref "keyword_detail:steam air fryer" \
  --output <数据源目录>/02_keyword_信号_搜索量数据.csv

2.2 Alternative Collection When Sorftime Is Unavailable

The keyword dimension must not be left blank. When Sorftime is unavailable, obtain alternative data through the following free data sources:

Search volume estimation (replacing keyword_detail):

  1. Use WebSearch to search for "[功能关键词]" amazon search volume or "[功能关键词]" keyword search volume
  2. Obtain approximate search volume from SEO tool pages (such as Ahrefs free version, Ubersuggest, Keywords Everywhere public data)
  3. Use WebFetch to try to access https://trends.google.com/trends/explore?q=[关键词]&geo=US to obtain Google Trends relative popularity
  4. Mark the data source in the report as "third-party estimate"; accuracy is lower than Sorftime

Trend data (replacing keyword_trend):

  1. Google Trends is the core alternative source: use WebFetch to obtain the trend curve for the past 12 months
  2. Check Google Trends for each keyword variant and record the trend direction (rising/stable/falling)
  3. Use WebSearch to search for "[功能关键词]" trend 2025 2026 to obtain trend judgments from industry discussions

Related terms (replacing keyword_extends):

  1. Use WebSearch to search for amazon autocomplete [功能关键词], or directly search for [功能关键词] to observe the search engine's autocomplete suggestions
  2. Use WebSearch to search for "[功能关键词]" related searches to obtain related search terms
  3. Use WebFetch to try to access the Amazon search page and observe the search suggestion dropdown

CSV output requirements remain unchanged: the three CSVs (02/03/04) still need to be generated, with the source type marked as google_trends / web_search_estimate / amazon_autocomplete, not as Sorftime.

⛔ Keyword data must not be fabricated. If a data source is truly inaccessible, mark that field as "collection failed + reason" instead of just filling in N/A.

Step 3: Community Signal Collection

  1. Use WebSearch to search Reddit / Quora
  2. Keep the title, URL, publication date, sentiment summary, and query terms
  3. Use the script to export a standard CSV:
python3 skills/zach-feature-demand-validator/scripts/generate_community_csv.py \
  --data <community.json> \
  --source-ref 'site:reddit.com "air fryer steam"' \
  --output <数据源目录>/05_社区_信号_讨论摘要.csv

Step 4: Comprehensive Determination

Determination Condition Recommendation
✅ Strong real demand Positive signals in all three dimensions Worth investing in development
⚠️ Weak real demand Signals in two dimensions, one dimension missing Can be considered, but the risk must be acknowledged
❓ To be verified Only one dimension has a signal Don't make a big investment yet
❌ False demand No positive signals, or clear negative signals already exist Investment not recommended

If using the no-Sorftime alternative version, the overall conclusion must state: "Keyword data sources are Google Trends / third-party estimates, with lower accuracy than Sorftime."

Step 5: Generate report

Delivery always includes:

  1. [日期]_[品类]_[功能]_功能需求验证报告.md
  2. Five standard CSVs
  3. If using the Review fallback, also attach:
    • review_source_pack/source_manifest.json
    • review_source_pack/raw/*

Step 6: Delivery validation

python3 skills/zach-feature-demand-validator/scripts/validate_deliverables.py --dir <output_dir>

Only when it returns validate_ok is it considered complete.

Standard output

outputs/feature-validation/
├── YYYY-MM-DD_[品类]_[功能]_功能需求验证报告.md
└── YYYY-MM-DD_[品类]_[功能]_数据源/
    ├── 01_review_信号_原始数据.csv
    ├── 02_keyword_信号_搜索量数据.csv
    ├── 03_keyword_信号_趋势数据.csv
    ├── 04_keyword_信号_延伸词.csv
    ├── 05_社区_信号_讨论摘要.csv
    └── review_source_pack/               # 仅 fallback 场景需要
        ├── source_manifest.json
        └── raw/

All CSVs must include:

  • 数据来源
  • 来源类型
  • 来源链接/查询词
  • 原始文件名
  • 采集时间

Script Directory

Script Purpose
scripts/parse_reviews.py Parse Sorftime product_reviews JSON
scripts/parse_review_source_pack.py Parse manually exported Amazon Review evidence package
scripts/generate_keyword_csv.py Export keyword data as standard CSV
scripts/generate_community_csv.py Export community discussions as standard CSV
scripts/validate_deliverables.py Validate whether the MD, CSV, and fallback evidence package are complete
scripts/WINDOWS_USAGE.md Windows run instructions

Hard rules

  1. ⛔ When Sorftime is available, the Review and keyword dimensions should prioritize Sorftime
  2. ⛔ When Sorftime is unavailable, all three dimensions must have real data collection; no dimension may be left blank or filled with N/A
  3. ⛔ ASIN must be a real, verifiable 10-character ID(e.g., B0PUBLIC01); placeholders such as MULTI, UNKNOWN, B0XXXXX, or brand names are strictly prohibited.parse_reviews.py and validate_deliverables.py both enforce ASIN format validation; illegal values will cause the script to error out and exit
  4. ⛔ Multi-ASIN scenarios must be processed grouped by ASIN: call parse_reviews.py --asin <真实ASIN>separately for each ASIN, or add the ASIN / __asin field to each review in the JSON. Using one placeholder to cover all rows is prohibited
  5. ⛔ Review collection target is no less than 80 items (across 3-5 ASINs); the actual collected amount must be written into the report
  6. ⛔ Raw Review data must be parsed via a Python script; large blocks of raw JSON / HTML must not be stuffed directly into the report
  7. ⛔ Each CSV must retain verifiable source fields, and the source type must truthfully reflect the data source (sorftime_mcp / google_trends / web_search_estimate, etc.)
  8. ⛔ Negative signals must be written into the report
  9. ⛔ All conclusions must cite specific data; vague judgments are not allowed

Reference documents

  • references/csv_schema.md
  • references/report_template.md
  • references/judgment_criteria.md
  • references/keyword_construction_guide.md
  • references/review_fallback_pack.md

Risks and boundaries

  • This Skill does not do: does not make product development decisions, only verifies whether demand is real or false
  • risk-level: low — pure analysis/information collection

Upstream / Downstream

  • Upstream：zach-product-research — provides category direction
  • Downstream: → product development decision (manual) → /zach-new-product-listing-writer

After completion

Report completion status: DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT