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

{claude_code_kit-0.36.0 → claude_code_kit-0.38.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.38.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

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

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.36.0",
+  "version": "0.38.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.38.0}/CHANGELOG.md

@@ -4,6 +4,47 @@ 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.38.0] — 2026-06-26
+
+**New `library-review` core skill + a property-based-testing note** (two genuinely-new ideas
+cherry-picked, stack-agnostic, from the MIT [`wdm0006/python-skills`](https://github.com/wdm0006/python-skills);
+the rest of that collection was skipped as redundant with existing core/collection skills).
+
+- **`skills/library-review/`** (core — SKILL.md only, stack-agnostic) — a structured **pre-add
+  dependency-adoption evaluation**: need & fit, alternatives (stdlib/native/existing dep),
+  maintenance & bus factor, license compatibility, security/supply-chain history, transitive weight,
+  lock-in/exit cost, and a documented adopt/reject decision. Re-cast (health-signal dimensions
+  adapted from the MIT upstream's `reviewing-python-libraries`) as an *adoption* gate. Reuse-first:
+  cross-linked to and explicitly bounded against `mandatory-workflow.md` §2a.5 (whether a dep is
+  needed at all), `over-engineering-review`, the `dependency-scanner` agent (audits *installed* deps —
+  this is its pre-add counterpart), and `code-review-and-quality` (whose 5-point Dependency
+  Discipline list now points here as its full form).
+- **`test-driven-development`** gains a **Property-Based Testing** section (count-neutral edit):
+  what it is, when to reach for it, the round-trip/idempotence/invariant/metamorphic property shapes,
+  and one-per-language ecosystem pointers (Hypothesis · fast-check · jqwik · proptest · …).
+- Counts: **97 → 98** total skills (**51 → 52** core; stack-collection unchanged at 46). No
+  `docs/stack-skills` row (core skills aren't listed there). Version bumped across the 5 parity files.
+
+## [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.38.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.36.0
+Version: 0.38.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) + **98** context-activated skills (52 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
+- **98 on-demand skills** in [`skills/`](skills/) (52 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, 98 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.38.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) + **98** context-activated skills (52 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
+- **98 on-demand skills** in [`skills/`](skills/) (52 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, 98 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.38.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.38.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.36.0"
+version = "0.38.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.38.0}/skills/code-review-and-quality/SKILL.md

@@ -280,6 +280,8 @@ Part of code review is dependency review:
 
 **Rule:** Prefer standard library and existing utilities over new dependencies. Every dependency is a liability.
 
+For a full pre-add evaluation of a specific candidate (maintenance/bus-factor, license, supply-chain history, transitive weight, lock-in, adopt/reject decision), use the `library-review` skill — this 5-point list is its quick form.
+
 ## The Review Checklist
 
 ```markdown

claude_code_kit-0.38.0/skills/library-review/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: library-review
+description: Structured pre-add evaluation of a candidate third-party dependency before you adopt it—need & fit, alternatives (stdlib/native/existing dep), maintenance & bus factor, adoption signals, license compatibility, security & supply-chain history, install weight & transitive deps, lock-in/exit cost, and a documented adopt/reject decision. Stack-agnostic (pip, npm, cargo, go modules, maven, gems, …). Use when proposing or choosing between new libraries, or when mandatory-workflow §2a.5 rung 5 ("can an existing dependency do it?") points at pulling in a new one. Do NOT use to decide whether you need a dependency at all (use the §2a.5 reuse/YAGNI gate + over-engineering-review) or to audit ALREADY-installed dependencies for CVEs (use the dependency-scanner agent).
+---
+
+# Library Review (pre-add dependency evaluation)
+
+> Health-signal dimensions adapted (stack-agnostic, re-cast as an *adoption* decision) from the
+> MIT-licensed [`wdm0006/python-skills`](https://github.com/wdm0006/python-skills)
+> `reviewing-python-libraries` skill (© Will McGinnis). That skill audits a library's *own* quality
+> for publishing; this one turns the same signals into a **"should we take on this dependency?"** gate.
+
+## What this is (and is not)
+
+Adding a dependency is a long-lived liability: it ships its bugs, its CVEs, its license, its
+maintainer's availability, and its transitive tree into your project, and removing it later is rarely
+free. This skill is the **structured evaluation you run before adopting a specific candidate** — or
+when choosing between two or three.
+
+It is deliberately scoped, and it composes with three things already in the kit — use those first /
+alongside, don't duplicate them:
+
+- **Do we even need a new dependency?** That is the **§2a.5 Reuse & YAGNI Gate**
+  (`.claude/rules/mandatory-workflow.md`) and the `over-engineering-review` skill — walk the ladder
+  (need it at all? → in the codebase? → stdlib? → native platform? → an *existing* dependency?) and
+  only reach this skill once a *new* dependency is genuinely on the table.
+- **Auditing dependencies you have ALREADY installed** for known CVEs / outdated versions is the
+  `dependency-scanner` agent. This skill is its **pre-add counterpart** — it runs *before* the
+  dependency is in the lockfile.
+- The 5-point "Before adding any dependency" list in `code-review-and-quality` is the quick form;
+  this skill is its full expansion.
+
+## When to use
+
+- A new third-party dependency is being proposed (by you or in review)
+- Choosing between 2–3 candidate libraries for the same need
+- §2a.5 rung 5 surfaced a *new* dependency as the cheapest option
+- A dependency upgrade crosses a major version, changes its license, or changes maintainership
+
+**When NOT to use:** deciding *whether* you need a dependency (→ §2a.5 / `over-engineering-review`);
+scanning installed deps for CVEs (→ `dependency-scanner`); reviewing your *own* code (→
+`code-review-and-quality`).
+
+## Evaluation dimensions
+
+Score each; a single hard failure (incompatible license, unpatched critical CVE, abandoned) is
+disqualifying regardless of the rest.
+
+| Dimension | What to check | Disqualifier |
+|-----------|---------------|--------------|
+| **Need & fit** | Does it solve the *actual* problem, not a superset? How much of its API will you really use? | You'd use 5% of a large lib for one function |
+| **Alternatives** | stdlib / native platform feature / an already-installed dep / ~20 lines of your own | A cheaper rung of §2a.5 satisfies it |
+| **Maintenance & bus factor** | Recent commits, release cadence, issue/PR responsiveness, number of active maintainers, is it archived/deprecated? | Abandoned (no commits ~1yr), sole unresponsive maintainer, archived |
+| **Adoption & trust** | Real-world usage; downloads/dependents as *weak* signals (not popularity contests); who else relies on it | Effectively unused / no track record for critical use |
+| **License** | Compatible with *your* project's license and distribution model. Copyleft (GPL/AGPL) vs permissive (MIT/BSD/Apache); transitive licenses too. A copyleft dep in a permissive project may mean *document, don't vendor* | Incompatible / missing license |
+| **Security & supply chain** | CVE/advisory history *and how fast they're patched*; signed/2FA'd releases; typosquat/name-confusion check; provenance | Unpatched critical CVE; suspicious provenance |
+| **Weight & transitive deps** | Install/bundle/binary size; count and quality of transitive deps (each is its own liability); platform/runtime support | Huge transitive blast radius for a small need |
+| **API fit & lock-in** | Idiomatic for your stack? Type stubs/typings? How deeply would it thread through your code — i.e. exit cost? | Pervasive lock-in with no seam to swap it |
+| **Operational fit** | Compatible version range with your runtime/other deps; maintenance burden of pinning/upgrading | Conflicts with existing pinned deps |
+
+## Red flags 🚩 / Green flags ✅
+
+**🚩** No tests · no license · last release long ago · single unresponsive maintainer · exact-pins
+everything (fragile) · heavy transitive tree for a tiny need · unpatched advisories · you'd vendor
+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.
+
+## The decision
+
+Conclude explicitly — never let a dependency slip in undecided:
+
+1. **Adopt** — passes every dimension; pin sensibly and move on.
+2. **Adopt behind a seam** — acceptable but with real lock-in/risk → wrap it behind a thin interface
+   so it can be swapped, and note the exit path.
+3. **Reject** — a disqualifier fires, or a cheaper §2a.5 rung wins → record what you'll do instead.
+
+**Adding a dependency needs user approval** (per §2a.5 rung 5 / mandatory-workflow 2a). Record the
+decision and its rationale where future readers will find it — an ADR via `documentation-and-adrs`
+for a consequential one, or at minimum a line in the PR / change proposal. A rejected candidate is
+worth recording too, so the question isn't re-litigated.
+
+## Quick checklist
+
+```
+- [ ] §2a.5 walked first — a new dependency is genuinely the cheapest rung
+- [ ] Need & fit: solves the real problem; we use a meaningful share of it
+- [ ] No cheaper alternative (stdlib / native / existing dep / a few lines)
+- [ ] Actively maintained; bus factor > 1; not archived/deprecated
+- [ ] License compatible with the project (incl. transitive)
+- [ ] No unpatched critical/high CVEs; releases are patched promptly
+- [ ] Transitive-dep weight acceptable for the value gained
+- [ ] Lock-in understood; seam added if exit cost is high
+- [ ] User approval obtained; decision + rationale recorded
+```
+
+## Related
+
+- `.claude/rules/mandatory-workflow.md` (§2a.5 Reuse & YAGNI Gate) — the gate that decides *whether* a dep is needed
+- `over-engineering-review` — reactive twin of §2a.5; stdlib/native/yagni lenses
+- `dependency-scanner` agent — audits *already-installed* deps for CVEs (this skill's post-add counterpart)
+- `code-review-and-quality` (Dependency Discipline) — the quick 5-point form of this evaluation
+- `documentation-and-adrs` — record a consequential adopt/reject as an ADR

{claude_code_kit-0.36.0 → claude_code_kit-0.38.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.38.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.38.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.38.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.38.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.38.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.