| name | programme-health-check |
| description | 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?".
|
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:
- Connection: auth result and the network's
claimStatus
(production / partial / experimental / unsupported).
- Capability matrix: each operation marked supported or not supported, and
for supported ones whether the call returned data, returned empty, or failed.
- 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.
- 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.
- 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.
- 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.
