Merge step (d): content merges for README and ce-brainstorm/plan/work

Applies triage docs 016-019 — merges upstream's structural refactor with
local's fork-specific additions.

README:
- Drop entries for locally-removed agents (dhh/kieran-rails, design/*,
  ankane-readme-writer, performance-oracle, security-sentinel,
  data-migration-expert)
- Add local custom skills (ce-john-voice, ce-hugo-blog-publisher,
  ce-story-lens, ce-essay-outline, ce-essay-edit, ce-excalidraw-png-export,
  ce-sync-confluence, ce-jira-ticket-writer, ce-upstream-merge,
  ce-proof-push, ce-ship-it, ce-weekly-shipped) under appropriate sections
- Add local custom agents (ce-design-conformance-reviewer,
  ce-tiangolo-fastapi-reviewer, ce-zip-agent-validator, ce-lint,
  ce-python-package-readme-writer)
- Add ce-fastapi-style, ce-python-package-writer to Development Frameworks
- Preserve "privacy/compliance angle" suffix on ce-data-integrity-guardian
- Add ce-previous-comments-reviewer entry (present in code, was missing
  from README)
- Update component counts to match actual filesystem (47 agents, 50 skills)

ce-brainstorm: insert Deploy wiring flag paragraph once in Phase 2
approach presentation (local carried this edit; deduped the accidental
double-insertion from the local diff).

ce-plan: insert Deploy wiring check bullet in "Every plan should contain"
list and in Phase 1 Repo Scan Signals section.

ce-work: insert "Did I add new env vars or config fields?" row in the
Phase 2 pattern-sensitive check table.

ce-work shipping-workflow: insert "If new env vars added to backend
config, deploy values files updated in same PR" line in pre-PR checklist.

All deploy-wiring additions reference
docs/solutions/deployment-issues/missing-env-vars-in-values-yaml.md
(note: the referenced solution doc doesn't exist yet — flagged for
follow-up).

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

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

@@ -191,6 +191,8 @@ For each approach, provide:
 
 After presenting all approaches, state 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

@@ -52,6 +52,7 @@ Every plan should contain:
 - Existing patterns or code references to follow
 - Enumerated test scenarios for each feature-bearing unit, specific enough that an implementer knows exactly what to test without inventing coverage themselves
 - Clear dependencies and sequencing
+- **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`.
 
 A plan is ready when an implementer can start confidently without needing the plan to write the code for them.
 
@@ -222,6 +223,7 @@ The ce-repo-research-analyst output includes a structured Technology & Infrastru
 - 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

@@ -220,6 +220,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
    | **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."
 

plugins/compound-engineering/skills/ce-work/references/shipping-workflow.md

@@ -111,6 +111,7 @@ Before creating PR, verify:
 - [ ] Figma designs match implementation (if applicable)
 - [ ] Evidence decision handled by `ce-commit-push-pr` when the change has observable behavior
 - [ ] 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)
 - [ ] Code review completed (inline self-review or full `ce-code-review`)
 - [ ] PR description includes summary, testing notes, and evidence when captured