awin-application-auto-approval

---
name: awin-application-auto-approval
description: |
  Use this skill when an agency operator wants to work through a brand's pending Awin publisher applications and approve or decline them in one assisted batch. The pending queue is read from the Awin API; the approve or decline click is carried out in the operator's own authenticated Awin session through Claude-in-Chrome, because Awin exposes no public approve/decline endpoint. Decisions follow the brand's recorded strategy only, and the whole batch runs against a single explicit human confirmation.
  Trigger on: "approve pending Awin publishers for Acme", "work through Acme's Awin application queue", "auto-approve Awin applicants for [brand]", "clear the Awin pending publishers for Acme".
---

# Operating instructions

You work through one brand's pending Awin publisher applications and carry out an
approve or decline for each, in an assisted batch. The pending queue is the
verified source and is read from the Awin API. The approve or decline itself is a
click Awin gives no API for, so it happens in the operator's own authenticated
Awin session through Claude-in-Chrome. You decide approve, decline, or ask using
only the brand's recorded advisory strategy, you show the operator the full batch,
and you execute only after one explicit confirmation of the whole set.

This skill is assisted, not unattended. It never invents an approval rule and
never records a result the browser consumer did not observe at the verify
target.

## Step 1 — resolve the brand

If the operator did not name a brand, ask which one. One brand per run.

Call `affiliate_resolve_brand`. If the operator named the network, pass
`{ network: "awin-advertiser" }`; otherwise call with no arguments and filter the
result to the named brand. The response is an array of
`{ brand, network, networkBrandId }`. Keep only the binding whose `network` is
`awin-advertiser` and whose `brand` matches.

If there is no `awin-advertiser` binding for the brand, say the brand is not
registered for Awin advertiser, suggest `affiliate_resolve_brand` with no
arguments to see what is, and stop.

## Step 2 — confirm readiness

Confirm the write actions are usable before reading anything else:

1. Call `affiliate_list_actions({ brand, network: "awin-advertiser", effect: "write" })`
   and check that `approvePublisher` and `declinePublisher` report `ready`.
2. Call `affiliate_run_diagnostic` for the brand's Awin advertiser binding to
   confirm live auth.

If readiness is `missing_credentials` or `unsupported`, or the diagnostic shows
auth is not working, report exactly what is missing and stop. Do not proceed to
read the queue or open a browser.

## Step 3 — read the pending queue from the API

Read the queue from the API, never the dashboard:

Call `affiliate_awin-advertiser_list_media_partners({ brand })`, passing `brand`
exactly as it came back from `affiliate_resolve_brand`. Keep only the partners
whose `status` is `pending`.

State plainly that the API is the verified source of the queue and that the
browser is used later only for the approve or decline click Awin exposes no API
for. If the call fails, surface the verbatim envelope (network, operation,
message, httpStatus) and stop. Never treat a failure as an empty queue.

If the queue is genuinely empty, say there are no pending applications and stop.

## Step 4 — read the advisory strategy

Call `affiliate_get_client_strategy({ brand })`.

Treat `strategy` prose and `kpi.targets` as advisory context only. They shape
which applicants you propose to approve or decline; they never authorise a write.
If `kpi.parseErrors` is non-empty, report each malformed line verbatim and
exclude it from your reasoning. Never guess what a malformed line meant.

If no strategy is recorded, say so. You may still run, but every applicant the
strategy does not cover becomes an **ask** in Step 5.

## Step 5 — build the proposed decision set

For each pending applicant, decide approve, decline, or **ask**, using only the
recorded strategy:

- **Approve** when the recorded strategy clearly endorses this applicant's type,
  region, or promotion method.
- **Decline** when the recorded strategy clearly excludes it (for example a
  deprioritised partner type or a brand-safety rule it breaks).
- **Ask** when the strategy is silent, the applicant's type, region, or promotion
  method is not covered, or a KPI line that would have decided it failed to
  parse. Surface each ask with the reason it could not be decided.

Never invent an approval rule. Where the strategy does not speak, the answer is
ask, not a guessed approve or decline.

## Step 6 — show the batch and get one confirmation

Show the operator the full batch as a table: applicant name and id, the proposed
decision, and the strategy line that justifies it (or "needs your decision" for
an ask).

Resolve every **ask** with the operator first. Then get ONE explicit
confirmation of the whole set before any execution. This single confirmation is
the Tier-3 human gate that authorises the batch. Do not execute any decision
before it, and do not re-prompt per applicant after it.

## Step 7 — execute each confirmed decision

For each confirmed decision, in turn:

### 7a — emit the handoff

Call
`affiliate_awin-advertiser_propose_publisher_decision({ brand, programmeId, publisherId, publisherName, decision, declineReason? })`.
It returns an `ApiGapResponse` carrying a `BrowserHandoff` and records a
`handoff_emitted` audit line. Pass `declineReason` only for a decline the
operator gave a reason for.

### 7b — carry out the handoff in the browser

Drive Claude-in-Chrome to carry out the handoff, honouring
`browserFallback.constraints` exactly:

- Navigate ONLY to `browserFallback.startingUrl` using
  `mcp__Claude_in_Chrome__navigate`. Do not navigate anywhere else.
- Locate the named publisher row and confirm it is pending, using
  `mcp__Claude_in_Chrome__read_page`, `mcp__Claude_in_Chrome__get_page_text`, or
  `mcp__Claude_in_Chrome__find`.
- Click approve or decline and, if `inputs.declineReason` is present, enter it,
  using `mcp__Claude_in_Chrome__computer` or `mcp__Claude_in_Chrome__form_input`.

Operate only on the named `publisherId`. Skip any row that is not in a pending
state; it may already be decided, and you must not repeat a completed mutation.
Stop and hand back to the operator on any login, MFA, or re-authentication
challenge. Never touch payment, payout, commission, or contract fields. Never
tick a consent or terms box the operator has not seen. If the approve or decline
control is missing, stop and report it.

### 7c — verify and close the arc

Revisit `browserFallback.verify.url` and check `browserFallback.verify.expect`
(the applicant should no longer be pending). Then record the observed outcome by
calling
`affiliate_awin-advertiser_report_publisher_decision_result({ brand, programmeId, publisherId, decision, verified, note? })`
with `verified: true` when the verify target showed the expected state, or
`verified: false` when it did not. This records `verified` or `verify_failed` and
closes the `handoff_emitted -> verified | verify_failed` arc. Never report a
result the verify target did not actually show.

## Step 8 — summarise

Summarise the run: how many were approved, declined, asked, and failed to verify,
each by applicant name and id. Remind the operator that the browser actions ran
in their own authenticated Awin session.

Matter-of-fact tone, UK spelling, no hype.

## Constraints

- Assisted batch approve, not unattended. A human resolves every ask and confirms
  the whole set.
- The single batch confirmation is the only authority to execute. It is the
  Tier-3 human gate; nothing runs before it.
- Strategy is advisory. It shapes the proposed decisions; it never authorises a
  write.
- Ask when the strategy is silent. Never invent an approval rule and never guess
  a decision the strategy did not support.
- Never invent applicants or pad the queue. An unreadable queue is a surfaced
  failure, not zero pending.
- One brand per run, Awin advertiser only.
- The queue read is the API (the verified source). Execution is the browser, in
  the operator's own authenticated session.
- Never record a result the browser consumer did not observe at the verify
  target. Close each handoff only as `verified` or `verify_failed`, never as
  applied.