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

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

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

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

@@ -4,6 +4,26 @@ 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,

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.36.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.36.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.36.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.36.0 → claude_code_kit-0.37.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.36.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.36.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.36.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`.

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

@@ -0,0 +1,72 @@
+# Determinism (why workflows replay, and the rules that follow)
+
+Workflows are durable because Workers **re-execute the workflow code from the top** to rebuild state
+— after a crash, a cache eviction, or when a long timer fires. Instead of re-running side effects,
+the SDK matches each operation your code emits (a **Command**) against the recorded **Event History**
+and feeds back the stored result.
+
+```
+First run:   code → Commands → Server stores Events
+Replay:      code runs again → Commands compared to stored Events
+             match  → reuse stored result, continue
+             differ → NondeterminismError (workflow blocks until code is fixed)
+```
+
+Every orchestration operation maps Command → Event, e.g.:
+
+| Workflow code     | Command                       | Event                          |
+|-------------------|-------------------------------|--------------------------------|
+| Execute activity  | `ScheduleActivityTask`        | `ActivityTaskScheduled`        |
+| Sleep / timer     | `StartTimer`                  | `TimerStarted`                 |
+| Child workflow    | `StartChildWorkflowExecution` | `ChildWorkflowExecutionStarted`|
+| Complete workflow | `CompleteWorkflowExecution`   | `WorkflowExecutionCompleted`   |
+
+If replayed code emits a *different* Command than history recorded (or in a different order), replay
+fails. Classic trap: branching on wall-clock time — `if now().hour < 12` takes one branch at first
+run and the other on replay, producing a different `ScheduleActivityTask`.
+
+## Sources of non-determinism (keep all of these OUT of workflow code)
+
+- **Time**: `now()`, `time.time()`, `Date.now()`
+- **Randomness / IDs**: `random()`, `Math.random()`, `uuid4()`
+- **External state**: files, env vars, DBs, HTTP/network calls
+- **Unordered iteration**: map/dict/set iteration order (language-dependent)
+- **Concurrency/threads**: races that change ordering or outcome
+
+## The central rule
+
+**Put non-determinism and side effects in Activities.** An Activity runs *once per attempt* outside
+replay, with durable recorded results, automatic retries, and timeouts. The workflow only
+orchestrates. For a few common cases the SDK gives you replay-safe variants to use *inside* the
+workflow instead of an activity — durable time, sleep, UUID, random, and a replay-aware logger
+(e.g. `workflow.now()`, `workflow.sleep()`, `workflow.uuid4()`, `workflow.logger`; names vary by
+SDK). Everything else → an activity.
+
+## How much the SDK protects you (varies by language)
+
+- **Python** — sandbox intercepts and aborts many non-deterministic calls *at runtime*, early.
+- **TypeScript** — isolated V8 sandbox; auto-replaces common sources with deterministic variants.
+- **Java / Go / .NET** — **no sandbox**; determinism is by convention (`Workflow.*` / `workflow.*`
+  safe APIs). Violations usually surface only at *replay*. Optional static analyzers exist
+  (`temporal-workflowcheck` for Java, `workflowcheck` for Go).
+- **Ruby** — runtime illegal-call tracing on the workflow fiber + a durable fiber scheduler.
+- **Rust** — runtime detection for external async wake sources; use SDK primitives (`ctx.timer()`,
+  the SDK `select!`), avoid synchronous non-determinism by convention.
+
+Regardless of SDK, **it is your responsibility** to keep workflow code deterministic. Don't rely on
+the sandbox catching everything — write replay tests (`testing.md`).
+
+## Recovery
+
+- **Accidental non-determinism introduced by a code change** → revert workflow code to match history,
+  restart the worker; the workflow auto-recovers.
+- **Intentional logic change on running workflows** → use the **Patching API** or terminate-and-restart
+  (`versioning.md`). Never just "edit and redeploy" a workflow with open executions.
+
+## Best practices
+
+1. Use SDK-provided safe variants for time / random / UUID / logging.
+2. Move *all* I/O to activities; the workflow only orchestrates.
+3. Write **replay tests** before deploying workflow changes.
+4. Use **patching** for intentional changes to in-flight workflows.
+5. Keep workflows small and focused — complexity is where non-determinism hides.

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

@@ -0,0 +1,69 @@
+# Gotchas (the cross-language anti-patterns that cost the most time)
+
+Conceptual traps that recur in every SDK. See `references/{language}/gotchas.md` upstream for the
+language-specific symptoms.
+
+## Non-idempotent activities
+
+Activities run **at least once** — retries and worker failures cause re-execution. An external call
+without an idempotency key can double-charge a card, send duplicate emails, or create duplicate rows.
+**Fix:** pass an idempotency key (workflow ID, activity ID, or a domain key like order ID) to every
+external mutation. Local Activities are faster but still retried — same rule applies.
+
+## Side effects / non-determinism in workflow code
+
+Workflow code runs on the first execution **and every replay**. Any side effect (log, metric,
+notification) fires multiple times; any non-deterministic call (clock, random, I/O, threads) breaks
+replay. **Fix:** use the SDK's replay-safe variants for logging/time/UUID/random; put everything else
+in an activity. (See `determinism.md`.)
+
+## Multiple workers running different code
+
+If worker A runs part of a workflow on v1 and worker B (v2) picks it up, replay can mismatch.
+**Fix in prod:** worker versioning or patching. **Fix in dev:** kill old workers before starting new
+ones; ensure every worker on a task queue runs identical code. Workflows started on old code keep
+running after you change it — in *dev only*, terminate stale ones.
+
+## Retry policy mistakes
+
+- **Failing too fast** — `maximum_attempts=1` everywhere turns transient blips into workflow
+  failures. Reserve it for truly non-retryable ops; otherwise let exponential backoff ride out
+  transient errors.
+- **Wrong classification** — **retryable**: network errors, timeouts, rate limits, transient
+  unavailability. **Non-retryable**: invalid input, auth failures, business-rule violations, not-found.
+  Mark them correctly or you get infinite retries on bad input (or hard failures on a blip).
+
+## Query / update-validator misuse
+
+Queries and update **validators** are strictly **read-only and non-blocking** — they must not mutate
+state (non-determinism on replay) and must not await activities/timers/conditions (timeouts,
+deadlocks). Need to mutate-and-return? Use an **Update**. Need to trigger async work? Use a **Signal**
+or **Update**. *(Query to peek, Signal to push, Update to pop.)*
+
+## Cancellation not handled
+
+- **Workflow cancellation:** cleanup after the cancellation point won't run unless protected — use
+  cancellation scopes / `try…finally` for compensation and resource release.
+- **Activity cancellation:** an activity only learns it was cancelled if it **heartbeats** and
+  **checks** for cancellation. Otherwise it runs to completion, wasting compute and delaying the
+  workflow. Heartbeat long-running activities and react to the cancellation signal.
+
+## Swallowing errors
+
+Catching without handling produces silent failures and workflows that "succeed" despite errors. Log
+and decide deliberately: re-raise, fall back, or document why ignoring is safe.
+
+## Payload size limits
+
+Hard limits: **2 MB** per payload, **4 MB** per gRPC message, **50 MB** per workflow history (aim for
+< 10 MB). **Fix:** store large blobs externally (S3/GCS) and pass references, use a compression codec,
+or chunk across activities. Unbounded history → use **Continue-as-New** to reset it.
+
+## Dev-server / CLI gotchas
+
+- `temporal server start-dev` is **in-memory and single-process** — state is lost on restart
+  (`--db-filename` persists it) and it is **never** for production.
+- `temporal workflow update` is a **command group**, not one command — use
+  `update execute|start|result|describe`.
+- On `workflow update start`, `--wait-for-stage` only accepts `accepted`.
+- On `workflow reset`, `--reapply-type` only accepts `Signal` or `None`.