--- name: onesignal-campaign-message-audit description: Audit OneSignal message history and templates as a read-only retrospective, checking what went out, to which audience, on which template, and what is missing (no template, unclear audience, unclear send window, no record of approval). Use when the user asks to review past campaigns, check what was sent last week, find messages with no template or segment, or prepare a post-send review. Do not use it to plan a new send. --- # Audit past OneSignal messages This is a retrospective. The question is: **what went out, to whom, and does the record show that it was intended and controlled?** Planning a new send is a different job. If the user wants a new message, say so and stop; this skill only reads. The strongest findings are missing things: a message with no traceable template, an audience that cannot be identified, a send that happened outside the window someone agreed. Look for absence as hard as you look for errors. ## 1. Set the scope before listing anything Confirm with the user before pulling data: - **Which app.** Every call is app-scoped. If the account has more than one app, state the app name in your report, and do not mix results from two apps. - **Time window.** Message lists are large. Pick a window (for example the last 30 days) and say it in the output. Do not audit "everything". - **Which channels.** Push, email, SMS and in-app are reviewed differently. Ask if it matters; otherwise cover all and label them. ## 2. Pull the message history in pages Use `list_messages` with the window and channel filter. Work through pages and keep a running tally rather than reading every row into your answer. Record per message: id, name or title, channel, status, sent or scheduled time, and whatever audience and template fields the response returns. If the response is empty, check the window and the app first. An empty result is usually a wrong filter, not a clean record. Say which filter you checked. ## 3. Sort messages into the review buckets Apply these checks to each message and count how many fall in each: | Bucket | What it means | Why it matters | |---|---|---| | **Untemplated** | Sent without a template reference, so the copy cannot be traced to an approved version | Copy may have been typed ad hoc under deadline | | **Unidentifiable audience** | Audience cannot be tied to a named segment or filter | Nobody can say who received it, so opt-out and complaint checks are impossible | | **Broad audience** | Sent to all subscribers or a very large group with no segment | High risk of irrelevant or non-consented sends | | **Off-window** | Sent outside the window the team agreed (quiet hours, a freeze, a holiday) | Customer experience and policy problem | | **Test leaked** | Name or audience suggests a test ("TEST", "dummy", internal list) reached real users | Serious; check the audience count | | **Clean** | Template, audience and timing all traceable | Baseline | Do not label something "untemplated" just because a field is empty in the response. If the field was not returned at all, the bucket is **not established**, not a finding. ## 4. Check the template behind each templated message For each distinct template referenced, call `get_template` and check: - The template still exists and is not a copy of an older version with a different name. - Required fields (title, body, links) are populated. An empty body that still sent is a defect. - The template's content matches the message's stated purpose. A promotional template on a transactional name is a finding. Group by template. A template used in ten messages with one defect is one finding with ten instances. ## 5. Read patterns, not just rows Look for shapes that a single row hides: - **Repeated sends** of the same message to the same audience close together: a scheduling loop or a re-trigger. - **Sudden volume spikes** on one day: check for a backfill or a mistaken bulk send. - **Messages sent by one name on many dates** with no template: a person working around the process, which is a process finding, not a blame finding. - **Scheduled messages that show as sent**, or drafts that show as sent: status confusion. ## 6. Keep the retrospective honest Report what the record shows. Where the record cannot show something (who approved a send, whether a segment was edited after the send), write it under "Not established". Do not infer approval from the fact that a message exists. ## Common patterns and traps - **Confusing scheduled with sent.** A message scheduled for 09:00 tomorrow is not a send. Check the status field and the actual sent time. - **Trusting audience counts without the window.** A count can be the current audience, not the audience at send time. Say which, if the response does not make it clear. - **Treating a clean list as proof of control.** The list shows what the system recorded. Gaps in the record are themselves the finding. - **Chasing individual names.** Frame process gaps as process gaps. The useful output is a fix for the workflow, not a list of people to blame. - **Auditing a test app as production.** Check the app name first. - **Ignoring pagination.** A first page that looks complete may not be. Confirm you reached the end before counting. ## Output ``` App: Window: to Channels: Messages reviewed: Templates checked: Buckets - Clean: - Untemplated: (examples: ) - Unidentifiable audience: - Broad audience: - Off-window: - Test leaked: Template defects -