GTM Engineering skill 10 of 13

GTM Workflow QA SKILL.md

The GTM Workflow QA skill makes Claude Code or another AI agent check every row of a Clay or other GTM table against a written spec before anything is sent or synced. It checks required fields, formats, ICP and exclusion rules, duplicates, CRM mapping and AI-written copy, using code for exact rules and AI only for judgement, then groups failures by cause and gives a go or no-go.

gtm-workflow-qa/SKILL.md, version 1.0.0, 1,692 words.

Go-to-market (GTM) workflows built in tools such as Clay chain many steps together: find companies, enrich contacts, run waterfalls across data providers, score fit, write personalised lines with AI, then push records to a CRM or sequencer. Each step can fail quietly. A provider returns an empty value, a formula breaks on one country's data, an AI column writes "[First Name]" or invents a fact, a filter lets the wrong companies through, and hundreds of emails go out before anyone notices. Spot-checking ten rows does not catch problems that affect 3% of a 5,000-row table.

This skill runs row-by-row QA on a GTM table against a written spec. It checks every row for data completeness and format, business rules (ICP fit, exclusions, routing), copy quality (personalisation, tone, banned words, claims) and technical requirements (field mapping, duplicates, CRM readiness), using deterministic checks in code and AI judgement only where rules cannot decide. It produces a pass or fail per row, an error summary by cause, examples and fixes, and a go or no-go recommendation before anything is sent or synced.

Operating principles

  1. The spec is the source of truth. QA checks rows against written requirements, not against vibes.
  2. Check every row, not a sample. Quiet failures hide in small percentages.
  3. Code for rules, AI for judgement. Formats, lengths and lists are checked deterministically; tone and factual fit get AI review.
  4. Group errors by cause. Fix the step that broke, not each row by hand.
  5. Nothing ships on a fail. Sending, syncing or launching waits for a go decision.

Technical requirements

RequirementDetail
AgentClaude Code (or another agent that can run Python and read files)
RuntimePython 3.10 or later with pandas (pip install pandas)
InputTable export as CSV (from Clay: export the table or a view), UTF-8
Specqa-spec.md or qa-spec.yaml in the same folder (template below)
OptionalClay API or webhook access to pull data directly; CRM field list
Outputqa-report.md, qa-results.csv (row ID, status, failed checks, notes)
ScaleCode checks handle tens of thousands of rows; AI review runs in batches (for example 50 rows) to control cost
PrivacyContact data stays local or in approved tools; never paste personal data into unapproved services

The QA spec

Write the spec before building or before QA, with the person who owns the campaign.

table: outbound-q4-fintech
row_id: record_id
required_fields: [company_name, domain, first_name, last_name, email, title, country, opener_line]
formats:
  email: email
  domain: domain
  linkedin_url: url_contains:linkedin.com/in/
allowed_values:
  country: [United Kingdom, Ireland, Netherlands, Germany]
rules:
  - name: icp_employee_range
    check: employees between 50 and 1000
  - name: exclude_customers
    check: domain not in customers.csv
  - name: title_seniority
    check: title contains any [Head, Director, VP, Chief, Lead]
duplicates:
  unique: [email]
  unique_per_company_max: 3
copy:
  field: opener_line
  max_words: 25
  must_not_contain: ["[", "{", "undefined", "N/A", "I hope this finds you well"]
  must_reference: company_name or recent_signal
  tone: plain, specific, no flattery, British English
  no_invented_facts: true
crm:
  push_fields: {email: Email, first_name: FirstName, company_name: Company}
  required_for_push: [email, company_name, owner]
thresholds:
  max_fail_rate: 2%
  max_copy_fail_rate: 5%

When to use, and when not to

Use it before sending any outbound sequence, before syncing enriched data to a CRM, after changing a workflow step or provider, when launching a new table template, and on a schedule for always-on workflows.

Don't use it as a replacement for data provider compliance checks or legal review of outreach rules (for example data protection and email marketing laws in each country), which the team must handle separately.

Raw SKILL.md file

.md

This is the exact file agents read, including the credit header and licence notice. Save it as gtm-workflow-qa/SKILL.md.

