Clay tables are intricate stacks of formulas, AI columns, and API integrations, and a single wrong setting breaks a run silently. AutoClayBuilder makes building one safe and provable: describe the table you want, it forces an exact build plan you approve before anything is created, builds it into a throwaway scratch table, then mathematically proves the result matches the spec. Reverse-engineering an existing table is part of it — but only as the calibration step that proves the build payloads are right.
Building a Clay table by hand is slow and silently error-prone. Cloning one to "learn how it works" still leaves you guessing whether your next build is right. AutoClayBuilder turns building into a planned, verified process.
Click 100+ columns into existence from memory. One wrong field type or missing input binding and the run produces wrong output — with no error to tell you.
An approved plan first, a scratch build second, then a field-by-field parity score against the spec. You ship a number, not a guess.
No setup, no command to remember. The repo self-activates into a planning gate.
The repo ships a CLAUDE.md at its root. Any AI coding agent (Claude Code, etc.) loads it automatically the instant the repo is opened.
That note hard-gates building behind an approved plan: the agent must lock the spec, read every past scar in docs/learnings/, fill in plans/TEMPLATE.md, and get your explicit "go" — before a single Clay API call fires.
So "how should this table be built?" is answered in writing, by the repo itself, every time — not improvised mid-build.
Steps 1–4 happen before anything is created. Step 4 is a hard approval gate. The build itself only ever touches a throwaway scratch table, with action columns saved without running so no real API calls fire by accident.
Interview until the goal, the source of truth, every column and its type, and the non-goals are unambiguous. You can't build what you can't state exactly.
plans/TEMPLATE.md draft.Pull in the reusable column patterns and — critically — every past failure already paid for, so this build doesn't repeat one.
docs/recent-table-patterns.md — reusable column/integration patternsdocs/frontend-api-patterns.md — which endpoints are verified vs inferreddocs/learnings/ — the scars. If a learning flagged a column type as unstable, the plan must call it out with a link.Fill a 10-section build plan: goal, exact target shape column-by-column, field mapping, every endpoint marked verified or inferred, risks from past scars, non-goals, verification plan, and the ordered runbook.
Present the plan, ask for an unambiguous yes. Silence, enthusiasm, or "looks good" on one section is not approval. Pushback → edit plan → re-ask. Nothing is created in Clay until this clears.
Recreate every column, formula, AI prompt, integration, field group, view order, and seed row in a brand-new disposable table — saved without running it.
POST /v3/workbooks → POST /v3/tables (template:"no_views")inputsBinding, inputFieldIds, extracted fields, views, cross-table refs)cellCount = 0 so no placeholder API calls fire.Re-fetch the scratch table fresh — a "200 OK" write isn't proof Clay kept what you sent; it silently normalizes. Score config parity against the spec field-by-field.
scripts/score_clay_parity.py: strips volatile keys, remaps target IDs back to source IDs, deep-compares each field. Outputs score (matched/total), status (perfect_config_parity / config_mismatch), and typed mismatches. The fresh readback is the only authority.End every build with a redacted learnings file: what worked, what didn't, the mistakes, what the next builder should do differently. Then ask before opening a PR.
docs/learnings/YYYY-MM-DD-<slug>.md. The next build inherits the scar, not the wound. Never auto-push.When calibrating against a known table, the same target is rebuilt four different ways at once. Whichever reaches perfect parity first wins; the rest are marked "abandoned by better path." This is how the builder earns confidence in its payloads.
Configure entirely via the frontend API. Browser only for gaps and final verification.
Recreate through the Clay UI like a human would, then verify with an API snapshot.
Use Clay's native duplicate endpoint as a head start, then patch the mismatches.
API-built scratch base, with the browser handling un-reproducible columns.
Everything in the middle stays local and gitignored. Only redacted, public-safe artifacts ever leave the machine.
Two systems are called directly. The rest are Clay column types the builder must recreate faithfully — not services this tool calls itself.
Column types it must build exactly:
Calibration run on 2026-05-03 against a real 103-field table.
The best non-duplicate rebuild recreated 103 fields, 2 views, 7 field groups, and 10 seed rows faithfully — proving the build payloads are correct.
The only mismatch: 4 Claygent / use-ai fields where a hidden rate-limit setting was silently normalized from 200 → workspace default 5 despite Clay returning 200 OK. No UI control to override — a documented, evidence-backed blocker, not a build error.