programme-health-check

---
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:

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.