---
name: gtm-workflow-qa
description: "QA every row of a Clay or other GTM table against a written spec before sending or syncing: required fields, formats, ICP and exclusion rules, duplicates, CRM mapping, copy checks for placeholders, length, banned phrases, invented facts and tone, code checks plus batched AI judgement, errors grouped by cause and a go or no-go report. Use whenever someone builds outbound or enrichment workflows in Clay or similar tools, wants to QA a table or AI-written copy before launch, check data against a spec, catch quiet workflow failures or validate records before a CRM sync, especially with Claude Code."
license: CC-BY-4.0
metadata:
  author: Afeez Adebayo
  author_url: https://afeezadebayo.com
  author_linkedin: https://www.linkedin.com/in/afeez-adebayo/
  author_x: https://x.com/za_icon
  source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/gtm-workflow-qa/
  category: marketing
  subcategory: gtm-engineering
  version: "1.0.0"
  created: "2026-10-13"
  updated: "2026-10-13"
---

# GTM Workflow QA

Go-to-market (GTM) workflows built in tools such as Clay chain many steps together: find companies, enrich contacts, run waterfalls across data providers, score fit, write personalised lines with AI, then push records to a CRM or sequencer. Each step can fail quietly. A provider returns an empty value, a formula breaks on one country's data, an AI column writes "[First Name]" or invents a fact, a filter lets the wrong companies through, and hundreds of emails go out before anyone notices. Spot-checking ten rows does not catch problems that affect 3% of a 5,000-row table.

This skill runs row-by-row QA on a GTM table against a written spec. It checks every row for data completeness and format, business rules (ICP fit, exclusions, routing), copy quality (personalisation, tone, banned words, claims) and technical requirements (field mapping, duplicates, CRM readiness), using deterministic checks in code and AI judgement only where rules cannot decide. It produces a pass or fail per row, an error summary by cause, examples and fixes, and a go or no-go recommendation before anything is sent or synced.

## Operating principles
1. **The spec is the source of truth.** QA checks rows against written requirements, not against vibes.
2. **Check every row, not a sample.** Quiet failures hide in small percentages.
3. **Code for rules, AI for judgement.** Formats, lengths and lists are checked deterministically; tone and factual fit get AI review.
4. **Group errors by cause.** Fix the step that broke, not each row by hand.
5. **Nothing ships on a fail.** Sending, syncing or launching waits for a go decision.

## Technical requirements
| Requirement | Detail |
|---|---|
| Agent | Claude Code (or another agent that can run Python and read files) |
| Runtime | Python 3.10 or later with pandas (`pip install pandas`) |
| Input | Table export as CSV (from Clay: export the table or a view), UTF-8 |
| Spec | `qa-spec.md` or `qa-spec.yaml` in the same folder (template below) |
| Optional | Clay API or webhook access to pull data directly; CRM field list |
| Output | `qa-report.md`, `qa-results.csv` (row ID, status, failed checks, notes) |
| Scale | Code checks handle tens of thousands of rows; AI review runs in batches (for example 50 rows) to control cost |
| Privacy | Contact data stays local or in approved tools; never paste personal data into unapproved services |

## The QA spec
Write the spec before building or before QA, with the person who owns the campaign.
```yaml
table: outbound-q4-fintech
row_id: record_id
required_fields: [company_name, domain, first_name, last_name, email, title, country, opener_line]
formats:
  email: email
  domain: domain
  linkedin_url: url_contains:linkedin.com/in/
allowed_values:
  country: [United Kingdom, Ireland, Netherlands, Germany]
rules:
  - name: icp_employee_range
    check: employees between 50 and 1000
  - name: exclude_customers
    check: domain not in customers.csv
  - name: title_seniority
    check: title contains any [Head, Director, VP, Chief, Lead]
duplicates:
  unique: [email]
  unique_per_company_max: 3
copy:
  field: opener_line
  max_words: 25
  must_not_contain: ["[", "{", "undefined", "N/A", "I hope this finds you well"]
  must_reference: company_name or recent_signal
  tone: plain, specific, no flattery, British English
  no_invented_facts: true
crm:
  push_fields: {email: Email, first_name: FirstName, company_name: Company}
  required_for_push: [email, company_name, owner]
thresholds:
  max_fail_rate: 2%
  max_copy_fail_rate: 5%
```

## When to use, and when not to
Use it before sending any outbound sequence, before syncing enriched data to a CRM, after changing a workflow step or provider, when launching a new table template, and on a schedule for always-on workflows.

