claude-code-kit 0.63.0__tar.gz → 0.64.0__tar.gz

{claude_code_kit-0.63.0 → claude_code_kit-0.64.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.63.0",
+      "version": "0.64.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.63.0",
+  "version": "0.64.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.63.0 → claude_code_kit-0.64.0}/CHANGELOG.md

@@ -4,6 +4,82 @@ 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.64.0] — 2026-07-16
+
+**Curated engineering-writing sweep — folding widely-taught senior-engineer patterns into the
+existing skill/rule set.** Prompted by a request to learn from a Medium post on "coding patterns
+from senior engineers" and, more broadly, from the canon of freely-readable engineering writing
+(SRE Book, AWS Builders' Library, Google's API Design Guide & Eng Practices, Martin Fowler,
+Brendan Gregg, and the classic distributed-systems / "boring technology" essays). Every pattern
+was checked against what the kit already ships and adopted **only where genuinely novel**;
+everything is re-derived as stack-agnostic prose and **attributed to its public source, never
+vendored**. Reuse-first per golden rule #7 — **0 new skills, agents, or rules; 0 new components**.
+All additions are append-only `###` subsections; no headings were renumbered (cross-refs stay
+stable). (0.63.0 is reserved by the in-flight chrome-devtools-mcp PR #90 — merge that first; see
+the version note in this PR.)
+
+### Added
+
+- **`resilience-engineering` rule — CAP/PACELC as a design-time lens** and a **"Fallbacks and
+  shedding — the sharp edges"** subsection: a provider-wide outage flips *all* traffic to the
+  secondary at once, so size the fallback for full load (or shed) and exercise it — an untested
+  fallback amplifies the outage (static-stability framing, per the AWS Builders' Library).
+- **`devops-observability` rule — "Error budgets as a control loop"**: the budget is the shared
+  release/reliability throttle — burn it fast → freeze features and spend on stability; hold it →
+  spend it on velocity (per the Google SRE Book).
+- **`_references/performance-checklist` — "Network Latency Fundamentals"**: the order-of-magnitude
+  latency table (L1/RAM/SSD/disk/same-DC RTT/cross-region RTT) as the back-of-envelope every design
+  review should start from (per "Latency Numbers Every Programmer Should Know", Dean/Norvig).
+- **`load-testing` — on-CPU vs off-CPU time**, Amdahl's Law, and the Universal Scalability Law:
+  why throughput can *fall* under load (coherency/contention), not just plateau (per Brendan Gregg
+  on off-CPU analysis and Neil Gunther's USL).
+- **`library-review` — "Boring is a feature (innovation-token budget)"**: spend a small, finite
+  budget of novelty on the few places it's a differentiator; default to proven tech elsewhere
+  (per Dan McKinley, "Choose Boring Technology").
+- **`over-engineering-review` — "The wrong abstraction"**: a bad abstraction costs more than
+  duplication; inlining back to duplication is legitimate, not regression (per Sandi Metz).
+- **`deprecation-and-migration` — "Parallel Change (Expand → Migrate → Contract)"**: the
+  three-phase safe-rename/evolve discipline (per Martin Fowler / Danilo Sato), resolving a
+  dangling cross-reference from the planning skill.
+- **`api-pagination-filtering-sorting` — cursor/keyset pagination vs offset**: why `OFFSET n`
+  degrades and drifts under concurrent writes, and when a stable cursor is required.
+- **`redis-caching-patterns` — cache-stampede protection for hot keys**: single-flight/request
+  coalescing plus probabilistic early expiration (per the AWS Builders' Library and the XFetch
+  scheme, Vattani et al.), with a matching anti-pattern entry.
+- **`api-and-interface-design` — three additions**: decouple the API surface from the storage
+  schema (DTO/serializer seam), **Idempotency-Key** mutations with stored-result replay, and
+  **Long-Running Operations** (202 + pollable operation resource) — per Stripe's idempotency
+  design and the Google API Design Guide; plus three matching Red Flags.
+- **`testing-conventions` — Consumer-Driven Contract testing** across services: the consumer
+  publishes a pact, the provider replays every consumer's pact in its own CI (per Fowler / Ian
+  Robinson) — the cross-service twin of the existing contract-testing pipeline.
+- **`code-review-and-quality` — "If you cannot understand it, that *is* the finding"**:
+  incomprehensibility is a defect; "I don't understand this — please clarify or simplify" is a
+  legitimate blocking review comment (per Google's Code Review Developer Guide).
+- **`notifications-and-messaging` — fallback-amplification caveat** on the provider fallback
+  chain, cross-linked to the new `resilience-engineering` static-stability note.
+
+### Changed
+
+- Appended a row to `docs/influences.md` recording this curated engineering-writing sweep.
+
+### Not adopted (deliberately)
+
+- **"Master the tools you hate" / "order-of-magnitude exploration" / "bottom-up strategy
+  synthesis"** — real senior habits, but meta-advice about how an engineer works, not
+  stack-agnostic engineering *conventions* the kit can enforce or check. Out of the kit's lane.
+- **"A shared platform scales the org"** — already the throughline of `library-review` and the
+  YAGNI/over-engineering skills; adding it verbatim would duplicate, not extend.
+- **"Separate simple from easy" (Rich Hickey, *Simple Made Easy*)** — its operative advice already
+  lives in `over-engineering-review` and `code-simplification`; folding in the vocabulary added no
+  new decision the reviewer could act on.
+- **Mechanical-sympathy detail (cache-line/false-sharing/data-locality)** — below the kit's
+  abstraction level; the kept latency table gives the right-altitude version without prescribing
+  memory-layout tactics no stack-agnostic reviewer can apply.
+- **Per-client request-rate estimation for capacity** — fragile in practice and already covered by
+  the retry-budget / load-shedding guidance in `resilience-engineering`.
+- **No new skills/agents/rules.** Every pattern above extends an existing file; nothing warranted a
+  new component (reuse-first, golden rule #7). Component counts are unchanged.
 ## [0.63.0] — 2026-07-16
 
 **Catalog fix — the `auditor` agent can finally get the MCP server it depends on.** The `auditor`

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.63.0
+Version: 0.64.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

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/docs/influences.md

@@ -32,6 +32,7 @@ non-duplicative gaps**, minimally and catalog-wired.
 | **[facebook](https://github.com/facebook) (Meta) org review** (all 168 repos) | Interprocedural taint / data-flow security analysis (source→sink across functions); continuous A/B performance-regression CI gate; defense-in-depth agent-sandbox enforcement (argument validation + OS-level backstop) | Prose extensions to `linting-and-formatting` (taint/data-flow layer), `devops-observability` (perf-regression gate), `agent-guardrails` (§4 layered sandbox enforcement) — **0 new agents/skills/rules** (from pyre-check/Pysa · mariana-trench · FAI-PEP · mcpguard-dynamic; the org is mostly libraries/frameworks, so the verify pass *dropped* the rest — `DNE-TaaC`, `mbt`, plus already-covered `infer`/`mariana-trench`-as-tool, `fbt`, `memlab`, …) | `0.52.0` |
 | **[Netflix](https://github.com/Netflix) · [aws](https://github.com/aws) · [apple](https://github.com/apple) org review** (all **1,214** repos) | Service-level resilience the kit lacked entirely — stability patterns (timeout/retry-budget/circuit-breaker/bulkhead) + adaptive concurrency limiting, chaos engineering, and bounded-clock distributed time; failure-domain-aware progressive rollout; deterministic simulation testing; a formal RFC process (working-backwards + API bar-raiser); continuous usage-based least-privilege | The **new `resilience-engineering` rule** (chaos + stability patterns + bounded clocks, from `Netflix/concurrency-limits` · `Netflix/chaosmonkey` · `aws/clock-bound`); plus prose extensions to `devops-observability` (failure-domain rollout, from `aws/zone-aware-controllers-for-k8s`), `testing` (deterministic simulation testing, from `apple/foundationdb`), `spec-driven-development` (RFC track, from `aws/aws-cdk-rfcs`), and `security-and-hardening` (continuous least-privilege, from `Netflix/repokid`) — **1 new rule, 0 new agents/skills** (the orgs are overwhelmingly SDKs/CLIs/services, so the survey kept only 7 of 1,214) | `0.53.0` |
 | **1,345-repo OSS adoption scan** (39 provenance-tagged searches across the AI/Claude/MCP/context ecosystem; 76 verified adoption ideas → 30-item backlog) | Agent-config supply-chain vetting + toxic-flow legs taxonomy; hidden-Unicode detection; content-type-aware **reversible** output compression (~200-token floor) + "think in code" (from Apache-2.0 `headroomlabs-ai/headroom` · `gsd-build/get-shit-done`; deterministic shell-side companion `rtk-ai/rtk`, referenced); symbol-first retrieval ladder (from MIT `oraios/serena` · `MinishLab/semble`); budget-visible statusline HUDs (`jarrodwatts/claude-hud`, referenced); tribal-standards elicitation (from `buildermethods/agent-os`); evidence-based test nagging + falsifiability eval discipline (from `maxritter/pilot-shell`); colocated skill evals (from `darkrishabh/agent-skills-eval`) | Waves across `dependency-verification` (vetting canon), `catalog/mcp.yaml` (+5 fragments → 22, all leg-annotated), `validator.py` (Unicode scan + INFO channel), **new `check_cross_references.py` CI gardener**, `context-engineering` (compression recipes · 5th primitive · retrieval ladder · budget visibility · pressure symptoms · tribal test), `tool-design`, `evals` §9–10 + `eval-harness`, `agent-guardrails` §3/§4, orchestrator VALIDATE, consolidate-learnings Promote, and ~10 more files — **0 new agents/skills, 1 new CI script** | `0.60.0`–`0.62.0` |
+| **Curated engineering-writing sweep** (a Medium "senior-engineer patterns" prompt → the freely-readable canon: Google SRE Book · AWS Builders' Library · Google API Design Guide & Eng Practices · Martin Fowler · Brendan Gregg · Dan McKinley · Sandi Metz · Stripe/Google idempotency & LRO · Dean/Norvig latency numbers) | Design-time CAP/PACELC + static-stability fallback sizing; error budgets as a release throttle; order-of-magnitude latency table; off-CPU/Amdahl/USL scalability; innovation-token budgeting; the wrong-abstraction cost; Parallel Change (expand→migrate→contract); cursor vs offset pagination; cache-stampede (single-flight + XFetch); DTO/storage decoupling + Idempotency-Key + long-running-operation API shapes; consumer-driven contract testing; "if you can't understand it, that's the finding" | Prose extensions to `resilience-engineering` & `devops-observability` rules + 9 skills (`_references/performance-checklist`, `load-testing`, `library-review`, `over-engineering-review`, `deprecation-and-migration`, `api-pagination-filtering-sorting`, `redis-caching-patterns`, `api-and-interface-design`, `testing-conventions`, `code-review-and-quality`, `notifications-and-messaging`) — **0 new agents/skills/rules; component counts unchanged** | `0.64.0` |
 
 > Each adoption is detailed in the [CHANGELOG](../CHANGELOG.md) — including, for every review, what we
 > deliberately **did not** add because the kit already covered it.

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.63.0"
+version = "0.64.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.63.0 → claude_code_kit-0.64.0}/rules/devops-observability.md

@@ -72,6 +72,25 @@ is gone. The SRE pattern is to alert on **how fast the SLO's error budget is bur
 > [`google/prometheus-slo-burn-example`](https://github.com/google/prometheus-slo-burn-example).
 > Re-derived in prose; not vendored — the windows/multipliers are a starting point to tune per SLO.
 
+### Error budgets as a control loop (what you *do* when the budget burns)
+
+Burn-rate alerting tells you the budget is draining; the error budget is also the **decision rule** for
+the team, not just a dashboard number. Close the loop:
+
+- **Spend it, or freeze.** Budget remaining ⇒ you can take launch/velocity risk. Budget **exhausted** ⇒
+  **freeze risky launches** and redirect effort to reliability until you are back in budget — an
+  automatic, blameless policy agreed in advance, not a per-incident argument.
+- **Don't over-achieve the SLO.** Running far *above* target is not free: it means you spent velocity
+  you didn't have to and trained users to depend on reliability you never promised. 100 % is the wrong
+  target — the budget exists to be *used*.
+- **Cap toil.** Manual, repetitive operational work should be bounded (a common ceiling is ≤ ~50 % of
+  an owner's time); past the cap, **automate it or escalate**, because toil that grows with traffic
+  doesn't scale and starves the reliability work the burn-rate signal is asking for.
+
+> Per the Google SRE Book (error budgets as a launch-gating policy, "100 % is the wrong target", toil
+> budgets), sre.google/sre-book. Applied in prose as the organizational counterpart to the burn-rate
+> *detection* above.
+
 ### High-volume logging: rate-limit and defer
 
 Logging on a hot path or in an error burst can become its own incident — the log call dominates CPU, or

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/rules/resilience-engineering.md

@@ -63,6 +63,43 @@ limit where queueing begins**.
 > not vendored — the algorithm maps onto any language's concurrency primitive (semaphore, pool, worker
 > count).
 
+### Partition behavior: choose consistency or availability, per operation (CAP/PACELC)
+
+When the network **partitions**, a replicated store cannot be both consistent and available for a
+write — it must either **reject** the operation (stay consistent) or **accept** it and risk divergence
+(stay available). This is not one system-wide switch: decide **per operation** by its blast radius.
+"Add to cart" can stay available and reconcile later; "charge the card" or "sell the last unit of
+stock" must reject rather than double-spend. And the trade-off does not vanish when the network is
+healthy — **PACELC**'s *else* clause: absent a partition, you still trade **latency against
+consistency**, because stronger consistency costs coordination round-trips. Set that knob per
+operation too (a stale read is fine for a dashboard, not for an authorization check). Don't take a
+datastore's advertised guarantee on faith — assert the one you depend on with fault injection (§3),
+the way partition testing repeatedly surfaces consistency violations the vendor didn't expect.
+
+> Per the CAP / PACELC framing (Eric Brewer; Daniel Abadi) and *Designing Data-Intensive Applications*
+> (Martin Kleppmann); "verify, don't trust the guarantee" follows Kyle Kingsbury's Jepsen partition
+> testing (jepsen.io). Applied in prose to the per-operation choice, independent of any one datastore.
+
+### Fallbacks and shedding — the sharp edges
+
+Two of the patterns in the table bite back if applied naively:
+
+- **A fallback can amplify the outage it's meant to survive.** If the fallback path itself calls a
+  dependency (or retries the failing one), it *adds* load exactly when the system is already failing —
+  turning a partial outage into a total one. The safe fallback returns a **static or cached** value and
+  introduces **no new dependency at failure time** (*static stability*: pre-provision the answer so the
+  degraded path does less work, not more). And always make the fallback **observable** — a silently
+  successful fallback masks a real dependency failure.
+- **Under overload, drop work that has already missed its deadline.** A request whose deadline has
+  passed is worthless to process — its caller has given up (and likely retried), so serving it burns
+  capacity for no one. Check the deadline **at dequeue**, not just at accept, and shed the expired work.
+  When saturated, prefer serving the **newest** requests first (LIFO): it keeps *some* requests fast
+  instead of making *all* of them uniformly slow and stale.
+
+> Per the AWS Builders Library ("Avoiding fallback in distributed systems"; static stability),
+> aws.amazon.com/builders-library, and the CoDel / Google SRE intuition on deadline-aware, LIFO-under-
+> overload queueing. Applied in prose; the discipline is transport- and language-independent.
+
 **Self-check at every remote call:** does it have a timeout and a deadline budget; is its retry
 idempotent, jittered, and budgeted; is there a breaker so a *down* dependency fails fast; and is its
 resource pool isolated so it can't starve the rest?

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/_references/performance-checklist.md

@@ -6,6 +6,7 @@ Quick reference checklist for web application performance. Use alongside the `pe
 
 - [Core Web Vitals Targets](#core-web-vitals-targets)
 - [TTFB Diagnosis](#ttfb-diagnosis)
+- [Network Latency Fundamentals](#network-latency-fundamentals)
 - [Frontend Checklist](#frontend-checklist)
 - [Backend Checklist](#backend-checklist)
 - [Measurement Commands](#measurement-commands)
@@ -27,6 +28,29 @@ When TTFB is slow (> 800ms), check each component in DevTools Network waterfall:
 - [ ] **TCP/TLS handshake** slow → enable HTTP/2, consider edge deployment, verify keep-alive
 - [ ] **Server processing** slow → profile backend, check slow queries, add caching
 
+## Network Latency Fundamentals
+
+On a well-provisioned connection most "slow page" problems are **latency**-bound, not bandwidth-bound —
+past ~5 Mbps, adding bandwidth barely moves page-load time, but every millisecond of round-trip time
+(RTT) does. Know these before optimising:
+
+- **RTT is set by distance and bounded by the speed of light** — you can't compress it, only move the
+  bytes closer. **Geographic proximity (CDN / edge) is the single biggest RTT lever.**
+- **Each new connection costs round-trips before any data flows** — DNS + TCP handshake (1 RTT) + TLS
+  (1–2 RTT). **Reuse connections** (keep-alive, pooling, `preconnect`) so you pay this once, not per request.
+- **TCP slow-start makes a fresh connection slow even on a fast link** — the congestion window ramps up
+  over several round-trips, so a cold connection can't use full bandwidth for the first few KB. Another
+  reason to reuse warm connections and keep critical responses small.
+- **Head-of-line (HOL) blocking wastes the link.** HTTP/1.1 lets one response block those behind it on a
+  connection (the origin of old domain-sharding hacks). **HTTP/2** multiplexes many streams over one
+  connection (fixes it at the application layer); a lost packet still stalls all streams at the TCP
+  layer, which **HTTP/3 (QUIC over UDP)** fixes at the transport layer. Prefer H2/H3.
+- **Bandwidth-delay product** (bandwidth × RTT) is how much data must be "in flight" to keep the pipe
+  full; on a high-RTT link a too-small window/buffer leaves the link idle no matter the bandwidth.
+
+> Per Ilya Grigorik, *High Performance Browser Networking* (free full text at hpbn.co). A stack-agnostic
+> primer; the concrete resource hints live in the Network checklist below.
+
 ## Frontend Checklist
 
 ### Images

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/api-and-interface-design/SKILL.md

@@ -34,6 +34,20 @@ This means: every public behavior — including undocumented quirks, error messa
 
 Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.
 
+### Decouple the API Surface from the Storage Schema
+
+The wire contract and the database schema are two different things that change at two different rates.
+If the API just serializes your tables, every storage refactor (splitting a column, normalizing,
+reshaping for a new index) becomes a *breaking API change*, and conversely every API need distorts the
+schema. Design the resource representation for the **consumer**, then map it to storage explicitly
+through a serializer / DTO layer, so either side can evolve behind that seam. This is why `Task` (the
+output type below) is defined separately from any table row — and why "establishing a database schema
+that informs API shape" (in *When to Use*) means *informs*, never *dictates*: Hyrum's Law makes an
+accidentally-exposed column as permanent as a deliberately-promised field.
+
+> Per the Google API Design Guide (resource-oriented design; cloud.google.com/apis/design). Stack-agnostic —
+> the DTO/serializer seam applies equally to REST, GraphQL, and RPC.
+
 ### 1. Contract First
 
 Define the interface before implementing it. The contract is the spec — implementation follows.
@@ -206,6 +220,49 @@ PATCH /api/tasks/123
 { "title": "Updated title" }
 ```
 
+### Idempotent Mutations (Idempotency-Key)
+
+A client that retries a `POST` after a timeout must not create the resource twice — but the network
+can't tell the client whether the first attempt actually landed. Let the client send a unique
+**`Idempotency-Key`** header per logical operation; the server records that key with the result of the
+first successful execution and, on any replay of the same key, returns the **stored result** instead of
+re-running the side effect:
+
+```
+POST /api/payments
+Idempotency-Key: 5f3a…-once-per-operation
+{ "amount": 4200, "currency": "usd" }
+```
+
+Scope keys per endpoint + caller, give them a retention window (e.g. 24h), and key on the *operation*,
+not the request body (a changed body under a reused key is a client error → `422`). This makes
+create/charge/enqueue endpoints safe to retry — the API-surface counterpart to the at-least-once /
+idempotent-consumer discipline in `.claude/rules/resilience-engineering.md`.
+
+> Per Stripe's idempotent-requests design and the Google API Design Guide (cloud.google.com/apis/design).
+> Stack-agnostic; the store behind the key can be any durable KV.
+
+### Long-Running Operations
+
+When an operation can't finish within a request (a large export, a provisioning job, a batch), don't
+hold the connection open and don't fake a synchronous `200`. Return **`202 Accepted`** with an
+**operation resource** — a real, pollable URL — and make that operation a first-class resource with its
+own lifecycle, not an out-of-band job id:
+
+```
+POST /api/exports            → 202 Accepted, { "operation": "/api/operations/abc" }
+GET  /api/operations/abc     → { "done": false }
+GET  /api/operations/abc     → { "done": true, "result": { "url": "/api/exports/abc.csv" } }
+                            // or { "done": true, "error": { "code": "...", "message": "..." } }
+```
+
+The client polls (or is notified via webhook) until `done`. This keeps the API's latency contract
+honest and its failures observable, instead of hiding a slow job behind a request that will eventually
+time out.
+
+> Per the Google API Design Guide's Long-Running Operations pattern (cloud.google.com/apis/design).
+> Stack-agnostic.
+
 ## Type-Safe Interface Patterns
 
 ### Use Discriminated Unions for Variants
@@ -280,6 +337,9 @@ function getTask(id: TaskId): Promise<Task> { ... }
 - List endpoints without pagination
 - Verbs in REST URLs (`/api/createTask`, `/api/getUsers`)
 - Third-party API responses used without validation or sanitization
+- Non-idempotent `POST`/create endpoints with no idempotency key — retries silently double-charge/double-create
+- Long jobs served synchronously (a `POST` that blocks for minutes) instead of returning a `202` + operation resource
+- Response bodies that are 1:1 serializations of database rows (storage schema leaking through the API)
 
 ## Verification
 

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/api-pagination-filtering-sorting/SKILL.md

@@ -48,6 +48,10 @@ Standardize HTTP query parameter conventions and response metadata for paginated
 
 15. **Caching paginated responses**: For expensive queries, cache results by a key derived from `(query_params, hierarchy_filters, org_id, run_id)`. Serialize the Pydantic response model to JSON for cache storage. Cache TTL is typically 1 hour. Invalidate cache on data writes. Use Redis or in-memory cache. Avoid caching every page individually; instead cache the full result set or the first page and accept cache misses for deeper pages.
 
+16. **Cursor/keyset pagination — and *why* it beats offset for large or mutating sets**: offset pagination (`LIMIT/OFFSET`) has two failure modes the conventions above don't fix. **Correctness:** when rows are inserted or deleted between two page fetches, the offset shifts, so the client silently **skips rows or sees the same row twice** across page boundaries. **Performance:** the database must scan and discard all `offset` rows before returning the page, so deep pages (`OFFSET 100000`) degrade linearly. **Cursor (keyset) pagination** fixes both by paginating *relative to a stable ordering key* instead of a numeric skip: `WHERE (sort_key, id) > (:last_sort_key, :last_id) ORDER BY sort_key, id LIMIT :n`. Return an **opaque, encoded `next_cursor`** (the last row's ordering key(s) — never a raw offset the client can tamper with) plus `has_next`. It requires a **total, stable sort** — append a unique tiebreaker (e.g. `id`) so ties can't reorder between requests. Trade-off: no "jump to page 50" and no exact `total_pages`. Use offset for small, bounded, human-paged lists; use cursor for infinite scroll, large tables, and any list that mutates under the reader.
+
+> The offset-skips-rows / deep-page-cost rationale and the opaque-cursor convention follow common API design canon (e.g. Stripe's list pagination). Stack-agnostic; the `(sort_key, id)` keyset predicate maps to any ordered store.
+
 ## Skeleton / example
 
 ```python

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/code-review-and-quality/SKILL.md

@@ -46,6 +46,18 @@ Can another engineer (or agent) understand this code without the author explaini
 - Would comments help clarify non-obvious intent? (But don't comment obvious code.)
 - Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments?
 
+**If you cannot understand it, that *is* the finding.** When a reviewer genuinely can't follow what a
+piece of code does after a fair effort, do not approve it and do not wave it through with a guess — the
+incomprehensibility is itself a defect, because code the next reader (human or agent) can't understand
+can't be safely changed or debugged later. "I don't understand this — please clarify or simplify" is a
+legitimate, blocking review comment, not an admission of reviewer inadequacy; the burden is on the
+author to make the code understandable, not on the reviewer to decode it. (This is also a signal the
+code may be too complex — see `over-engineering-review`.)
+
+> Per Google's Code Review Developer Guide (google.github.io/eng-practices) — if a reviewer doesn't
+> understand a change, it is likely too complex, and the reviewer should ask for clarification or
+> simplification rather than approve.
+
 ### 3. Architecture
 
 Does the change fit the system's design?

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/deprecation-and-migration/SKILL.md

@@ -194,6 +194,29 @@ function getTaskService(userId: string): TaskService {
 }
 ```
 
+### Parallel Change (Expand → Migrate → Contract)
+
+To change an interface, schema, or contract that already has consumers, never edit it in place — evolve
+it in three independently-deployable, reversible phases so the change is never breaking:
+
+```
+Expand   — add the new form alongside the old (new column / field / method / parameter); both work at
+           once, and producers write BOTH forms.
+Migrate  — move every consumer from the old form to the new one, incrementally. When done, the old form
+           has zero readers.
+Contract — remove the old form. (This is exactly the Pre-Removal Safety Check above — verify zero
+           consumers first.)
+```
+
+This is the **schema/interface-level** counterpart to the Strangler pattern (which routes *traffic*
+between whole systems). Use it for the small, high-frequency breaking changes: renaming a database
+column (add new column → dual-write + backfill → switch reads → drop old), changing a function
+signature, evolving an API response field, or changing a message schema consumers deserialize. Because
+each phase ships and rolls back on its own, a breaking change becomes a sequence of safe ones.
+
+> Per Martin Fowler, "Parallel Change" / expand-contract (martinfowler.com). The interface-level twin
+> of Strangler; both keep the old and new forms alive during the move.
+
 ## Zombie Code
 
 Zombie code is code that nobody owns but everybody depends on. It's not actively maintained, has no clear owner, and accumulates security vulnerabilities and compatibility issues. Signs:

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/library-review/SKILL.md

@@ -67,6 +67,18 @@ just one helper from it.
 **✅** Active, regular releases · clear changelog + semver · permissive compatible license · security
 scanning / signed releases · small focused surface · typings available · several reputable dependents.
 
+## Boring is a feature (innovation-token budget)
+
+Prefer **proven, boring** technology for anything that is not your core differentiator. Treat novelty
+as a scarce budget: a team has only a few "innovation tokens" to spend on genuinely-new tech (whose
+failure modes, operational quirks, and hiring pool it doesn't yet know), so **spend them on the
+problems that are actually your product** and take the well-understood option everywhere else. A
+candidate that is exciting but unproven should clear a *higher* bar on Maintenance, Adoption, and
+Security above — not a lower one.
+
+> Per Dan McKinley, *Choose Boring Technology* (boringtechnology.club). A lens over the dimensions
+> above, not a separate score.
+
 ## The decision
 
 Conclude explicitly — never let a dependency slip in undecided:

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/load-testing/SKILL.md

@@ -73,6 +73,26 @@ export default function (data) {
 - p95 within the endpoint's SLO; p99 no more than ~2–3× p95 (bigger gap = tail problems).
 - Throughput scales with concurrency until a plateau — find where it flattens.
 
+## Where the time goes: on-CPU vs off-CPU, and why throughput plateaus
+
+Two ideas explain most load-test curves and stop you optimising the wrong thing:
+
+- **Latency rising while CPU stays low means the service is blocked *off-CPU*** — waiting on a lock, a
+  connection-pool slot, disk/network IO, or a downstream call, not computing. A CPU profiler shows
+  almost nothing in this state; you have to profile the *waiting* (**off-CPU analysis**). So when the
+  latency knee appears (Method step 6), check saturation of the *waited-on* resource — pool, lock,
+  downstream — before touching application code.
+- **Throughput plateaus because of the serial fraction, and can *decline* because of coordination.**
+  **Amdahl's Law**: the part of the work that can't be parallelised caps total speedup no matter how
+  many workers you add. The **Universal Scalability Law** adds a *coherency* penalty — the cost of
+  workers coordinating (contended locks, a shared counter, a hot row): past a point, adding concurrency
+  makes throughput go **down**, not just flat (the retrograde region). A plateau-then-decline as you
+  raise VUs is that signature; the fix is shrinking the serial/contended fraction, not adding workers.
+
+> Off-CPU analysis per Brendan Gregg (brendangregg.com/offcpuanalysis.html); Amdahl's Law and the
+> Universal Scalability Law (Neil Gunther) as public canon. Applied in prose to reading load-test
+> curves; tool-agnostic.
+
 ## Rules
 
 1. **Never load-test production** without explicit approval — test a staging/local stack. See `.claude/rules/human-in-the-loop.md`.

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/notifications-and-messaging/SKILL.md

@@ -30,7 +30,7 @@ Standardize multi-provider notification delivery across email (SendGrid, Nodemai
 
 5. **Dev-mode logging instead of sending**: when `NODE_ENV === "development"` or `DISABLE_EMAIL === "true"`, skip actual API calls. Log email/SMS details to console (recipient, subject, preview of HTML/text, OTP codes) and return `{ success: true, message: "Logged (dev mode)" }`. Useful for local testing without burning quota or exposing credentials.
 
-6. **Fallback chain for high availability**: wrap provider calls in a retry/fallback wrapper (`retryOnFailure(fn, provider, options)`) that attempts the primary provider, then falls back to a secondary provider on failure. Example: SendGrid primary → Nodemailer SMTP secondary. Track failure counters and alert on repeated fallback usage.
+6. **Fallback chain for high availability**: wrap provider calls in a retry/fallback wrapper (`retryOnFailure(fn, provider, options)`) that attempts the primary provider, then falls back to a secondary provider on failure. Example: SendGrid primary → Nodemailer SMTP secondary. Track failure counters and alert on repeated fallback usage. **Caveat — a provider-wide outage flips *all* traffic to the secondary at once**, so size the secondary for full load (or accept shedding) and exercise the fallback path regularly; an untested fallback that can't absorb the surge amplifies the outage instead of surviving it. See the fallback-amplification / static-stability note in `.claude/rules/resilience-engineering.md`.
 
 7. **Template-driven messages**: define templates as functions that accept data objects and return `{ subject, html, text }`. Common templates: `verificationOtpEmail(name, otp)`, `passwordResetEmail(name, resetLink)`, `welcomeEmail(name, portalLink)`, `interviewScheduledEmail(candidate, job, interviewDate, meetingLink)`, `offerExpiringEmail(candidate, job, expiryDate)`. Use a template engine (Nunjucks, Handlebars, or inline string templates) for HTML generation. Store templates in `templates/` or `src/templates/emails/`.
 

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/over-engineering-review/SKILL.md

@@ -55,6 +55,24 @@ Dependencies the stdlib or platform already ships · single-implementation inter
 one product · wrappers that only delegate · modules exporting one thing · dead flags and config ·
 hand-rolled stdlib · speculative "for later" scaffolding.
 
+## The wrong abstraction (when de-duplication went too far)
+
+Over-engineering also hides in the *inverse* of duplication. Watch for a shared abstraction that keeps
+growing **boolean / enum / "mode" parameters** so each caller can fork its behavior down a different
+branch. That parameter accretion is the signature of the **wrong abstraction** — code de-duplicated
+before the right shape was known, so now every caller pays for a generalization that fits none of them,
+and each new requirement wedges in another flag.
+
+The counter-intuitive fix: **re-inline it back into its callers** (yes, re-introducing the
+duplication), then let the *correct* abstraction re-emerge once the real axis of variation is visible.
+**A little duplication is far cheaper than the wrong abstraction** — copied code is a local, obvious
+cost; a wrong abstraction taxes every caller and compounds. Flag it (`shrink:` on the flag-laden
+generalization, recommending re-inlining) when a "reusable" helper is mostly `if mode == …` branches.
+
+> Per Sandi Metz, "The Wrong Abstraction" (prefer duplication over the wrong abstraction). The
+> complement to the `yagni:` tag: `yagni:` catches abstraction built too *early*; this catches
+> abstraction that de-duplicated too *aggressively*.
+
 ## Burden of proof — scrutinize each addition
 
 The five tags catch complexity that already exists. In **diff mode**, also invert the burden of proof

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/redis-caching-patterns/SKILL.md

@@ -46,6 +46,12 @@ Standardize Redis caching implementation with multi-tenant key isolation, TTL st
 
 13. **Cross-link multi-tenancy-patterns and async-python-patterns**: see `multi-tenancy-patterns` for RLS/schema isolation and tenant context propagation; see `async-python-patterns` for asyncio task scheduling, connection pooling, and async context managers.
 
+14. **Cache-stampede protection for hot keys** (single-flight + early recompute): when a popular key expires, many concurrent requests miss *at the same instant* and all recompute it simultaneously — a *thundering herd* that can overload the very origin the cache exists to protect (and the network can't tell them to wait for each other). Two composable defenses; reserve them for genuinely hot keys, since the coordination cost isn't worth it for cold ones:
+    - **Request coalescing / single-flight** — the first miss takes a short per-key lock (`SET {key}:lock <token> NX EX <few s>`), recomputes, and populates the cache; concurrent callers that fail to get the lock briefly wait-and-retry the read (or serve the last good value) instead of stampeding the origin. Only one caller hits the backend per key per expiry. Release the lock by token (compare-and-delete) so a slow holder can't delete a successor's lock.
+    - **Probabilistic early expiration (XFetch)** — store the value's recompute cost and its expiry alongside it, and let each reader *probabilistically* recompute slightly *before* the TTL elapses (the probability rises as expiry nears). One request refreshes the key while it is still warm; everyone else keeps hitting the cache, so the key never actually expires under load. This avoids the synchronized miss entirely, without a lock.
+
+    > Per the AWS Builders Library ("Caching challenges and strategies", aws.amazon.com/builders-library) and the XFetch scheme (Vattani et al., "Optimal Probabilistic Cache Stampede Prevention"). Stack-agnostic; the lock/early-recompute discipline maps to any cache, not just Redis.
+
 ## Skeleton / example
 
 ```python
@@ -495,6 +501,7 @@ class TenantRedis:
 8. **Not logging cache errors**: silent failures are invisible. Log at `warning` or `error` level for monitoring/alerting.
 9. **Mixing sync and async Redis clients**: use `redis.asyncio` consistently in async services (FastAPI, aiohttp). Sync `redis-py` blocks the event loop.
 10. **Storing sensitive data without encryption**: cache should not hold PII/secrets unless encrypted at application layer. Use short TTLs for sensitive data.
+11. **No stampede protection on hot keys**: letting a popular key expire with no coalescing or early recompute means every concurrent miss recomputes at once and can knock over the origin — the failure often looks like a mysterious periodic latency/error spike synced to the TTL. Add single-flight and/or probabilistic early expiration for hot keys (convention 14).
 
 ## References
 

{claude_code_kit-0.63.0 → claude_code_kit-0.64.0}/skills/testing-conventions/SKILL.md

@@ -175,6 +175,22 @@ jobs:
       - run: pytest -m integration -v
 ```
 
+### Consumer-Driven Contract Testing (across services)
+
+The "Contract testing pipeline" above validates one repo's schema against its own frontend. When a
+provider serves *multiple independent consumers* (other services, mobile clients, partner APIs),
+generalize it to **consumer-driven contracts (CDC)**: each consumer publishes the exact subset of the
+provider's responses it actually depends on (a *pact*), and the provider replays **every** consumer's
+pact in **its own CI**. The provider then learns it broke a downstream consumer *before* it deploys —
+without standing up a full end-to-end environment — and stays free to change anything no consumer's
+contract pins. CDC is the test-suite counterpart to the cross-service planning in
+`planning-and-task-breakdown` and the expand/contract rollout in `deprecation-and-migration`: green
+pacts are how you know the "contract" (removal) phase is actually safe. _(cross-service test pattern)_
+
+> Per Martin Fowler / Ian Robinson, "Consumer-Driven Contracts" (martinfowler.com). Stack- and
+> tool-agnostic — Pact is one implementation; the discipline (consumer defines, provider verifies in
+> CI) is the point.
+
 ### Security-Regression Tests
 
 Functional tests prove a feature *works*; security-regression tests prove it *can't be abused*. They are

{claude_code_kit-0.63.0 → claude_code_kit-0.64.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.63.0"
+__version__ = "0.64.0"