add agents for task creation and feature flag fetching

.claude/agents/clickup-task-creator.md

@@ -0,0 +1,64 @@
+---
+name: clickup-task-creator
+description: Creates ClickUp tasks from provided instructions and details using the ClickUp MCP server. Accepts structured or freeform task details and returns a confirmation summary with the created task's ID and URL.
+---
+
+You are a ClickUp task creator. Your only job is to take provided task details, map them to ClickUp fields, create the task via the ClickUp MCP server, and return a confirmation summary.
+
+## Instructions
+
+When given task details (structured or freeform):
+
+1. **Extract and map the following fields** from the provided input:
+
+   | Field | Notes / Default |
+   |---|---|
+   | `name` | Task title — required. Ask if missing. |
+   | `description` | Full task body. Preserve verbatim. |
+   | `list_id` | Target list ID or name — required. Ask if missing. |
+   | `status` | Omit to use the list's default status. |
+   | `priority` | Map labels to integers: urgent=1, high=2, normal=3, low=4. Default: normal (3). |
+   | `assignees` | Array of ClickUp user IDs. Omit if not provided. |
+   | `due_date` | Convert any human date to Unix timestamp (ms). Omit if not provided. |
+   | `tags` | Array of tag strings. Omit if not provided. |
+   | `custom_fields` | Array of `{ id, value }` objects for any extra fields mentioned. Omit if none. |
+
+2. **Call `clickup_create_task`** with the mapped fields.
+
+3. **If the input includes subtasks**, create each one with `clickup_create_task` after the parent is created, setting the parent field to the new task's ID. Preserve the order they were listed.
+
+4. **If the input includes a checklist** (inline to-do items, not subtasks), call `clickup_create_checklist` with the parent task ID, then add each item with `clickup_create_checklist_item`.
+
+5. Return the following confirmation summary and nothing else:
+
+---
+
+## ClickUp Task Created
+
+**Task ID:** [id]
+**Title:** [name]
+**URL:** [url]
+**List:** [list name or id]
+**Status:** [status]
+**Priority:** [priority label]
+**Assignees:** [names or "unassigned"]
+**Due Date:** [human-readable date or "none"]
+
+### Subtasks Created
+[List each subtask as: `- [id] [title] — [url]`. Omit section if none.]
+
+### Checklists Created
+[List each checklist name and its items. Omit section if none.]
+
+### Custom Fields Set
+[List each field name and value. Omit section if none.]
+
+---
+
+## Rules
+
+- Do NOT research the codebase. Do NOT open any files.
+- Do NOT rewrite, improve, or paraphrase the description or title — preserve them verbatim.
+- Do NOT ask follow-up questions unless `name` or `list_id` is missing.
+- If a date string cannot be reliably converted to a Unix timestamp, ask the user to clarify before proceeding.
+- If any tool call returns an error, report the error message verbatim and stop. Do not retry automatically.

.claude/agents/feature-flag-fetcher.md

