feat(skills): add 5 engineering skills + wire into worker pipeline (v0.1.38)

New skills:
- flow-code-security: OWASP Top 10, three-tier boundary (Always/Ask/Never),
  secrets management, input validation, file upload safety
- flow-code-code-review: five-axis review (correctness/readability/architecture/
  security/performance), severity labels (Critical→FYI), change sizing
- flow-code-incremental: vertical slicing, Implement→Test→Verify→Commit cycle,
  scope discipline, Save Point Pattern, rollback-friendly commits
- flow-code-tdd: Red-Green-Refactor cycle, Prove-It Pattern for bugs,
  test pyramid (80/15/5), DAMP over DRY, mock guidance
- flow-code-simplify: Chesterton's Fence, 18 simplification patterns,
  behavior preservation, dead code removal + /flow-code:simplify command

Pipeline integration:
- Worker Phase 4: references flow-code-tdd skill + Prove-It Pattern
- Worker Phase 5: references flow-code-incremental for vertical slicing
- Worker Phase 6: upgraded to five-axis self-review from flow-code-code-review
- Worker domain table: all domains load incremental + code-review skills;
  backend/architecture/ops load security skill; testing loads tdd skill
- Existing flow-code-api-design already complete (kept as-is)

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

Author: z23cc

agents/worker.md

@@ -251,21 +251,28 @@ Parse the spec carefully. Identify:
 **Domain-specific skill loading:**
 Based on the task `domain` field, you MUST Read and follow the corresponding skill file. This is a quality gate — not optional.
 
-| Domain | Skill file to load | Focus |
-|--------|-------------------|-------|
-| `frontend` | `skills/flow-code-frontend-ui/SKILL.md` | Component architecture, design system, accessibility, AI aesthetic avoidance |
-| `backend` | Apply `flow-code-api-design` patterns (if skill exists) | API design, DB queries, error handling, input validation |
-| `testing` | Apply `flow-code-debug` patterns | Test coverage, edge cases, regression guards |
+| Domain | Skill files to load | Focus |
+|--------|---------------------|-------|
+| `frontend` | `flow-code-frontend-ui` | Component architecture, design system, accessibility, AI aesthetic avoidance |
+| `backend` | `flow-code-api-design` + `flow-code-security` | API design, DB queries, input validation, OWASP prevention |
+| `testing` | `flow-code-tdd` + `flow-code-debug` | TDD Red-Green-Refactor, Prove-It Pattern, test pyramid |
 | `docs` | Follow project's doc conventions | Accuracy, completeness, cross-references |
-| `architecture` | Apply `flow-code-api-design` patterns | Module boundaries, dependency direction, interface stability |
-| `ops` | Focus on idempotency, rollback safety, monitoring | CI/CD, infra, deploy scripts |
+| `architecture` | `flow-code-api-design` + `flow-code-security` | Module boundaries, dependency direction, contract-first |
+| `ops` | `flow-code-security` | Idempotency, rollback safety, secrets management, monitoring |
+
+**All domains additionally load:**
+- `flow-code-incremental` — vertical slicing, scope discipline, Implement→Test→Verify→Commit cycle
+- `flow-code-code-review` — five-axis self-review in Phase 6
 
 ```bash
-# Example: load frontend skill
+# Load domain skills (read each that exists)
 PLUGIN_ROOT="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}"
+cat "$PLUGIN_ROOT/skills/flow-code-incremental/SKILL.md"
+cat "$PLUGIN_ROOT/skills/flow-code-code-review/SKILL.md"
+# Then load domain-specific skills per table above, e.g.:
 cat "$PLUGIN_ROOT/skills/flow-code-frontend-ui/SKILL.md"
 ```
-If the skill file does not exist for a domain, apply the domain focus guidelines from the table above.
+If a skill file does not exist, skip it and apply the focus guidelines from the table above.
 
 **Baseline check:**
 ```bash
@@ -361,7 +368,7 @@ END
 
 **Skip this phase if TDD_MODE is not `true`.**
 
-Before implementing the feature, write failing tests first:
+Follow the `flow-code-tdd` skill for the full TDD methodology. Core cycle:
 
 1. **Red** — Write test(s) that cover the acceptance criteria. Run them to confirm they FAIL:
    ```bash
@@ -374,12 +381,16 @@ Before implementing the feature, write failing tests first:
 
 3. **Refactor** — After tests pass, clean up without changing behavior. Run tests again to confirm still green.
 
+**For bug fixes**: always use the Prove-It Pattern — write a test that demonstrates the bug, confirm it fails, then fix.
+
 The key constraint: **no implementation code before a failing test exists**. This ensures every change is test-driven.
 <!-- /section:tdd -->
 
 <!-- section:core -->
 ## Phase 5: Implement
 
