gift-card-triage

name	gift-card-triage
description	Triage pending gift-card rewards from a rewards spreadsheet. Fetches rows where "Sent?" is empty, flags duplicates and prior rewards, identifies the reward program, and runs referral fraud checks. Use when the user asks for "pending gift cards", "gift card triage", "gift cards to send", "check gift card sheet", or "triage rewards".

Gift Card Triage

Triage pending gift-card reward requests from a rewards spreadsheet. Identifies new requests that need review, flags duplicates and prior rewards, and runs referral fraud checks to produce approve/deny/investigate verdicts.

Prerequisites

• A Google Workspace CLI that can read Sheets — either gog or gws. Check with which gog and which gws; if both are available, prefer gog.
• The referral-fraud-check skill — used to validate referrals.

Configuration

Set these in your .env (see .env.example):

• REWARDS_SHEET_ID — the spreadsheet ID backing the reward queue. This sheet contains PII (emails, names, tokens); keep it private.
• APPROVALS_CHANNEL_ID — optional Slack channel for posting the summary.

Workflow

Step 1: Fetch sheet data

Use the available Google Workspace CLI to fetch the rewards tab from $REWARDS_SHEET_ID as JSON, including the header row. Parse the first row as headers and locate columns by name (do not assume fixed positions). Typical columns: an email, a tier, a submission timestamp, a program name, a "Sent?" column (empty = not yet processed), a submitter name, and a token column (populated when sent).

Step 2: Separate pending vs. already-sent

• Pending: rows where "Sent?" is empty — these need triage.
• Already sent: rows where "Sent?" is non-empty — historical records.

Filter out redacted rows (where the email is blank or masked).

Step 3: Flag duplicates

Flag duplicate submissions in the pending set (same email + same tier); only one reward should be sent per email+tier.

Step 4: Check prior rewards

For each pending email, check whether it also appears in the already-sent set and note which tiers were already fulfilled, to avoid double-sending.

Step 5: Identify the program

Group pending requests by their program column (e.g. referral tiers vs. non-referral rewards like surveys or interviews). Referral tiers need a fraud check; non-referral rewards just need a real/active-user check.

Step 6: Run referral fraud checks

Collect the unique pending emails and run the referral-fraud-check skill (read that skill for the workflow — it spawns a cloud agent with warehouse access). Pass all emails in one batch; each returns APPROVE / DENY / INVESTIGATE.

Step 7: Present results

Summarize by verdict (DENY, INVESTIGATE, APPROVE). For each email include the program/tier, submission date, verdict + key reason, and any flags (duplicate, prior reward, name/email mismatch). Also note totals, duplicates skipped, and prior-reward conflicts.

Step 8: Send to Slack (optional)

Only if explicitly asked. Format as Slack mrkdwn and post using $BUZZ_SLACK_TOKEN to $APPROVALS_CHANNEL_ID.

Edge Cases

• No Google Workspace CLI available: ask the user to install gog or gws.
• CLI not authenticated / sheet access denied: guide the user through auth or suggest an account with access.
• Zero pending rows: report that all rewards are up to date.
• Redacted emails: skip rows with blank/masked emails.
• Same email, different programs: check each program separately.

Constraints

• Do NOT hardcode or log any tokens, sheet IDs, or PII.
• The referral-fraud-check skill handles all warehouse work — this skill stays local.