Don't use it as a replacement for data provider compliance checks or legal review of outreach rules (for example data protection and email marketing laws in each country), which the team must handle separately.

## Workflow

### Step 1. Confirm the spec
Read `qa-spec`. If key rules are missing (exclusions, copy limits, thresholds), ask the owner before running.

### Step 2. Load and profile the data
Row count, columns present versus spec, empty rates per column, obvious encoding problems.

### Step 3. Run deterministic checks on every row
Required fields, formats, allowed values, numeric rules, exclusion lists, duplicates, CRM required fields, copy length and forbidden strings.

### Step 4. Run AI judgement checks
Only for checks code cannot decide: does the opener reference something real from the row's data, is the tone right, does it invent a fact, is the title a real decision maker for this offer? Review in batches; record a reason for every fail.

### Step 5. Group failures by cause
Map failed checks to the workflow step that produced them (provider, formula, AI prompt, filter, mapping).

### Step 6. Compare with thresholds
Fail rate overall and per check versus the spec.

### Step 7. Report and recommend
Go, go with fixes (exclude failed rows) or no-go (fix the workflow and re-run).

### Step 8. Re-run after fixes
Run QA again on the corrected table; keep both reports.

## Deterministic checker (starter script)
```python
import pandas as pd, re
df = pd.read_csv("table.csv", dtype=str).fillna("")
results = []
EMAIL = re.compile(r"^[^@\s]+@[^@\s]+\.[a-z]{2,}$", re.I)
BANNED = ["[", "{", "undefined", "N/A", "I hope this finds you well"]
for _, r in df.iterrows():
    fails = []
    for f in ["company_name", "domain", "first_name", "email", "title", "opener_line"]:
        if not r.get(f, "").strip(): fails.append(f"missing:{f}")
    if r.get("email") and not EMAIL.match(r["email"]): fails.append("format:email")
    line = r.get("opener_line", "")
    if len(line.split()) > 25: fails.append("copy:too_long")
    if any(b.lower() in line.lower() for b in BANNED): fails.append("copy:banned_or_placeholder")
    if r.get("company_name") and r["company_name"].lower() not in line.lower(): fails.append("copy:no_company_reference")
    results.append({"record_id": r.get("record_id", ""), "status": "fail" if fails else "pass", "fails": ";".join(fails)})
dup = df[df.duplicated("email", keep=False) & (df["email"] != "")]
out = pd.DataFrame(results)
out.loc[out["record_id"].isin(dup.get("record_id", [])), "fails"] += ";duplicate:email"
out.to_csv("qa-results.csv", index=False)
print(out["status"].value_counts())
```
Extend it from the spec: allowed values, exclusion lists, numeric ranges and CRM mappings.

## Copy checks
| Check | Method | Fail example |
|---|---|---|
| Placeholder left in | Code | "Hi [First Name], loved {company}'s..." |
| Too long | Code | 48-word opener |
| Banned phrases | Code | "I hope this finds you well" |
| References real data | AI with row data | Mentions a funding round not in the row |
| Tone and spelling | AI | Gushing flattery; US spelling in a UK campaign |
| Relevance to offer | AI | Line about hiring for an analytics product pitch |

## Report format
```
# QA report: <table>, <date>
Rows: 4,812 | Pass: 4,590 (95.4%) | Fail: 222 (4.6%) | Threshold: 2% -> NO-GO
Top causes
1. Missing email (118 rows): provider waterfall skipped step 3 for .de domains
2. Placeholder in opener (61 rows): AI column ran before first_name was filled
3. Existing customers (24 rows): exclusion list outdated
4. Copy invents facts (19 rows): prompt asks for "recent news" with no news column
Fixes: <step, change, owner>
Examples: <3 failed rows per cause>
Recommendation: fix causes 1 and 2, refresh exclusions, re-run QA
```

## Edge cases and judgement calls
| Situation | What to do |
|---|---|
| No written spec | Draft one from the brief and workflow; get owner approval first |
| Very large tables | Code checks on all rows; AI checks on all rows with copy, in batches |
| Mixed languages | Spec per language; AI checks in the right language |
| Always-on workflow | Schedule QA daily on new rows; alert on threshold breaches |
| Borderline AI judgements | Mark "review" rather than pass or fail; a human decides |
| Sensitive or regulated targeting | Escalate to legal or compliance before sending |

