Coding-Agent GTM Skills for AI Agents

Purpose

Capture hard bounce events in real time and add those addresses to a central suppression list before the next send.

Inputs

• ESP webhook payload format and signing secret
• Database connection string for the suppression table
• List of bounce codes that count as permanent

Steps

1. Stand up an endpoint that verifies the webhook signature and rejects unsigned calls.
2. Parse each event and keep only bounce types matching the permanent codes list.
3. Normalize the email to lowercase and strip plus tags before lookup.
4. Upsert the address into the suppression table with source, reason code, and timestamp.
5. Push the same address to every connected sending tool through its API so no seat re-adds it.
6. Log failures to a retry queue and alert if the failure rate crosses a threshold.
7. Emit a daily count of new suppressions grouped by reason.

Output

A running suppression sync service plus a daily summary of newly suppressed addresses and any sync failures needing manual review.

Purpose

Use a coding agent to write a script that pushes new Clay or sheet rows into your CRM without duplicates.

Inputs

• CRM name and API docs URL
• Source of truth (a Clay webhook payload sample or a sheet)
• Field mapping between source and CRM

Steps

1. Give Claude Code the CRM API docs link and a sample source payload.
2. Ask it to scaffold a script that reads source rows and maps fields to CRM properties.
3. Have it add an idempotency check that queries the CRM by email before creating a record.
4. Tell it to update existing records instead of inserting duplicates.
5. Ask for retry and rate-limit handling around the API calls.
6. Have it log every create and update to a local file for auditing.
7. Run it against five test rows before pointing it at the full list.

Output

A tested sync script with logging, idempotency, and a dry-run flag you can schedule with cron.

Purpose

Wrap a flaky enrichment API in a script that retries transient failures, respects rate limits, and records every call outcome.

Inputs

• Enrichment API base URL, auth key, and endpoint docs
• List of records to enrich as CSV or JSON
• Rate limit and monthly credit budget

Steps

1. Read the record list and map each row to a request payload with a stable unique key.
2. Send requests through a client that sets timeouts and honors the documented rate limit with a token bucket.
3. On 429 or 5xx responses, retry with exponential backoff up to a set cap, then mark the row as failed.
4. On 4xx client errors, skip retries, tag the reason, and move on.
5. Write each result to an append-only log with timestamp, status, credits used, and latency.
6. After the run, emit a summary of successes, permanent failures, and total credits spent.

Output

An enriched output file plus a run log and a summary report of success rate, retry counts, and credit usage.

Purpose

Fill gaps in an existing enriched table while skipping any row that already has valid data so you never pay twice.

Inputs

• Export of current contact or account table with enrichment columns
• List of fields that must be present (email, title, company size)
• Provider or Clay table you will run the backfill through

Steps

1. Load the export and tag each row with which required fields are empty or malformed.
2. Build a skip rule so any row with all required fields already valid is excluded from the run.
3. Group the remaining rows by which specific fields are missing to route only needed lookups.
4. Run each group through the matching enrichment step and write results to a staging column.
5. Compare staging values against existing values and only overwrite when the cell was empty.
6. Log a per-row status of filled, skipped, or failed with a reason.
7. Merge the staging columns back and produce a before to after fill count.

Output

An updated table plus a summary of rows filled, rows skipped, credits used, and rows still empty for review.

Purpose

Have a coding agent build a webhook that scores and routes inbound leads to the right owner in real time.

Inputs

• A sample form or webhook payload
• Routing rules by territory, size, or product interest
• Destination endpoints (Slack, CRM, or an email API)

Steps

1. Give the agent a sample payload and your routing rules in plain language.
2. Ask it to build a small webhook server that validates the incoming payload.
3. Have it add an enrichment call to fill company size or domain if missing.
4. Have it apply your rules to assign an owner and a priority tier.
5. Route each lead to the matching Slack channel or CRM queue.
6. Add signature verification and a dead-letter log for failed sends.
7. Ask for a test harness that replays saved payloads.

Output

A deployable webhook service that assigns, enriches, and routes each inbound lead with a replayable test suite.

Purpose

Build a script with a coding agent that turns enriched lead data into one custom first line per contact.

Inputs

• A CSV or Clay export with company, role, and a research snippet column
• An LLM API key
• Your opener style guide or three example lines

Steps

