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.