## Handoffs to related skills
- ICP definition used in rules: the Product Marketing `ideal-customer-profile` skill
- CRM data hygiene: the CRM and Lifecycle `crm-data-hygiene` skill
- Lead scoring and routing: the CRM and Lifecycle `lead-scoring-routing` skill
- Cold email copy itself: the Content, Copy and PR `marketing-copywriting` skill
- Email security and deliverability: the CRM and Lifecycle `email-deliverability` skill

## Worked example
A growth team built a Clay table of 4,812 fintech contacts with a provider waterfall, an AI opener column and a push to their sequencer. Spot checks looked fine. Full QA found a 4.6% fail rate against a 2% threshold: German domains skipped a provider step, an AI column ran before first names were filled, 24 contacts were existing customers and 19 openers mentioned news that was not in the data. The team fixed the waterfall order and the column dependency, refreshed the exclusion list and changed the prompt to use only provided signals. The re-run passed at 0.8%, and the campaign launched without the errors reaching prospects.

## Common mistakes
- QA by scrolling a few rows.
- No written spec, so nobody agrees what "correct" means.
- Using AI for checks code can do exactly.
- Fixing rows by hand instead of fixing the step.
- Sending before the report says go.

## Self-check before you answer
- Was every row checked against a written spec?
- Are code checks and AI checks separated, with reasons for AI fails?
- Are failures grouped by cause with fixes?
- Is there a clear go or no-go against thresholds?

---
Created by Afeez Adebayo, Marketing, SEO & Growth Expert
Website: https://afeezadebayo.com
LinkedIn: https://www.linkedin.com/in/afeez-adebayo/
X: https://x.com/za_icon
Source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/gtm-workflow-qa/

Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). You may copy, share and adapt this skill, including for commercial use, as long as you credit Afeez Adebayo and link to the source URL above. Keep this notice in any copy or adapted version.

Workflow

Step 1. Confirm the spec

Read qa-spec. If key rules are missing (exclusions, copy limits, thresholds), ask the owner before running.

Step 2. Load and profile the data

Row count, columns present versus spec, empty rates per column, obvious encoding problems.

Step 3. Run deterministic checks on every row

Required fields, formats, allowed values, numeric rules, exclusion lists, duplicates, CRM required fields, copy length and forbidden strings.

Step 4. Run AI judgement checks

Only for checks code cannot decide: does the opener reference something real from the row's data, is the tone right, does it invent a fact, is the title a real decision maker for this offer? Review in batches; record a reason for every fail.

Step 5. Group failures by cause

Map failed checks to the workflow step that produced them (provider, formula, AI prompt, filter, mapping).

Step 6. Compare with thresholds

Fail rate overall and per check versus the spec.

Step 7. Report and recommend

Go, go with fixes (exclude failed rows) or no-go (fix the workflow and re-run).

Step 8. Re-run after fixes

Run QA again on the corrected table; keep both reports.

Deterministic checker (starter script)

import pandas as pd, re
df = pd.read_csv("table.csv", dtype=str).fillna("")
results = []
EMAIL = re.compile(r"^[^@\s]+@[^@\s]+\.[a-z]{2,}$", re.I)
BANNED = ["[", "{", "undefined", "N/A", "I hope this finds you well"]
for _, r in df.iterrows():
    fails = []
    for f in ["company_name", "domain", "first_name", "email", "title", "opener_line"]:
        if not r.get(f, "").strip(): fails.append(f"missing:{f}")
    if r.get("email") and not EMAIL.match(r["email"]): fails.append("format:email")
    line = r.get("opener_line", "")
    if len(line.split()) > 25: fails.append("copy:too_long")
    if any(b.lower() in line.lower() for b in BANNED): fails.append("copy:banned_or_placeholder")
    if r.get("company_name") and r["company_name"].lower() not in line.lower(): fails.append("copy:no_company_reference")
    results.append({"record_id": r.get("record_id", ""), "status": "fail" if fails else "pass", "fails": ";".join(fails)})
dup = df[df.duplicated("email", keep=False) & (df["email"] != "")]
out = pd.DataFrame(results)
out.loc[out["record_id"].isin(dup.get("record_id", [])), "fails"] += ";duplicate:email"
out.to_csv("qa-results.csv", index=False)
print(out["status"].value_counts())

