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/README.md

@@ -10,8 +10,8 @@ After installing, run `/ce-setup` in any project. It diagnoses your environment,
 
 | Component | Count |
 |-----------|-------|
-| Agents | 50+ |
-| Skills | 42+ |
+| Agents | 47 |
+| Skills | 50 |
 
 ## Skills
 
@@ -68,8 +68,9 @@ For `/ce-optimize`, see [`skills/ce-optimize/README.md`](./skills/ce-optimize/RE
 | Skill | Description |
 |-------|-------------|
 | `ce-agent-native-architecture` | Build AI agents using prompt-native architecture |
-| `ce-dhh-rails-style` | Write Ruby/Rails code in DHH's 37signals style |
+| `ce-fastapi-style` | Write FastAPI/Python code following modern async, Pydantic, and dependency-injection conventions |
 | `ce-frontend-design` | Create production-grade frontend interfaces |
+| `ce-python-package-writer` | Scaffold Python packages with pyproject, typed code, and ergonomic test/release conventions |
 
 ### Review & Quality
 
@@ -82,12 +83,24 @@ For `/ce-optimize`, see [`skills/ce-optimize/README.md`](./skills/ce-optimize/RE
 | Skill | Description |
 |-------|-------------|
 | `ce-proof` | Create, edit, and share documents via Proof collaborative editor |
+| `ce-john-voice` | Write content in John Lamb's voice — applies core voice, venue guides, signature moves, and a revision checklist |
+| `ce-hugo-blog-publisher` | Publish posts to a Hugo blog via SSH — supports `links` (pull-quote + commentary) and `blog` (original essays) post types |
+| `ce-story-lens` | Apply Saunders-framework story structure to essays and long-form writing |
+| `ce-essay-outline` | Transform a brain dump into a story-structured essay outline |
+| `ce-essay-edit` | Polish a written essay through structural and line-level editing, preserving the author's voice |
 
 ### Automation & Tools
 
 | Skill | Description |
 |-------|-------------|
 | `ce-gemini-imagegen` | Generate and edit images using Google's Gemini API |
+| `ce-excalidraw-png-export` | Generate and export Excalidraw diagrams to PNG with canvas measurement and validation |
+| `ce-sync-confluence` | Sync Markdown docs to Confluence pages |
+| `ce-jira-ticket-writer` | Write Jira tickets with project-specific tone, API reference, and structural guidance |
+| `ce-upstream-merge` | Reconcile upstream changes into this local fork while preserving local intent |
+| `ce-proof-push` | Push local changes to Proof for collaborative edit |
+| `ce-ship-it` | Execute the final-shipping checklist after a PR is approved |
+| `ce-weekly-shipped` | Summarize what shipped across a week from commits, PRs, and session history |
 
 ### Beta / Experimental
 
@@ -111,26 +124,25 @@ Agents are specialized subagents invoked by skills — you typically don't call
 | `ce-architecture-strategist` | Analyze architectural decisions and compliance |
 | `ce-code-simplicity-reviewer` | Final pass for simplicity and minimalism |
 | `ce-correctness-reviewer` | Logic errors, edge cases, state bugs |
-| `ce-data-integrity-guardian` | Database migrations and data integrity |
-| `ce-data-migration-expert` | Validate ID mappings match production, check for swapped values |
+| `ce-data-integrity-guardian` | Database migrations and data integrity (privacy/compliance angle) |
 | `ce-data-migrations-reviewer` | Migration safety with confidence calibration |
 | `ce-deployment-verification-agent` | Create Go/No-Go deployment checklists for risky data changes |
-| `ce-dhh-rails-reviewer` | Rails review from DHH's perspective |
+| `ce-design-conformance-reviewer` | Review code for deviations from design intent and plan completeness |
 | `ce-julik-frontend-races-reviewer` | Review JavaScript/Stimulus code for race conditions |
-| `ce-kieran-rails-reviewer` | Rails code review with strict conventions |
-| `ce-kieran-python-reviewer` | Python code review with strict conventions |
+| `ce-kieran-python-reviewer` | Python code review with strict conventions, plus FastAPI-specific hunting |
 | `ce-kieran-typescript-reviewer` | TypeScript code review with strict conventions |
 | `ce-maintainability-reviewer` | Coupling, complexity, naming, dead code |
 | `ce-pattern-recognition-specialist` | Analyze code for patterns and anti-patterns |
-| `ce-performance-oracle` | Performance analysis and optimization |
 | `ce-performance-reviewer` | Runtime performance with confidence calibration |
+| `ce-previous-comments-reviewer` | Verify prior PR review feedback has been addressed |
 | `ce-reliability-reviewer` | Production reliability and failure modes |
 | `ce-schema-drift-detector` | Detect unrelated schema.rb changes in PRs |
 | `ce-security-reviewer` | Exploitable vulnerabilities with confidence calibration |
-| `ce-security-sentinel` | Security audits and vulnerability assessments |
 | `ce-swift-ios-reviewer` | Swift and iOS code review -- SwiftUI state, retain cycles, concurrency, Core Data threading, accessibility |
 | `ce-testing-reviewer` | Test coverage gaps, weak assertions |
+| `ce-tiangolo-fastapi-reviewer` | FastAPI code review from tiangolo's perspective (anti-patterns, conventions) |
 | `ce-project-standards-reviewer` | CLAUDE.md and AGENTS.md compliance |
+| `ce-zip-agent-validator` | Pressure-test zip-agent PR review comments against codebase context |
 | `ce-adversarial-reviewer` | Construct failure scenarios to break implementations across component boundaries |
 
 ### Document Review
@@ -159,18 +171,11 @@ Agents are specialized subagents invoked by skills — you typically don't call
 | `ce-slack-researcher` | Search Slack for organizational context relevant to the current task |
 | `ce-web-researcher` | Perform iterative web research and return structured external grounding (prior art, adjacent solutions, market signals, cross-domain analogies) |
 
-### Design
-
-| Agent | Description |
-|-------|-------------|
-| `ce-design-implementation-reviewer` | Verify UI implementations match Figma designs |
-| `ce-design-iterator` | Iteratively refine UI through systematic design iterations |
-| `ce-figma-design-sync` | Synchronize web implementations with Figma designs |
-
 ### Workflow
 
 | Agent | Description |
 |-------|-------------|
+| `ce-lint` | Run Python linting and code quality checks (ruff, mypy, djlint, bandit) |
 | `ce-pr-comment-resolver` | Address PR comments and implement fixes |
 | `ce-spec-flow-analyzer` | Analyze user flows and identify gaps in specifications |
 
@@ -178,7 +183,7 @@ Agents are specialized subagents invoked by skills — you typically don't call
 
 | Agent | Description |
 |-------|-------------|
-| `ce-ankane-readme-writer` | Create READMEs following Ankane-style template for Ruby gems |
+| `ce-python-package-readme-writer` | Create READMEs following concise documentation style for Python packages |
 
 ## Installation
 

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