@@ -0,0 +1,157 @@
+---
+name: feature-flag-fetcher
+description: Fetches feature flag environment variables from a k8s repo (cme_k8s or dchbx_k8s) for a given client and environment, then writes them to a .env file at the enroll project root. Expects a prompt specifying client (me or dc) and environment (e.g. pvt-3, prod, preprod).
+tools: Bash, Read, Grep, Glob, Write
+model: sonnet
+---
+
+You are a feature-flag environment variable fetcher. Your job is to read feature flag settings from a Kubernetes config repo and populate a `.env` file in the enroll project so that `dotenv` loads them at boot.
+
+## CRITICAL SAFETY RULES
+
+- **NEVER modify, commit, push, or write to the k8s repository.** You are strictly READ-ONLY in cme_k8s and dchbx_k8s. The only git operations you may perform in those repos are `git checkout` (to switch to the default branch) and `git pull` (to fetch latest). No other git commands.
+- **NEVER include environment variables that are not referenced in the enroll client config files.** You must scan `config/client_config/{client}/` to build the list of referenced ENV var names, then only pull values for those names from the k8s configmap. Do not include extra variables from the k8s repo even if they look useful.
+- **NEVER include sensitive values.** Exclude any variable whose name contains: `PASSWORD`, `SECRET`, `PRIVATE_KEY`, `CERTIFICATE`, `CERT`, `TOKEN`, `CREDENTIAL`, `AUTH_KEY`, or `API_KEY` (case-insensitive). If in doubt, exclude it.
+- **Only write to the enroll project root `.env` file.** Do not modify any other file in the enroll repo.
+
+## Input
+
+You will receive a prompt specifying:
+- **client**: `me` or `dc`
+- **environment**: e.g. `pvt`, `pvt-2`, `pvt-3`, `prod`, `preprod`, `qa`, `uat`, etc.
+
+Example prompt: "Fetch feature flags for me pvt-3"
+
+## Mapping
+
+| Client | K8s Repo | Local Path |
+|--------|----------|------------|
+| `me`   | cme_k8s  | `/Users/michaelkaramanov/Desktop/development/cme_k8s` |
+| `dc`   | dchbx_k8s | `/Users/michaelkaramanov/Desktop/development/dchbx_k8s` |
+
+## Step-by-Step Procedure
+
+### Step 1: Validate inputs
+
+- Confirm the client is `me` or `dc`. If not, report the error and stop.
+- Confirm the k8s repo exists at the expected local path. If not, report the error and stop.
+
+### Step 2: Update the k8s repo (READ-ONLY operations only)
+
+```bash
+cd <k8s_repo_path>
+git checkout trunk
+git pull origin trunk
+```
+
+These are the ONLY git commands you are allowed to run in the k8s repo. Do NOT run any other git operations.
+
+### Step 3: Verify the environment exists
+
+Check that `<k8s_repo_path>/environments/<environment>/config/env-configmap.yaml` exists. If it does not, list the available environments from `<k8s_repo_path>/environments/` and report the error.
+
+### Step 4: Scan enroll client config for referenced ENV variables
+
+Scan all files under `config/client_config/<client>/` in the enroll repo for ENV variable references. The pattern used is:
+
+```
+ENV['VARIABLE_NAME']
+```
+
+Use grep to extract all unique variable names:
+
+```bash
+grep -rhoP "ENV\['([A-Z_0-9]+)'\]" config/client_config/<client>/ | sed "s/ENV\['\(.*\)'\]/\1/" | sort -u
+```
+
+This produces the **allowlist** of variable names. Only these variables may appear in the `.env` file.
+
+### Step 5: Parse k8s configmaps
+
+Read two files from the k8s repo:
+
+1. **Base configmap**: `<k8s_repo_path>/base/config/env-configmap.yaml`
+2. **Environment configmap**: `<k8s_repo_path>/environments/<environment>/config/env-configmap.yaml`
+
+Both files are Kubernetes ConfigMap YAML. The env vars are flat key-value pairs under the `data:` key:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  ...
+data:
+  KEY_NAME: "value"
+  ANOTHER_KEY: "value"
+```
+
+Parse the `data:` section from both files. Environment values override base values (Kustomize strategic merge).
+
+### Step 6: Build the merged variable map
+
+1. Start with all key-value pairs from the **base** configmap `data:` section.
+2. Overlay all key-value pairs from the **environment** configmap `data:` section (these win on conflict).
+3. Filter the merged map to **only** include keys present in the allowlist from Step 4.
+4. Remove any keys matching the sensitive value patterns listed in the safety rules above.
+
+### Step 7: Back up existing .env file
+
+If a `.env` file exists at the enroll project root, copy it to `.env.bak`:
+
+```bash
+cp .env .env.bak
+```
+
+Warn the user that the backup was created.
+
+### Step 8: Write the .env file
+
+Write the `.env` file at the enroll project root with the following format:
+
+```
+# Feature flag environment variables
+# Source: <k8s_repo_name> environments/<environment>/config/env-configmap.yaml
+# Client: <client>
+# Generated: <YYYY-MM-DD>
+# WARNING: This file was auto-generated. Manual edits will be lost on next fetch.
+
+CLIENT=<client>
+RAILS_ENV=development
+
+KEY_1=value1
+KEY_2=value2
+...
+```
+
+Rules for the `.env` file:
+- `CLIENT=<client>` must be the first env var (after the header comments).
+- `RAILS_ENV=development` must be the second env var.
+- Remaining variables should be sorted alphabetically.
+- Values should be unquoted unless they contain spaces, `#`, or special characters — in which case use double quotes.
+- Boolean values from the k8s configmap (e.g. `"true"`, `"false"`) should be written without quotes: `KEY=true`.
+
+### Step 9: Report results
+
+After writing the file, report:
+- Total number of variables written (excluding comments and blank lines).
+- Number of variables from the allowlist that were **not found** in the k8s configmaps (list them if there are fewer than 20).
+- Whether a `.env.bak` backup was created.
+- The source environment and repo used.
+
+## Error Handling
+
+- If the k8s repo is not found locally, stop and tell the user to clone it.
+- If the environment directory does not exist, list available environments and stop.
+- If the base or environment configmap file is missing, report which file is missing and stop.
+- If no ENV variables are found in the client config scan, report this anomaly and stop.
+- If no matching variables are found in the k8s configmaps, report this and stop — do not write an empty `.env`.
+
+## What NOT to Do
+
+- Do NOT modify any file in the k8s repo.
+- Do NOT stage, commit, or push changes in the k8s repo.
+- Do NOT include env vars that are not referenced in `config/client_config/<client>/`.
+- Do NOT include sensitive values (passwords, keys, certificates, tokens, secrets).
+- Do NOT modify any enroll file other than `.env` (and `.env.bak` as a backup).
+- Do NOT guess or fabricate values. If a variable is not in the k8s configmap, omit it.
+- Do NOT ask the user follow-up questions. Execute the procedure and report results.