Extend it from the spec: allowed values, exclusion lists, numeric ranges and CRM mappings.

Copy checks

CheckMethodFail example
Placeholder left inCode"Hi [First Name], loved {company}'s..."
Too longCode48-word opener
Banned phrasesCode"I hope this finds you well"
References real dataAI with row dataMentions a funding round not in the row
Tone and spellingAIGushing flattery; US spelling in a UK campaign
Relevance to offerAILine about hiring for an analytics product pitch

Report format

# QA report: <table>, <date>
Rows: 4,812 | Pass: 4,590 (95.4%) | Fail: 222 (4.6%) | Threshold: 2% -> NO-GO
Top causes
1. Missing email (118 rows): provider waterfall skipped step 3 for .de domains
2. Placeholder in opener (61 rows): AI column ran before first_name was filled
3. Existing customers (24 rows): exclusion list outdated
4. Copy invents facts (19 rows): prompt asks for "recent news" with no news column
Fixes: <step, change, owner>
Examples: <3 failed rows per cause>
Recommendation: fix causes 1 and 2, refresh exclusions, re-run QA

Edge cases and judgement calls

SituationWhat to do
No written specDraft one from the brief and workflow; get owner approval first
Very large tablesCode checks on all rows; AI checks on all rows with copy, in batches
Mixed languagesSpec per language; AI checks in the right language
Always-on workflowSchedule QA daily on new rows; alert on threshold breaches
Borderline AI judgementsMark "review" rather than pass or fail; a human decides
Sensitive or regulated targetingEscalate to legal or compliance before sending
  • ICP definition used in rules: the Product Marketing ideal-customer-profile skill
  • CRM data hygiene: the CRM and Lifecycle crm-data-hygiene skill
  • Lead scoring and routing: the CRM and Lifecycle lead-scoring-routing skill
  • Cold email copy itself: the Content, Copy and PR marketing-copywriting skill
  • Email security and deliverability: the CRM and Lifecycle email-deliverability skill

Worked example

A growth team built a Clay table of 4,812 fintech contacts with a provider waterfall, an AI opener column and a push to their sequencer. Spot checks looked fine. Full QA found a 4.6% fail rate against a 2% threshold: German domains skipped a provider step, an AI column ran before first names were filled, 24 contacts were existing customers and 19 openers mentioned news that was not in the data. The team fixed the waterfall order and the column dependency, refreshed the exclusion list and changed the prompt to use only provided signals. The re-run passed at 0.8%, and the campaign launched without the errors reaching prospects.

Common mistakes

  • QA by scrolling a few rows.
  • No written spec, so nobody agrees what "correct" means.
  • Using AI for checks code can do exactly.
  • Fixing rows by hand instead of fixing the step.
  • Sending before the report says go.

Self-check before you answer

  • Was every row checked against a written spec?
  • Are code checks and AI checks separated, with reasons for AI fails?
  • Are failures grouped by cause with fixes?
  • Is there a clear go or no-go against thresholds?

When to use this skill, and when not to

Use it before launching any outbound sequence, before syncing enriched data to a CRM, after changing a workflow step or provider, when launching a new table template and on a schedule for always-on workflows.

Multi-step GTM workflows break quietly: an empty provider result, a formula that fails for one country, a placeholder or invented fact in an AI line. Spot checks miss problems that affect a few percent of thousands of rows.

It does not replace legal review of outreach rules or data provider compliance checks.

Example prompts

  • “QA this Clay export against our spec before we launch.”
  • “Write a QA spec for our outbound table.”
  • “Check every AI opener for placeholders and invented facts.”
  • “Group these failures by the step that broke.”
  • “Run QA daily on new rows and alert me.”

Example output

The skill returns a fixed structure. A shortened example for an imaginary site:

Rows: 4,812 | Pass: 95.4% | Fail: 4.6% | Threshold: 2% -> NO-GO
1. Missing email (118): waterfall skipped step 3 for .de domains
2. Placeholder in opener (61): AI column ran before first_name
3. Existing customers (24): exclusion list outdated
4. Invented facts (19): prompt asked for news with no news column
Re-run after fixes: 0.8% -> GO

Every row is checked, and failures are grouped by the workflow step that caused them so the fix happens once.

What the agent needs from you

