con un clic
shopify-admin-chargeback-watchlist-tagger
// Identifies customers with disputed or charged-back orders and tags their customer record for proactive review on future orders.
// Identifies customers with disputed or charged-back orders and tags their customer record for proactive review on future orders.
| name | shopify-admin-chargeback-watchlist-tagger |
| role | customer-ops |
| description | Identifies customers with disputed or charged-back orders and tags their customer record for proactive review on future orders. |
| toolkit | shopify-admin, shopify-admin-execution |
| api_version | 2025-01 |
| graphql_operations | ["orders:query","customerUpdate:mutation"] |
| status | stable |
| compatibility | Claude Code, Cursor, Codex, Gemini CLI |
Scans historical orders for any associated chargeback or dispute, then tags the customer record with chargeback-history (configurable). Future orders from these customers can be filtered or held for manual review by ops. Reduces repeated chargeback losses without blocking customers outright. Defaults to dry_run: true.
shopify store auth --store <domain> --scopes read_orders,read_customers,write_customersread_orders, read_customers, write_customers| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
| store | string | yes | — | Store domain (e.g., mystore.myshopify.com) |
| days_back | integer | no | 730 | Historical window to scan for disputes (2 years default) |
| watchlist_tag | string | no | chargeback-history | Tag applied to flagged customers |
| include_won_disputes | bool | no | false | If false, only tag customers whose disputes were lost or are open |
| dry_run | bool | no | true | Preview without applying tags |
| format | string | no | human | Output format: human or json |
⚠️
customerUpdatemodifies customer tags that are visible to staff and may drive segmentation rules. Tag a customer incorrectly and you may downgrade their experience or block their orders. Run withdry_run: truefirst and review the list before committing. Won disputes (where the merchant won) are excluded by default to avoid false positives.
OPERATION: orders — query
Inputs: query: "created_at:>='<NOW - days_back days>' chargeback_status:*" (any chargeback state), first: 250, select disputes { id, status, initiatedAs, finalizedOn }, customer { id, displayName, tags, defaultEmailAddress { emailAddress } }, totalPriceSet, pagination cursor
Expected output: All orders that have at least one dispute in the window
Group disputes by customer. For each customer:
WON and include_won_disputes: falsewatchlist_tagOPERATION: customerUpdate — mutation
Inputs: input: { id, tags: [<existing tags>, watchlist_tag] } for each queued customer
Expected output: Updated customer with new tag list; userErrors
If dry_run: true, do not call mutation — just report the queue.
# orders:query — validated against api_version 2025-01
query OrdersWithDisputes($query: String!, $after: String) {
orders(first: 250, after: $after, query: $query) {
edges {
node {
id
name
createdAt
totalPriceSet {
shopMoney {
amount
currencyCode
}
}
disputes {
id
status
initiatedAs
finalizedOn
}
customer {
id
displayName
defaultEmailAddress {
emailAddress
}
numberOfOrders
amountSpent {
amount
currencyCode
}
tags
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
# customerUpdate:mutation — validated against api_version 2025-01
mutation TagChargebackCustomer($input: CustomerInput!) {
customerUpdate(input: $input) {
customer {
id
tags
}
userErrors {
field
message
}
}
}
Claude MUST emit the following output at each stage. This is mandatory.
On start, emit:
╔══════════════════════════════════════════════╗
║ SKILL: Chargeback Watchlist Tagger ║
║ Store: <store domain> ║
║ Started: <YYYY-MM-DD HH:MM UTC> ║
╚══════════════════════════════════════════════╝
After each step, emit:
[N/TOTAL] <QUERY|MUTATION> <OperationName>
→ Params: <brief summary of key inputs>
→ Result: <count or outcome>
If dry_run: true, prefix every mutation step with [DRY RUN] and do not execute it.
On completion, emit:
For format: human (default):
══════════════════════════════════════════════
CHARGEBACK WATCHLIST (<days_back> days)
Orders with disputes: <n>
Unique customers: <n>
Disputes lost/open: <n>
Disputes won (excluded): <n>
Already tagged: <n>
─────────────────────────────
Customers to tag: <n>
Tags applied: <n> (or [DRY RUN] would apply)
Errors: <n>
Output: chargeback_watchlist_<date>.csv
══════════════════════════════════════════════
For format: json, emit:
{
"skill": "chargeback-watchlist-tagger",
"store": "<domain>",
"dry_run": true,
"orders_with_disputes": 0,
"unique_customers": 0,
"customers_to_tag": 0,
"tags_applied": 0,
"errors": 0,
"output_file": "chargeback_watchlist_<date>.csv"
}
CSV file chargeback_watchlist_<YYYY-MM-DD>.csv with columns:
customer_id, email, name, dispute_count, latest_dispute_status, latest_dispute_initiated_as, total_disputed_amount, currency, existing_tags, tag_to_apply, action
| Error | Cause | Recovery |
|---|---|---|
THROTTLED | API rate limit exceeded | Wait 2 seconds, retry up to 3 times |
userErrors on customerUpdate | Customer not found / archived | Log error, skip, continue |
| Order without a customer | Guest checkout dispute | Cannot tag — record in CSV with action: skipped_guest |
Dispute with status null | Very recent dispute, not yet categorized | Treat as open / not won |
dry_run: true and audit the CSV — false positives damage customer trust.watchlist_tag with a Shopify Flow or order-routing rule that holds new orders from tagged customers for manual approval.include_won_disputes: false (default). If you won, the bank ruled in your favor — do not penalize the customer.Master skill collection for Shopify store operators. Provides access to all merchandising, marketing, support, and operations capabilities.
Read-only: identifies products with high single-purchase rates that could benefit from cross-sell pairing based on category and price affinity.
Read-only: calculates the true ROI of each discount code and automatic discount by comparing incremental revenue against discount cost.
Read-only: mines order history to find product pairs and triplets frequently purchased together, generating cross-sell and bundle recommendations.
Read-only: extracts gift messages, gift recipients, and gift flags from order custom attributes and notes for fulfillment teams to print on packing slips.
Read-only: identifies orders 7–14 days post-fulfillment that are eligible for a post-purchase survey campaign, excluding refunded or cancelled orders.