agentsclimarketplace
Sign in

Programme health check

Skill bobberrisford/affiliatemcp/skills/programme-health-check

Use this skill for a one-off diagnostic across every available data operation for a brand, typically at account handover or kick-off: is the connection healthy, what can we actually read, is data flowing, and where are the gaps. It is the "audit the account before we start" pass, not a recurring report. Trigger on: "Audit Acme's programme", "Health-check the Acme account", "Run a full check on [brand]", "We just won Acme, what can we see?", "Is the Acme connection working end to end?".From its SKILL.md

Install
npx -y skills add bobberrisford/affiliatemcp --skill programme-health-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.3 KB, as published. Nobody here has run it

Operating instructions

You are running a one-off health check on a brand's programme: confirm the connection works, map what each bound network can read, exercise every supported read operation once, and report data presence and gaps. This is a handover or kick-off diagnostic. For the recurring "how is the brand doing" view use programme-performance-report; for the week-over-week scan use programme-anomaly-watch.

Step 1 — resolve the brand

If the user did not name a brand, ask which one. Do not guess.

Call affiliate_resolve_brand. If the user named a network, pass { network: "<slug>" } to filter; otherwise call with no arguments and filter the result to the brand the user named.

The response is an array of { brand, network, networkBrandId }. Reduce it to the bindings whose brand matches the user's brand. If none remain, tell the user the brand is not registered, suggest affiliate_resolve_brand with no args to see what is, and stop.

Step 2 — confirm the connection and read capabilities

For the brand's bindings, confirm health and capability before pulling data:

  • Call affiliate_run_diagnostic for the configured networks, or affiliate_<network>_verify_auth per binding, to confirm credentials work. Awin advertiser: affiliate_awin-advertiser_verify_auth.
  • Call affiliate_list_networks once and retain each binding's metadata: network claimStatus, knownLimitations, and any per-operation claim-status overrides. Use the diagnostic result's operations object as the source of truth for supported / unsupported operations.

If auth fails for a binding, record it as a red flag and skip that binding's data pulls; do not retry around a failed credential.

Step 3 — exercise each supported read operation once

For every binding, call each brand-scoped data operation the diagnostic says the network supports, once, over a recent window (default last 30 days, ending today). Skip operations the network does not support and record them as "not supported" rather than calling them. Tool names follow affiliate_<network>_<operation>. At minimum, cover these when supported:

  • Programmes: affiliate_awin-advertiser_list_programmes({ brand })
  • Per-publisher performance: affiliate_awin-advertiser_get_programme_performance({ brand, from, to })
  • Roster: affiliate_awin-advertiser_list_media_partners({ brand })
  • Transactions (where supported): affiliate_awin-advertiser_list_transactions({ brand, from, to })

Pass brand exactly as it came back from affiliate_resolve_brand. For each call record three outcomes: it succeeded with data, it succeeded but returned nothing, or it failed (capture the verbatim envelope: network, operation, message, httpStatus). A success with no rows is a finding, not a failure.

Step 4 — present the health check

Output in this order, per network binding:

  1. Connection: auth result and the network's claimStatus (production / partial / experimental / unsupported).
  2. Capability matrix: each operation marked supported or not supported, and for supported ones whether the call returned data, returned empty, or failed.
  3. Data presence: a one-line note per successful operation — programme count, partner count by status, recent transaction count, whether any performance rows came back. Numbers only where the data shows them.
  4. Known limitations: surface each binding's knownLimitations verbatim (for example normalised-zero clicks, missing reversal reasons) so they are visible before the account team relies on a metric.
  5. Tracking-link check (manual): note that link tracking is not verified by this skill. If the operator wants live link verification, point them at the shipped audit-affiliate-links skill; do not claim this check ran.
  6. Red flags and gaps: failed auth, unsupported core operations, empty results that look wrong for a live programme, and any verbatim errors.

Close with a short plain-language verdict: is the account ready to report on, or are there gaps to resolve first.

Matter-of-fact tone, UK spelling, no hype. Keep the matrix compact.

Constraints

  • Read-only diagnostic. It never changes configuration or contacts a network beyond the read calls above.
  • Distinguish "not supported" (the adapter has no such operation) from "empty" (the call ran and returned nothing) from "failed" (an error envelope). Never collapse these into one state.
  • Never invent figures or capabilities. An unsupported operation is reported as unsupported, not as zero data.
  • Surface knownLimitations rather than hiding them; a healthy connection with a known metric gap is still a gap the account team must see.
  • Do not cite a tracking-link check as having run. Link verification is the separate audit-affiliate-links workflow.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.