---
name: process-ticket
description: Process and implement a data ticket end to end — branch, explore, plan, implement against Gemma conventions, verify with dbt, and prepare a PR.
disable-model-invocation: true
argument-hint: "[ticket description]"
---

Process and implement a ticket. The ticket description is provided as argument or will be pasted by the user: $ARGUMENTS

## Steps

1. **Prepare the branch**:
   - Check out `main` and pull latest changes
   - **If `main` is not currently checked out** (another feature is in progress), create a git **worktree** for this ticket instead of stacking on the existing branch — this also keeps parallel teammates from colliding in one working tree.
   - Read the ticket description (from `$ARGUMENTS` or ask the user to paste it)

2. **Explore the codebase**:
   - Identify all models, files, and layers affected by the ticket
   - Read the relevant SQL models, YML schema files, and macros
   - Trace the data flow from source through base → interim → reporting → service
   - Check for existing patterns, columns, or utilities that can be reused. **Before re-deriving a mapping or transformation inline, check whether an upstream model already exposes it** — and **look for an existing similar model to extend or follow before greenfield-building a new one.**

3. **Enter plan mode and design the implementation**:
   - Enter plan mode with `/plan`
   - Write a structured plan covering:
     - Context: why this change is needed
     - Step-by-step implementation with specific file paths and changes
     - YML documentation and test additions
     - Verification steps (dbt compile, dbt build)
     - Validation queries (when adding tests or data quality checks): include BigQuery queries the user can run to verify correctness before/after deployment
   - Ask the user clarifying questions before finalizing
   - Exit plan mode for user approval

4. **Implement the changes**:
   - Create a feature branch from main
   - Make all code changes following the Gemma SQL style guide
   - Add YML documentation and tests for new/changed columns
   - Update DDL comment blocks if external table schemas change

5. **Verify**:
   - Activate the dbt virtual environment if the project uses one. Check for `dbt-env/bin/activate`, `.venv/bin/activate`, and `venv/bin/activate` in order; if none exists, ask the user where their dbt environment is before running dbt. (Skip if dbt is on PATH, e.g. `dbtf`.)
   - Run `dbt compile` on all changed models to verify SQL syntax
   - Run `dbt build` if the warehouse connection is available
   - Fix any issues found

6. **Prepare for review**:
   - Commit changes with a descriptive message
   - Ask the user if they want to push and create a PR
   - PR title format: `[Topic/Department]: [Verb] [Summary]` (e.g., `Financial P&L: Removing Display Cost Distribution`, `SGPO Launch: Add Order Product Mix Classification`)
   - **Always link the originating ticket in the PR description.** The ticket-fetcher carries the ticket's URL/ID on the task — include it (e.g. `Ticket: <url>`). If you don't have the link, ask the lead/user for it before opening the PR; don't open a ticket-less PR.

## Important

- Activate the project's dbt virtual environment before running dbt commands (discover its name rather than assuming `dbt-env`); skip if dbt is already on PATH
- Follow the Gemma Analytics SQL style guide for all SQL changes
- New columns need descriptions in YML files and appropriate tests
- Use `dbt compile` freely to check syntax — it does not query the warehouse
- If BigQuery external table DDLs need updating, prepare the SQL statements and note them as a manual step
- Each PR should represent one logical unit of work
- **Every PR links back to its source ticket** — reviewers and future readers must be able to trace the work to its origin. No ticket link, no PR.
- **Push derivation logic upstream.** Don't re-derive a mapping inline in a downstream report when an upstream model could expose it; if you must do it inline to ship, file a follow-up `ae` ticket to move it upstream.
- **Comment non-obvious filters.** A filter like excluding the current partial month (`WHERE date < CURRENT_DATE(...)`) needs a one-line rationale so reviewers know it's intentional, not a bug.