1. Give the agent your example openers and the input columns.
2. Ask it to write a script that loops rows and builds a prompt per contact.
3. Have it enforce a length cap and ban generic phrases in the prompt.
4. Add a post-check that rejects openers referencing missing data.
5. Have it retry rejected rows once with a stricter prompt.
6. Write results back to a new column and flag rows that failed twice.
7. Cap concurrency to respect the API rate limit.

Output

A CSV with one reviewed opener per contact and a flag column marking lines that need a human.

Purpose

Use a coding agent to turn a messy list of company names into a clean, deduped, domain-matched account file.

Inputs

• A raw list of company names or URLs
• A search or enrichment API key for domain lookup
• Your required output columns

Steps

1. Hand the agent the raw list and your target schema.
2. Ask it to write a script that trims names and strips legal suffixes like Inc or Ltd.
3. Have it resolve each name to a primary domain via the search API.
4. Add a confidence score and flag low-confidence matches for review.
5. Dedupe by resolved domain, keeping the richest row.
6. Validate each domain resolves with a quick HTTP head request.
7. Export to CSV in your schema with a review column.

Output

A clean account CSV with resolved domains, a match-confidence score, and flagged rows for manual checks.

Purpose

Compare a previous and current export of your outbound sequence configuration and produce a readable change log so nobody silently breaks a live campaign.

Inputs

• Old sequence config export (JSON or CSV)
• New sequence config export (JSON or CSV)
• List of fields that matter (subject, body, delay days, send window, active flag)

Steps

1. Load both exports and align records by sequence ID and step number.
2. Flag added steps, removed steps, and reordered steps.
3. For matched steps, diff each watched field and record old value to new value.
4. Classify each change as low risk (typo, casing) or high risk (delay, send window, active flag).
5. Group changes by sequence and count how many active sequences were touched.
6. Write a plain text change log with a high risk section pinned to the top.
7. Commit the log to Git with a timestamped filename for audit history.

Output

A grouped change log listing every field level difference, tagged by risk, plus a committed file for tracking over time.

Purpose

Make sure every outbound email template carries a valid unsubscribe path and that opt-outs land in a suppression list automatically.

Inputs

• Folder of email templates (HTML or plain text)
• Base URL for your unsubscribe endpoint
• Suppression list storage target (CSV or database table)

Steps

1. Parse each template and check for an existing unsubscribe link or footer token.
2. Flag templates missing a link and inject a tokenized unsubscribe URL tied to the recipient ID.
3. Generate a small endpoint handler that validates the token and writes the address to the suppression store.
4. Add a check that blocks sends to any address already present in suppression.
5. Write a test that submits a fake opt-out and confirms the address is recorded and blocked on the next send.
6. Produce a diff of every template change for review before commit.

Output

Updated templates with unsubscribe links, an endpoint handler script, a suppression sync check, and a change diff summary.

Purpose

Detect when a third-party webhook changes its payload structure so your downstream GTM automations do not silently break.

Inputs

• Sample of recent webhook payloads (JSON logs)
• A reference schema or known-good payload example
• List of fields your automations depend on

Steps

1. Load the reference payload and infer its schema, including field names, types, and nesting depth.
2. Parse the recent payload sample and build a schema for each incoming event.
3. Compare each event schema against the reference and flag added fields, missing fields, and type changes.
4. Cross-check flagged changes against the dependency list to rank severity by what your automations actually use.
5. Write a small validation function that rejects or quarantines payloads failing the required-field checks.
6. Draft alert text describing what changed, which automation is at risk, and a suggested fix.

Output

A drift report ranking each schema change by severity, a reusable payload validator function, and a ready-to-send alert message for the owning team.

Purpose

Catch failed webhook deliveries to your CRM or sequencer and hold them for automatic retry or manual replay.

Inputs

• List of webhook endpoints and expected 2xx codes
• Max retry count and backoff schedule
• Connection string for a Redis or Postgres store

Steps

1. Wrap each outbound webhook call in a send function that records the payload, target, and timestamp before firing.
2. On a non-2xx or timeout, push the payload to a retry queue with an attempt counter and next-retry time.
3. Run a worker that polls due items, retries them, and increments the attempt count on failure.
4. When attempts exceed the max, move the item to a dead-letter table with the last error and full payload.
5. Expose a replay command that reads dead-letter rows and re-enqueues selected ones.
6. Log every state change with a correlation ID so you can trace one payload end to end.

Output

A running retry worker, a dead-letter store of undelivered payloads, and a replay command to reprocess them.