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