The task
Scenario. A coding agent is about to fix a broken revenue query against `fct_orders`. It has two candidate column names in mind for the discount field and no way to tell which one is real. Guess wrong here and the fix either fails outright or, worse, runs clean against the wrong column and quietly reports the wrong number to finance.
The ask
- The real columns and types on the table, not the ones the agent guessed
- Which of them are certified, and whether a governed definition already covers them
- Confirmation that nothing changed underneath you recently
Hero prompt
Before you touch the query, pull the real columns and types on `fct_orders`, tell me which ones are certified, and flag if any glossary term already defines what 'discount' means on this table.
Step by step
-
Find the exact table.
Find the <fct_orders> table in the <schema> schema, by description if you're unsure of the exact name.
-
Pull columns, types, and certification.
Show its columns, data types, and certification status, so I'm coding against what's actually there.
-
Check for a governed definition.
Check whether <the column — e.g. discount> has a governed glossary definition, so it means the same in my code as it does to the business.
-
Confirm nothing changed recently.
Show the certification date and any open announcements on <fct_orders> before I commit the fix.
What you'll give it
Required context
- The table name, or a close description of it, and the schema it lives in
- Read access to metadata for that schema
Optional context
- The draft SQL or script you're about to run, so the agent can check it against the real columns directly
- The specific business term you're worried about (e.g. "discount", "revenue")
What Atlan creates
Outputs
- The real column list, types, and certification status for the table
- The governed definition for any business term you flagged, if one exists
- A go/no-go read on whether your draft SQL references anything that doesn't exist or is deprecated
Summary. You now know the fix is being written against what the table actually contains, not a guess, and you know whether the term you're using in your query matches what the business means by it.
Read-only. Nothing in Atlan is written or updated; this only pulls context into your coding session.
Follow-up prompts
Keep going once the first answer lands.
Cover the whole pipeline
Do the same check across every table this pipeline touches before I run the full refactor.
Check downstream impact
Trace what else depends on this table before I change a column.
Recheck before merge
Re-run this check right before I merge, not just when I started.
Tips & troubleshooting
The five minutes this costs you is cheaper than the hour you'll spend debugging a query that ran clean against the wrong column.
- Match the client to the work.** Run this inside whatever coding agent you're already using; you want the context to land in the same session where you're about to write the fix, not in a separate tab.
- Automate or chain it.** Wire this into the start of every coding session touching production tables, or chain it as a pre-commit check on any PR that changes a SQL file referencing a known schema.
- Recheck on long sessions.** If your coding session runs for hours, the schema underneath you can change. Re-pull column and certification status before you actually run the fix, not just when you started writing it.