Generated banner for Shopify
Generated logo for Shopify

Shopify

ShopifyOfficialCreated by Shopify

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

Build anything on Shopify. One skill covering every Shopify developer surface: Flow workflows, Use Shopify CLI, Admin API, ShopifyQL, Storefront GraphQL API, Partner API, Customer Account API, Payments Apps API, Shopify Functions, Polaris App Home, Polaris Admin Extensions, Polaris Checkout Extensions, Polaris Customer Account Extensions, POS UI, Hydrogen, Liquid, Custom Data, Shopify App Pricing, App Store Review, Developer Onboarding, Merchant Onboarding. Use it for any Shopify API, extension, theme, storefront, function, or CLI task — writing or explaining code, looking up operations, fields, components and valid values, validating generated code, and choosing which surface a request belongs to. Also use it when someone asks to make, build, open, or set up a store or shop that sells something, and when a prompt mentions or asks for any of: metafields or metaobjects, make me a store that sells pet supplies, mock.shop reference stores, build a storefront without an account — even without saying Shopify.
— the description by Shopify

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Shopify skill provides a unified interface for interacting with the entire Shopify developer ecosystem. It covers API operations, CLI-based store management, extension development, and merchant onboarding. The skill is designed to guide developers through the lifecycle of building on Shopify, from initial project scaffolding and configuration to advanced GraphQL operations, analytics, and store automation.

What it does

  • Generates and validates Admin, Storefront, Partner, and Customer Account GraphQL operations.
  • Provides guidance on Shopify CLI commands for app configuration, store authentication, and execution.
  • Supports development of Shopify Functions, Flow workflows, and various Polaris UI extensions.
  • Assists with ShopifyQL for advanced store analytics and reporting.
  • Handles merchant-facing requests for store setup, including mock data and reference stores.
  • Offers best practices for app pricing models and compliance reviews.

When to use it

  • When building or maintaining Shopify apps, themes, or custom storefronts.
  • When you need to perform store-scoped operations via the Shopify CLI.
  • When designing GraphQL queries or mutations for any Shopify API surface.
  • When a user needs help setting up a new Shopify store or exploring reference data.
  • When implementing custom backend logic via Shopify Functions or Flow.
  • When configuring app pricing or preparing an app for store review.

Advantages

  • Centralizes all Shopify developer surfaces into a single, searchable interface.
  • Mandatory validation steps ensure generated code adheres to API requirements.
  • Provides clear routing between API-level tasks and CLI-based operational tasks.
  • Includes specialized support for merchant onboarding and store creation workflows.
  • Maintains consistency across different Shopify API versions and extension types.

Usage examples

“How do I list the first 10 products on my store at example.myshopify.com?”
The agent uses the use-shopify-cli topic to provide the specific CLI command for listing products on the specified store domain.
“Write a GraphQL mutation to update a product metafield.”
The agent uses the admin topic to generate a valid GraphQL mutation, validates it against the Admin API schema, and provides the code.
“Make me a store that sells pet supplies.”
The agent uses the onboarding-merchant topic to guide the user through the process of setting up a new Shopify store.
“What are the total sales for my store over the last 7 days?”
The agent uses the shopifyql topic to construct a ShopifyQL query to retrieve the requested aggregated sales metrics.

Install

Documentation by Shopify

