claude-code-kit 0.35.0__tar.gz → 0.37.0__tar.gz

{claude_code_kit-0.35.0 → claude_code_kit-0.37.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.35.0",
+      "version": "0.37.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.35.0",
+  "version": "0.37.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.35.0 → claude_code_kit-0.37.0}/CHANGELOG.md

@@ -4,6 +4,43 @@ 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.37.0] — 2026-06-26
+
+**New `temporal-developer` collection skill — Temporal *fundamentals*, language-agnostic** (re-derived
+concisely from the official MIT [`temporalio/skill-temporal-developer`](https://github.com/temporalio/skill-temporal-developer);
+nothing vendored, cross-checked against https://docs.temporal.io). Complements — does **not** duplicate —
+the existing `temporal-config-driven` skill (which stays scoped to this kit's config-driven worker-map /
+DAG-as-data architecture and *assumes* these fundamentals).
+
+- **`skills/temporal-developer/`** (SKILL.md + README.md with MIT provenance) covers the durable-execution
+  model, **why workflows must be deterministic** (history replay → Command/Event matching), the
+  workflow/activity/worker split, Query vs Signal vs Update, and six compact references:
+  `determinism.md`, `versioning.md` (patching · workflow-type · worker/Build-ID versioning),
+  `testing.md` (local/time-skipping env, activity mocking, replay tests), `gotchas.md`,
+  `cli.md` (`temporal server start-dev` + the `workflow start/execute/signal/query/update` dev loop),
+  and `languages.md` (Python/Go/TypeScript starters + pointer to upstream Java/.NET/Ruby/Rust depth).
+- **Auto-trigger boundary** wired both ways: each skill's `description` carries an explicit
+  `Do NOT use … → use <sibling>` clause, with reciprocal pointers in both SKILL.md/README.md bodies.
+- Counts: **96 → 97** total skills (**45 → 46** stack-collection; core unchanged at 51), plus a new
+  `docs/stack-skills` catalog row. No catalog/stack/hook/agent changes (Temporal is a skill, not a stack axis).
+
+## [0.36.0] — 2026-06-25
+
+**Rule-presentation + context-hygiene polish** (patterns adopted from Karpathy-skills, addyosmani/agent-skills,
+and shanraisshan/claude-code-best-practice — all MIT; presentation only, no substance change). Same rules,
+stickier and more actionable:
+
+- **6 high-value rules** (`mandatory-workflow`, `quality-gates`, `agent-resilience`,
+  `goal-setting-and-monitoring`, `reasoning-techniques`, `code-organization`) each gain a **bold quotable
+  tagline** under the H1, one or two **embedded self-check** lines in their key section, and a measurable
+  **"This rule is working if …"** success-signal line.
+- **`skills/context-engineering/SKILL.md`** gains quantitative guardrails: a **<200-line CLAUDE.md target**,
+  a **degradation-zone threshold** (~40% of window) in the failure taxonomy, **session-boundary heuristics**
+  ("new task = new session"; summarize-before-rewind) under Level 5, and a **≈30% baseline headroom** target
+  for progressive disclosure.
+
+Markdown-only, count-neutral (no new rules/skills); existing behavior unchanged.
+
 ## [0.35.0] — 2026-06-25
 
 **3-strike fix-attempt discipline** (pattern adopted from gstack's "Iron Law" + the superpowers

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.35.0
+Version: 0.37.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
@@ -84,7 +84,7 @@ Quick start) for the full breakdown of any row.
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression (zero open Critical/High/Medium to advance), per-profile gate sets, a fast-track for small changes, and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents + per-database overlays + **6** org personas, led by an Orchestrator that never writes code |
 | 🔍 **Self-verification & review** | RARV green-Verify (real commands, not imagined), blind parallel review, and read-only risk classification |
-| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **96** context-activated skills (51 core + 45 stack-collection) |
+| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **97** context-activated skills (51 core + 46 stack-collection) |
 | 🧱 **Stacks & overlays** | Stack-agnostic core + **10** overlay rule sets (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands, incl. a full React design system |
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
@@ -281,7 +281,7 @@ need.
 - **23 stack-agnostic core rules** in [`rules/`](rules/) — `mandatory-workflow`, `quality-gates`,
   `rarv-cycle`, `continuity`, plus eight agent-operation rules and `autonomy-levels` +
   `risk-classification` (see [`docs/agentic-patterns.md`](docs/agentic-patterns.md)).
-- **96 on-demand skills** in [`skills/`](skills/) (51 core + 45 stack-collection) — spec-driven dev, planning, TDD, debugging, code
+- **97 on-demand skills** in [`skills/`](skills/) (51 core + 46 stack-collection) — spec-driven dev, planning, TDD, debugging, code
   review, threat modeling, and more — activated by context and led by the `sdlc` entrypoint.
 - **Profile-subset install** — each profile installs a strict subset of agents, skills, hooks, and
   rules (`lean ⊂ standard ⊂ enterprise`), from fast track to full audit.
@@ -437,7 +437,7 @@ owned gates, and the rule that **no gate passes on an unproven verdict**.
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar agent collections | Large libraries of individual subagent prompts you pick from | A **smaller, opinionated set wired into a sequenced pipeline with owned quality gates** — agents aren't a menu, they're stages that hand off and block on each other. Adopt-by-reuse, not by accumulation. |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | A spec-driven workflow (constitution → spec → tasks → analyze) | The same coverage-gate idea (the `story-planner` 1f gate + `task-tracker-sync`) **absorbed into a broader** lifecycle that also covers review, security, build, test, release, and observability gates. Complementary, wider scope. |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | **Portable configuration**, not a running process — the orchestration is described in rules the host (Claude Code) executes. 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 23 rules, 28 agents, 96 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
+| **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 23 rules, 28 agents, 97 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
 
 **Choose claude-kit when** you want a consistent, reviewable, **gate-enforced** autonomous-SDLC setup
 that's the same across every repo and stack, installs in seconds, ships nothing you have to run, and

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/README.md

@@ -54,7 +54,7 @@ Quick start) for the full breakdown of any row.
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression (zero open Critical/High/Medium to advance), per-profile gate sets, a fast-track for small changes, and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents + per-database overlays + **6** org personas, led by an Orchestrator that never writes code |
 | 🔍 **Self-verification & review** | RARV green-Verify (real commands, not imagined), blind parallel review, and read-only risk classification |
-| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **96** context-activated skills (51 core + 45 stack-collection) |
+| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **97** context-activated skills (51 core + 46 stack-collection) |
 | 🧱 **Stacks & overlays** | Stack-agnostic core + **10** overlay rule sets (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands, incl. a full React design system |
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
@@ -251,7 +251,7 @@ need.
 - **23 stack-agnostic core rules** in [`rules/`](rules/) — `mandatory-workflow`, `quality-gates`,
   `rarv-cycle`, `continuity`, plus eight agent-operation rules and `autonomy-levels` +
   `risk-classification` (see [`docs/agentic-patterns.md`](docs/agentic-patterns.md)).
-- **96 on-demand skills** in [`skills/`](skills/) (51 core + 45 stack-collection) — spec-driven dev, planning, TDD, debugging, code
+- **97 on-demand skills** in [`skills/`](skills/) (51 core + 46 stack-collection) — spec-driven dev, planning, TDD, debugging, code
   review, threat modeling, and more — activated by context and led by the `sdlc` entrypoint.
 - **Profile-subset install** — each profile installs a strict subset of agents, skills, hooks, and
   rules (`lean ⊂ standard ⊂ enterprise`), from fast track to full audit.
@@ -407,7 +407,7 @@ owned gates, and the rule that **no gate passes on an unproven verdict**.
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar agent collections | Large libraries of individual subagent prompts you pick from | A **smaller, opinionated set wired into a sequenced pipeline with owned quality gates** — agents aren't a menu, they're stages that hand off and block on each other. Adopt-by-reuse, not by accumulation. |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | A spec-driven workflow (constitution → spec → tasks → analyze) | The same coverage-gate idea (the `story-planner` 1f gate + `task-tracker-sync`) **absorbed into a broader** lifecycle that also covers review, security, build, test, release, and observability gates. Complementary, wider scope. |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | **Portable configuration**, not a running process — the orchestration is described in rules the host (Claude Code) executes. 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 23 rules, 28 agents, 96 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
+| **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 23 rules, 28 agents, 97 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
 
 **Choose claude-kit when** you want a consistent, reviewable, **gate-enforced** autonomous-SDLC setup
 that's the same across every repo and stack, installs in seconds, ships nothing you have to run, and

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/docs/stack-skills/README.md

@@ -1,6 +1,6 @@
 # Production Engineering Skills Collection
 
-These forty-five Claude Code skills encode production-proven engineering conventions derived from real-world Python/FastAPI, Node/Express, and React services. Each skill was extracted from analyzing patterns across multiple production backend and frontend services, capturing canonical patterns for FastAPI microservices, async Python, Kafka/Temporal integration, multi-tenancy, database access, layered configuration, Redis caching, GCS file handling, LLM integration (Vertex AI / Langfuse), Node/Express services, React frontends (state, data-fetching, forms, design systems, testing), observability (including Grafana dashboards & unified alerting), authentication, containerization (with granular Dockerfile/compose deep-dives), testing, data pipelines, security scanning (OWASP ZAP VAPT/DAST and autonomous AI pentesting), security architecture (edge-to-service signed-identity trust boundary, Kubernetes workload hardening), scheduled & recurring jobs (Kubernetes CronJob + Temporal Schedule), kubectl day-2 operations, and modernization strategies. Use them to align new projects with established patterns, audit existing services, or onboard engineers to modern Python, Node, and React development practices.
+These forty-six Claude Code skills encode production-proven engineering conventions derived from real-world Python/FastAPI, Node/Express, and React services. Each skill was extracted from analyzing patterns across multiple production backend and frontend services, capturing canonical patterns for FastAPI microservices, async Python, Kafka/Temporal integration, multi-tenancy, database access, layered configuration, Redis caching, GCS file handling, LLM integration (Vertex AI / Langfuse), Node/Express services, React frontends (state, data-fetching, forms, design systems, testing), observability (including Grafana dashboards & unified alerting), authentication, containerization (with granular Dockerfile/compose deep-dives), testing, data pipelines, security scanning (OWASP ZAP VAPT/DAST and autonomous AI pentesting), security architecture (edge-to-service signed-identity trust boundary, Kubernetes workload hardening), scheduled & recurring jobs (Kubernetes CronJob + Temporal Schedule), kubectl day-2 operations, and modernization strategies. Use them to align new projects with established patterns, audit existing services, or onboard engineers to modern Python, Node, and React development practices.
 
 > **Where these live in this repo:** the skill folders are under [`skills/`](../../skills/) (auto-discovered by the claude-kit plugin). The links below point there.
 
@@ -15,6 +15,7 @@ These forty-five Claude Code skills encode production-proven engineering convent
 | **async-python-patterns** | Async Python best practices — asyncio coordination (gather/wait_for/TaskGroup), cancellation handling, resource lifecycle, connection pool management, structured concurrency | [SKILL.md](../../skills/async-python-patterns/SKILL.md) |
 | **kafka-config-driven** | Config-driven Kafka producer/consumer infrastructure — JSON DSL topic/consumer config, message handling abstraction, aiokafka vs confluent_kafka, GSSAPI/SASL_SSL auth | [SKILL.md](../../skills/kafka-config-driven/SKILL.md) |
 | **temporal-config-driven** | Config-driven Temporal workflow/activity orchestration — JSON DSL workflow registry, worker launcher, schedule/cron management, RetryPolicy patterns | [SKILL.md](../../skills/temporal-config-driven/SKILL.md) |
+| **temporal-developer** | Temporal *fundamentals* (language-agnostic; complement to temporal-config-driven) — durable execution, why workflows must be deterministic (history replay), signals/queries/updates, safe versioning of running workflows (patching/worker versioning), testing (time-skipping/replay), gotchas, the `temporal` CLI dev loop, + Python/Go/TS starters; re-derived from the MIT temporalio/skill-temporal-developer | [SKILL.md](../../skills/temporal-developer/SKILL.md) |
 | **frontend-repo-architecture** | React + Vite + TypeScript frontend structure — three organizational models (module-scoped, feature-sliced, GraphQL-based), API layer strategies, hand-written types, state management | [SKILL.md](../../skills/frontend-repo-architecture/SKILL.md) |
 | **design-patterns-and-conventions** | Design conventions across repos — naming (classes/files/routes), error handling (ResponseData envelope), config hierarchy, logging structured-log patterns, code organization | [SKILL.md](../../skills/design-patterns-and-conventions/SKILL.md) |
 | **multi-tenancy-patterns** | Multi-tenant isolation strategies — tenant resolution (header/JWT/session), Postgres RLS, multi-pool databases, lazy connectors, data-layer org_id tenancy | [SKILL.md](../../skills/multi-tenancy-patterns/SKILL.md) |

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.35.0"
+version = "0.37.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.35.0 → claude_code_kit-0.37.0}/rules/agent-resilience.md

@@ -1,5 +1,7 @@
 # Agent Resilience
 
+**Every retry is bounded; every recovery tells the truth about what's left.**
+
 How the **agent machinery itself** behaves when something goes wrong: a tool errors, a command fails,
 a sub-agent returns empty or malformed output, an external service is down or rate-limited, a network
 call times out. The book's thesis is that production-grade agents must be treated as **complex
@@ -72,6 +74,13 @@ pipeline. Different scopes, same principle: no loop is unbounded.
 4. **Promote recurring failures.** A failure mode worth avoiding next time goes to `agent-memory/` via
    `remember`.
 
+**Self-check before retrying or handing off:** does every loop I'm in have a limit, and does my
+reported state match what actually happened (no silent swallow, no fake "done")?
+
+**This rule is working if** no run hangs in an unbounded loop, every fallback or degradation is stated
+truthfully in the handoff, and a crash or compaction resumes from the last checkpoint rather than from
+zero.
+
 ## Relationship to other rules
 
 - **`.claude/rules/continuity.md`** — the checkpoint that makes resume-after-failure possible.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/rules/code-organization.md

@@ -1,7 +1,12 @@
 # Code Structure & Conventions
 
+**Match the codebase that exists — new code follows established patterns, it never invents parallel ones.**
+
 Codified patterns extracted from the existing codebase. All new code must follow these established conventions.
 
+**Self-check before adding a file or utility:** did I find the existing pattern first? New code should
+read as if it was always part of this codebase — same layout, same mixins, same base classes.
+
 ## 1. Backend Module Layout
 
 Every domain module follows a consistent structure. Example for a layered web service:
@@ -310,3 +315,9 @@ if existing:
 - Use framework status constants — never magic numbers
 - `detail` is a user-facing string — never expose internal errors
 - Never catch and swallow exceptions silently
+
+---
+
+**These conventions are working if** new code is indistinguishable in shape from the code already
+there — no parallel utility, no bypassed base repository, no hand-rolled pattern that an existing one
+already covered.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/rules/goal-setting-and-monitoring.md

@@ -1,5 +1,7 @@
 # Goal Setting & Monitoring
 
+**If you can't say what "done" looks like and measure whether you're getting there, you're drifting.**
+
 An agent that can't say *what done looks like* and *whether it's getting there* drifts. Every task
 runs against **measurable success criteria** that are recorded up front, **monitored** as work
 proceeds, and used to **prioritize** what to do next. This rule turns "I produced output" into "I met
@@ -27,6 +29,9 @@ Record them in `.claude/CONTINUITY.md` (and for features, they live in the spec)
 criterion measurable, that ambiguity is a human decision point — see
 `.claude/rules/human-in-the-loop.md`.
 
+**Self-check:** is every criterion something a command, test, or metric can pass or fail? If it's a
+feeling ("make it better"), it isn't a criterion yet — sharpen it or escalate it.
+
 ## 2. Monitor progress against them
 
 - **Track, don't assume.** As stages complete, check actual results against the criteria — the RARV
@@ -63,6 +68,9 @@ at backlog/sprint scope).
 3. **Re-prioritize on new information; don't sunk-cost a stale plan.**
 4. **Goal met = every criterion verified**, not "the code is written." Hand off against the criteria.
 
+**This rule is working if** every task names a checkable goal up front, progress is measured against it
+rather than assumed, and priorities visibly re-rank when new information lands.
+
 ## Relationship to other rules
 
 - **`.claude/rules/rarv-cycle.md`** — Verify proves each criterion; this rule defines the criteria.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/rules/mandatory-workflow.md

@@ -1,5 +1,7 @@
 # Mandatory Workflow
 
+**Identify the workflow first, then walk every gate in order — no phase starts until the one before it has passed.**
+
 This document defines **two development workflows**: one for bug fixes and one for features.
 Identify which workflow to follow FIRST, then execute it step by step.
 
@@ -23,6 +25,9 @@ If unclear whether a task is a bug fix or feature, ask the user.
 
 ## Working Memory & Self-Check (both workflows)
 
+**Self-check before every handoff:** which stage am I at, which gate is next, and can I show the
+captured evidence that the current one passed? If you can't, you are not done.
+
 - **CONTINUITY.md** — read `.claude/CONTINUITY.md` at the start of every turn and write it
   back at the end and at each stage transition. It carries phase, active work, decisions,
   mistakes, and next steps across context compaction and new sessions. Durable learnings go
@@ -373,3 +378,9 @@ user for the ticket ID — never guess.
 ## Files that require user approval before editing
 Build config, dependency manifests + lockfiles, CI config, app entry points, shared component
 barrels/index files, `CLAUDE.md`, and `.claude/rules/*`. Define the exact list for your project.
+
+---
+
+**This workflow is working if** every change can name the gate it last cleared, no phase started
+before its predecessor passed, and a reviewer could reconstruct the path from spec to PR from the
+artifacts alone.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/rules/quality-gates.md

@@ -1,5 +1,7 @@
 # Quality Gates, Severity & Blind Review
 
+**A gate passes only with zero open Critical/High/Medium — and never on a verdict you can't prove.**
+
 This rule adds three things on top of the existing pipeline in `mandatory-workflow.md`:
 
 1. a single **severity model** every reviewer and tester classifies findings against,
@@ -66,6 +68,8 @@ A gate result is a claim about reality, so it must be grounded in reality. A PAS
 
 A fabricated, assumed, or partial-output-based verdict is an **auto-Critical** finding (§1): it defeats every downstream gate that trusts it. This is the gate-level form of the RARV rule "Verify means run it, not imagine it" (`.claude/rules/rarv-cycle.md`).
 
+**Self-check before recording any verdict:** can I point to the captured command output or the `file:line` finding behind this PASS/FAIL? If not, it is a TODO, not a verdict — leave the gate closed.
+
 ---
 
 ## 3. Blind Review + Devil's Advocate
@@ -124,3 +128,9 @@ Track these in `CONTINUITY.md` when running a full pipeline; they reveal a degra
 | Defect-loop cycles per feature | ≤ 1 | 2 (then escalate) |
 
 These are observability for the *process*, not a gate. Do not block on them.
+
+---
+
+**This rule is working if** no gate ever passes with an open Critical/High/Medium, no verdict ships
+without the evidence that produced it, and a unanimous PASS always saw the Devil's Advocate before it
+counted.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/rules/reasoning-techniques.md

@@ -1,5 +1,7 @@
 # Reasoning Techniques
 
+**Match the thinking to the stakes: show the path, observe before you act, and ask when it's genuinely ambiguous.**
+
 How an agent should *think* before and while it acts. This is the layer underneath the RARV cycle:
 `.claude/rules/rarv-cycle.md` says **reflect and verify before handoff**; this rule says **how to
 reason your way to a correct answer in the first place**. Match the technique to the difficulty of
@@ -36,6 +38,9 @@ heavier techniques.
    human decision point — see `.claude/rules/human-in-the-loop.md`. Reasoning harder cannot
    manufacture a requirement that was never given.
 
+**Self-check:** could the next agent (or a reviewer) follow *why*, not just *what*? If the reasoning
+isn't inspectable, slow down and make it so — that's the input the Reflect step needs.
+
 ## Resource-aware effort & model tiers
 
 Reasoning has a cost; allocate it deliberately (see also `.claude/rules/agent-resilience.md` for the
@@ -52,6 +57,9 @@ failure side of resource awareness).
   isolate large reads behind a research subagent (`Explore`) so the main context stays clear enough
   to think. See the `context-engineering` skill.
 
+**This rule is working if** the depth of thinking visibly scales with the stakes, tool actions follow
+observations rather than blind chains, and genuine ambiguity becomes a question instead of a guess.
+
 ## Relationship to other rules
 
 - **`.claude/rules/rarv-cycle.md`** — RARV is the *discipline* (reflect + verify before handoff); this

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/skills/context-engineering/SKILL.md

@@ -71,6 +71,11 @@ Create a rules file that persists across sessions. This is the highest-leverage
 [One short example of a well-written component/module in your style]
 ```
 
+**Keep it short.** Target **under 200 lines** (aim 100–150). A rules file competes with the task for
+attention — past ~200 lines it costs more than it gives. Push stack- or area-specific detail into
+separate rule files the agent loads only when relevant (progressive disclosure, below), rather than
+growing one giant CLAUDE.md.
+
 **Equivalent files for other tools:**
 - `.cursorrules` or `.cursor/rules/*.md` (Cursor)
 - `.windsurfrules` (Windsurf)
@@ -114,8 +119,12 @@ When tests fail or builds break, feed the specific error back to the agent:
 
 Long conversations accumulate stale context. Manage this:
 
+- **New task = new session.** A genuinely different task starts cleaner in a fresh session than dragging
+  a long, unrelated history behind it.
 - **Start fresh sessions** when switching between major features
 - **Summarize progress** when context is getting long: "So far we've completed X, Y, Z. Now working on W."
+- **Summarize *from here* before rewinding or compacting** — write done-state to `.claude/CONTINUITY.md`
+  first, so the summary survives the reset (`.claude/rules/continuity.md`).
 - **Compact deliberately** — if the tool supports it, compact/summarize before critical work
 
 ## Context Degradation: the failure taxonomy
@@ -133,13 +142,21 @@ modes — recognize them so you reach for the right fix:
   and end (a U-shaped curve). *Fix:* put the most important instructions/facts at the top or bottom,
   never buried in a long paste.
 
+**Degradation-zone thresholds (rules of thumb, not hard limits).** Quality starts to slip well before
+the window is "full": watch once live context passes **~40% of the window**, because the back half of a
+window earns less attention than the front (the lost-in-the-middle curve, at scale). Pair this with the
+flooding thresholds in Anti-Patterns (>5,000 lines is a smell; aim for <2,000 *focused* lines per
+task). When you cross these, compact or split the work — don't push on and hope.
+
 ## Advanced: progressive disclosure, compaction, offloading
 
 Three primitives keep long runs coherent:
 
 - **Progressive disclosure** — don't load everything up front. Expose names + one-line descriptions and
   load full detail only on use (how skills and well-designed tools work — see
-  `.claude/rules/tool-design.md`). Preserves the baseline attention budget for the task.
+  `.claude/rules/tool-design.md`). Preserves the baseline attention budget for the task — aim to keep
+  that standing baseline well under the degradation zone (≈30% of the window) so there's room to
+  actually reason.
 - **Compaction** — when history grows, summarize completed work into a compact state ("done: X, Y;
   now: Z") and continue from the summary, not the full transcript. Compact *deliberately* before
   critical work, not only when forced.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/skills/temporal-config-driven/README.md

@@ -11,6 +11,14 @@ Temporal workflow orchestration patterns derived from real-world production Pyth
 - **Dynamic worker generation** for matrix-based workers (e.g., file_type × business_unit)
 - **Graceful shutdown** patterns (SIGTERM/SIGINT handling in worker processes)
 
+## Related skill
+
+For Temporal **fundamentals** — durable execution, why workflows must be deterministic (history
+replay), safely changing running workflows (patching/worker versioning), testing
+(time-skipping/replay), signals/queries/updates, and non-Python SDKs — use the complementary
+**`temporal-developer`** skill. This skill assumes those fundamentals and focuses on the
+config-driven worker-map / DAG-as-data architecture.
+
 ## Source provenance
 
 Derived from real-world production Python/FastAPI services implementing Temporal orchestration at scale.

{claude_code_kit-0.35.0 → claude_code_kit-0.37.0}/skills/temporal-config-driven/SKILL.md

@@ -1,12 +1,18 @@
 ---
 name: temporal-config-driven
-description: Encodes Temporal workflow orchestration patterns derived from production Python/FastAPI services—config-driven worker maps, workflow/activity definitions, retry policies, idempotency via activity_id, cron-based schedules, and DAG-based config-as-data orchestration. Use when implementing or debugging Temporal workflows, workers, activities, retries, schedules, or config-driven orchestration engines. Use when setting up worker bootstrap with graceful shutdown, or when building DAG-based config-as-data orchestration systems.
+description: Encodes Temporal workflow orchestration patterns derived from production Python/FastAPI services—config-driven worker maps, workflow/activity definitions, retry policies, idempotency via activity_id, cron-based schedules, and DAG-based config-as-data orchestration. Use when implementing or debugging this kit's config-driven Temporal architecture (WORKER_MODE_CONFIG_MAP, _execute_dag/NODE_TYPE_MAP, schedule registration), worker bootstrap with graceful shutdown, or DAG-based config-as-data orchestration systems. Do NOT use for Temporal fundamentals (determinism/history replay, safe versioning of running workflows, testing, signals/queries/updates) or non-Python SDKs—use temporal-developer for those.
 ---
 
 # temporal-config-driven
 
 Temporal workflow orchestration using config-driven worker maps and DAG-based execution.
 
+> **Fundamentals live elsewhere.** This skill is the *config-driven architecture* layer and assumes
+> you already understand durable execution. For Temporal **fundamentals** — why workflows must be
+> deterministic (history replay), safely versioning running workflows, testing (time-skipping/replay),
+> signals/queries/updates, and non-Python SDKs — use the **`temporal-developer`** skill. They are
+> complementary.
+
 ## When to use
 
 - Implementing Temporal workers with mode-based configuration (WORKER_MODE_CONFIG_MAP)

claude_code_kit-0.37.0/skills/temporal-developer/README.md

@@ -0,0 +1,38 @@
+# temporal-developer
+
+Temporal **fundamentals** for durable execution, language-agnostic: the workflow/activity/worker
+split, why workflows must be deterministic (history replay), signals/queries/updates, child
+workflows, saga, continue-as-new, retry/timeout/cancellation, safe versioning of running workflows,
+testing, and the `temporal` CLI dev loop.
+
+This is the conceptual layer *underneath* a Temporal codebase. It is **complementary** to this kit's
+`temporal-config-driven` skill, which encodes a specific config-driven worker-map / DAG-as-data
+architecture and assumes these fundamentals. See each skill's `description` for the auto-trigger
+boundary.
+
+## Source provenance
+
+Re-derived **concisely, in claude-kit's own idiom** from the official, MIT-licensed
+[`temporalio/skill-temporal-developer`](https://github.com/temporalio/skill-temporal-developer)
+(© Temporal Technologies Inc., MIT License). **Nothing is vendored** — the upstream reference files
+were read for grounding and the concepts paraphrased into compact notes, with cross-checks against
+the public Temporal docs (https://docs.temporal.io).
+
+The upstream skill is the **authority** and carries the full per-language depth (Python, TypeScript,
+Go, Java, .NET, Ruby, Rust) plus integrations and ops material. These notes deliberately stay lean
+and point back to it; when the two disagree, trust upstream.
+
+## How to apply
+
+1. **Read `SKILL.md`** for the durable-execution model and the workflow/activity/worker rules — the
+   ideas every Temporal codebase depends on.
+2. **Hit a non-determinism / command-mismatch error?** Go straight to
+   [`references/determinism.md`](references/determinism.md).
+3. **Changing a workflow with in-flight executions?** Use
+   [`references/versioning.md`](references/versioning.md) before you touch the Command sequence.
+4. **Writing tests?** Use [`references/testing.md`](references/testing.md) (time-skipping env, replay
+   tests, activity mocking).
+5. **Need the full per-language API?** Use [`references/languages.md`](references/languages.md) for
+   compact starters, then follow the upstream link for your SDK.
+6. **For this kit's config-driven worker maps / DAG interpreter / cron schedules**, use the sibling
+   `temporal-config-driven` skill instead.

claude_code_kit-0.37.0/skills/temporal-developer/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: temporal-developer
+description: Temporal fundamentals for durable execution across languages (Python, Go, TypeScript, Java, .NET, Ruby, Rust)—the workflow/activity/worker split, why workflows must be deterministic (history replay), signals/queries/updates, child workflows, saga/compensation, continue-as-new, timers, retry policies, cancellation/heartbeating, safe versioning of running workflows (patching, worker versioning), testing (time-skipping, replay tests, activity mocking), and the temporal CLI dev loop. Use when building or debugging Temporal workflows/activities/workers, fixing non-determinism errors, or deciding how to change running workflows safely. Do NOT use for this kit's config-driven worker-map / DAG-as-data orchestration engine (WORKER_MODE_CONFIG_MAP, _execute_dag, NODE_TYPE_MAP, schedule registration)—use temporal-config-driven for that.
+---
+
+# temporal-developer
+
+Temporal **fundamentals**: how durable execution actually works, and the rules you must follow to
+build correct workflows in any Temporal SDK. This is the conceptual layer underneath any
+Temporal codebase — read it before writing workflow code, and reach for it when a workflow throws a
+non-determinism error or you need to change code that running workflows depend on.
+
+> **Sibling boundary.** `temporal-config-driven` covers *this kit's* specific config-driven
+> architecture (mode→worker maps, the DAG-as-data interpreter, idempotency-via-`activity_id`,
+> cron schedule registration). It **assumes** the fundamentals below. If you are wiring
+> `WORKER_MODE_CONFIG_MAP`, `_execute_dag`, or `register_schedules`, use that skill. If you are
+> learning *why workflows replay*, fixing determinism, versioning a live workflow, or working in a
+> non-Python SDK, use **this** one. They are complementary, not duplicates.
+
+## When to use
+
+- Building your first workflow / activity / worker, or onboarding a new SDK language
+- A workflow raised a **non-determinism / command-mismatch error** (see `references/determinism.md`)
+- You need to change a workflow that has **in-flight executions** without breaking them (`references/versioning.md`)
+- Writing tests for workflows — time-skipping, replay tests, activity mocking (`references/testing.md`)
+- Choosing between **Signal, Query, and Update**, or adding child workflows / saga / continue-as-new
+- Setting retry policies, timeouts, cancellation + heartbeating correctly
+- Driving workflows from the `temporal` CLI during the dev loop (`references/cli.md`)
+
+## The durable-execution model (the one idea everything rests on)
+
+A Temporal **Workflow** is ordinary code whose execution is made *durable*: it survives process
+crashes, deploys, and machine loss, and can sleep for months. It achieves this not by checkpointing
+memory but by **replaying code against an Event History**.
+
+```
+Workflow code runs ──> emits Commands ──> Server records them as Events (the History)
+Worker dies / cache evicts / long timer fires
+Worker re-runs the SAME code from the top ──> for each Command, the SDK matches it to the
+  recorded Event and feeds back the stored result ──> state is reconstructed, execution continues
+```
+
+Three consequences fall directly out of replay — internalize these:
+
+1. **Workflow code must be deterministic.** Same inputs + same history ⇒ identical sequence of
+   Commands, every replay. Wall-clock time, `random`, UUIDs, env vars, file/network I/O, and
+   unordered map iteration all break this. → `references/determinism.md`.
+2. **All non-determinism and all side effects belong in Activities.** An **Activity** is a plain
+   function that runs *once*, outside replay, with at-least-once execution, automatic retries, and
+   timeouts. Workflows *orchestrate*; Activities *do the I/O*. Because activities can run more than
+   once, they must be **idempotent** (use an idempotency key).
+3. **Changing workflow code can break replay.** New code that emits a different Command sequence than
+   the recorded history fails open executions. Use **patching** or **worker versioning** to change
+   live workflows safely. → `references/versioning.md`.
+
+### Workflow vs Activity vs Worker
+
+| Piece | What it is | Rules |
+|-------|-----------|-------|
+| **Workflow** | Orchestration logic; deterministic; replayed | No I/O, no clock/random/UUID except SDK-safe variants; only orchestrate |
+| **Activity** | A unit of real work (I/O, compute); runs once per attempt | Must be idempotent; gets retries + timeouts; heartbeat if long-running |
+| **Worker** | Process that polls a **task queue** and runs your workflow + activity code | All workers on a queue must run *identical* code (else replay mismatch) |
+
+### Talking to a running workflow — Query vs Signal vs Update
+
+| Operation | Modifies state? | Returns a result? | May block? | Use for |
+|-----------|-----------------|-------------------|-----------|---------|
+| **Query** | No | Yes | No | Read current state (read-only — never mutate) |
+| **Signal** | Yes | No | Yes | Fire-and-forget input/mutation |
+| **Update** | Yes | Yes | Yes | A mutation that must return a result |
+
+> Mnemonic: **Query to peek, Signal to push, Update to pop.** Queries and update *validators* are
+> strictly read-only — mutating in them is non-deterministic on replay.
+
+## References
+
+- [determinism.md](references/determinism.md) — replay mechanics, what workflow code may/may not do, SDK protection levels, recovery
+- [versioning.md](references/versioning.md) — patching API, workflow-type versioning, worker (Build ID) versioning; when *not* to patch
+- [testing.md](references/testing.md) — local/time-skipping environment, activity mocking, signal/query/update tests, replay tests
+- [gotchas.md](references/gotchas.md) — the highest-leverage cross-language anti-patterns and their fixes
+- [cli.md](references/cli.md) — `temporal server start-dev` + `workflow start/execute/signal/query/update` dev loop
+- [languages.md](references/languages.md) — compact Python/Go/TypeScript starters + pointer to upstream per-language depth (Java/.NET/Ruby/Rust + AI integrations)
+
+## Upstream (authoritative, full 7-language depth)
+
+These references are **re-derived concisely** in this kit's idiom from the official, MIT-licensed
+**`temporalio/skill-temporal-developer`**. For exhaustive per-language guides (Python · TypeScript ·
+Go · Java · .NET · Ruby · Rust), integrations (OpenAI Agents SDK, Google ADK, …), and ops-grade
+material, go to the source — it is the authority and is kept current by Temporal:
+
+- Repo: https://github.com/temporalio/skill-temporal-developer
+- Docs: https://docs.temporal.io
+
+When upstream and these notes disagree, trust upstream and update this skill.

claude_code_kit-0.37.0/skills/temporal-developer/references/cli.md

@@ -0,0 +1,63 @@
+# `temporal` CLI — the developer dev loop
+
+The same commands work against the dev server, a self-hosted cluster, or Temporal Cloud — only the
+connection descriptor changes. **Always pass `--output json`** so output is parseable.
+
+## Dev server
+
+```bash
+temporal server start-dev                 # in-memory, single process — DEV ONLY
+temporal server start-dev --db-filename temporal.db   # persist state across restarts
+```
+
+Loses all state on restart unless `--db-filename` is set; never use it for production. Default
+frontend address is `localhost:7233`; the Web UI is served too (default `localhost:8233`).
+
+## Start vs execute
+
+```bash
+# Start asynchronously — returns Workflow ID + Run ID immediately
+temporal workflow start --output json \
+  --type YourWorkflow --task-queue YourTaskQueue \
+  --workflow-id YourId --input '{"k": "v"}'
+
+# Start AND block until completion — streams progress; non-zero exit = failed/cancelled/timed out
+temporal workflow execute --output json \
+  --type YourWorkflow --task-queue YourTaskQueue --input '{"k": "v"}'
+```
+
+`--type` and `--task-queue` are required; `--workflow-id` is optional (server generates a UUID).
+`execute` is ideal for one-shot smoke tests in the dev loop. Useful start flags: `--id-reuse-policy`
+(`AllowDuplicate` | `AllowDuplicateFailedOnly` | `RejectDuplicate` | `TerminateIfRunning`),
+`--id-conflict-policy` (`Fail` | `UseExisting` | `TerminateExisting`), `--execution-timeout` /
+`--run-timeout`, `--search-attribute KEY=VALUE`, `--cron` (legacy — prefer `temporal schedule create`).
+
+## Interacting with a running workflow
+
+```bash
+# Signal (fire-and-forget mutation)
+temporal workflow signal --output json -w YourId --name YourSignal --input '{"k":"v"}'
+
+# Query (read-only; works on running AND completed workflows)
+temporal workflow query --output json -w YourId --name YourQuery
+
+# Update is a COMMAND GROUP, not one command:
+temporal workflow update execute -w YourId --name YourUpdate --input '{"k":"v"}'      # start + wait for result
+temporal workflow update start   -w YourId --name YourUpdate --wait-for-stage accepted # start + wait for accept
+temporal workflow update result  -w YourId --update-id YourUpdateId                    # fetch a prior update's result
+temporal workflow update describe -w YourId --update-id YourUpdateId                   # status
+```
+
+Gotchas: `--wait-for-stage` on `update start` only accepts `accepted`; `update` alone does nothing.
+
+## Inspecting & dev-only lifecycle
+
+```bash
+temporal workflow show --output json -w YourId    # full Event History (save for replay tests)
+temporal workflow list --output json --query '<visibility query>'
+temporal workflow terminate -w YourId             # DEV ONLY — kill a stale execution
+```
+
+`workflow show --output json` is how you capture a history to feed a **replay test** (`testing.md`).
+For bulk operations (`--query` batch signal/terminate), schedules, and ops tooling, see the upstream
+`skill-temporal-developer` references and `skill-temporal-ops`.