Resolve stash conflicts: keep upstream + local deploy wiring checks

Merge upstream's ce-brainstorm skip-menu guidance and ce-plan
repo-research-analyst integration with local deploy wiring flag
additions.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

plugins/compound-engineering/skills/ce-brainstorm/SKILL.md

@@ -144,6 +144,8 @@ For each approach, provide:
 
 Lead with your recommendation and explain why. Prefer simpler solutions when added complexity creates real carrying cost, but do not reject low-cost, high-value polish just because it is not strictly necessary.
 
+**Deploy wiring flag:** If any approach introduces new backend env vars or config fields, call this out explicitly in the approach description. Deploy values files (e.g. `values.yaml`, `.env.*`, Terraform vars) must be updated alongside the config code — not as a follow-up. This is a hard-won lesson; see `docs/solutions/deployment-issues/missing-env-vars-in-values-yaml.md`.
+
 If one approach is clearly best and alternatives are not meaningful, skip the menu and state the recommendation directly.
 
 If relevant, call out whether the choice is:

plugins/compound-engineering/skills/ce-plan/SKILL.md

@@ -187,6 +187,7 @@ The repo-research-analyst output includes a structured Technology & Infrastructu
 - If the feature touches a technology layer the scan found absent or thin (e.g., no existing proto files when planning a new gRPC service), lean toward external research -- there are no local patterns to follow
 - If the scan detected deployment infrastructure (Docker, K8s, serverless), note it in the planning context passed to downstream agents so they can account for deployment constraints
 - If the scan detected a monorepo and scoped to a specific service, pass that service's tech context to downstream research agents -- not the aggregate of all services. If the scan surfaced the workspace map without scoping, use the feature description to identify the relevant service before proceeding with research
+- **Deploy wiring check**: If the feature adds new env vars to backend config (`config.py`, `settings.py`, or similar), the plan MUST include explicit tasks for updating deploy values files (e.g. `values.yaml` for Helm, `.env.*` files, Terraform vars). This is not a follow-up — the feature is not done until deploy config is wired. See `docs/solutions/deployment-issues/missing-env-vars-in-values-yaml.md`.
 
 **Always lean toward external research when:**
 - The topic is high-risk: security, payments, privacy, external APIs, migrations, compliance

plugins/compound-engineering/skills/ce-work/SKILL.md

@@ -145,6 +145,7 @@ This command takes a work document (plan, specification, or todo file) and execu
    | **Can failure leave orphaned state?** If your code persists state (DB row, cache, file) before calling an external service, what happens when the service fails? Does retry create duplicates? | Trace the failure path with real objects. If state is created before the risky call, test that failure cleans up or that retry is idempotent. |
    | **What other interfaces expose this?** Mixins, DSLs, alternative entry points (Agent vs Chat vs ChatMethods). | Grep for the method/behavior in related classes. If parity is needed, add it now — not as a follow-up. |
    | **Do error strategies align across layers?** Retry middleware + application fallback + framework error handling — do they conflict or create double execution? | List the specific error classes at each layer. Verify your rescue list matches what the lower layer actually raises. |
+   | **Did I add new env vars or config fields?** If you added a field to backend config (e.g. `config.py`, `settings.py`), the deploy values files (`values.yaml`, `.env.*`, Terraform vars) must be updated in the same PR. | Check deploy config files for the new var. If missing, add it now — not as a follow-up. Features with unwired config silently fail in staging/production. See `docs/solutions/deployment-issues/missing-env-vars-in-values-yaml.md`. |
 
    **When to skip:** Leaf-node changes with no callbacks, no state persistence, no parallel interfaces. If the change is purely additive (new helper method, new view partial), the check takes 10 seconds and the answer is "nothing fires, skip."
 
@@ -464,6 +465,7 @@ Before creating PR, verify:
 - [ ] Figma designs match implementation (if applicable)
 - [ ] Before/after screenshots captured and uploaded (for UI changes)
 - [ ] Commit messages follow conventional format
+- [ ] If new env vars added to backend config, deploy values files updated in same PR (not a follow-up)
 - [ ] PR description includes Post-Deploy Monitoring & Validation section (or explicit no-impact rationale)
 - [ ] PR description includes summary, testing notes, and screenshots
 - [ ] PR description includes Compound Engineered badge with accurate model, harness, and version

plugins/compound-engineering/skills/jira-ticket-writer/SKILL.md

@@ -7,11 +7,6 @@ description: This skill should be used when the user wants to create a Jira tick
 
 Write Jira tickets that sound like a human wrote them. Drafts go through tone review before the user sees them, and nothing gets created without explicit approval.
 
-## Reference
-For tickets pertaining to Talent Engine (Agentic App), TalentOS, Comparably, or the ATS Platform: Use the `ZAS` Jira project
-When creating epics and tickets for Talent Engine always add the label `talent-engine` and prefix the name with "[Agentic App]"
-When creating epics and tickets for the ATS Platform always add the label `ats-platform` and prefix the name with "[ATS Platform]"
-
 ## Workflow
 
 ### Phase 1: Validate Scope