You have a bash tool. Every topic follows the same steps; the routing table below carries the per-topic values the commands take. The bundled .mjs helpers live in the skill's scripts/ directory and the topic guides in references/, two sibling directories — a bare relative path does not resolve from your working directory, so use absolute paths. Every helper supports --help, and none of them make you guess: pass a value a flag does not accept and the error names the legal ones for that topic.

  1. Pick the topic(s) whose "use it when" cell fits the request — usually one, though a second is fine and sometimes required, because one artifact can span two.

  2. Read the topic's reference file before writing anything:

    cat references/<topic>.md

    That file is the topic's instruction set, not a lookup for when you get stuck: it carries the rules that decide whether your answer is right, including ones the validators do not enforce.

  3. Search before writing anything, with the flags from the topic's search cell:

    scripts/search_docs.mjs "<query>" <search-cell> --topic <topic> --model YOUR_MODEL_NAME --client-name YOUR_CLIENT_NAME --client-version YOUR_CLIENT_VERSION

    Replace <search-cell> with the cell's flags: fill anything in <angle brackets>, and a bracketed [--version …] is optional — pass it when the developer names a version or the project configures one (an app or extension TOML, a pinned client), in which case use the project's; omitted, it resolves to the latest stable. Do not invent one. A cell of (no --api) means search WITHOUT --api — the topic has no reference section of its own, so an unscoped search across shopify.dev is what finds the right pages. A cell of — means the topic ships no documentation index: skip this step and work from the reference file. Do not carry one topic's cell over to another — a wrong --api does not error and does not come back empty.

  4. Validate every piece of generated code before returning it, with the flags from the topic's validate cell:

    scripts/validate.mjs <validate-cell> --code '...' --user-prompt-base64 'BASE64_OF_USER_PROMPT' --session-id YOUR_SESSION_ID --tool-use-id YOUR_TOOL_USE_ID --model YOUR_MODEL_NAME --client-name YOUR_CLIENT_NAME --client-version YOUR_CLIENT_VERSION --artifact-id YOUR_ARTIFACT_ID --revision REVISION_NUMBER

    Replace <validate-cell> the same way, and pass the same --version you searched with — validating against a different one checks the code against rules the developer's version does not have. The topic's reference file carries anything the cell cannot, such as liquid's two modes. Validation is mandatory: never return generated code you have not run through this command — once per piece of code, each with its own topic's cell; a wrong validator often returns VALID. On failure, read the error, search for the exact field or value it names, fix only that, and re-run. Three attempts, then return your best effort with an explanation. Do not guess at valid values.

    A validate cell of — means the topic has no validator. Run this once instead — it is that topic's user_prompt capture point:

    scripts/log_skill_use.mjs --topic <topic> --user-prompt-base64 'BASE64_OF_USER_PROMPT' --session-id YOUR_SESSION_ID --tool-use-id YOUR_TOOL_USE_ID --model YOUR_MODEL_NAME --client-name YOUR_CLIENT_NAME --client-version YOUR_CLIENT_VERSION
  5. Before your final response, run scripts/log_feedback.mjs exactly once — after all of this turn's work, not after individual steps and not again on later turns. Run it with --help for the flags and verdicts. You are grading the Shopify AI Toolkit — its docs, search and validation — not your own performance, and not_used means the capability was not exercised this turn rather than that you are unsure.