+Follow the `flow-code-incremental` skill: build in vertical slices (Implement→Test→Verify→Commit per slice). Each slice leaves the system working. Scope discipline: only touch what the task spec requires.
+
 **First, capture base commit for scoped review:**
 ```bash
 BASE_COMMIT=$(git rev-parse HEAD)
@@ -529,17 +540,23 @@ Continue until guard passes. There is no retry limit — this is not a retry loo
 
 **Teams mode constraint:** When `TEAM_MODE=true`, only fix files in `OWNED_FILES`. If the failure is caused by a file you don't own, request access via `flowctl approval create --kind file_access` + `approval show --wait` (or fallback `Need file access:` SendMessage), then wait for a resolution. If access is rejected or times out, note the issue in your completion summary.
 
-### Step 2: Review your own diff
+### Step 2: Five-axis self-review
+
+Follow the `flow-code-code-review` skill. Review your own diff across all five axes:
+
 ```bash
 git diff
 ```
 
-Scan your changes for obvious issues:
+**Axis 1 — Correctness:** Does it match the spec? Edge cases handled?
+**Axis 2 — Readability:** Clear names? Functions <40 lines? No dead code?
+**Axis 3 — Architecture:** Follows project patterns? Module boundaries respected?
+**Axis 4 — Security:** Input validated? Queries parameterized? No secrets in code?
+**Axis 5 — Performance:** No N+1 queries? No unbounded fetches? No main-thread blocking?
 
+Also check:
 - No commented-out code or debug prints left behind
 - No hardcoded values that should be constants/config
-- Naming is consistent with existing codebase patterns
-- New functions handle error cases, not just happy path
 - No duplicate logic — reuse existing utilities
 
 If you find issues, fix them and re-run `<FLOWCTL> guard` to verify.

bin/flowctl

@@ -0,0 +1,13 @@
+---
+name: flow-code:simplify
+description: "Reduce code complexity while preserving exact behavior"
+argument-hint: "[file or directory to simplify]"
+---
+
+# IMPORTANT: This command MUST invoke the skill `flow-code-simplify`
+
+The ONLY purpose of this command is to call the `flow-code-simplify` skill. You MUST use that skill now.
+
+**User request:** $ARGUMENTS
+
+Pass the user request to the skill. The skill handles all code simplification logic.

commands/flow-code/simplify.md

@@ -1,6 +1,6 @@
 [package]
 name = "flowctl-cli"
-version = "0.1.37"
+version = "0.1.38"
 description = "CLI entry point for flowctl"
 edition.workspace = true
 rust-version.workspace = true

flowctl/crates/flowctl-cli/Cargo.toml

@@ -0,0 +1,201 @@
+---
+name: flow-code-code-review
+description: "Use when reviewing code changes — self-review in Worker Phase 6, impl-review, or PR review. Applies five-axis scoring with severity labels."
+tier: 2
+user-invocable: true
+---
+<!-- SKILL_TAGS: review,quality,correctness,security -->
+
+# Five-Axis Code Review
+
+> **Startup:** Follow [Startup Sequence](../_shared/preamble.md) before proceeding.
+
+## flowctl Setup
+
+```bash
+FLOWCTL="$HOME/.flow/bin/flowctl"
+```
+
+## Overview
+
+Structured code review across five orthogonal axes. Every finding gets a severity label. Every review ends with a clear verdict. This replaces ad-hoc "looks good" reviews with systematic quality gates.
+
+## When to Use
+
+- Worker Phase 6 (self-review before commit)
+- Implementation review (impl-review phase)
+- PR review before merge
+- Manual code review requests
+
+**When NOT to use:**
+- Plan review (that checks spec alignment, not code quality)
+- Architecture design review (use flow-code-api-design instead)
+
+## The Five Axes
+
+Review every diff across these five dimensions. Each axis is independent — a change can score well on correctness but poorly on security.
+
+### Axis 1: Correctness
+
+- Does the code do what the spec says?
+- Are edge cases handled? (null, empty, boundary values, overflow)
+- Are errors caught and handled appropriately?
+- Do tests cover the actual behavior, not just happy path?
+- Are race conditions possible under concurrent access?
+
+### Axis 2: Readability & Simplicity
+
+- Can a new team member understand this code without explanation?
+- Are names clear and specific? (`processData` → `validateUserInput`)
+- Is the logic straightforward or unnecessarily clever?
+- Are functions under 40 lines? Files under 300 lines?
+- Is there dead code, commented-out code, or TODOs that should be tickets?
+
+### Axis 3: Architecture
+
+- Does the change follow existing project patterns?
+- Are module boundaries respected? (no cross-layer imports)
+- Is the abstraction level appropriate? (not too deep, not too shallow)
+- Would this change make future modifications harder?
+- Are dependencies flowing in the right direction?
+
+### Axis 4: Security
+
+- Is all user input validated at the boundary?
+- Are queries parameterized?
+- Are auth and authorization checks present where needed?
+- Are secrets, tokens, or PII protected?
+- See `flow-code-security` skill for full checklist.
+
+### Axis 5: Performance
+
+- Are there N+1 query patterns?
+- Are there unbounded loops or data fetches?
+- Could this block the main thread or event loop?
+- Are expensive operations cached where appropriate?
+- Are there unnecessary re-renders (React) or recomputations?
+
+## Severity Labels
+
+Every finding MUST have a severity label:
+
+| Label | Meaning | Action Required |
+|-------|---------|-----------------|
+| **Critical** | Blocks merge. Bug, security hole, data loss risk. | Must fix before proceeding. |
+| **Important** | Should fix. Correctness concern or significant quality issue. | Fix unless strong justification. |
+| **Suggestion** | Consider this. Improvement opportunity. | Author decides. |
+| **Nit** | Minor style or naming preference. | Author may ignore. |
+| **FYI** | Informational. No action needed. | For awareness only. |
+
+## Change Sizing
+
+| Lines Changed | Rating | Action |
+|---------------|--------|--------|
+| ~100 | Good | Easy to review thoroughly |
+| ~300 | Acceptable | Review in one sitting |
+| ~500 | Large | Consider splitting |
+| ~1000+ | Too large | Split into smaller changes |
+
+If a diff exceeds 500 lines, flag it: "This change is large (~N lines). Consider splitting into focused commits."
+
+## Review Process
+
+### Step 1: Understand Context
+
+Before looking at code:
+- Read the task spec / PR description
+- Understand WHAT should have changed and WHY
+- Check which files are expected to change
+
+### Step 2: Review Tests First
+
+- Do tests exist for the change?
+- Do they test behavior, not implementation?
+- Are edge cases covered?
+- Would the tests catch a regression if someone reverted the key logic?
+
+### Step 3: Review Implementation
+
+Walk through the diff with all five axes active:
+- Read file-by-file in dependency order (utilities → services → handlers → tests)
+- For each file, check all five axes
+- Note findings with severity labels
+
+### Step 4: Categorize Findings
+
+Group findings by severity:
+```
+## Critical (must fix)
+- [Correctness] Missing null check on user.email (line 42) — NPE in production
+- [Security] SQL built with template literal (line 89) — injection risk
+
+## Important (should fix)
+- [Architecture] Direct DB access from handler — should go through service layer
+- [Performance] Fetching all users to count them — use COUNT query
+
+## Suggestions
+- [Readability] Rename `processData` to `validateOrderInput` for clarity
+- [Readability] Extract lines 120-145 into a named function
+
+## Nits
+- [Readability] Inconsistent spacing in object literal (line 67)
+```
+
+### Step 5: Verdict
+
+| Verdict | Criteria |
+|---------|----------|
+| **SHIP** | Zero Critical, zero Important, all Suggestions are minor |
+| **NEEDS_WORK** | Has Critical or Important findings that need fixes |
+| **MAJOR_RETHINK** | Fundamental approach is wrong — need to redesign |
+
+## Multi-Model Review Pattern
+
+For highest quality, use cross-model review:
+1. Model A (Claude) writes the code
+2. Model B (Codex/different model) reviews independently
+3. Model A addresses findings
+4. Human approves final result
+
+This catches blind spots that same-model review misses.
+
+## Dead Code Hygiene
+
+During review, flag:
+- Commented-out code blocks (delete or create a ticket)
+- Unused imports, variables, functions
+- Feature flags for features that shipped months ago
+- `TODO` comments older than 30 days without tickets
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It works, so it's fine" | Working code can still have security holes, performance issues, and maintenance debt. |
+| "We'll clean it up later" | Later never comes. Fix it now or create a tracked ticket. |
+| "It's just a nit" | Accumulated nits become a maintenance burden. Fix the pattern, not individual instances. |
+| "The tests pass" | Tests only catch what they test for. Review the untested paths. |
+| "I don't have context on this area" | Say so. Ask questions. Don't rubber-stamp code you don't understand. |
+
+## Red Flags
+
+- No tests added for new behavior
+- Error handling that swallows exceptions silently
+- Magic numbers or strings without constants
+- Functions with more than 4 parameters
+- Deeply nested conditionals (3+ levels)
+- Mixed concerns in a single commit (feature + refactor + config change)
+- TODOs without ticket references
+- Changes to generated files
+
+## Verification
+
+After completing a review:
+
+- [ ] All five axes evaluated (correctness, readability, architecture, security, performance)
+- [ ] Every finding has a severity label
+- [ ] Critical/Important findings have specific fix guidance
+- [ ] Clear SHIP / NEEDS_WORK / MAJOR_RETHINK verdict given
+- [ ] Change size noted if >500 lines
+- [ ] Tests reviewed before implementation
+- [ ] No rubber-stamping — every approval reflects genuine review