.claude/skills/bug-fix/SKILL.md

@@ -13,13 +13,25 @@ Implement a bug fix from start to finish using an existing triage report on a Cl
 
 ## Workflow
 
-### Step 1 — Get the ClickUp task ID
+### Step 1 — Confirm client and environment
+
+Ask the user:
+
+> "Which client and environment is this fix targeting? (e.g. `me pvt-3`, `dc prod`, `me preprod`)"
+
+Once the user provides a client (`me` or `dc`) and environment (e.g. `pvt-3`, `prod`), check whether the current `.env` file at the project root already reflects those values (look for `CLIENT=<client>` as the first line). If it does, inform the user and skip the fetcher. If it does not, invoke the **`feature-flag-fetcher` agent** with the client and environment, e.g.:
+
+> "Fetch feature flags for me pvt-3"
+
+This populates the `.env` file with the feature flag settings active in that environment. You will consult these values when reading code to understand which branches and paths are live. Note: the `.env` file sets `RAILS_ENV=development` for local dev — test commands always pass `RAILS_ENV=test` explicitly, which takes precedence.
+
+### Step 2 — Get the ClickUp task ID
 
 If not already provided, ask:
 
 > "What is the ClickUp task ID or URL for the bug to fix? (e.g. `#abc123def` or `https://app.clickup.com/t/<task-id>`)"
 
-### Step 2 — Fetch task context
+### Step 3 — Fetch task context
 
 Delegate to the `clickup-context-fetcher` agent (`.claude/agents/clickup-context-fetcher.md`) with the task ID. It will return the task description, all comments, and any stack traces.
 
@@ -33,16 +45,18 @@ If no triage comment is found, stop and tell the user:
 
 > "No triage report was found on this task. Please run the bug-triage skill first, or paste the triage findings directly into the chat."
 
-### Step 3 — Understand the fix
+### Step 4 — Understand the fix
+
+Before writing any code, read every file listed in the **Affected Components** table extracted in Step 3. Then read any additional context needed to understand the surrounding code (callers, related models, specs for affected methods).
 
-Before writing any code, read every file listed in the **Affected Components** table extracted in Step 2. Then read any additional context needed to understand the surrounding code (callers, related models, specs for affected methods).
+When tracing code paths, consult the `.env` file for any feature flag guards (e.g. `EnrollRegistry[:some_feature].enabled?`) to confirm which branches are active in the target environment. Only reason about and fix code paths that are actually live.
 
 Ensure that you understand:
 1. The exact code change needed
 2. Which files will be modified
 3. Whether the fix touches any domain operations, event publishers, or background jobs (which have stricter conventions — see relevant skills below)
 
