agentic-sdlc-wizard 1.18.0 → 1.20.0

package/CHANGELOG.md

@@ -4,6 +4,25 @@ All notable changes to the SDLC Wizard.
 
 > **Note:** This changelog is for humans to read. Don't manually apply these changes - just run the wizard ("Check for SDLC wizard updates") and it handles everything automatically.
 
+## [1.20.0] - 2026-03-31
+
+### Added
+- CC version-pinned update gate — E2E tests run actual new CC version, not bundled binary (#46)
+- Tier 1 E2E flakiness fix — regression threshold 1.5→3.0, absorbs ±2-3 point LLM variance (#47)
+- Flaky test prevention guidance with external reference in wizard, SKILL.md
+- 2 release consistency tests (package.json ↔ CHANGELOG ↔ SDLC.md version parity)
+
+## [1.19.0] - 2026-03-31
+
+### Added
+- CI Local Shepherd Model — two-tier CI fix model (shepherd primary, bot fallback), SHA-based suppression (#36)
+- Gap Analysis vs `/claude-automation-recommender` — complementary tools positioning (#35)
+- `/clear` vs `/compact` context management guidance (#38)
+- Token efficiency auditing — `/cost`, `--max-budget-usd`, OpenTelemetry (#42)
+- Blank repo support — verified clean install, 10 new E2E tests (#31)
+- Feature documentation enforcement — ADR guidance, `claude-md-improver`, doc sync in SDLC (#43)
+- Setup skill description trimmed to 199 chars (v2.1.86 caps at 250)
+
 ## [1.18.0] - 2026-03-30
 
 ### Added

package/CLAUDE_CODE_SDLC_WIZARD.md

@@ -93,8 +93,10 @@ This prevents both false positives (crying wolf) and false negatives (missing re
 
 **How We Apply This:**
 - Weekly workflow tests new Claude Code versions before recommending upgrade
+- Version-pinned gate: installs the specific CC version and passes it via `path_to_claude_code_executable` so E2E actually runs the new binary
 - Phase A: Does new CC version break SDLC enforcement?
 - Phase B: Do changelog-suggested improvements actually help?
+- Green CI = safe to upgrade. Red = stay on current version until fixed
 - Results shown in PR with statistical confidence
 
 ---
@@ -209,6 +211,8 @@ When Anthropic provides official plugins or tools that handle something:
 | **Claude Code v2.1.69+** | Required for InstructionsLoaded hook, skill directory variable, and Tasks system |
 | **Git repository** | Files should be committed for team sharing |
 
+**Blank repos (no CLAUDE.md, no code):** The wizard works on empty repos. Run `npx agentic-sdlc-wizard init` — it installs hooks, skills, and the wizard doc. On first session, the hooks detect missing SDLC files and redirect to `/setup-wizard`, which generates CLAUDE.md, SDLC.md, TESTING.md, and ARCHITECTURE.md interactively. You do NOT need to run Claude's built-in `/init` first — the setup wizard handles everything.
+
 ---
 
 ## Recommended Effort Level
@@ -644,6 +648,33 @@ Security review depth should match your project's risk profile. During wizard se
 
 ---
 
+## Context Management: `/clear` vs `/compact`
+
+Two tools for managing context — use the right one:
+
+| | `/compact` | `/clear` |
+|---|---|---|
+| **What it does** | Summarizes conversation, frees space | Resets conversation entirely |
+| **When to use** | Continuing same task, need more room | Switching to an unrelated task |
+| **Preserves** | Summary of decisions + progress | Nothing (fresh start) |
+| **CLAUDE.md** | Re-loaded from disk | Re-loaded from disk |
+| **Hooks/skills/settings** | Unaffected | Unaffected |
+| **Task list** | Persists | Cleared |
+
+**Rules of thumb:**
+- `/compact` between planning and implementation (plan preserved in summary)
+- `/clear` between unrelated tasks (stale context wastes tokens and misleads Claude)
+- `/clear` after 2+ failed corrections on the same issue (context is polluted with bad approaches — start fresh with a better prompt)
+- After committing a PR, `/clear` before starting the next feature
+
+**Auto-compact** fires automatically at ~95% context capacity. You don't need to manage this manually — Claude Code handles it. The SDLC skill suggests `/compact` during CI idle time as a "context GC" opportunity.
+
+**What survives `/compact`:** Key decisions, code changes, task state (as a summary). What can be lost: detailed early-conversation instructions not in CLAUDE.md, specific file contents read long ago.
+
+**Best practice:** Put persistent instructions in CLAUDE.md (survives both `/compact` and `/clear`), not in conversation.
+
+---
+
 ## Example Workflow (End-to-End)
 
 Here's what a typical task looks like with this system:
@@ -912,21 +943,25 @@ The wizard creates TDD-specific automations that official plugins don't provide:
 
 ### Step 0.3: Additional Recommendations (Optional)
 
-After SDLC setup is complete, run `claude-code-setup` for additional recommendations:
+After SDLC setup is complete, run `/claude-automation-recommender` for stack-specific tooling:
 
 ```
-"Based on your codebase, recommend additional automations"
+/claude-automation-recommender
 ```
 
-This may suggest:
-- MCP Servers (context7 for docs, Playwright for frontend)
-- Additional hooks (auto-format if Prettier configured)
-- Subagents (security-reviewer if auth code detected)
+**The wizard is an enforcement engine** — it installs working hooks, skills, and process guardrails that run automatically. **The recommender is a suggestion engine** — it analyzes your codebase and suggests additional automations you might want. They're complementary:
 
-**Claude prompts for each:**
-> "[Detected: Prettier config] Want to add auto-format hook? (y/n)"
+| Category | Wizard Ships | Recommender Suggests |
+|----------|-------------|---------------------|
+| SDLC process (TDD, planning, review) | Enforced via hooks + skills | Not covered |
+| CI workflows (self-heal, PR review) | Templates + docs | Not covered |
+| MCP servers (context7, Playwright, DB) | Not covered | Per-stack suggestions |
+| Auto-formatting hooks (Prettier, ESLint) | Not covered | Per-stack suggestions |
+| Type-checking hooks (tsc, mypy) | Not covered | Per-stack suggestions |
+| Subagent templates (code-reviewer, etc.) | Cross-model review only | 8 templates |
+| Plugin recommendations (LSPs, etc.) | Not covered | Per-stack suggestions |
 
-These are additive—they don't replace our TDD hooks.
+The recommender's suggestions are additive — they don't replace the wizard's TDD hooks or SDLC enforcement.
 
 ### Git Workflow Preference
 
@@ -1660,7 +1695,7 @@ TodoWrite([
   { content: "Present approach + STATE CONFIDENCE LEVEL", status: "pending", activeForm: "Presenting approach" },
   { content: "Signal ready - user exits plan mode", status: "pending", activeForm: "Awaiting plan approval" },
   // TRANSITION PHASE (After plan mode, before compact)
-  { content: "Update feature docs with discovered gotchas", status: "pending", activeForm: "Updating feature docs" },
+  { content: "Doc sync: update feature docs if code change contradicts or extends documented behavior", status: "pending", activeForm: "Syncing feature docs" },
   { content: "Request /compact before TDD", status: "pending", activeForm: "Requesting compact" },
   // IMPLEMENTATION PHASE (After compact)
   { content: "TDD RED: Write failing test FIRST", status: "pending", activeForm: "Writing failing test" },
@@ -1701,7 +1736,7 @@ TodoWrite([
 
 **Workflow:**
 1. **Plan Mode** (editing blocked): Research → Write plan file → Present approach + confidence
-2. **Transition** (after approval): Update feature docs → Request /compact
+2. **Transition** (after approval): Doc sync (update feature docs if code contradicts/extends them) → Request /compact
 3. **Implementation** (after compact): TDD RED → GREEN → PASS
 
 **Before TDD, MUST ask:** "Docs updated. Run `/compact` before implementation?"
@@ -1898,7 +1933,7 @@ Debug it. Find root cause. Fix it properly. Tests ARE code.
 
 ## Flaky Test Prevention
 
-**Flaky tests are bugs. Period.** They erode trust in the test suite, slow down teams, and mask real regressions.
+**Flaky tests are bugs. Period.** They erode trust in the test suite, slow down teams, and mask real regressions. For a deep dive, see: [How do you Address and Prevent Flaky Tests?](https://softwareautomation.notion.site/How-do-you-Address-and-Prevent-Flaky-Tests-23c539e19b3c46eeb655642b95237dc0)
 
 ### Principles
 
@@ -1926,7 +1961,9 @@ Sometimes the flakiness is genuinely in CI infrastructure (runner environment, G
 - **Keep quality gates strict** — the actual pass/fail decision must NOT have `continue-on-error`
 - **Separate "fail the build" from "nice to have"** — a missing PR comment is not a regression
 
-## CI Feedback Loop (After Commit)
+## CI Feedback Loop — Local Shepherd (After Commit)
+
+**This is the "local shepherd" — the primary CI fix mechanism.** It runs in your active session with full context. The optional CI Auto-Fix bot (`.github/workflows/ci-autofix.yml`) is a fallback for unattended PRs only. When both are active, the bot detects your local pushes via SHA comparison and skips automatically.
 
 **The SDLC doesn't end at local tests.** CI must pass too.
 
@@ -1972,7 +2009,7 @@ Local tests pass -> Commit -> Push -> Watch CI
 - Flaky? Investigate - flakiness is a bug
 - Stuck? ASK USER
 
-## CI Review Feedback Loop (After CI Passes)
+## CI Review Feedback Loop — Local Shepherd (After CI Passes)
 
 **CI passing isn't the end.** If CI includes a code reviewer, read and address its suggestions.
 
@@ -2004,6 +2041,25 @@ CI passes -> Read review suggestions
 - **Ask first**: Present suggestions to user, let them decide which to implement
 - **Skip review feedback**: Ignore CI review suggestions, only fix CI failures
 
+## Shepherd vs. Bot: Two-Tier CI Fix Model
+
+| Aspect | Local Shepherd | CI Auto-Fix Bot |
+|--------|---------------|-----------------|
+| **When** | Active session (you're working) | Unattended (pushed and walked away) |
+| **Context** | Full: codebase, conversation, intent | Minimal: `--bare`, 200-line truncated logs |
+| **Cost** | Session tokens (marginal cost ~$0) | Separate API calls ($0.50-$2.00 per fix) |
+| **Noise** | 0 extra commits | 1+ `[autofix N/M]` commits per attempt |
+| **Quality** | High: full diagnosis, targeted fix | Lower: stateless, may repeat same approach |
+| **Speed** | Immediate: fix locally, push once | Delayed: workflow_run trigger + runner queue |
+| **Deconfliction** | N/A (is the primary) | SHA check: skips if branch advanced since failure |
+
+**The shepherd is the default.** It runs as part of the SDLC checklist above whenever you push from an active session. The bot is optional and only adds value for:
+- Dependabot/Renovate PRs (no human session)
+- PRs where you push and walk away
+- Overnight CI runs
+
+If you set up the bot, the SHA-based suppression ensures they never conflict.
+
 ## DRY Principle
 
 **Before coding:** "What patterns exist I can reuse?"
@@ -2266,7 +2322,7 @@ If deployment fails or post-deploy verification catches issues:
 
 **SDLC.md:**
 ```markdown
-<!-- SDLC Wizard Version: 1.18.0 -->
+<!-- SDLC Wizard Version: 1.20.0 -->
 <!-- Setup Date: [DATE] -->
 <!-- Completed Steps: step-0.1, step-0.2, step-0.4, step-1, step-2, step-3, step-4, step-5, step-6, step-7, step-8, step-9 -->
 <!-- Git Workflow: [PRs or Solo] -->
@@ -2577,9 +2633,17 @@ Want me to file these? (yes/no/not now)
 
 ## Going Further
 
-### Create Feature Plan Docs
+### Feature Documentation
 
-For each major feature, create `FEATURE_NAME_PLAN.md`:
+Keep feature docs alongside code. Three patterns, use what fits:
+
+| Pattern | When to Use | Example |
+|---------|-------------|---------|
+| `*_PLAN.md` / `*_DOCS.md` | Per-feature living docs | `AUTH_DOCS.md`, `PAYMENTS_PLAN.md` |
+| `docs/decisions/NNN-title.md` (ADR) | Architecture decisions that need rationale | `docs/decisions/001-use-postgres.md` |
+| `docs/features/name.md` | Feature docs in a `docs/` directory | `docs/features/auth.md` |
+
+**Feature doc template:**
 
 ```markdown
 # Feature Name
@@ -2597,7 +2661,36 @@ Things that can trip you up.
 What's planned but not done.
 ```
 
-Claude will read these during planning and update them with discoveries.
+**ADR (Architecture Decision Record) template** — for decisions that need context:
+
+```markdown
+# ADR-NNN: Decision Title
+
+## Status
+Accepted | Superseded by ADR-NNN | Deprecated
+
+## Context
+What is the problem? What forces are at play?
+
+## Decision
+What did we decide and why?
+
+## Consequences
+What are the trade-offs? What becomes easier/harder?
+```
+
+Store ADRs in `docs/decisions/`. Number sequentially. Claude reads these during planning to understand why things are built the way they are.
+
+**Keeping docs in sync with code:**
+
+Docs drift when code changes but docs don't. The SDLC skill's planning phase detects this:
+
+- During planning, Claude reads feature docs for the area being changed
+- If the code change contradicts what the doc says, Claude updates the doc
+- The "After Session" step routes learnings to the right doc
+- Stale docs cause low confidence — if Claude struggles, the doc may need updating
+
+**CLAUDE.md health:** Run `/claude-md-improver` periodically (quarterly or after major changes). It audits CLAUDE.md specifically — structure, clarity, completeness (6 criteria, 100-point rubric). It does NOT cover feature docs, TESTING.md, or ADRs — the SDLC workflow handles those.
 
 ### Expand TESTING.md
 
@@ -2621,6 +2714,10 @@ Add project-specific guidance to skills:
 - Preferred patterns
 - Architecture decisions
 
+### Complementary Tools
+
+The wizard handles SDLC process enforcement. For stack-specific tooling, run `/claude-automation-recommender` — it suggests MCP servers, formatting hooks, type-checking hooks, subagent templates, and plugins based on your detected tech stack. See [Step 0.3](#step-03-additional-recommendations-optional) for the full comparison.
+
 ---
 
 ## Testing AI Apps: What's Different
@@ -2688,6 +2785,49 @@ _Sources: [Confident AI](https://www.confident-ai.com/blog/llm-testing-in-2024-t
 
 ---
 
+## Token Efficiency
+
+Practical techniques to reduce token consumption without sacrificing quality.
+
+### Monitor Costs
+
+| Tool | What It Shows | When to Use |
+|------|---------------|-------------|
+| `/cost` | Session total: USD, API time, code changes | After a session to review spend |
+| `/context` | What's consuming context window space | When hitting context limits |
+| Status line | Real-time `cost.total_cost_usd` + token counts | Continuous monitoring |
+
+### Reduce Consumption
+
+| Technique | Savings | How |
+|-----------|---------|-----|
+| `/compact` between phases | ~40-60% context | Plan → compact → implement (plan preserved) |
+| `/clear` between tasks | 100% context reset | No stale context from prior work |
+| Delegate verbose ops to subagents | Separate context | `Agent` tool returns summary, not full output |
+| Use skills for on-demand knowledge | Smaller base context | Skills load only when invoked |
+| Scope investigations narrowly | Fewer tokens read | "investigate auth module" > "investigate codebase" |
+| `--effort low` for simple tasks | ~50% thinking tokens | Simple renames, config changes |
+
+### CI Cost Control
+
+Add `--max-budget-usd` to CI workflows as a safety net:
+
+```yaml
+claude_args: "--max-budget-usd 5.00 --max-turns 30"
+```
+
+| Flag | Purpose |
+|------|---------|
+| `--max-budget-usd` | Hard dollar cap per CI invocation |
+| `--max-turns` | Limit agentic turns (prevents infinite loops) |
+| `--effort` | `low`/`medium`/`high` controls thinking depth |
+
+### Advanced: OpenTelemetry
+
+For organization-wide cost tracking, enable `CLAUDE_CODE_ENABLE_TELEMETRY=1`. This exports per-request `cost_usd`, `input_tokens`, `output_tokens` to any OTLP-compatible backend (Datadog, Honeycomb, Prometheus).
+
+---
+
 ## CI/CD Gotchas
 
 Common pitfalls when automating AI-assisted development workflows.
@@ -2749,7 +2889,9 @@ Claude: [fetches via gh api, discusses with you interactively]
 
 This is optional - skip if you prefer fresh reviews only.
 
-### CI Auto-Fix Loop (Optional)
+### CI Auto-Fix Loop (Optional — Bot Fallback)
+
+> **Two-tier model:** The SDLC skill's CI loops (above) are the "local shepherd" — they handle CI fixes during active sessions. This bot is the second tier: an unattended fallback for when no one is watching. The bot includes SHA-based suppression — if you push a fix locally before the bot runs, it skips automatically.
 
 Automatically fix CI failures and PR review findings. Claude reads the error context, fixes the code, commits, and re-triggers CI. Loops until CI passes AND review has no findings at your chosen level, or max retries hit.
 
@@ -3079,21 +3221,19 @@ Claude reads the CHANGELOG to show you what's new **before** applying anything.
 ```
 Claude: "Fetching CHANGELOG to check for updates..."
 
-Your version: 1.8.0
-Latest version: 1.13.0
+Your version: X.Y.0
+Latest version: X.Z.0
 
-What's new since 1.8.0:
-- v1.13.0: Self-update improvements, optional CI notification
-- v1.12.0: Full system audit, apply step fixes
-- v1.11.0: Stale output cleanup, error handling
-- v1.10.0: "Prove It's Better" CI automation
-- v1.9.0: Workflow consolidation (6 → 5 workflows)
+What's new since X.Y.0:
+- vX.Z.0: Latest features and improvements
+- vX.Y+1.0: Previous version changes
+  (... entries from CHANGELOG between your version and latest ...)
 
 Now checking your setup against latest wizard...
 
 ✓ Hooks - up to date
 ✓ Skills - content differs (update available)
-✗ step-update-notify - NOT DONE (new in v1.13.0, optional)
+✗ step-update-notify - NOT DONE (new in vX.Z.0, optional)
 
 Summary:
 - 1 file update available (SDLC skill)
@@ -3109,7 +3249,7 @@ Walk through updates? (y/n)
 Store wizard state in `SDLC.md` as metadata comments (invisible to readers, parseable by Claude):
 
 ```markdown
-<!-- SDLC Wizard Version: 1.18.0 -->
+<!-- SDLC Wizard Version: 1.20.0 -->
 <!-- Setup Date: 2026-01-24 -->
 <!-- Completed Steps: step-0.1, step-0.2, step-1, step-2, step-3, step-4, step-5, step-6, step-7, step-8, step-9 -->
 <!-- Git Workflow: PRs -->

package/cli/templates/skills/sdlc/SKILL.md

@@ -26,7 +26,7 @@ TodoWrite([
   { content: "Present approach + STATE CONFIDENCE LEVEL", status: "pending", activeForm: "Presenting approach" },
   { content: "Signal ready - user exits plan mode", status: "pending", activeForm: "Awaiting plan approval" },
   // TRANSITION PHASE (After plan mode)
-  { content: "Update feature docs with discovered gotchas", status: "pending", activeForm: "Updating feature docs" },
+  { content: "Doc sync: update feature docs if code change contradicts or extends documented behavior", status: "pending", activeForm: "Syncing feature docs" },
   // IMPLEMENTATION PHASE
   { content: "TDD RED: Write failing test FIRST", status: "pending", activeForm: "Writing failing test" },
   { content: "TDD GREEN: Implement, verify test passes", status: "pending", activeForm: "Implementing feature" },
@@ -280,6 +280,8 @@ Everything else needs integration tests.
 
 ## Flaky Test Recovery
 
+**Flaky tests are bugs. Period.** See: [How do you Address and Prevent Flaky Tests?](https://softwareautomation.notion.site/How-do-you-Address-and-Prevent-Flaky-Tests-23c539e19b3c46eeb655642b95237dc0)
+
 When a test fails intermittently:
 1. **Don't dismiss it** — "flaky" means "bug we haven't found yet"
 2. **Identify the layer** — test code? app code? environment?
@@ -333,7 +335,9 @@ If tests fail:
 
 Debug it. Find root cause. Fix it properly. Tests ARE code.
 
-## CI Feedback Loop (After Commit)
+## CI Feedback Loop — Local Shepherd (After Commit)
+
+**This is the "local shepherd" — the primary CI fix mechanism.** It runs in your active session with full context. The optional CI Auto-Fix bot (`.github/workflows/ci-autofix.yml`) is a fallback for unattended PRs only. When both are active, the bot detects your local pushes via SHA comparison and skips automatically.
 
 **The SDLC doesn't end at local tests.** CI must pass too.
 
@@ -379,7 +383,7 @@ Local tests pass -> Commit -> Push -> Watch CI
 - Flaky? Investigate - flakiness is a bug
 - Stuck? ASK USER
 
-## CI Review Feedback Loop (After CI Passes)
+## CI Review Feedback Loop — Local Shepherd (After CI Passes)
 
 **CI passing isn't the end.** If CI includes a code reviewer, read and address its suggestions.
 
@@ -411,6 +415,14 @@ CI passes -> Read review suggestions
 - **Ask first**: Present suggestions to user, let them decide which to implement
 - **Skip review feedback**: Ignore CI review suggestions, only fix CI failures
 
+## Context Management
+
+- `/compact` between planning and implementation (plan preserved in summary)
+- `/clear` between unrelated tasks (stale context wastes tokens and misleads)
+- `/clear` after 2+ failed corrections (context polluted — start fresh with better prompt)
+- Auto-compact fires at ~95% capacity — no manual management needed
+- After committing a PR, `/clear` before starting the next feature
+
 ## DRY Principle
 
 **Before coding:** "What patterns exist I can reuse?"
@@ -480,11 +492,25 @@ CI passes -> Read review suggestions
 
 **THE RULE:** Delete old code first. If it breaks, fix it properly.
 
+## Documentation Sync (During Planning)
+
+When a code change affects a documented feature, update the doc in the same PR:
+
+1. **During planning**, read feature docs for the area being changed (`*_PLAN.md`, `*_DOCS.md`, `docs/features/`, `docs/decisions/`)
+2. If your code change contradicts what the doc says → update the doc
+3. If your code change extends behavior the doc describes → add to the doc
+4. If no feature doc exists and the change is substantial → note it in the summary (don't create one unprompted)
+
+**Doc staleness signals:** Low confidence in an area often means the docs are stale, missing, or misleading. If you struggle during planning, check whether the docs match the actual code.
+
+**CLAUDE.md health:** `/claude-md-improver` audits CLAUDE.md structure and completeness. Run it periodically. It does NOT cover feature docs — the SDLC workflow handles those.
+
 ## After Session (Capture Learnings)
 
 If this session revealed insights, update the right place:
 - **Testing patterns, gotchas** → `TESTING.md`
-- **Feature-specific quirks** → Feature docs (`*_PLAN.md`)
+- **Feature-specific quirks** → Feature docs (`*_PLAN.md`, `*_DOCS.md`)
+- **Architecture decisions** → `docs/decisions/` (ADR format) or `ARCHITECTURE.md`
 - **General project context** → `CLAUDE.md` (or `/revise-claude-md`)
 
 ---

package/cli/templates/skills/setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: setup-wizard
-description: Interactive project setup wizard that scans the codebase, asks all 16 configuration questions, generates SDLC files (CLAUDE.md, SDLC.md, TESTING.md, ARCHITECTURE.md), and verifies the installation. Use this skill when setting up the SDLC wizard for the first time or re-running setup.
+description: Setup wizard — scans codebase, asks 16 config questions, generates SDLC files (CLAUDE.md, SDLC.md, TESTING.md, ARCHITECTURE.md), verifies installation. Use for first-time setup or re-running setup.
 argument-hint: [optional: regenerate | verify-only]
 effort: high
 ---
@@ -159,12 +159,14 @@ Run verification checks:
 
 Report any issues found.
 
-### Step 11: Instruct Restart
+### Step 11: Instruct Restart and Next Steps
 
 Tell the user:
 > Setup complete. Hooks and settings load at session start.
 > **Exit Claude Code and restart it** for the new configuration to take effect.
 > On restart, the SDLC hook will fire and you'll see the checklist in every response.
+>
+> **Optional next step:** Run `/claude-automation-recommender` for stack-specific tooling suggestions (MCP servers, formatting hooks, type-checking hooks, plugins). These are complementary to the SDLC wizard — they add per-stack tooling, not process enforcement.
 
 ## Rules
 

package/cli/templates/skills/update/SKILL.md

@@ -46,12 +46,12 @@ Parse all CHANGELOG entries between the user's installed version and the latest.
 
 ```
 Installed: 1.15.0
-Latest:    1.18.0
+Latest:    1.20.0
 
 What changed:
+- [1.20.0] Version-pinned CC update gate, Tier 1 flakiness fix, flaky test guidance, ...
+- [1.19.0] CI shepherd model, token efficiency, feature doc enforcement, ...
 - [1.18.0] Added /update-wizard skill, ...
-- [1.17.0] Consolidated /testing into /sdlc, ...
-- [1.16.0] Cross-model review protocol, ...
 ```
 
 **If versions match:** Say "You're up to date! (version X.X.X)" and stop.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentic-sdlc-wizard",
-  "version": "1.18.0",
+  "version": "1.20.0",
   "description": "SDLC enforcement for Claude Code — hooks, skills, and wizard setup in one command",
   "bin": {
     "sdlc-wizard": "./cli/bin/sdlc-wizard.js"