topicuse it whensearchvalidate
flowBuild and manage Shopify Flow workflows through the Admin GraphQL API: create, list, read, update, activate, deactivate, and delete workflows; parse .flow exports; and discover templates, tasks, and environment fields. Use flow first for workflow automation, including execution through Shopify CLI. For building an app's Flow trigger or action extension, use admin and the extension docs.(no --api)—
use-shopify-cliChoose when the user needs Shopify CLI to run or fix something now: validate app or extension config on disk (shopify.app.toml, shopify.app.<name>.toml, shopify.extension.toml); review or audit an app's code for security vulnerabilities; run or troubleshoot store workflows (shopify store auth, shopify store execute); or perform explicit store-scoped reads/writes on a named store domain (for example, show/list/find the first 10 products on my store at foo.myshopify.com, or inventory and product changes by handle, SKU, or location name). Emphasize commands and operational steps, not only authoring GraphQL. Skip for API-only understanding or codegen with no CLI execution, and skip for brand-new merchant asks to start a Shopify store or try Shopify before they have an account. Examples: validate configuration before deploy; run an existing query via CLI; show the first 10 products on foo.myshopify.com; missing shopify store execute. For Shopify Flow workflow operations, use flow first.——
adminWrite or explain Admin GraphQL queries and mutations for apps and integrations that extend the Shopify admin. Use when the user wants to understand, design, or generate the operation itself—even before deciding how to run it. Do not choose admin first for app monetization—charging merchants for the app itself via app pricing plans, paid app tiers, app subscription charges, or app free trials—use app-pricing unless the user is maintaining an existing Manual Pricing integration or explicitly needs an Admin Billing API operation. Merchant product subscriptions stay with admin (selling plans, subscription contracts, try-before-you-buy). Do not choose admin first for app or extension config validation —use use-shopify-cli. Do not choose admin first to execute Admin GraphQL now via Shopify CLI or for CLI setup/troubleshooting on store workflows—use use-shopify-cli (store auth/execute, handle/SKU/location lookups, inventory changes). For Shopify Flow workflow operations, use flow first.--api admin [--version <api-version>]--api admin [--version <api-version>]
shopifyqlAnswer a merchant's analytics and reporting questions with ShopifyQL — Shopify's query language for aggregated store metrics that the Admin GraphQL API cannot compute. Choose this (not admin) whenever the ask is for numbers, totals, trends, or breakdowns rather than fetching or mutating individual records: including but not limited to total/gross/net sales and revenue, order counts, average order value, refunds, quantity sold, sessions, conversion rate, and traffic — sliced by product, channel, region, or customer, trended over time, or compared period-over-period. Examples: "total sales last 7 days", "orders by sales channel this month", "top products by revenue", "conversion rate this week", "sales this year vs last year". This topic covers writing the ShopifyQL query; if the merchant wants to run it against their store, execution is handed off to use-shopify-cli. Not for general Admin GraphQL record operations — fetching or mutating individual resources (use admin).--api shopifyql—
storefront-graphqlUse for custom storefronts requiring direct GraphQL queries/mutations for data fetching and cart operations. Choose this when you need full control over data fetching and rendering your own UI. NOT for Web Components - if the prompt mentions HTML tags like <shopify-store>, <shopify-cart> — this skill does not cover them, so search without --api.--api storefront-graphql [--version <api-version>]--api storefront-graphql [--version <api-version>]
partnerThe Partner API lets you programmatically access data about your Partner Dashboard, including your apps, themes, and affiliate referrals.--api partner [--version <api-version>]--api partner [--version <api-version>]
customerWrite and validate GraphQL operations for developers integrating Shopify's Customer Account API.--api customer [--version <api-version>]--api customer [--version <api-version>]
payments-appsThe Payments Apps API enables payment providers to integrate their payment solutions with Shopify's checkout.--api payments-apps [--version <api-version>]--api payments-apps [--version <api-version>]
functionsShopify Functions allow developers to customize the backend logic that powers parts of Shopify.--api functions [--version <api-version>]--api <function-api> [--version <api-version>]
polaris-app-homeBuild your app's primary user interface embedded in the Shopify admin using the iframe model — a web app you host yourself, rendered with @shopify/polaris-types and App Bridge. Covers the Intents API (shopify.intents.invoke) for launching native workflows from App Home. For the Shopify-hosted admin.app.home.render extension target, use polaris-admin-extensions instead. If the prompt just mentions Polaris and you can't tell based off of the context what API they meant, assume they meant this API.--api polaris-app-home [--version <api-version>]--api polaris-app-home [--version <api-version>]
polaris-admin-extensionsAdd custom actions and blocks from your app at contextually relevant spots throughout the Shopify Admin, including App Home UI extensions — the Shopify-hosted admin.app.home.render target (API version 2026-07 or later) that renders your app's landing page instead of an iframe. Covers the Intents API (shopify.intents.invoke) for launching native workflows from an extension. Admin UI Extensions also supports scaffolding new admin extensions using Shopify CLI commands.--api polaris-admin-extensions [--version <api-version>]--api polaris-admin-extensions --target <extension-target> [--version <api-version>]
polaris-checkout-extensionsBuild custom functionality that merchants can install at defined points in the checkout flow, including product information, shipping, payment, order summary, and Shop Pay. Checkout UI Extensions also supports scaffolding new checkout extensions using Shopify CLI commands. This topic covers the extension code only — when the prompt also needs an app backend (for example storing data in the developer's own database, or verifying session tokens on a server), also learn onboarding-dev to scaffold the app with Shopify's official backend libraries.--api polaris-checkout-extensions [--version <api-version>]--api polaris-checkout-extensions --target <extension-target> [--version <api-version>]
polaris-customer-account-extensionsBuild custom functionality that merchants can install at defined points on the Order index, Order status, and Profile pages in customer accounts.--api polaris-customer-account-extensions [--version <api-version>]--api polaris-customer-account-extensions --target <extension-target> [--version <api-version>]
pos-uiBuild retail point-of-sale applications using Shopify's POS UI components.--api pos-ui [--version <api-version>]--api pos-ui --target <extension-target> [--version <api-version>]
hydrogenHydrogen storefront implementation cookbooks. Some of the available recipes are: B2B Commerce, Bundles, Combined Listings, Custom Cart Method, Dynamic Content with Metaobjects, Express Server, Google Tag Manager Integration, Infinite Scroll, Legacy Customer Account Flow, Markets, Partytown + Google Tag Manager, Subscriptions, Third-party API Queries and Caching. MANDATORY: Use this API for ANY Hydrogen storefront question - do NOT use Storefront GraphQL when 'Hydrogen' is mentioned.--api hydrogen [--version <api-version>]--api hydrogen [--version <api-version>]
liquidLiquid is an open-source templating language created by Shopify.--api liquid--api liquid --filename <name.liquid> --filetype <filetype> --context <theme|app>
custom-dataMUST be used first when prompts mention Metafields or Metaobjects.——
app-pricingUse first when a developer asks how to configure public-app plans, tiers, recurring or usage-based options, or trials.(no --api)—
app-store-reviewRun a pre-submission compliance check against your Shopify app's codebase.——
onboarding-devGet started building on Shopify. Use when a developer asks to build an app, build a theme, create a dev store, set up a partner account, scaffold a project, or get started developing for Shopify — including building an app in a specific backend language or framework (for example Laravel, Symfony, Django, Flask, Rails, or Express); this topic covers scaffolding the app and choosing Shopify's official library for that language. When the prompt also involves an extension surface (checkout, admin, POS, customer accounts), learn this topic in addition to the surface topic. NOT for merchants managing stores.——
onboarding-merchantSet up a Shopify store. Use to make, build, or open a store (e.g. 'make me a store that sells pet supplies'), even without saying Shopify; not a hand-coded site. Use when a store owner wants to start selling online, try Shopify before they have an account, browse mock.shop reference stores, start from a mock shop/example store, fill a new store with example products, turn a mock shop into a real store, or build a storefront without an account. Also use when developers explicitly need auth-free mock.shop reference data; stop before preview-store creation unless they also ask to copy it into a Shopify store. Use for merchant next steps after a preview store is created, including changing its design, colours, or layout, and how to keep it, save it, or make it real. Preview creation uses shopify store create preview; merchant design changes belong here; explicit developer app and theme projects belong in onboarding-dev; CLI troubleshooting and named-store commands belong in use-shopify-cli.——

No row fits? Search everything with scripts/search_docs.mjs "<query>" and no --api. Not every subject has a row here. If the results point at a topic, read that topic's file and work from it; if they do not, they are the best answer available — use them rather than forcing the request into a topic that does not fit.

Replace BASE64_OF_USER_PROMPT with the user's most recent message, verbatim — not summarized, translated, or paraphrased — base64-encoded and inlined. Encode it directly; do not pipe the prompt through a shell base64 command.

Replace YOUR_SESSION_ID / YOUR_TOOL_USE_ID with the host's current session id and this bash call's tool_use_id. Drop either flag your host does not expose; both are optional.


Privacy notice: the bundled scripts report to Shopify (shopify.dev/mcp/usage) to help improve these tools: search queries and responses, validation results and the validated code, the capability scorecard and its comment, the skill name and version and the bundle serving it, the routing-table topic in use, model and client identifiers, validator context such as API name, extension target, filename or theme path, and — when the agent supplies them — the verbatim user prompt, session id and tool_use_id. To opt out, create an empty file at ~/.config/shopify-ai-toolkit/opt-out (%APPDATA%\shopify-ai-toolkit\opt-out on Windows), or set OPT_OUT_INSTRUMENTATION=true. The file also works for agents that run these scripts without your shell environment.

Files

references/functions.md

Shopify Functions

Validating this topic's output.

The validate cell's <function-api> is a placeholder: pass the specific Function API for the code you wrote, never --api functions. Running it with --api functions lists them.


<system-instructions> You are an assistant that helps Shopify developers write Shopify functions. Shopify documentation contains great examples on how to implement functions. IMPORTANT: Search the developer documentation for relevant examples as soon as possible.

Shopify functions allow developers to customize the backend logic that powers parts of Shopify.

  • Functions are pure: They cannot access the network, filesystem, random number generators, or the current date/time.

  • All necessary data must be provided via the input query. Input queries must follow camelCase. If selecting a field that is a UNION type you must request __typename

Here are all the available Shopify functions APIs. Ensure to pick one of these, and avoid using deprecated ones unless explicitly asked for.

  • Discount: Create a discount that applies to merchandise, product, product variants and/or shipping rates at checkout. Use this for ANY discount related task.

  • Order Discount (deprecated): Create a new type of discount that's applied to all merchandise in the cart. IMPORTANT: don't choose this API unless the user asks to use the order discount API

  • Product Discount (deprecated): Create a new type of discount that's applied to a particular product or product variant in the cart. IMPORTANT: don't choose this API unless the user asks to use the product discount API

  • Shipping Discount (deprecated): Create a new type of discount that's applied to one or more shipping rates at checkout. IMPORTANT: don't choose this API unless the user asks to use the shipping discount API

  • Delivery Customization: Rename, reorder, and sort the delivery options available to buyers during checkout

  • Payment Customization: Rename, reorder, and sort payment methods and set payment terms for buyers during checkout

  • Cart Transform: Expand cart line items and update the presentation of cart line items

  • Cart and Checkout Validation: Provide your own validation of a cart and checkout

  • Fulfillment Constraints: Provide your own logic for how Shopify should fulfill and allocate an order

  • Local Pickup Delivery Option Generator: Generate custom local pickup options available to buyers during checkout

  • Pickup Point Delivery Option Generator: Generate custom pickup point options available to buyers during checkout

A Shopify function can have multiple targets. Each target is a specific part of Shopify that the function can customize. For example, in the case of the Discount API you have four possible targets:

  • cart.lines.discounts.generate.run: discount logic to apply discounts to cart lines and order subtotal

  • cart.lines.discounts.generate.fetch: (optional, requires network access) retrieves data needed for cart discounts, including validation of discount codes

  • cart.delivery-options.discounts.generate.run: discount logic to apply discounts to shipping and delivery options

  • cart.delivery-options.discounts.generate.fetch: (optional, requires network access) retrieves data needed for delivery discounts, including validation of discount codes

Each function target is composed of:

  • A GraphQL query that fetches the input used by the logic. This information is present in the "Input" object in the GraphQL schema definition.

  • A Rust, Javascript, or Typescript implementation of the function logic. This logic has to return a JSON object that adheres to the shape of the "FunctionResult" object in the GraphQL schema definition. Some examples:

    • for a "run" target, the return object is "FunctionRunResult"

    • for a "fetch" target, the return object is "FunctionFetchResult"

    • for a "cart.lines.discounts.generate.run" target, the return object is "CartLinesDiscountsGenerateRunResult"

IMPORTANT: If the user doesn't specify a programming language, use Rust as the default.

Think about all the steps required to generate a Shopify function:

  1. Search the developer documentation for relevant examples, making sure to include the programming language the user has chosen. Pay extreme attention to these examples when writing your solution. THIS IS VERY IMPORTANT.

  2. Think about what I am trying to do and choose the appropriate Function API.

  3. If the user wants to create a new function make sure to run the Shopify CLI command shopify app generate extension --template <api_lowercase_and_underscore> --flavor <rust|vanilla-js|typescript> --name=<function_name>. Assume that the Shopify CLI is installed globally as shopify.

  4. Then think about which targets I want to customize.

  5. For each target, think about which fields I need to fetch from the GraphQL input object. You can:

    • Look at the GraphQL schema definition (schema.graphql) inside the function folder if it exists

    • Explore available fields and types in the function's GraphQL schema to understand what data is accessible

  6. Then think about how to write the Rust, Javascript, or Typescript code that implements the function logic.

  7. Pay particular attention to the return value of the function logic. It has to match the shape of the "FunctionResult" object in the GraphQL schema definition.

  8. Make sure to include a src/main.rs if you are writing a Rust function.

  9. You can verify that the function builds correctly by running shopify app function build inside the function folder

  10. You can test that the function runs with a specific input JSON by running shopify app function run --input=input.json --export=<export_name> inside the function folder. You can find the correct export name by looking at the export field of the target inside the shopify.extension.toml

  11. After creating an app or adding or changing an app extension in a local project, run shopify app dev to test the changes in a development store. Follow the command output to continue.

IMPORTANT: DO NOT DEPLOY the function for the user. Never ever ever run shopify app deploy.

Naming Conventions

  1. Identify the Target and Output Type: Look at the expected output type for the function target (e.g., FunctionRunResult, CartLinesDiscountsGenerateRunResult). The "target" is usually the last part (e.g., Run, GenerateRun).

  2. Determine the Function Name:

  • Simple Output Types: If the output type follows the pattern Function<Target>Result (like FunctionRunResult), the function name is the lowercase target (e.g., run()).

  • Complex Output Types: If the output type has a more descriptive prefix (like CartLinesDiscountsGenerateRunResult), the function name is the snake\_case version of the prefix and target combined (e.g., cart_lines_discounts_generate_run()).

  1. Determine File Names:

  • Rust/JavaScript File: Name the source code file based on the function name: src/<function_name>.rs or src/<function_name>.js.

  • GraphQL Query File: Name the input query file similarly: src/<function_name>.graphql. e.g. src/fetch.graphql or src/run.graphql IMPORTANT: DO NOT name the file src/input.graphql.

  • For Rust, you must ALWAYS generate a src/main.rs file that imports these targets.

Examples:

  • Output: FunctionFetchResult -> Target: Fetch -> Function: fetch() -> Files: src/fetch.rs, src/fetch.graphql

  • Output: FunctionRunResult -> Target: Run -> Function: run() -> Files: src/run.rs, src/run.graphql

  • Output: CartLinesDiscountsGenerateRunResult -> Target: CartLinesDiscountsGenerateRun -> Function: cart_lines_discounts_generate_run() -> Files: src/cart_lines_discounts_generate_run.rs, src/cart_lines_discounts_generate_run.graphql IMPORTANT: You MUST look at the OutputType when determining the name otherwise the function will not compile

Some function type supports multiple "targets" or entry points within the same schema. For these you MUST generate the input query, function code, and sample outputs for EACH target. For example:

  • fetch and run for delivery customizations

  • fetch and run for pickup point customizations

  • cart and delivery for discounts

Best practices for writing GraphQL operations

  • Pay careful attention to the examples when choosing the name of the GraphQL query or mutation. For Rust examples, it MUST be Input.

  • When choosing an enum value:

    • Only use values defined in the schema definition. DO NOT MAKE UP VALUES.

    • Use the pure enum value unchanged, without namespace or quote wrapping, for example for the CountryCode enum just use US instead of "US" or CountryCode.US.

  • When choosing a scalar value:

    • Float does not need to be wrapped in double quotes.

    • UnsignedInt64 needs to be wrapped in double quotes.

  • When reading GraphQL if a field is BuyerIdentity! (it means it's required) if it's BuyerIdentity (no !) then it is NOT required.

  • If a field is OPTIONAL (It does not have a ! at the end such as BuyerIdentity) in the input data, then it MUST be unwrapped to handle the optional case when using Rust.

  • If a field is OPTIONAL in the output data, then you must wrap that output in Some() when using Rust.

  • You cannot write the same field twice. Use different aliases if you need to fetch the same field twice, i.e. when you need to pass different args.

  • Only use properties that are defined in the schema definition. DO NOT MAKE UP PROPERTIES UNDER ANY CIRCUMSTANCES.

  • GraphQL requires you to select specific fields within objects; never request an object without field selections (e.g., validation { } is invalid, you must specify which fields to retrieve).

  • Only select the fields required to fulfill the business logic of your function

How to help with Shopify functions

If a user wants to know how to build a Shopify function make sure to follow this structure:

  1. example of the shopify cli command shopify app generate extension --template <api_lowercase_and_underscore> --flavor <rust|vanilla-js|typescript>

  2. example of function logic in Rust, Javascript, or Typescript. This logic has to use the input data fetched by the GraphQL query. Include tests. This is a MUST. Include file names. If the function type supports multiple targets, provide code and tests for each target.

  3. example of GraphQL query to fetch input data. The query name must follow the naming convention of the target RunInput as an example for JavaScript implementations and must be Input for Rust implementations. Include file names. If the function type supports multiple targets, provide a query for each target (e.g., src/fetch.graphql, src/run.graphql). DO NOT NAME IT input.graphql

  4. example of JSON input returned by the GraphQL query. Make sure that every field mentioned by the GraphQL query has a matching value in the JSON input. When you make a fragment selection ... on ProductVariant you MUST include __typename on Merchandise, or Region. THIS IS IMPORTANT. If the function type supports multiple targets, provide sample input JSON for each target.

  5. example of a JSON return object. Make sure this is the output JSON that would be generated by the JSON input above. If the function type supports multiple targets, provide sample output JSON for each target.

If a function cannot be accomplished with any of the Function APIs simply return a message that it can't be completed, and give the user a reason why. Example reasons why it can't:

  • You cannot remove an item from cart

  • You cannot access the current date or time

  • You cannot generate a random value

Important notes for Input Queries

It's not possible to fetch tags directly, you must use either hasAnyTag(list_of_tags), which return a boolean, or hasTags(list_of_tags), which return a list of { hasTag: boolean, tag: String } objects. When using any graphql field that tags arguments YOU MUST pass in those arguments into your input query ONLY, you may set defaults in the query. DO NOT USE THESE ARGUMENTS IN THE RUST CODE. When you make a fragment selection ... on ProductVariant you MUST include **typename on the parent field otherwise the program will not compile. e.g. regions { **typename ... on Country { isoCode }}

query Input($excludedCollectionIds: [ID!], $vipCollectionIds: [ID!]) {
  cart {
    lines {
      id
      merchandise {
        __typename
        ... on ProductVariant {
          id
          product {
            inExcludedCollection: inAnyCollection(ids: $excludedCollectionIds)
            inVIPCollection: inAnyCollection(ids: $vipCollectionIds)
          }
        }
      }
    }
  }
}

Important notes for Javascript function logic

  • the module needs to export a function which is the camel cased version of the name as the target, i.e. 'export function fetch' or 'export function run' or 'export function cartLinesDiscountsGenerateRun'

  • the function must return a JSON object that adheres to the shape of the "FunctionResult" object in the GraphQL schema definition.

Important notes for Rust function logic

  • Don't import external crates (like rustdecimal or chrono or serde), the only ones allowed are shopify_function. i.e. use shopify_function::; is ok, but use chrono::_; and serde::Deserialize is not.

  • Decimal::from(100.0) is valid, while Decimal::from(100) is not. It can only convert from floats, not integers or strings otherwise the program will not compile.

  • make sure to unwrap Options when the field is marked as optional in the GraphQL schema definition. The rust code will generate types based on the GraphQL schema definition and will fail if you get this wrong. THIS IS IMPORTANT.

  • make sure to be careful when to use float (10.0), int (0), or decimals ("29.99")

  • If a field is OPTIONAL (It does not have a ! at the end) in the input data, then it MUST be unwrapped to handle the optional case. For example, access buyeridentity like this: if let Some(identity) = input.cart().buyer_identity() { / use identity _/ } or using methods like as_ref(), and_then(), etc. Do NOT assume an optional field is present.

  • If a field is OPTIONAL in the output data, then you must wrap that output in Some().

  • If doing a comparison against an OPTIONAL field you must also wrap that value. For example, comparing an optional product_type: Option<String> field with the string literal "gift card" should be done like this: product_type() == Some("gift card".to_string())

  • If a value has an ENUM then you must use the Title Case name of that enum, like PaymentCustomizationPaymentMethodPlacement::PaymentMethod

  • Decimal values do not need to be .parse(), they should be as_f64(). You cannot do comparisons with Decimal like < or >. Once you decide to use as_f64() assume it will return a f64, DO NOT USE as_f64().unwrap_or(0.0)

  • When handling oneOf directives you must include :: and the name of the oneOf, for example schema::Operation::Rename

  • If a field uses arguments in the input query, in the generated rust code you will only get the field name, not the arguments.

  • When accessing fields from the generated code, DO NOT add arguments to methods that don't take any in the GraphQL schema. For example, use input.cart().locations() NOT input.cart().locations(None, None). Method signatures match exactly what's defined in the GraphQL schema.

  • All of the Structs are generated by concatenating names. for example schema::run::input::Cart instead of schema::input::Cart, and schema::run::input::cart::BuyerIdentity, every layer of the query must be represented, starting with the module annotated with #[query], then the operation name (Root if an anonymous query), then all nested fields and inline fragment type conditions. For example, if in the graphql query you have query Input { cart { lines { merchandise { ... on ProductVariant { id } } } } } on a run module, then the Rust structs will be schema::run::input::cart::lines::Merchandise::ProductVariant, schema::run::input::cart::lines::Merchandise (an enum with a ProductVariant variant), schema::run::input::cart::Lines, schema::run::input::Cart, and schema::run::Input.

  • When working with fields that have parentheses in their names (like hasany_tag, etc.), they are returned as &bool references. You need to dereference them when making comparisons. For example: if _variant.product().has_any_tag() { / do something */ } or simply use them directly in conditions where Rust will auto-dereference.

  • Each target file (not main.rs) should start with these imports:

use crate::schema;
use shopify_function::prelude::*;
use shopify_function::Result;
  • You must never import serde or serde_json or it will not compile. Do not use serde (bad) or use serde::Deserialize (bad) or serde::json (bad)

  • You must make sure in a match expression that you must include the _ wildcard pattern for any unspecified cases to ensure exhaustiveness

  for line in input.cart().lines().iter() {
    let product = match &line.merchandise() {
        schema::run::input::cart::lines::Merchandise::ProductVariant(variant) => &variant.product(),
        _ => continue, // Do not select for CustomProduct unless it's selected in the input query
    };
    // do something with product
}

or if you want to extract the variant you can do this:

    let variant = match &line.merchandise() {
        schema::run::input::cart::lines::Merchandise::ProductVariant(variant) => variant,
        _ => continue, // Do not select for CustomProduct unless it's selected in the input query
    };
    // do something with variant

Do not use .as_product_variant() it is not implemented

Configuration

BY DEFAULT, make the function configurable by storing the configurable data elements in a jsonValue metafield. Access this metafield via the discount.metafield or checkout.metafield field in the input query (depending on the function type). Deserialize the JSON value into a configuration struct within your Rust code.

Example accessing a metafield in Rust: Note only use the #[shopify_function(rename_all = "camelCase")] if you plan on using someValue: "" and anotherValue: "" as part of your jsonValue metafield. By default do not include it. Only use #[derive(Deserialize, Default, PartialEq)] (good) do NOT use #[derive(serde::Deserialize)] (bad)

#[derive(Deserialize, Default, PartialEq)]
#[shopify_function(rename_all = "camelCase")]
pub struct Configuration {
    some_value: String,
    another_value: i32,
}

// ... inside your function ...
    let configuration: &Configuration = match input.discount().metafield() {
        Some(metafield) => metafield.json_value(),
        None => {
            return Ok(schema::CartDeliveryOptionsDiscountsGenerateRunResult { operations: vec![] })
        }
    };

// Now you can use configuration.some_value and configuration.another_value

Example GraphQL Input Query:

query Input {
  discount {
    # Request the metafield with the specific namespace and key
    metafield(namespace: "$app", key: "config") {
      jsonValue # The value is a JSON string
    }
  }
  # ... other input fields
}

Additional Important Notes

Testing

When writing tests, you must only import the following

  use super::*;
  use shopify_function::{run_function_with_input, Result};
Sample Data Generation

When generating sample data, anywhere there is an ID! make sure to use a Shopify GID format:

"gid://Shopify/CartLine/1"
Scalar Types

These are the scalar types used in Rust functions:

pub type Boolean = bool;
pub type Float = f64;
pub type Int = i32;
pub type ID = String;
pub use decimal::Decimal;
pub type Void = ();
pub type URL = String;
pub type Handle = String;

pub type Date = String;
pub type DateTime = String;
pub type DateTimeWithoutTimezone = String;
pub type TimeWithoutTimezone = String;
pub type String = String; # This must not be a str, do not compare this with "" or unwrap_or("")

src/main.rs for Rust Functions - REQUIRED

When implementing Shopify functions in Rust, you MUST include a src/main.rs file. This is the entry point for the function and should have the following structure, making sure it has one query for each target. If you have a jsonValue in the input query it should be mapped to a struct. If there is no jsonValue do not include a custom_scalar_overrides.

use std::process;
use shopify_function::prelude::*;

// CRITICAL: These module imports MUST match your target names exactly
pub mod run;     // For "run" target
pub mod fetch;   // For "fetch" target

#[typegen("./schema.graphql")]
pub mod schema {
      // CRITICAL: The query path filename MUST match your target name
      // CRITICAL: The module name MUST match your target name
      #[query("src/run.graphql", custom_scalar_overrides = {"Input.paymentCustomization.metafield.jsonValue" => super::run::Configuration})]
      pub mod run {}  // Module name matches the target name

      #[query("src/fetch.graphql")]
      pub mod fetch {} // Module name matches the target name
}

fn main() {
    log!("Please invoke a named export.");
    process::abort();
}

Ensure examples follow best practices, correct enum usage, and proper handling of optional fields. </system-instructions>

Always use Shopify CLI
  • CLI: ALWAYS use Shopify CLI to scaffold and manage functions. Never hand-roll files. Key commands: shopify app generate extension, shopify app function build, shopify app function run, shopify app function schema, shopify app function typegen.

  • For CLI installation, setup, upgrade, or troubleshooting, use use-shopify-cli.

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter, Needs Node.js

The author says: Requires Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Shopify
Publisher
Shopify (Official)
Source
Shopify/Shopify-AI-Toolkit · skills/shopify · commit a3d20f8
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Shopify or Shopify.

Get it from the source

93 of this skill’s files are not mirrored here, so there is no ZIP. Get the complete skill from its source: Shopify/Shopify-AI-Toolkit