docs(agents): document Dag naming convention

.github/skills/airflow-translations/locales/th.md

@@ -13,8 +13,8 @@ The following technical terms should **remain in English** in Thai translations:
 
 ### Core Technical Terms (คำศัพท์ทางเทคนิค)
 
-- **DAG** (Directed Acyclic Graph) - Keep as "DAG"
-- **DAG Run** - Keep as "DAG Run"
+- **Dag** - Keep as "Dag" (Airflow convention; never write "DAG")
+- **Dag Run** - Keep as "Dag Run"
 - **Task Instance** - Keep as "Task Instance"
 - **XCom** - Keep as "XCom"
 - **Asset** - Keep as "Asset"
@@ -24,7 +24,7 @@ The following technical terms should **remain in English** in Thai translations:
 - **Sensor** - Keep as "Sensor"
 - **Hook** - Keep as "Hook"
 - **Operator** - Keep as "Operator" (โอเปอเรเตอร์) or in English
-- **DAGBag** - Keep as "DAGBag"
+- **DagBag** - Keep as "DagBag"
 
 ### UI Components (ส่วนประกอบของอินเทอร์เฟซ)
 
@@ -123,14 +123,14 @@ In Airflow UI and messages, numerals are typically formatted as:
 Example:
 
 ```text
-งาน DAG รันสำเร็จ (DAG run successful)
+งาน Dag รันสำเร็จ (Dag run successful)
 ```
 
 ## Translation Style Guidelines
 
 ### 1. Technical Terminology
 
-Keep technical terms like DAG, XCom, Operator in English when:
+Keep technical terms like Dag, XCom, Operator in English when:
 
 - They appear in code or configuration examples
 - No clear Thai equivalent exists
@@ -181,8 +181,8 @@ Prefer translation for:
 
 ### 1. "Run" Context
 
-- "Run DAG" → "รัน DAG" or "ดำเนินการ DAG"
-- "DAG run" (noun) → "การรัน DAG" or "DAG Run"
+- "Run Dag" → "รัน Dag" or "ดำเนินการ Dag"
+- "Dag run" (noun) → "การรัน Dag" or "Dag Run"
 - "Run ID" → "รันไอดี" or "Run ID"
 
 ### 2. "Task" Context
@@ -191,11 +191,11 @@ Prefer translation for:
 - "Task instance" → "Task Instance" or "อินสแตนซ์งาน"
 - "Task ID" → "Task ID" or "ไอดีงาน"
 
-### 3. "DAG" Context
+### 3. "Dag" Context
 
-- "DAG run" → "การรัน DAG" or "DAG Run"
-- "DAG ID" → "DAG ID" or "ไอดี DAG"
-- "Sub DAG" → "DAG ย่อย" or "Sub DAG"
+- "Dag run" → "การรัน Dag" or "Dag Run"
+- "Dag ID" → "Dag ID" or "ไอดี Dag"
+- "Sub Dag" → "Dag ย่อย" or "Sub Dag"
 
 ### 4. Configuration
 
@@ -252,14 +252,14 @@ However, these are typically omitted in technical documentation to maintain conc
 "Tree View" → "มุมมองต้นไม้" or "Tree View"
 "Graph View" → "มุมมองกราฟ" or "Graph View"
 "Task Instances" → "Task Instances" or "อินสแตนซ์งาน"
-"DAG Runs" → "DAG Runs" or "การรัน DAG"
+"Dag Runs" → "Dag Runs" or "การรัน Dag"
 ```
 
 ### Message Examples
 
 ```text
 "Task failed" → "งานล้มเหลว"
-"DAG run successful" → "การรัน DAG สำเร็จ"
+"Dag run successful" → "การรัน Dag สำเร็จ"
 "XCom pushed" → "ดัน XCom แล้ว" or "XCom pushed"
 "Connection test failed" → "การทดสอบการเชื่อมต่อล้มเหลว"
 ```

AGENTS.md

@@ -3,6 +3,34 @@
 
 # AGENTS instructions
 
+## Naming
+
+Always write **Dag** (title case) in prose — documentation, markdown, comments,
+docstrings, commit messages, PR titles and descriptions, code review comments,
+issue bodies, and chat replies. Never write "DAG" (all caps) or "dag"
+(lowercase) outside of literal code tokens.
+
+Exceptions where the literal form is required and must be preserved as-is:
+
+- **Python source code** where a class or variable is literally named `DAG`
+  (e.g., `from airflow.sdk import DAG`, `dag = DAG("my_dag", ...)`). The `DAG`
+  class itself is current and stays as-is in code; only its appearance in
+  prose moves to "Dag". The token `DAG` in code cannot be rewritten in
+  documentation that shows the code. Same applies to lowercase identifiers
+  like `dag_id`, `dag`, `my_dag`.
+- **CLI subcommands** that are literally named `dags` (e.g.,
+  `airflow dags list`, `airflow dags test`). Lowercase is the actual command
+  name.
+- **File / directory / config tokens** that are literally those identifiers
+  (`dag_processing/`, `dagprocessor`, `get_dag`, etc.).
+- **Anti-pattern callouts** that quote the wrong form to teach the rule (e.g.,
+  `Use "DAG" — always write "Dag"`). The literal `DAG` is required to convey
+  what to avoid; this is the rule's spirit, not a violation.
+
+Do not write **Directed Acyclic Graph** in documentation. The only exception is
+when describing what the term originally meant (historical / etymological
+context). In current prose, just use "Dag".
+
 ## Environment Setup
 
 - Install prek: `uv tool install prek`

providers/AGENTS.md

@@ -46,14 +46,14 @@ Airflow has two distinct user roles with different trust levels:
 - **Connection editors** — UI/API users with permission to create or edit
   Connections. They control the host, login, password, and the `extra` JSON
   blob.
-- **DAG authors** — users who write the Python code that constructs hooks
+- **Dag authors** — users who write the Python code that constructs hooks
   and operators. They control which arguments are passed at call sites.
 
 These are *not* the same population, and the security model treats them
 differently. A Connection editor is trusted to supply credentials for a target
 system; they are **not** trusted to alter how the worker process behaves, load
 arbitrary Python code, change file paths the worker reads, or pass options
-into client libraries that the DAG author did not opt into.
+into client libraries that the Dag author did not opt into.
 
 ### What goes wrong when extras are forwarded blindly
 
@@ -90,7 +90,7 @@ model does not grant them.
 - When adding support for a new extra key, treat it like any other public
   argument: review what the underlying library does with it, and document
   it in the provider's connection docs.
-- If a DAG author genuinely needs to pass a non-allowlisted option, that
+- If a Dag author genuinely needs to pass a non-allowlisted option, that
   option should be a **Dag-author-supplied argument** on the operator or
   hook (with its own review), not something a Connection editor can set.