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-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