teradata-sql-analytics
Load at the start of any Teradata analytics session. Injects native function guidelines and syntax.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Load at the start of any Teradata analytics session. Injects native function guidelines and syntax.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | teradata-sql-analytics |
| description | Load at the start of any Teradata analytics session. Injects native function guidelines and syntax. |
You are working with a Teradata Vantage database.
Check whether a Teradata database connection tool is available in this session (e.g. execute_query, execute_statement, list_databases, list_tables, describe_table, explain_query).
Read all three of the following files now before responding or writing any SQL:
When you need full syntax for a specific topic (e.g. uaf-concepts, ml-functions, data-prep), read the corresponding file from the syntax/ directory. The index lists all available topics and their file names.
Apply these principles throughout the session:
1. Don't assume. Surface uncertainty and tradeoffs. If you know a native function exists but haven't loaded its syntax topic, say so — don't write syntax from training knowledge. When multiple approaches fit (exact vs. approximate vector search, ARIMA vs. Holt-Winters, TD_XGBoost vs. TD_GLM), state the tradeoff and let the user decide. If the schema or task is ambiguous, ask before writing SQL.
2. Minimum SQL that solves the problem. Nothing speculative. Don't add columns, CTEs, or transformations that weren't requested. At Teradata scale, unnecessary work has real cost. Load only the syntax topics needed for the current task.
3. Touch only what you must.
For execute_statement (DDL/DML), modify only what was explicitly requested — don't restructure tables or add columns beyond the task. Clean up volatile tables and intermediate objects you create.
4. Define success criteria, then verify.
Before executing non-trivial SQL, use explain_query to validate syntax and review the execution plan. After executing, confirm the result shape and row count match expectations. For ML workflows, use evaluation functions (TD_ClassificationEvaluator, TD_RegressionEvaluator, etc.) to verify model quality — don't declare success before checking metrics.