/product-study

name: product-study
description: Study an existing product from its public pages and turn it into an evidence-backed blueprint plus an MVP cut that AutoCode can build and ship. Use this whenever the user wants something "like X", "similar to X", "my own version of X", "a clone of X", names a competitor they admire, or pastes a product URL and asks to build it — even when they never say "research" or "analyze". Public sources only (official site, docs, pricing, changelog, public repos, app-store listings, public reviews); no logins, captures, decompiling, or copying of code, copy, images or brand.
version: 6.1.0

::GENE{product-study|conf:confirmed|scope:global} T:learn_structure_not_skin T:public_pages_only T:every_claim_has_source_and_confidence T:end_with_an_mvp_the_agent_can_build_in_one_session T:classify_target_first|saas_with_public_pages|open_source_project|app_with_store_listing|undocumented T:acceptance_line=user_does+should_see+machine_checks T:mvp_names_learned_rules_vs_own_decisions T:verify_runs_before_go_live_and_again_on_the_live_url|tool:scripts/acceptance_run.py A:reverse_engineer_or_capture⇒refuse_and_continue_with_public_pages A:report_tests_passed⇒show_expected_vs_actual_table A:copy_ui_copy_images_brand_code⇒describe_structure_instead A:present_blueprint_as_the_product⇒it_is_a_map_the_build_comes_next

::ACTIVATE{product-study} ON:user_names_a_product_to_imitate ON:user_pastes_product_url_with_build_intent

Product study

The user saw a product and wants their own. What they need from you is a **map of its structure** — features, objects, flows, pricing, ecosystem — gathered from pages anyone can open, with the evidence attached, and ending in an **MVP cut small enough to build and deploy in one session**. You are a product analyst who walks in through the front door: every line you write can be traced to a public page, and nothing of the original's skin (interface, copy, images, brand, code) ends up in the user's product. That is what makes the result safe to ship and the user's own.

Step 0 — Frame it in one sentence

Before any fetching, tell the user what will happen, in their language:

> I'll study *X* from its public pages, give you a blueprint of how it's built, > and cut an MVP we can ship today. We learn the structure and design our own look.

This sentence does two jobs: it sets the expectation that the result is not a pixel copy, and it tells the user the study comes before the build. If you cannot talk to the user mid-run (a batch or sub-agent setting), lead the final reply with it instead. Then ask at most **one** question, only if the header line of the blueprint cannot be filled without it: *who is your version for, and what is the one job it must do?* If the user already said it, do not ask.

Step 1 — Collect public pages

Scripts live in this skill's `scripts/` folder; both are Python 3.8+ standard library and refuse out-of-scope URLs on their own. They write under `.autocode/study/<slug>/` **relative to the directory you run them from**, so run them from the user's project root and call them by their absolute path (or pass `--root <dir>`). `$SKILL` below stands for this skill's folder.

python3 $SKILL/scripts/fetch_public.py discover https://example.com          # candidate pages, nothing saved
python3 $SKILL/scripts/fetch_public.py fetch <slug> <url> [<url> ...]        # save text + outline as S1.txt, S2.txt ...
python3 $SKILL/scripts/fetch_public.py links <slug> S3 [--grep docs]       # same-site links seen on S3, no network
python3 $SKILL/scripts/fetch_public.py github <slug> owner/repo             # public repo README + license (if open source)
python3 $SKILL/scripts/fetch_public.py list <slug>

Decide first which kind of thing the user pointed at; the sources differ:

• **SaaS with public pages** (Linear, Notion…): pricing, docs, changelog, help center, reviews. The live app itself is usually a login wall; the docs are the map.
• **Open-source project** (a small game, a CLI, a template): the public repo *is* the map. `github` records README and license; if there is no LICENSE file the script reads the header of the main source file. Readable source files fetched with `fetch` count as sources — you learn the **rules** from them (numbers, state changes, orders of operations) and cite line numbers; you never copy the code. Copyleft (GPL/AGPL): architecture only.
• **App with a store listing**: the store page and help center; no binaries.
• **Undocumented**: say so, write a thin blueprint with low confidence, and let the MVP carry more `{guess}`.

Run `discover` on the homepage **and** on the docs root; docs navigation is often rendered by JavaScript, so if no concepts / data-model page shows up, try the usual slugs directly (`/docs/concepts`, `/docs/conceptual-model`, `/docs/data-model`, `/docs/glossary`, `/docs/getting-started`): a 404 is refused harmlessly and recorded. Once a docs page is fetched, `links <slug> S3` walks its navigation without another round trip.

Pick 8–20 pages, in this order of value: pricing · docs "concepts" / data-model / getting-started pages · feature pages · changelog (last 6–12 months) · API / developer docs · integrations · security · careers (stack clues) · mobile/desktop · customer stories · comparison pages. App-store listings and public review sites (G2, Capterra, Product Hunt) count as public pages too. Read `references/sources-policy.md` for what each page type is good for and the exact line between public and not.

What the tool refuses, you do not work around: login/account/billing paths, robots-disallowed paths, pages that redirect to a sign-in, non-text files. A page that comes back with almost no text was rendered by JavaScript — look for the same content in the docs subdomain or a help center, or go without it. If the product is genuinely undocumented in public, say so and build the blueprint from what exists, with lower confidence tags; a thin hone