Skip to main content

​
How to Use These Docs Effectively

These docs are designed for both humans and AI systems, but they are not meant to be consumed as one giant undifferentiated dump. The corpus is organized so overview pages explain the shape of the platform, how-to pages explain implementation steps, and reference pages hold canonical facts. If you are using an AI assistant, start with the right page type and then pull in the specific reference pages that own the facts you need.
If two pages seem to overlap, trust the canonical reference page. See the Documentation Contract for the full rules.

​
How the Docs Are Organized

Page typeWhat it doesWhat to use it for
OverviewExplains what something is, when to use it, and how it connectsOrientation, planning, feature discovery
How-toGives implementation steps and sequencingBuilding, setup, migration, QA
ReferenceHolds canonical facts, schemas, fields, endpoints, payloads, selectors, and variablesSource-of-truth technical detail
Use-case pageRoutes a developer or operator to the right referencesFast starts, task routing
AI playbookHelps AI assistants reason about CreatorCommerce workflows without inventing factsPrompting, implementation guidance, workflow framing

​
1. Start with the smallest page that frames the task

Use:
  • an overview page if you need orientation
  • a use-case page if you know the job to be done
  • a how-to page if you are already implementing

​
2. Add the canonical references

For any factual or structural detail, pull in the canonical page instead of relying on summaries from multiple guides. Common reference homes:

​
3. Ask the AI to cite the references it used

This keeps the answer anchored to the real source-of-truth pages and makes it easier to spot drift or assumptions.

​
4. Add your local context last

After the docs, add:
  • your actual code
  • theme or app constraints
  • exact storefront surface or page type
  • what is already working
  • what is failing

​
What Not to Do

  • Do not give the AI five overlapping pages that all restate the same facts in slightly different ways.
  • Do not prefer a long overview page over a canonical reference page for field names, schemas, selectors, or payloads.
  • Do not rely on legacy documentation for new work.
  • Do not point public implementation workflows at repo-local draft files or internal notes.

​
Good Prompt Patterns

​
Implementation prompt

I'm implementing CreatorCommerce on a Shopify theme.

Use these pages as the source of truth:
- /guides/storefronts/migrate-existing-sections
- /references/sdk/referencing-creator-content
- /references/drops-products-data-model

Here is my current section code:
[paste code]

Please propose the smallest safe change, cite which reference page each important decision came from, and call out any assumptions.

​
Debugging prompt

I'm debugging creator resolution on a PDP.

Canonical references:
- /references/sdk/getting-started
- /references/sdk/cart-attributes
- /references/sdk/referencing-creator-content

Observed behavior:
- landing pages personalize correctly
- PDPs do not

Here is the Liquid:
[paste code]

Please explain the most likely failure points in order.

​
Strategy-to-build prompt

I need a plan for a creator directory implementation.

Use these pages:
- /guides/storefronts/creator-directory
- /guides/storefronts/co-branded-storefront-ui-glossary
- /references/creator-collab-data-model
- /references/custom-fields-reference

Please separate:
1. what is canonical data model fact
2. what is implementation recommendation
3. what is an assumption

​
Conflict Resolution

When pages overlap, resolve conflicts in this order:
  1. Reference pages in references/
  2. Glossary for naming and terminology
  3. How-to pages for implementation sequencing
  4. Overview pages for framing
  5. AI playbooks for prompting guidance

​
Start Here