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

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

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

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

@@ -4,6 +4,38 @@ 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.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
+`systematic-debugging` skill, both MIT; re-derived in claude-kit's idiom). Retry *budgets* existed for
+gates and operations, but nothing bounded blind *fix* attempts on a single bug:
+
+- **`rules/agent-resilience.md` — new "Fix-attempt discipline (the 3-strike rule)" section.** Attempts
+  1–2 must each test a *different, explicit* hypothesis (a near-duplicate edit doesn't count). At the
+  3rd failed attempt: STOP — re-derive the root cause (`debugging-and-error-recovery` skill), question
+  whether the *approach/architecture* is wrong (not the line), then escalate via `human-in-the-loop.md`
+  with what each attempt ruled out. Explicitly scoped against the `quality-gates.md` defect-loop budget
+  (that bounds review→fix cycles across the pipeline; this bounds blind attempts within one issue).
+
+Single-rule, count-neutral change; existing commands unaffected.
+
 ## [0.34.0] — 2026-06-25
 
 **Delta-specs + change-scoped artifacts** (pattern adopted from [OpenSpec](https://github.com/Fission-AI/OpenSpec),

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.34.0
+Version: 0.36.0
 Summary: Cookiecutter-style scaffolder for an autonomous Claude Code SDLC configuration (no app code, no Docker). Asks ordered questions and installs CLAUDE.md + .claude/ (rules, the chosen profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop.
 Project-URL: Homepage, https://github.com/ajyadav013/claude-kit
 Project-URL: Repository, https://github.com/ajyadav013/claude-kit

{claude_code_kit-0.34.0 → claude_code_kit-0.36.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.34.0"
+version = "0.36.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.34.0 → claude_code_kit-0.36.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
@@ -41,6 +43,25 @@ Operation fails
 | **Idempotency awareness** | Before retrying a side-effecting action | Re-running a commit/write/deploy/API-POST can double-apply. Check state first; make the retry safe. |
 | **Checkpointing** | Long runs, before risky steps, pre-compaction | Write `.claude/CONTINUITY.md` so a crash/compaction resumes from the last good state, not from zero. See `.claude/rules/continuity.md`. |
 
+## Fix-attempt discipline (the 3-strike rule)
+
+Bounded retry applies to *fixes*, too. Three failed attempts at the same failure is not a
+fourth-attempt problem — it is a signal that you do not yet understand the root cause, or the design
+is wrong. Retrying variations of the same fix is the deterministic-failure trap above wearing a
+disguise.
+
+- **Attempts 1–2** — allowed, but each must test a *different, explicit* hypothesis, changing one
+  variable at a time. The same edit retried (or a near-duplicate) does not count as a new attempt.
+- **At the 3rd failed attempt — STOP.** Do not attempt a fourth blind fix. Switch modes: re-derive
+  the root cause from first principles (`.claude/skills/debugging-and-error-recovery/SKILL.md`), and
+  ask the harder question — is the *approach or architecture* wrong, not the line?
+- **Then escalate** (`.claude/rules/human-in-the-loop.md`) with what you tried, what each attempt
+  ruled out, and the hypothesis you cannot resolve — not just "it still fails."
+
+This bounds *blind fix attempts within a single issue*; the defect-loop **budget** in
+`.claude/rules/quality-gates.md` bounds how many times a finding may cycle review→fix across the
+pipeline. Different scopes, same principle: no loop is unbounded.
+
 ## Rules
 
 1. **Fail loud, never silent.** A swallowed error that lets work continue on bad state is worse than a
@@ -53,6 +74,13 @@ Operation fails
 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.34.0 → claude_code_kit-0.36.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.34.0 → claude_code_kit-0.36.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.34.0 → claude_code_kit-0.36.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.34.0 → claude_code_kit-0.36.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.34.0 → claude_code_kit-0.36.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.34.0 → claude_code_kit-0.36.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.34.0 → claude_code_kit-0.36.0}/src/claude_kit/__init__.py

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