The skill needs Claude Code or another agent that can run Python 3.10 or later with pandas, a CSV export of the table, a qa-spec file with fields, formats, rules, copy limits, CRM mapping and thresholds, exclusion lists and, optionally, Clay API or CRM field access. It writes qa-report.md and qa-results.csv.

How this skill hands off to related skills

How to run GTM Workflow QA step by step

  1. Install the skill as gtm-workflow-qa/SKILL.md in Claude Code.
  2. Write the qa-spec with the campaign owner.
  3. Export the table as CSV.
  4. Run code and AI checks on every row.
  5. Fix the failing steps.
  6. Re-run and launch on a go.

Situations this skill handles

GTM Workflow QA handles these situations:

SituationWhat the skill does
No written specDrafted and approved first
Very large tablesCode on all rows, AI in batches
Mixed languagesSpec per language
Always-on workflowDaily QA with alerts
Borderline AI judgementsMarked for review
Regulated targetingLegal escalation

What makes this skill different

Most QA is scrolling a few rows. This skill checks every row against agreed requirements, splits exact checks from judgement calls, traces each failure to the step that caused it and blocks launch until thresholds are met.

Practical tips from real projects

  • The spec is the source of truth.
  • Check every row.
  • Code for rules, AI for judgement.
  • Nothing ships on a fail.

A worked example: a growth team built a Clay table of 4,812 fintech contacts with a provider waterfall, an AI opener column and a push to their sequencer. Spot checks looked fine. Full QA found a 4.6% fail rate against a 2% threshold: German domains skipped a provider step, an AI column ran before first names were filled, 24 contacts were existing customers and 19 openers mentioned news that was not in the data. The team fixed the waterfall order and the column dependency, refreshed the exclusion list and changed the prompt to use only provided signals. The re-run passed at 0.8%, and the campaign launched without errors reaching prospects.

Copy checks combine both methods. Code catches placeholders such as a bracketed first name, openers over the word limit and banned phrases. AI checks whether each line refers to real data in the row, keeps the right tone and spelling and stays relevant to the offer, recording a reason for every fail.

The workflow confirms the spec, loads and profiles the data, runs deterministic checks on every row, runs AI judgement checks in batches, groups failures by the workflow step that produced them, compares fail rates with thresholds, reports with examples and fixes and re-runs after changes, keeping both reports. The included Python starter script checks required fields, email format, opener length, banned strings, company references and duplicate emails and writes a results file that teams extend from their own spec.

The spec is written with the campaign owner before QA: the table name and row identifier, required fields, formats for emails, domains and LinkedIn URLs, allowed countries, rules such as employee ranges, excluded customer domains and senior titles, unique fields and limits per company, copy rules for the opener, CRM field mapping and fields required before a push, and the maximum overall and copy fail rates. Contact data stays local or in approved tools.

The report states the row count, pass and fail rates against the threshold and a go or no-go, then lists the top causes with row counts, the workflow step behind each, examples of failed rows and the fix with an owner. Edge cases are handled deliberately: with no written spec, one is drafted from the brief and workflow and approved before running; very large tables get code checks on every row and AI checks in batches to control cost; mixed-language tables get a spec per language; always-on workflows run daily on new rows with alerts; borderline AI judgements are marked for human review; and sensitive or regulated targeting is escalated to legal or compliance before sending.

Common mistakes are QA by scrolling a few rows, no written spec, using AI for checks code can do exactly, fixing rows by hand instead of fixing the step and sending before the report says go. The final check confirms every row was checked against the spec, code and AI checks are separated with reasons for AI fails, failures are grouped by cause with fixes and a clear go or no-go is given.

Frequently asked questions

Write a spec, export the table, run code checks on every row, run AI checks on copy in batches, group failures by cause, fix and re-run.

Required fields, formats, allowed values, ICP and exclusion rules, duplicate limits, copy rules, CRM mapping and fail thresholds.

Claude Code or a similar agent, Python 3.10 or later with pandas, a CSV export and the spec file.

Code checks exact rules cheaply and reliably; AI is reserved for tone, relevance and invented facts.

The team sets it in the spec, for example 2% overall and 5% for copy.

Yes, on a schedule for new rows, with alerts when thresholds are breached.

Changelog

  • 1.0.0, 10 October 2026: first release.

Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo and link to this page.