Claude Code Skill

Atribu ships an opinionated Claude Code skill that teaches Claude how to reason about your attribution data. Once installed, the skill auto-loads whenever you ask about ROAS, campaigns, creatives, or customer journeys — Claude follows the skill's rules and calls the right MCP tools in the right order.

What the skill does

The MCP server returns raw data; the skill supplies the judgment:

• Cash-ROAS by default — the skill teaches Claude that revenue_type='cash' is the only thing that counts as ROAS. GHL pipeline deals are "deal value," not revenue.
• Tool ordering heuristics — for each common question ("which ads should I kill?", "why is ROAS dropping?", "who's converting?"), the skill specifies which MCP tools to call and in what order.
• Model guidance — when to use last_touch vs linear vs compare_attribution_models based on conversion volume and sales cycle.
• Write-back safety — mandatory preview → user-confirm → confirm-with-idempotency-key flow for send_meta_conversions.
• Onboarding order — the golden path from an empty workspace to a live CAPI destination, which step needs which, and which errors mean "a human has to act" (see Onboarding below).
• PII explanations — when you ask for unmasked data and your token can't provide it, Claude explains exactly what to change instead of silently returning masked values.

Onboarding

The skill's write-back section (below) is about a workspace that is already configured. This section is the other half: what to do when it is not, which since #1058 an agent can do end to end over MCP.

Every session starts with whoami. It costs 0 units and now carries a readiness summary — how many golden-path steps are done, which is next, and every step that is not done with the reason and the action that unblocks it. An empty dashboard is almost always a missing connection, not a missing result, and this is where that shows.

The order, and why it is the order

Each step needs the one before it. Skipping is what produces a configuration that looks finished and reports zeroes.

1. create_workspace — only when whoami shows none. You become the owner.
2. Write-back starts ON for a workspace create_workspace just created — no human has to flip anything before the write tools below will run. Only a workspace created some other way — in the console, or by a Shopify/partner-app install — can have it off: check whoami's active_workspace.mcp_writeback_enabled. If it is false, say so in one sentence and give the user the URL from the error's action_url; do not narrate the whole setting page.
3. create_profile — one advertiser/brand/client. Everything after this is scoped to it. (Or create_demo_profile, when the user wants to see the product working before connecting anything real.)
4. issue_tracking_key → get_tracker_installer — mint the key, then hand over the installer verbatim. Ask which surface first (snippet / gtm / shopify_pixel); guessing produces an install they cannot use.
5. start_connect({ provider }) — give the user the url exactly as returned, then poll get_handoff({ id }). Do not open it, do not shorten it, do not summarise it.
6. list_outcome_events → suggest_conversion_definitions → create_conversion_definition — read what the profile actually emits, propose from that, create what the user confirms. Never invent an event name.
7. set_attribution_windows — only if the customer's sales cycle needs it. It rewrites already-reported numbers, so say so before confirming. 7b. sign_dpa — Conversion Sync exports nothing until the DPA is accepted. You cannot sign it; hand over the URL. already_signed: true is a success — say so and move on rather than offering a link.
8. configure_meta_capi → send_test_event — the dataset and its rules, then one synthetic event the customer watches land in Events Manager.

Rules the skill enforces

• Preview, show, confirm. Every write tool takes mode. Run preview, put its will_call and (where present) its dry-run counts in front of the user in their own words, and only then confirm. Never confirm in the same turn you previewed unless the user already said yes to that exact thing.
• A same-name create_workspace replay from the same caller is safe within a short window — it returns created: false and the ORIGINAL workspace, never a second one. A different name is always a different workspace. If you did not read the outcome of a call, retry with the identical name rather than guessing a new one.
• Read the error CODE, not the prose. insufficient_scope → the token needs re-consent. insufficient_role → a human with an owner/admin role has to act; re-consenting cannot fix it. writeback_disabled → one setting, one URL. connector_required → start_connect. Each carries an action_url; give that link, do not describe the path.
• Only cash counts for ROAS. When creating a conversion definition for what the customer calls "sales" or "revenue", that is revenue_type: "cash". pipeline fills the funnel and contributes nothing to any ratio — a dashboard of zeroes with no error anywhere.
• A hand-off is the user's to complete. Poll get_handoff every few seconds; do not mint a second one while the first is pending; an expired status means mint a fresh one, a 404 means the id is wrong.
• A partial configure_meta_capi is not a success. It returns complete: false and failed_rules. Say which conversions will not reach Meta rather than reporting the destination as done.

Install

The skill is distributed as a Claude Code plugin from the public repo AtribuCore/atribu-attribution-skill.

/plugin marketplace add AtribuCore/atribu-attribution-skill
/plugin install atribu-attribution@atribu-attribution

What skills are available?

claude mcp add atribu --transport http \
  https://mcp.atribu.app/mcp \
  --header "Authorization: Bearer atb_user_YOUR_TOKEN"

Updating

When the skill is updated upstream, refresh with:

/plugin update atribu-attribution

Other MCP clients

Cursor, Claude Desktop, Windsurf, and other MCP-compatible tools use the same MCP server but don't have Claude Code's plugin system. Copy the contents of SKILL.md into your system prompt or project rules for equivalent behavior.

Skill structure

Inside the public repo, the plugin is laid out as:

atribu-attribution-skill/
├── .claude-plugin/marketplace.json     # Marketplace manifest
├── plugins/
│   └── atribu-attribution/
│       ├── .claude-plugin/plugin.json  # Plugin manifest
│       └── skills/atribu-attribution/
│           ├── SKILL.md                # Main instructions
│           ├── references/
│           │   ├── tool-ordering.md    # Detailed heuristics
│           │   └── error-playbook.md   # Error code handling
│           └── evals/evals.json        # Test cases
├── README.md
└── LICENSE                             # MIT

The main SKILL.md stays focused — the quick reference. When Claude needs deeper detail (error handling or tool selection), it reads files in references/ on demand. This follows Anthropic's recommendation to keep SKILL.md lean and lazy-load verbose material.

Evals

The skill ships with evals/evals.json — test cases with expected behavior. Each eval is a { prompt, expected_output, assertions } object that documents what Claude should do when the skill is loaded.

Example assertions:

• "Which ads should I kill?" → must call creative_fatigue_check first, then top_creatives
• "Show me actual email addresses" → must explain the three-condition PII requirement, not silently return masked data
• "Send conversions to Meta" → must call preview first, ask for user confirmation, generate an idempotency key, report the audit_id

Evals aren't automatically run by Claude Code — they're reference test cases for anyone modifying the skill. Use them as a regression checklist before changing SKILL.md.

Contributing

The skill is open source under MIT. If you find it giving bad guidance, open an issue or send a PR at AtribuCore/atribu-attribution-skill. Released versions are tagged so end users can pin if they want.

Related