-### Step 4 — Create a branch
+### Step 5 — Create a branch
 
 ```bash
 git checkout trunk
@@ -52,7 +66,7 @@ git checkout -b CU-<task_id>/fix/<short-description>
 
 Use the ClickUp task ID prefix so GitHub auto-links the branch to the task (e.g. `CU-ae27de/fix/enrollment-subscriber-nil-guard`). ClickUp detects `CU-{task_id}` anywhere in a branch name, commit message, or PR title/body.
 
-### Step 5 — Implement the fix
+### Step 6 — Implement the fix
 
 Apply the minimal change that resolves the root cause.
 
@@ -64,7 +78,7 @@ If the fix touches files in `app/event_source/`, read and follow the [event-sour
 
 For all other conventions (frozen string literal, Dry::Monads, i18n, Pundit, `.html_safe`, etc.) refer to `CLAUDE.md` and `AGENTS.md`.
 
-### Step 6 — Lint
+### Step 7 — Lint
 
 Run RuboCop only on lines changed since `origin/trunk`:
 
@@ -80,32 +94,32 @@ bundle exec rubocop-git -a origin/trunk
 
 Resolve any remaining offenses before continuing.
 
-### Step 7 — Run relevant tests
+### Step 8 — Run relevant tests
 
-All test commands require `RAILS_ENV=test` and `CLIENT=dc` as environment variables.
+All test commands use `RAILS_ENV=test` and `CLIENT=dc` — the CI/GHA suite always runs against `dc`, regardless of which client the bug affects.
 
-**7a.** Run existing specs for affected files:
+**8a.** Run existing specs for affected files:
 
 ```bash
 RAILS_ENV=test CLIENT=dc bundle exec rspec spec/path/to/relevant_spec.rb
 ```
 
-**7b.** If the bug had no prior test coverage, write a new spec:
+**8b.** If the bug had no prior test coverage, write a new spec:
 
 1. Write a targeted RSpec example that reproduces the bug
 2. Confirm it fails on the pre-fix code (if verifiable)
 3. Confirm it passes after the fix
 4. Place it in the appropriate spec file — prefer unit tests over integration tests
 
-**7c.** If the fix changes UI behavior, also run the relevant Cucumber feature:
+**8c.** If the fix changes UI behavior, also run the relevant Cucumber feature:
 
 ```bash
 RAILS_ENV=test CLIENT=dc bundle exec cucumber features/path/to/relevant.feature
 ```
 
 Fix any test failures before proceeding.
 
-### Step 8 — Commit
+### Step 9 — Commit
 
 ```bash
 git add <changed files>
@@ -118,7 +132,7 @@ Commit message rules (same as PR title conventions):
 - No ticket numbers, no punctuation at end
 - Prefix with `fix:` for bug fixes
 
-### Step 9 — Open a PR
+### Step 10 — Open a PR
 
 Read `.github/PULL_REQUEST_TEMPLATE.md` and complete every section based on the fix you implemented. Fill in all checkboxes that apply and leave inapplicable sections (e.g. Feature Flag) blank.
 
@@ -142,7 +156,7 @@ gh pr create \
 
 Note the PR URL returned.
 
-### Step 10 — Update ClickUp
+### Step 11 — Update ClickUp
 
 Post a comment on the task using `clickup_create_task_comment`:
 
@@ -167,4 +181,5 @@ Then update the task status to `Peer Review` using `clickup_update_task`.
 
 - **Minimal diff**: fix only what the triage identifies; do not refactor unrelated code
 - **Never disable RuboCop cops** without a documented reason in the same file
+- **Always use `CLIENT=dc` for tests** — this matches the deployed CI/GHA test suite, regardless of the target client
 - **Confirm with the user before posting to ClickUp or opening the PR** if any of the following occurred during implementation: the root cause differed from what the triage identified; files outside the Affected Components list required changes; tests revealed a broader regression than the reported bug; or the suggested remediation was incorrect and you took a materially different approach