claude-code-kit 0.58.2__tar.gz → 0.59.0__tar.gz

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "claude-kit",
       "source": "./",
       "description": "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC config (no app code, no Docker): install CLAUDE.md + .claude/ (rules, the profile's agents/skills, hooks, artifact templates) + optional .mcp.json, then run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop.",
-      "version": "0.58.2",
+      "version": "0.59.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.58.2",
+  "version": "0.59.0",
   "description": "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC config (no app code, no Docker). `claude-kit init` asks ordered questions and installs CLAUDE.md + .claude/ (rules, the profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates with working memory and a self-improving learnings loop.",
   "author": {
     "name": "Arjunsingh Yadav",

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/CHANGELOG.md

@@ -4,6 +4,55 @@ All notable changes to claude-kit are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/), and the project uses
 [semantic versioning](https://semver.org/).
 
+## [0.59.0] — 2026-07-08
+
+**The kit gains a deploy-execution skill — the lifecycle's last mile.** Until now the pipeline
+deliberately stopped at a merge-ready PR: `devops-engineer`/`/ci-cd-and-automation`/
+`/shipping-and-launch` *prepared* delivery, but nothing executed and verified a deployment. The
+new `deploy` skill closes that gap for projects whose deployment is driven from the repo,
+generalized from a battle-tested platform workflow contributed by the project owner
+(commit-in-format → tag → watch pipeline → verify pods → test → repeat).
+
+### Added
+
+- **`skills/deploy` — a configuration-driven deploy-and-verify loop** (standard + enterprise
+  profiles; lean stays minimal). First run interviews the user — integration branch, byte-exact
+  commit format, deploy trigger (tag push / branch push / CI dispatch / deploy command),
+  pipeline monitor (CI CLI, provider MCP, browser dashboard via Chrome DevTools MCP, or
+  manual), and runtime verification (Kubernetes rollout/pods, container/compose listings,
+  cloud service CLIs, PaaS CLIs, HTTP health/version endpoints, log queries) — and persists the
+  answers to `.claude/config/deploy.yaml` so the interview never repeats. Modes: single run,
+  `commit-only`, `no-deploy`, `setup`, and `loop` (implement → local checks → commit → merge →
+  trigger → monitor → verify → browser-test → findings become the next iteration's worklist).
+  Safety rails: read-only verification commands, no force-push, no deploying from the default
+  branch unless trunk-based is configured, migration-bearing releases pause for human
+  confirmation with a rollback note, evidence-or-it-didn't-happen success claims (new revision
+  observably live, not just a green build), a 3-strike stop, and an iteration cap. The skill
+  executes an existing human-designed delivery path — it never invents one (that remains
+  `/ci-cd-and-automation` + `/shipping-and-launch` territory).
+- The scaffolded project README's DevOps/release row now leads with `/deploy` (covered by the
+  0.58.2 phantom-command drift test — it must exist in the payload, and it does).
+
+### Changed
+
+- Skill counts: **105** context-activated skills (57 core + 48 stack-collection); standard
+  default-stack install goes 42 → 43. README footprint/compare tables updated to match
+  (verified empirically via `catalog.resolve()` per profile).
+
+### Not adopted (deliberately)
+
+- **An `autonomous-deploy` autonomy level** — the skill stays governed by the user's Claude
+  Code permission settings plus its own human-gate points (migrations, conflicts, 3-strike
+  escalation) rather than adding a standing autonomy tier that permits merges/deploys. If
+  demand materializes, that's a separate, explicit `autonomy-levels.md` revision with its own
+  review — not a rider on a skill PR.
+- **Auto-rollback on failed verification** — the loop stops and escalates with evidence
+  instead of executing rollbacks itself; rollback commands vary too much across platforms to
+  run unconfirmed, and a wrong rollback is worse than a paused loop.
+- **A `postgres`/K8s-specific verification agent** — verification is config data
+  (`verify:` commands in `deploy.yaml`), not a new agent; the stack-agnostic core stays
+  tool-neutral with balanced example menus only.
+
 ## [0.58.2] — 2026-07-08
 
 **The advisory hook layer is now actually visible, and the scaffolded docs stop advertising

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.58.2
+Version: 0.59.0
 Summary: Cookiecutter-style scaffolder for an autonomous Claude Code SDLC configuration (no app code, no Docker). Asks ordered questions and installs CLAUDE.md + .claude/ (rules, the chosen profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop.
 Project-URL: Homepage, https://github.com/ajyadav013/claude-kit
 Project-URL: Repository, https://github.com/ajyadav013/claude-kit
@@ -146,7 +146,7 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 |------|--------------|
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression — a phase advances only with zero open Critical/High/Medium findings — plus a fast-track for small changes and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
-| 📐 **Rules & skills** | **25** stack-agnostic core rules + **104** context-activated skills (56 core + 48 stack-collection), pulled into context on demand |
+| 📐 **Rules & skills** | **25** stack-agnostic core rules + **105** context-activated skills (57 core + 48 stack-collection), pulled into context on demand |
 | 🧱 **Stacks & overlays** | A stack-agnostic core + **13** overlay rule files (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
 | 🛠️ **Hooks & guards** | **18** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
 | 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **17** ready MCP fragments (version-pinned), edit-preserving `upgrade`, and a root `AGENTS.md` at init so non-Claude agents share the same standards |
@@ -224,8 +224,8 @@ PostgreSQL project, individual scope:
 | Profile | Agents | Skills | Rules |
 |---------|-------:|-------:|------:|
 | `lean` | 8 | 15 | 36 |
-| `standard` (default) | 26 | 42 | 36 |
-| `enterprise` | 31 | 104 | 36 |
+| `standard` (default) | 26 | 43 | 36 |
+| `enterprise` | 31 | 105 | 36 |
 
 - **Rules are profile-independent** — every profile installs the same 25 core rules + the selected
   stack's overlays (11 for this stack = 36); rigor changes the *agents and gates*, not the rule set.
@@ -251,7 +251,7 @@ that matters most: **native gives you the agents; claude-kit gives you the gover
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar collections | Large libraries of individual subagent prompts you pick from | A smaller, opinionated set wired into a sequenced pipeline — agents are stages that hand off and block on each other, not a menu |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | Spec-driven development as a platform: constitution → spec → tasks → analyze, plus label-driven CI stages | The same coverage-gate idea absorbed into a broader in-session lifecycle — review, security, build, test, release, and observability gates with enforced severity blocking. Complementary: their CI stages, this kit's gate depth ([details](docs/autonomous-operation.md)) |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | Portable configuration, not a running process — no daemon, no lock-in, no app code |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 28 agents, 104 skills, gates, and hooks — kept upgradeable with your edits preserved |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 28 agents, 105 skills, gates, and hooks — kept upgradeable with your edits preserved |
 
 **Choose claude-kit when** you want a consistent, gate-enforced autonomous-SDLC setup that's the
 same across every repo and stack, installs in seconds, and ships nothing you have to run. It is

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/README.md

@@ -113,7 +113,7 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 |------|--------------|
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression — a phase advances only with zero open Critical/High/Medium findings — plus a fast-track for small changes and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
-| 📐 **Rules & skills** | **25** stack-agnostic core rules + **104** context-activated skills (56 core + 48 stack-collection), pulled into context on demand |
+| 📐 **Rules & skills** | **25** stack-agnostic core rules + **105** context-activated skills (57 core + 48 stack-collection), pulled into context on demand |
 | 🧱 **Stacks & overlays** | A stack-agnostic core + **13** overlay rule files (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
 | 🛠️ **Hooks & guards** | **18** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
 | 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **17** ready MCP fragments (version-pinned), edit-preserving `upgrade`, and a root `AGENTS.md` at init so non-Claude agents share the same standards |
@@ -191,8 +191,8 @@ PostgreSQL project, individual scope:
 | Profile | Agents | Skills | Rules |
 |---------|-------:|-------:|------:|
 | `lean` | 8 | 15 | 36 |
-| `standard` (default) | 26 | 42 | 36 |
-| `enterprise` | 31 | 104 | 36 |
+| `standard` (default) | 26 | 43 | 36 |
+| `enterprise` | 31 | 105 | 36 |
 
 - **Rules are profile-independent** — every profile installs the same 25 core rules + the selected
   stack's overlays (11 for this stack = 36); rigor changes the *agents and gates*, not the rule set.
@@ -218,7 +218,7 @@ that matters most: **native gives you the agents; claude-kit gives you the gover
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar collections | Large libraries of individual subagent prompts you pick from | A smaller, opinionated set wired into a sequenced pipeline — agents are stages that hand off and block on each other, not a menu |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | Spec-driven development as a platform: constitution → spec → tasks → analyze, plus label-driven CI stages | The same coverage-gate idea absorbed into a broader in-session lifecycle — review, security, build, test, release, and observability gates with enforced severity blocking. Complementary: their CI stages, this kit's gate depth ([details](docs/autonomous-operation.md)) |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | Portable configuration, not a running process — no daemon, no lock-in, no app code |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 28 agents, 104 skills, gates, and hooks — kept upgradeable with your edits preserved |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 28 agents, 105 skills, gates, and hooks — kept upgradeable with your edits preserved |
 
 **Choose claude-kit when** you want a consistent, gate-enforced autonomous-SDLC setup that's the
 same across every repo and stack, installs in seconds, and ships nothing you have to run. It is

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/catalog/profiles.yaml

@@ -74,6 +74,9 @@ profiles:
       - performance-optimization
       - load-testing
       - incident-postmortem
+      # deploy = the configuration-driven deploy-and-verify loop (interviews once, persists to
+      # .claude/config/deploy.yaml). Deploy execution stays gated by the user's permission settings.
+      - deploy
       - threat-model
       - accessibility-review
       - over-engineering-review

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.58.2"
+version = "0.59.0"
 description = "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC configuration (no app code, no Docker). Asks ordered questions and installs CLAUDE.md + .claude/ (rules, the chosen profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop."
 readme = "README.md"
 requires-python = ">=3.9"

claude_code_kit-0.59.0/skills/deploy/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: deploy
+description: >-
+  Deploy-and-verify loop: commit in the project's format → trigger the deployment → watch the
+  pipeline → verify the running instances → test → fix findings → repeat until clean. On first
+  use it interviews you for your delivery setup (integration branch, commit format, deploy
+  trigger, pipeline monitor, runtime verification) and persists the answers to
+  .claude/config/deploy.yaml so later runs never re-ask. Use when the user says "deploy",
+  "ship this", "commit and deploy", or "run the ship loop".
+argument-hint: '<commit message | "commit-only" | "no-deploy" | "setup" | "loop">'
+---
+
+# deploy — commit → deploy → monitor → verify → repeat
+
+A delivery-execution skill for projects where deployment is driven from the repo (a tag, a
+branch push, a CI dispatch, or a deploy command). It runs once by default, or loops
+autonomously until the exit condition is met. It is deliberately **configuration-driven**:
+nothing below assumes a specific CI provider, orchestrator, or cloud.
+
+| Usage | What it does |
+|-------|-------------|
+| `/deploy` | Commit + push (+ merge to the integration branch) + trigger the deployment |
+| `/deploy fix: use internal URL` | Same, with a custom commit description |
+| `/deploy commit-only` | Commit + push only — no merge, no deploy |
+| `/deploy no-deploy` | Commit + push + merge, skip the deploy trigger |
+| `/deploy setup` | (Re-)run the interview and rewrite `.claude/config/deploy.yaml` |
+| `/deploy loop` | Full ship loop: implement → commit → deploy → monitor → verify → test → repeat |
+
+---
+
+## Step 0 — Load or build the delivery profile
+
+Read `.claude/config/deploy.yaml`. If it exists, use it and **ask nothing** already answered.
+If it is missing (or `setup` mode), build it: **auto-detect first, ask only what detection
+can't settle**, then write the file so the interview never repeats.
+
+### What to detect / ask
+
+1. **Integration branch** — the branch deployments are cut from (staging/SIT/release), if any.
+   Detect: a branch named in `CLAUDE.md`, or the branch recent merge commits target. Trunk-based
+   projects answer "none — deploy from the default branch"; record that explicitly.
+2. **Commit message format** — detect from `git log --oneline -15` (a consistent prefix pattern
+   is the answer). Else ask, offering: Conventional Commits (`fix: …`), ticket-prefixed
+   (`PROJ-1234: …`), or a custom template with placeholders (e.g.
+   `ID:<ticket>; DONE:<pct>; HOURS:<n>; <description>`). Also ask for any required trailer.
+   Once configured, the format is **byte-exact, every commit** — no drift, no improvisation.
+3. **Deploy trigger** — how a deployment actually starts. One of:
+   - **tag push** — capture the exact tag format (e.g. `vX.Y.Z`, `deploy-<env>-<n>`) and the
+     remote it must be pushed to;
+   - **merge/push to a branch** — the deploy happens on push; nothing extra to run;
+   - **CI manual dispatch** — capture the exact command (e.g. the CI CLI's run/dispatch call);
+   - **a deploy command or script** — capture it verbatim, including arguments (many platforms
+     wrap tagging in a helper; treat the helper as the trigger and don't second-guess it).
+4. **Pipeline monitor** — how to watch the build/deploy pipeline. Offer, in order of preference:
+   - the CI provider's **CLI** (e.g. `gh run watch` for GitHub Actions, `glab ci status` for
+     GitLab, the Azure DevOps CLI for Azure Pipelines) — poll-able, scriptable;
+   - a **provider MCP server**, if one is connected — use its build-status tools;
+   - a **web dashboard URL** watched through the browser (Chrome DevTools MCP) when no CLI/API
+     is available — capture the URL;
+   - **none** — the user watches and reports back; the loop pauses at this step.
+5. **Runtime verification** — how to confirm the new version is actually live and healthy.
+   Ask which of these the project has (multiple allowed; capture the exact command, context,
+   and namespace/identifier for each — these run **read-only, every iteration**):
+   - **Kubernetes**: `kubectl rollout status <deployment>` then `kubectl get pods` (with the
+     configured `--context`/`-n`); `kubectl logs` for spot checks;
+   - **container runtime / compose**: the equivalent `ps`/service-status listing;
+   - **cloud service CLI**: the provider's service/revision describe command (ECS/Cloud Run/
+     App Service and equivalents);
+   - **PaaS CLI**: the platform's status command (fly/heroku/railway and equivalents);
+   - **HTTP**: a health/readiness endpoint, and ideally a **version endpoint** that reports the
+     deployed SHA/tag — the strongest single check;
+   - **logs/monitoring**: an error-rate or log query to compare before/after.
+6. **Test surface** — a URL to exercise in the browser after deploy (optional; skip if none).
+7. **Exit condition & bounds** — when the loop stops. Default: pipeline green **and** instances
+   healthy on the new revision **and** zero blocking/major findings. Default cap: 5 iterations;
+   3-strike rule below always applies.
+
+Write the answers to `.claude/config/deploy.yaml` (create `.claude/config/` if needed):
+
+```yaml
+integration_branch: <name or "none">
+commit_format:
+  template: "<the exact template>"
+  trailer: "<required trailer or omit>"
+deploy:
+  trigger: tag | branch-push | ci-dispatch | command
+  detail: "<tag format / command verbatim>"
+pipeline:
+  monitor: ci-cli | mcp | browser | manual
+  detail: "<command / URL>"
+verify:
+  - "<read-only command 1>"
+  - "<read-only command 2>"
+test_url: "<URL or omit>"
+loop:
+  max_iterations: 5
+```
+
+**Never store secrets or tokens in this file** — commands reference environment variables;
+the file is committed config, not a credential store. Record the active run's state (tag,
+build id, findings) in `.claude/CONTINUITY.md`, not here.
+
+---
+
+## Non-negotiable rules (every iteration)
+
+- **The commit format is law.** Use the configured template byte-exactly, every commit,
+  including merge commits and fix-up iterations.
+- **Stage by name.** `git add <path>` for the files you changed — never `git add -A`. Never
+  stage `.env`, credentials, OS junk, or large binaries.
+- **Never force-push. Never deploy from the default branch** unless the config explicitly says
+  the project is trunk-based. Never skip the configured merge step.
+- **Never auto-resolve merge conflicts** — show the conflicting files and ask.
+- **Verification commands are read-only.** Status, list, describe, logs — never delete,
+  restart, or scale anything while verifying (the kit's guard hooks block destructive
+  orchestrator commands regardless).
+- **A release that carries a database migration pauses for explicit human confirmation** with a
+  written rollback note before the trigger fires (see `.claude/rules/risk-classification.md`).
+- **No success without evidence.** "Deployed" means: the pipeline reports success, the runtime
+  checks show the **new** revision healthy, and — where possible — a unique marker from your
+  diff is observably live (a version endpoint, a log line, a visible change). An image tag or
+  a green build alone proves nothing on shared branches.
+- **3-strike stop.** If the same failure survives 3 iterations with no forward progress, STOP,
+  keep the environment as-is, and escalate with the evidence collected.
+- **Stash before switching.** `git stash --include-untracked` if the tree is dirty before any
+  checkout; pop when switching back.
+- **One deploy trigger per iteration.** Don't re-fire the trigger while a pipeline for the
+  previous one is still running.
+
+---
+
+## The flow
+
+### 1. Implement (loop mode only)
+Make the smallest coherent change toward the goal, matching the codebase's conventions. For
+non-trivial feature work, run it through `/sdlc` first and use this skill for the delivery
+tail. In non-loop mode, skip — the user already made their changes.
+
+### 2. Local checks (loop mode only)
+Run what the repo has — linter → type-check → build → unit tests — and get them green before
+anything ships. A red local check never proceeds to commit.
+
+### 3. Commit
+`git status -s` → if changes exist: `git diff --stat` to understand them, use `$ARGUMENTS` as
+the description when provided (and not a mode keyword), else write one from the diff. Stage by
+name, commit in the configured format, push to the feature branch. No changes → say so and
+continue. **`commit-only` mode stops here.**
+
+### 4. Merge to the integration branch (when configured)
+Skip when `integration_branch: none`. Otherwise: confirm there are new commits to merge
+(`git log <integration>..<feature> --oneline` — nothing new → say so and stop), then stash if
+dirty → checkout → pull → merge the feature branch (merge commit in the configured format) →
+push. Conflicts → stop and ask. **`no-deploy` mode stops after this step.**
+
+### 5. Trigger the deployment
+Fire the configured trigger exactly as recorded (push the tag in the configured format, or run
+the configured command verbatim). Don't add a second confirmation layer on top of the user's
+permission settings — Claude Code already gates tool execution. If the trigger command isn't
+found in this shell, tell the user the exact line to run themselves.
+
+### 6. Monitor the pipeline (~60s cadence)
+Watch via the configured monitor until it reports success or failure. On **failure**: pull the
+build/deploy logs through the same channel, root-cause, and go back to step 1 with the fix —
+never re-fire the trigger without a change. If the monitor is `manual`, hand the user the
+URL/command and wait for their report.
+
+### 7. Verify the runtime
+Run every configured `verify:` command. Confirm the **new** revision is what's serving:
+rollout complete, instances Ready/healthy, and the version endpoint / diff marker matches this
+iteration's change. Partial rollouts, crash-looping instances, or a stale version = failure →
+collect evidence → back to step 1.
+
+### 8. Test (loop mode only)
+If a `test_url` is configured, exercise it in the browser (Chrome DevTools MCP when available):
+the change renders and behaves correctly · network calls return expected status/payloads with
+no 5xx · zero new console errors · surrounding features still work. Record each finding:
+severity (blocking/major/minor) · what · where · repro · expected.
+
+### 9. Decide
+Switch back to the feature branch (pop the stash if one was made).
+- **Non-loop mode** → done. Report what was deployed, with the evidence.
+- **Loop mode** → exit condition met → STOP and report: what shipped, trigger reference
+  (tag/build id), runtime status, and the test log. Otherwise the findings become the worklist
+  → go to step 1. The 3-strike rule and the iteration cap always win over "one more try".
+
+---
+
+## Batching (loop mode)
+
+For a large worklist, group related fixes into coherent deployable batches — deploy and verify
+each batch before starting the next. Split any batch that mixes low-risk polish with a risky
+change; the risky change ships alone, with its own verification.
+
+## Working memory
+
+Checkpoint `.claude/CONTINUITY.md` at every stage transition — config in use, iteration number,
+trigger reference, pipeline result, runtime evidence, findings — so the loop survives context
+compaction and a fresh session can resume exactly where it stopped (see
+`.claude/rules/continuity.md`).
+
+## What this skill never does
+
+Provision infrastructure · merge to a production branch that requires human review · run
+destructive runtime commands · bypass the profile's quality gates for the code itself. It
+executes an **existing, human-designed delivery path** and verifies the result — it does not
+invent one. If the project has no delivery path yet, that's `/ci-cd-and-automation` and
+`/shipping-and-launch` territory first.

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/src/claude_kit/__init__.py

@@ -7,4 +7,4 @@ Docker): ``claude-kit init`` asks ordered questions and lays down ``CLAUDE.md``
 as a plugin. Extensibility is data-driven via the ``catalog/`` (stacks, profiles, MCP).
 """
 
-__version__ = "0.58.2"
+__version__ = "0.59.0"

{claude_code_kit-0.58.2 → claude_code_kit-0.59.0}/templates/README.claude-sdlc.md.tmpl

@@ -164,7 +164,7 @@ different autonomy levels per repo, and measure adoption.
 | Security review | `/security-and-hardening`, `/security-verification`, `/threat-model` | `security-reviewer`, `owasp-reviewer`, `secret-scanner`, `dependency-scanner`, `policy-validator` | `secrets-policy`, `agent-guardrails` | `protect-secrets`, `guard-commit-secrets`, `warn-sensitive-files` | `/security-verification` the auth change |
 | Performance review | `/performance-optimization`, `/load-testing` | `db-performance-reviewer` (PostgreSQL) | `risk-classification` | — | `/performance-optimization` the list endpoint |
 | Accessibility review | `/accessibility-review` | `ui-designer` | `responsive-and-accessibility` | — | `/accessibility-review` the modal |
-| DevOps / release | `/shipping-and-launch`, `/ci-cd-and-automation` | `devops-engineer`, `pr-raiser`, `observability-engineer` | `devops-observability`, `branch-and-pr-policy` | `guard-push-main` | `/shipping-and-launch` the release |
+| DevOps / release | `/deploy`, `/shipping-and-launch`, `/ci-cd-and-automation` | `devops-engineer`, `pr-raiser`, `observability-engineer` | `devops-observability`, `branch-and-pr-policy` | `guard-push-main` | `/deploy loop` until the release verifies clean |
 | Incident response | `/incident-postmortem` | `incident-responder` | `devops-observability` | `audit-log` | `/incident-postmortem` after a SEV1 |
 | Documentation | `/documentation-and-adrs`, `/refresh-docs` | `technical-architect` | `documentation` | — | `/refresh-docs` after an API change |
 {% if scope == "organization" %}| Onboarding | `/repo-onboarding` | `Explore`, `technical-architect` | `documentation`, `code-organization` | — | `/repo-onboarding` for a new hire |