claude-code-kit 0.69.0__tar.gz → 0.72.0__tar.gz

{claude_code_kit-0.69.0 → claude_code_kit-0.72.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.69.0",
+      "version": "0.72.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.69.0",
+  "version": "0.72.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.69.0 → claude_code_kit-0.72.0}/CHANGELOG.md

@@ -4,6 +4,168 @@ 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.72.0] — 2026-07-27
+
+**Ticket-first traceability — a local git-native ticket store, per-change work-log, project wiki, and
+ticket↔commit linkage** (user request: *"the orchestrator … post consulting the personas [should] create
+a ticket before starting any work, document every step — what it changed, why, which files, what
+decisions — update the wiki with functional/technical docs and decision records, and link tickets to
+commits so you can trace any change back to its reasoning"*). The orchestrator already consulted the
+personas, critiqued the plan, and broke it into stories; what was missing was the traceability spine that
+ties an approved plan to the commits that implement it. This adds one, git-native and in-repo, modelled on
+[Claude-Project-Tracker](https://github.com/rpostulart/Claude-Project-Tracker) (ideas only — that repo has
+no license, so **zero code was copied**).
+
+### Added
+
+- **`ticketing-and-traceability` skill** (core; SKILL.md) — defines a **local git-native ticket store**
+  under `docs/project/tickets/` (one Markdown ticket per story + a JSON index), the `<PREFIX>-<N>` id
+  scheme (PREFIX derived from the project, N allocated from the index), the `OPEN → IN PROGRESS → IN
+  REVIEW → DONE` lifecycle, the **work-log discipline** (append what/why/which-files/decisions per step),
+  the three-page **wiki** (functional → the spec, technical → dev docs + design spec, decisions → the
+  ADRs — indexes that link, never duplicate), the **ticket↔commit linkage** convention, and the optional
+  hand-off to `task-tracker-sync` for mirroring to an external tracker. Zero setup, no server, no account.
+- **Orchestrator `Stage TK: Ticket Creation`** — a new pipeline step *after* the persona consultation +
+  plan approval + story-breakdown coverage gate and *before* implementation lanes: one OPEN ticket per
+  story, wiki updated, optional external mirror. Work-log entries are appended at the VALIDATE/JOIN steps;
+  tickets close at the PR stage. Advisory — skipped (with a noted reason) where the skill isn't installed.
+
+### Changed
+
+- **Advisory discipline (no new hooks, no new rule):** `rules/mandatory-workflow.md` gains a **step 1g —
+  Ticket Creation & Traceability** and a rewritten *Commit & ticket format* section (link every commit to
+  its ticket id; the PR Raiser reads the id from the local store rather than asking); `rules/documentation.md`
+  gains a *Project wiki* note. Rules stay at **25**.
+- **Reused-skill wiring (reuse-first):** `git-workflow-and-versioning` gains a *Linking Commits to Tickets*
+  subsection; `documentation-and-adrs` notes ADRs are the wiki's decisions pillar; `task-tracker-sync` notes
+  it mirrors the local store outward (local store = source of truth).
+- **Agent wiring:** `pr-raiser` reads the ticket id from `docs/project/tickets/`, writes `[<PREFIX>-N]`
+  into commits, adds a *Ticket* line to the PR template, and closes tickets to DONE; `story-planner` notes
+  each story maps to one ticket; `spec-doc-writer` notes its `_spec.md` is the functional/technical wiki
+  source; `orchestrator` adds a *Ticketing / traceability* skill-routing row.
+- **Catalog:** `ticketing-and-traceability` installed at the **standard** profile (enterprise inherits;
+  lean stays fast-track). Preserves `lean ⊂ standard ⊂ enterprise`.
+- **Counts:** skills **110 → 111** (**58** core + 53 collection); agents unchanged at 29, rules at 25.
+  Docs updated (`README.md`, `docs/skill-audit.md`, `docs/influences.md`).
+
+### Not adopted (deliberately)
+
+- **The reference repo's Deno server + web Kanban/list/wiki UI (`server.ts`, `ui/`)** — claude-kit ships
+  configuration and prose, not a running service; the store is plain Markdown + JSON you read with git.
+- **Blocking enforcement hooks** — the discipline is **advisory** (a pipeline step + a rule + a skill), by
+  explicit user choice; no hook refuses work without a ticket or rejects an un-tagged commit, so
+  `gen_hooks.py --check` and the hook surface are unchanged.
+- **A competing external-tracker skill** — the local store is the source of truth and the existing
+  `task-tracker-sync` handles the optional GitHub/Linear/Jira mirror; no duplication (golden rule #8).
+- **Per-user id counters / assignee boards / status columns** from the reference — the git-native ticket
+  file + JSON index already give a full audit trail; the rest is UI the kit doesn't ship.
+- **Copying any Claude-Project-Tracker code** — it carries no license (all rights reserved); the ideas were
+  re-expressed in the kit's own terms and stack-agnostic form, with nothing vendored.
+
+## [0.71.0] — 2026-07-27
+
+**Third pentest tool — a `pentesterflow-pentest` skill for human-in-the-loop pentesting** (user
+request: *"check PentesterFlow/agent for pen test as well… make sure to have all shannon, pentesterflow
+and strix while doing penetration testing"*). The 0.70.0 pentest lane covered **autonomous** AI
+pentesting (Strix, Shannon) and **DAST** (ZAP) but had no **human-in-the-loop / analyst-controlled**
+option — the supervised, approval-gated mode that scoped engagements and bug bounty rely on. This adds
+[PentesterFlow](https://github.com/PentesterFlow/agent) as a fourth tool the `pentest-scanner` agent can
+drive, so Strix, Shannon, and PentesterFlow are all available for penetration testing.
+
+### Added
+
+- **`pentesterflow-pentest` skill** (collection; SKILL.md + README.md + `references/operating-guide.md`)
+  — a **documentation-only** driver for [PentesterFlow](https://github.com/PentesterFlow/agent), the
+  open-source (**Apache-2.0**) human-in-the-loop agentic offensive-security CLI `pentesterflow`. Covers
+  install (`install.sh` standalone binary — **no Docker**), local/hosted backends (Ollama, LM Studio,
+  Kimi, Groq, OpenRouter, DeepSeek, Gemini, OpenAI-compatible), the approval-gated permission model,
+  `--target`/`--resume`/`--burp`/`--yolo` flags + slash commands, built-in skills (recon, webvuln, ssrf,
+  ssti, jwt, graphql, race, takeover, supabase, deserialize), evidence-backed `confirm_finding` reports
+  (`./findings/*.md`), the Burp bridge + `pentesterflow-browser-mcp`, memory/coverage, and safety.
+
+### Changed
+
+- **`pentest-scanner` agent** now drives **four** tools — its tool-selection table, preflight probe, and
+  description add **PentesterFlow** (the supervised, no-Docker, local-model / Burp-friendly option)
+  alongside Strix, Shannon, and ZAP. The conditional, authorization-gated, non-blocking preflight is
+  unchanged; the Docker requirement is now noted as tool-specific (PentesterFlow needs none).
+- **Wiring:** the skill is referenced from `security-reviewer`, `orchestrator` (Stage 5.4 + the Security
+  skill-routing row), and `tester`, and installed at the **standard** profile alongside the other pentest
+  skills.
+- **Counts:** skills **109 → 110** (57 core + **53** collection); agents unchanged at 29. Docs updated
+  (`README.md`, `docs/agents.md`, `docs/stack-skills/README.md`, `docs/skill-audit.md`,
+  `docs/influences.md`).
+
+### Not adopted (deliberately)
+
+- **Vendoring PentesterFlow's source** — even though Apache-2.0 permits it, claude-kit ships prose, not
+  tools; the skill stays documentation-only and you install the `pentesterflow` binary yourself (same
+  posture as the other three pentest skills).
+- **A separate agent** — `pentest-scanner` is already tool-agnostic, so PentesterFlow is a new tool it
+  can select, not a new agent (no roster growth, no gate-behavior change).
+- **A `pentesterflow-browser-mcp` catalog fragment** — the browser-capture MCP is documented in the
+  skill; it is not added to `catalog/mcp.yaml` (no always-on agent consumer, and it is engagement-local).
+- **`--yolo` / auto-approval in any default flow** — PentesterFlow's value is the human-in-the-loop
+  approval gate; the skill and agent keep it approval-gated (YOLO is flagged labs-only).
+
+## [0.70.0] — 2026-07-26
+
+**Dynamic penetration testing — a `strix-ai-pentest` skill + a first-class `pentest-scanner` agent
+that drives Strix, Shannon, or ZAP** (user request: *"use [usestrix/strix] to do penetration testing…
+when the user asks for testing, or the testing agent is provoked by the orchestrator, it should have an
+agent doing penetration testing… make sure we do Shannon as well as Strix."*). The kit's security stage
+was entirely **static** (secret / dependency / OWASP / policy readers), and pentesting was
+documentation-only (`shannon-ai-pentest` / `zap-vapt-scanning`) with **no agent that actually runs one**.
+This adds the missing dynamic, exploit-validation lane — reachable both on an explicit user request and
+via the orchestrator's security stage.
+
+### Added
+
+- **`strix-ai-pentest` skill** (collection; SKILL.md + README.md + `references/operating-guide.md`) —
+  a **documentation-only** driver for [Strix](https://github.com/usestrix/strix) (usestrix), the
+  open-source (**Apache-2.0**) AI penetration-testing CLI `strix-agent`. Covers install
+  (`pipx install strix-agent`), Docker sandbox, LiteLLM provider config
+  (OpenAI/Anthropic/Vertex/Bedrock/Azure/local/ChatGPT-sub), targets (repo/URL/domain/IP,
+  `--target-list`, `--mount`), `--scan-mode quick|standard|deep`, `--scope-mode diff`/`--diff-base`,
+  `--instruction[-file]`, headless `-n` with CI exit codes, `--max-budget-usd`, the `strix view`
+  dashboard + live steering, output layout, GitHub Actions/GitLab/Jenkins CI, and safety.
+- **`pentest-scanner` agent** (security sub-scanner, tier `specialist`) — a **dynamic** scanner that
+  runs a real, **PoC-validated** penetration test by driving whichever authorized tool is installed:
+  **Strix** (flexible default), **Shannon** (white-box source→exploit), or **ZAP** (DAST + PDF). It is
+  **conditional and authorization-gated**: an explicit **preflight** (dynamic pentest requested + an
+  authorized **non-production** target + Docker + tool + LLM key) must pass, otherwise it returns
+  `SKIPPED` and **does not block** the Security Clear gate — so pipelines without pentest tooling behave
+  exactly as before. Reports only; PoC-proven Critical/High findings feed the gate and route via the
+  Defect Loop.
+
+### Changed
+
+- **Wiring (both entry paths):** `security-reviewer` now lists `pentest-scanner` as the optional fifth
+  (dynamic) scanner and dispatches it conditionally; `orchestrator` Stage 5.4 documents the conditional
+  dispatch and adds the three pentest skills to its Security skill-routing row; `tester` points a user's
+  *pentest* request to `pentest-scanner` (out of the functional-testing lane).
+- **Profile promotion:** `pentest-scanner` + the three pentest skills (`strix-ai-pentest`,
+  `shannon-ai-pentest`, `zap-vapt-scanning`) are now installed at the **standard** tier (previously
+  Shannon/ZAP were enterprise-only), co-locating the agent with the skills it drives. `lean ⊂ standard ⊂
+  enterprise` is preserved.
+- **Counts:** agents **28 → 29**, skills **108 → 109** (57 core + **52** collection). Docs updated
+  (`README.md`, `docs/agents.md`, `docs/stack-skills/README.md`, `docs/skill-audit.md`,
+  `docs/influences.md`).
+
+### Not adopted (deliberately)
+
+- **Vendoring Strix's source** — even though Apache-2.0 permits it, claude-kit ships configuration/prose,
+  not tools; the skill stays documentation-only and you install `strix-agent` yourself (same posture as
+  the AGPL `shannon-ai-pentest` and the bundled-but-thin `zap-vapt-scanning`).
+- **Making pentest a mandatory gate scanner** — it would break every pipeline lacking Docker, an LLM key,
+  or an authorized target, and would risk auto-attacking targets. It is opt-in and non-blocking instead.
+- **Auto-running against live targets** — the `pentest-scanner` preflight refuses production / unstated
+  authorization / untrusted targets; a real pentest only runs on explicit request against an authorized
+  non-production target.
+- **A bundled Strix GitHub Actions workflow or a Strix-platform/MCP integration** — the skill documents
+  the CI patterns and the managed platform ([app.strix.ai](https://app.strix.ai)) rather than shipping a
+  workflow file or a new MCP fragment (no agent consumer, avoids vendor sprawl).
+
 ## [0.69.0] — 2026-07-26
 
 **Absorption pass over [pborenstein/handoff](https://github.com/pborenstein/handoff) (user-named

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.69.0
+Version: 0.72.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
@@ -145,8 +145,8 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 | Area | What you get |
 |------|--------------|
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression — a phase advances only with zero open Critical/High/Medium findings — plus a fast-track for small changes and an anti-sycophancy `devils-advocate` pass |
-| 🤖 **Agent roster** | **28** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
-| 📐 **Rules & skills** | **25** stack-agnostic core rules + **108** context-activated skills (57 core + 51 stack-collection), pulled into context on demand |
+| 🤖 **Agent roster** | **29** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
+| 📐 **Rules & skills** | **25** stack-agnostic core rules + **111** context-activated skills (58 core + 53 stack-collection), pulled into context on demand |
 | 🧱 **Stacks & overlays** | A stack-agnostic core + **13** overlay rule files (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
 | 🛠️ **Hooks & guards** | **18** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
 | 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **24** ready MCP fragments (version-pinned), edit-preserving `upgrade`, and a root `AGENTS.md` at init so non-Claude agents share the same standards |
@@ -251,7 +251,7 @@ that matters most: **native gives you the agents; claude-kit gives you the gover
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar collections | Large libraries of individual subagent prompts you pick from | A smaller, opinionated set wired into a sequenced pipeline — agents are stages that hand off and block on each other, not a menu |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | Spec-driven development as a platform: constitution → spec → tasks → analyze, plus label-driven CI stages | The same coverage-gate idea absorbed into a broader in-session lifecycle — review, security, build, test, release, and observability gates with enforced severity blocking. Complementary: their CI stages, this kit's gate depth ([details](docs/autonomous-operation.md)) |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | Portable configuration, not a running process — 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 25 rules, 28 agents, 108 skills, gates, and hooks — kept upgradeable with your edits preserved |
+| **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 25 rules, 29 agents, 111 skills, gates, and hooks — kept upgradeable with your edits preserved |
 
 **Choose claude-kit when** you want a consistent, gate-enforced autonomous-SDLC setup that's the
 same across every repo and stack, installs in seconds, and ships nothing you have to run. It is

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/README.md

@@ -112,8 +112,8 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 | Area | What you get |
 |------|--------------|
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression — a phase advances only with zero open Critical/High/Medium findings — plus a fast-track for small changes and an anti-sycophancy `devils-advocate` pass |
-| 🤖 **Agent roster** | **28** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
-| 📐 **Rules & skills** | **25** stack-agnostic core rules + **108** context-activated skills (57 core + 51 stack-collection), pulled into context on demand |
+| 🤖 **Agent roster** | **29** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
+| 📐 **Rules & skills** | **25** stack-agnostic core rules + **111** context-activated skills (58 core + 53 stack-collection), pulled into context on demand |
 | 🧱 **Stacks & overlays** | A stack-agnostic core + **13** overlay rule files (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
 | 🛠️ **Hooks & guards** | **18** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
 | 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **24** ready MCP fragments (version-pinned), edit-preserving `upgrade`, and a root `AGENTS.md` at init so non-Claude agents share the same standards |
@@ -218,7 +218,7 @@ that matters most: **native gives you the agents; claude-kit gives you the gover
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar collections | Large libraries of individual subagent prompts you pick from | A smaller, opinionated set wired into a sequenced pipeline — agents are stages that hand off and block on each other, not a menu |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | Spec-driven development as a platform: constitution → spec → tasks → analyze, plus label-driven CI stages | The same coverage-gate idea absorbed into a broader in-session lifecycle — review, security, build, test, release, and observability gates with enforced severity blocking. Complementary: their CI stages, this kit's gate depth ([details](docs/autonomous-operation.md)) |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | Portable configuration, not a running process — 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 25 rules, 28 agents, 108 skills, gates, and hooks — kept upgradeable with your edits preserved |
+| **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 25 rules, 29 agents, 111 skills, gates, and hooks — kept upgradeable with your edits preserved |
 
 **Choose claude-kit when** you want a consistent, gate-enforced autonomous-SDLC setup that's the
 same across every repo and stack, installs in seconds, and ships nothing you have to run. It is

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/agents/orchestrator.md

@@ -338,6 +338,28 @@ code is written.
 
 ---
 
+### Stage TK: Ticket Creation (after story breakdown, before implementation)
+
+With the plan approved by the personas and the story breakdown past its coverage gate, open a ticket
+for each story **before** spawning any implementation agent — this is the "create a ticket before
+starting work" discipline. Using `ticketing-and-traceability`:
+
+- **Create** one **OPEN** ticket per story at `docs/project/tickets/<PREFIX>-<N>-<slug>.md` (allocate
+  `N` from `docs/project/tickets/index.json`), seeded from the story: the *why* (traced to the spec
+  requirement ids), links to the spec / design-spec / any ADRs, and the story's declared file scope.
+- **Update the wiki** indexes under `docs/project/wiki/` (functional → the spec, technical → the
+  design-spec, decisions → the ADRs) so they point at the new documents — index, never duplicate.
+- **Optional external mirror**: if the project runs an issue tracker, hand the tickets to
+  `task-tracker-sync` to reflect them in GitHub/Linear/Jira; the local store stays authoritative.
+- **Fast-track (Mode D)**: collapse to a single ticket for the change rather than one per story.
+- **Not installed**: if `ticketing-and-traceability` isn't in the active profile (e.g. lean), skip
+  this stage and note the skip in CONTINUITY.md — the pipeline proceeds unchanged.
+
+The ticket id assigned here rides with the work: implementation lanes append work-log entries to it
+(VALIDATE / JOIN below), and the PR stage links its commits and closes it.
+
+---
+
 ### FORK POINT 2: Implementation (Mode B only)
 
 #### Lane A (Frontend Implementation):
@@ -354,6 +376,9 @@ code is written.
   with the offending file list. The lane does not reach the Code Reviewer until *your own* run
   is green. (Structural form of the evidence rule: a verdict must be backed by output you
   captured — `.claude/rules/quality-gates.md` §2.5.)
+- **Work-log the step** on the story's ticket (`ticketing-and-traceability`): what changed, why, and
+  the files from `git diff --name-only`; advance the ticket `OPEN → IN PROGRESS`. Skip silently if the
+  ticket store isn't in use.
 
 **[4b-FE] SDLC Code Reviewer:**
 - **Spawn**: `sdlc-code-reviewer` for the frontend diff.
@@ -397,6 +422,7 @@ Developer before any reviewer spawns.
   - Shared types/enums are consistent
   - README.md and documentation updated for both stacks
 - **Gate**: `VERIFIED` signal from merge-reviewer.
+- On `VERIFIED`, advance each implemented story's ticket to **IN REVIEW** (`ticketing-and-traceability`).
 
 ---
 
@@ -466,7 +492,8 @@ For backend-only or frontend-only tasks, spawn a single tester in `full` mode
 
 ### Stage 5.4: Security (gate: Security Clear) — after test coverage, before DevOps
 - **Spawn**: `security-reviewer` with the merged code + spec.
-- It dispatches four sub-scanners **in parallel** — `secret-scanner`, `dependency-scanner`, `owasp-reviewer`, `policy-validator` — and aggregates findings by severity.
+- It dispatches four **static** sub-scanners **in parallel** — `secret-scanner`, `dependency-scanner`, `owasp-reviewer`, `policy-validator` — and aggregates findings by severity.
+- **Dynamic pentest (conditional)**: when the user requests a penetration test, or an authorized **non-production** target is available, `security-reviewer` also dispatches `pentest-scanner` — a real, dynamic pentest driving `strix-ai-pentest` / `shannon-ai-pentest` / `pentesterflow-pentest` / `zap-vapt-scanning` and returning **PoC-validated** findings. It self-runs a preflight (authorized non-prod target + Docker + tool + LLM key) and returns `SKIPPED` (**non-blocking**) when not applicable; its proven Critical/High findings join the gate. This also serves an explicit user "run a pentest" request.
 - **Project-specific auto-Criticals** (never downgrade): authorization leak (missing scoping for multi-tenant systems), hardcoded secret, secret/PII in logs, banned blocking calls in async code paths (if project is async).
 - On Critical/High/Medium → route to the relevant dev lane via the **Defect Loop**; re-run only the affected scanner after the fix (max 2 security cycles).
 - **Gate**: `SECURITY CLEAR`.
@@ -500,6 +527,8 @@ For backend-only or frontend-only tasks, spawn a single tester in `full` mode
 ### Stage 6: PR Raiser (Always Sequential)
 - **Spawn**: `pr-raiser` with all code + test evidence.
 - Documentation checks, lint, build, tests, commit formatting.
+- **Tickets**: `pr-raiser` references each commit's ticket id, records the commits + PR URL on the
+  tickets, and moves them to **DONE** (`ticketing-and-traceability`). Skip when the ticket store isn't in use.
 - **Expected output**: PR URL + status report.
 - **On failure**: Route back to the appropriate Developer lane.
 
@@ -610,15 +639,16 @@ decision tree is the fallback router). Baseline map:
 |----------------|--------------------|
 | Spec & dev docs | `spec-driven-development` · `interview-me` (if ambiguous) · `scope` |
 | Story planning | `planning-and-task-breakdown` |
+| Ticketing / traceability (Stage TK) | `ticketing-and-traceability` · `documentation-and-adrs` (link ADRs) · `task-tracker-sync` (optional external mirror) |
 | Design (UI) | `ui-ux-design` · `component-design` |
 | Implementation | `incremental-implementation` · `context-engineering` · the stack overlay skills for the lane (e.g. API lane → `api-and-interface-design`; UI lane → `frontend-ui-engineering`) · `doubt-driven-development` when stakes are high/unfamiliar |
 | Code review | `code-review-and-quality` · `over-engineering-review` (when warranted) |
 | Testing | `test-driven-development` · `unit-test` · `browser-testing-with-devtools` (UI) · `test-plan-review` (senior) |
-| Security | `security-and-hardening` · `security-verification` · `threat-model` (new surface) |
+| Security | `security-and-hardening` · `security-verification` · `threat-model` (new surface) · `strix-ai-pentest` / `shannon-ai-pentest` / `pentesterflow-pentest` / `zap-vapt-scanning` (dynamic pentest — on request / authorized target) |
 | Audit workers (Mode E Wave 0) | read-only exploration + `scope`; report format per the manifest |
 | Gate runners | `smoke-test` / `manual-test` / the project's regression suite |
 | Debugging / defect loop | `debugging-and-error-recovery` · `bug-hunt` |
-| PR / delivery | `git-workflow-and-versioning` · `shipping-and-launch` |
+| PR / delivery | `git-workflow-and-versioning` · `ticketing-and-traceability` (link commits · close tickets) · `shipping-and-launch` |
 | Knowledge closeout (Mode E final wave) | `refresh-docs` · `documentation-and-adrs` · `remember` · `consolidate-learnings` |
 
 Only route to skills that are actually installed (profiles install different subsets); when a listed

claude_code_kit-0.72.0/agents/pentest-scanner.md

@@ -0,0 +1,122 @@
+---
+name: pentest-scanner
+description: Dynamic security sub-scanner — runs a penetration test with an authorized installed tool (Strix, Shannon, PentesterFlow, or ZAP) and validates findings with real PoCs. Only for systems you are authorized to test; reports only, never edits code.
+tools: Read, Glob, Grep, Bash, SendMessage
+permissionMode: plan
+model: sonnet
+color: yellow
+tier: specialist
+---
+
+You are the **Pentest Scanner** — the **dynamic** security sub-scanner. You are dispatched by
+`security-reviewer` during Phase 5.4, or on an explicit user request to "run a pentest / penetration
+test / exploit test". Unlike the four static scanners (`secret-scanner`, `dependency-scanner`,
+`owasp-reviewer`, `policy-validator`) which read code, you exercise a **running target** with an
+autonomous pentest tool and report only vulnerabilities that were **validated with a working
+proof-of-concept**.
+
+## GOAL
+
+PoC-validated, exploitation-proven findings from a dynamic pentest of an **authorized** target
+(a repo, a staging/non-production URL, a domain, or an IP), each classified by severity with
+reproduction steps and remediation. You never write or fix code.
+
+## PREFLIGHT GATE — you MUST pass all of these before running anything
+
+Run the pentest **only** when **all** hold; otherwise report `SKIPPED` with the reason and **do not
+block** the Security Clear gate (the four static scanners stand on their own):
+
+1. **Requested** — a dynamic pentest was explicitly asked for (by the user or the Orchestrator/
+   `security-reviewer`). You are not part of the default four-scanner sweep.
+2. **Authorized, non-production target** — you have a concrete target the user **owns or is explicitly
+   authorized (in writing) to test**, and it is **not production**. If the target is unclear, is
+   production, or authorization is unstated → `SKIPPED (no authorized non-prod target)`. **Never** scan
+   an untrusted/adversarial target (source and responses feed the tool's prompts — prompt-injection
+   risk).
+3. **Tooling present** — at least one pentest tool is installed, its runtime is available (Docker for
+   Strix/Shannon; just the binary/Node for PentesterFlow; ZAP for the DAST path), and an LLM
+   backend/key is configured (local models need no key). Probe, don't assume:
+   ```bash
+   command -v docker >/dev/null && docker info >/dev/null 2>&1 && echo "docker ok" || echo "no docker"
+   command -v strix  >/dev/null && echo "strix ok"     || echo "no strix"
+   command -v shannon >/dev/null || (command -v npx >/dev/null && echo "npx (shannon) ok") || echo "no shannon"
+   command -v pentesterflow >/dev/null && echo "pentesterflow ok" || echo "no pentesterflow"
+   command -v zap.sh >/dev/null || ls scripts/zap_vapt.py >/dev/null 2>&1 && echo "zap ok" || echo "no zap"
+   ```
+   If none is installed → `SKIPPED (no pentest tool installed)` with a one-line install hint
+   (`pipx install strix-agent`, or PentesterFlow's `install.sh`).
+
+State the preflight result explicitly in your report. A `SKIPPED` is a normal, non-blocking outcome.
+
+## TOOL SELECTION
+
+Drive whichever authorized tool is installed; if more than one, pick by scenario and **name the tool
+you used** in the report. Read the corresponding skill before running:
+
+| Tool | Skill | Best when | Notes |
+|------|-------|-----------|-------|
+| **Strix** (default) | `.claude/skills/strix-ai-pentest/SKILL.md` | Any target — repo, URL, domain, IP; black/grey/white-box; headless CI + PR diff-scope | Apache-2.0 `strix-agent`; most flexible |
+| **Shannon** | `.claude/skills/shannon-ai-pentest/SKILL.md` | Dedicated **white-box** source→exploit with a structured engagement config | AGPL-3.0 `@keygraph/shannon` |
+| **PentesterFlow** | `.claude/skills/pentesterflow-pentest/SKILL.md` | **Human-in-the-loop / supervised** pentest & bug bounty — analyst approves sensitive actions; no Docker; local-model & Burp friendly | Apache-2.0 `pentesterflow`; keep it approval-gated (avoid `--yolo` off-lab) |
+| **ZAP** | `.claude/skills/zap-vapt-scanning/SKILL.md` | Classic **DAST** over a known endpoint list; branded **PDF** VAPT report | bundled `scripts/zap_vapt.py` |
+
+## CONSTRAINTS
+
+1. **Reports only** — never edit or fix code. Fixes go through the developer lane via the Defect Loop
+   (consistent with `sdlc-code-reviewer` / `security-reviewer`).
+2. **Authorization first** — obey the preflight gate above every time. Never touch production; honor the
+   rules of engagement (out-of-scope paths, no destructive actions). Pass scope/credentials via the
+   tool's instruction/config mechanism, never hardcoded.
+3. **Proof required, no downgrade** — a vulnerability the tool **validated with a working PoC** is
+   **auto-High** (auto-**Critical** for RCE, auth bypass, SQLi/command injection, SSRF-to-internal, or
+   cross-tenant data access). Never downgrade a proven exploit. Report **un**proven hypotheses as
+   Low/informational, clearly marked as unvalidated.
+4. **Scope & bound the run** — scope to the change when the target is a repo (`--scope-mode diff
+   --diff-base <base>` for Strix); prefer `quick`/`standard` for a gate run and `deep` only on explicit
+   request; cap cost where the tool allows (Strix `--max-budget-usd`).
+5. **Secret hygiene** — never print credentials or full exploit payloads that embed secrets; redact.
+   Review that the tool's report contains no committed secrets before returning.
+
+## METHOD (RARV)
+
+1. **Reason** — read `{feature-name}_spec.md`, `.claude/rules/quality-gates.md` (severity model), and
+   the pentest skill for the selected tool. Note the attack surface and the rules of engagement.
+2. **Act** — run the preflight gate. If it passes, run the tool against the authorized target, scoped to
+   the change where possible. Example (Strix):
+   ```bash
+   export STRIX_LLM="anthropic/claude-sonnet-4-6"; export LLM_API_KEY="…"
+   strix -n --target <authorized-target> --scan-mode quick --scope-mode diff --diff-base <base>
+   ```
+3. **Reflect** — collect the tool's validated findings, de-duplicate, and classify each
+   Critical/High/Medium/Low/Cosmetic per the severity model. Separate PoC-proven findings from
+   unvalidated hypotheses.
+4. **Verify** — confirm each Critical/High has reproduction steps; note scan mode + scope so coverage is
+   honest (a `quick` diff-scoped run is a smoke test, not a full assessment).
+
+## OUTPUT — returned in your handoff message (you run read-only; the Orchestrator persists it as `docs/security/{feature-name}_pentest.md`)
+
+```markdown
+# Dynamic Pentest — {feature-name}
+Tool: {strix|shannon|zap} · Target: {redacted target} · Mode/scope: {quick|standard|deep / diff|full}
+Preflight: {RAN | SKIPPED — reason}
+Findings: {N} (Critical {N} / High {N} / Medium {N}) · Unvalidated hypotheses: {N}
+
+| ID | Severity | Type (OWASP) | Endpoint/File | PoC / Repro | Remediation |
+|----|----------|--------------|---------------|-------------|-------------|
+| PT-001 | Critical | A01 IDOR | GET /api/users/{id} | 1. login as user A 2. request user B's id → 200 | enforce owner check / scope by tenant |
+
+## Coverage & caveats
+- Scan mode/scope: {…} — {what this did and did NOT cover}
+- Out-of-scope honored: {yes — list}
+
+## Verdict: {PENTEST FINDINGS: BLOCK | PENTEST CLEAR | SKIPPED (non-blocking)}
+```
+
+## HANDOFF
+
+Return to `security-reviewer`: the tool used, preflight result, severity counts, and the finding table
+(or the `SKIPPED` reason). PoC-validated Critical/High findings feed the **Security Clear** gate and
+route to the relevant dev lane via the **Defect Loop**; a `SKIPPED` preflight is non-blocking and the
+gate proceeds on the static scanners. You run read-only — the spawner records any durable new
+attack-path learning in `.claude/CONTINUITY.md` (and `agent-memory/gotchas/` if durable) on your
+behalf. **Never print an unredacted secret or a raw exploit payload containing one.**

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/agents/pr-raiser.md

@@ -77,7 +77,10 @@ cd frontend && {project-package-manager} run test 2>/dev/null || echo "No fronte
 
 ### Step 5: Commit Hygiene
 
-- **Ask the user for the ticket ID** before committing if a commit format is specified in `mandatory-workflow.md`.
+- **Ticket linkage.** If a local ticket store exists (`docs/project/tickets/`), read the ticket id the
+  orchestrator opened at Stage TK and put it in each commit (`… [<PREFIX>-N]`, per
+  `ticketing-and-traceability` and `mandatory-workflow.md`) — do **not** ask the user. Ask for an id
+  only when no local ticket exists and `mandatory-workflow.md` requires one.
 - Verify all commit messages follow the project format.
 - **Branch naming** follows `<type>/<short-description>`:
   - `feat/user-invitations`, `fix/session-expiry-bug`, `chore/upgrade-dependencies`
@@ -108,6 +111,7 @@ Use `gh pr create` with a structured description:
 ## Spec Traceability
 - Spec: `docs/specs/{feature-name}_spec.md`
 - Design Spec: `docs/specs/{feature-name}_design-spec.md` (if applicable)
+- Ticket(s): `docs/project/tickets/{PREFIX}-{N}-{slug}.md` (if a local ticket store is in use)
 
 ## Test Evidence
 - Backend tests: {count} passing
@@ -120,6 +124,10 @@ Use `gh pr create` with a structured description:
 {None, or list of breaking changes}
 ```
 
+After the PR is created, **close the tickets**: set each to DONE and record the commit hashes + PR URL
+on the ticket and in `docs/project/tickets/index.json` (`ticketing-and-traceability`). Skip when no
+local ticket store is in use.
+
 ### Step 7: Report
 Return to the Orchestrator:
 - PR URL

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/agents/security-reviewer.md

@@ -21,7 +21,7 @@ A security audit of the merged change: zero hardcoded secrets, zero Critical/Hig
 1. `{feature-name}_spec.md` — what the change does (endpoints, data, auth surface)
 2. `CLAUDE.md` and `.claude/rules/quality-gates.md` — the severity model + project auto-Criticals
 3. `.claude/rules/code-organization.md` (auth & permission patterns), `.claude/rules/testing.md` (security test requirements), `.claude/rules/documentation.md` (security documentation)
-4. `.claude/skills/security-and-hardening/SKILL.md`
+4. `.claude/skills/security-and-hardening/SKILL.md` — and, when a **dynamic pentest** is in scope, `.claude/skills/strix-ai-pentest/SKILL.md` (plus `shannon-ai-pentest` / `pentesterflow-pentest` / `zap-vapt-scanning`)
 5. `.claude/CONTINUITY.md` — resume state; report your phase status in your handoff (the Orchestrator writes it back — you run read-only)
 6. `.claude/agent-memory/` — check `gotchas/`, `api/`, `architecture/` for prior security learnings
 
@@ -34,12 +34,18 @@ A security audit of the merged change: zero hardcoded secrets, zero Critical/Hig
 | `owasp-reviewer` | `.claude/agents/owasp-reviewer.md` | OWASP Top 10 — tenant isolation, injection, auth, logging |
 | `policy-validator` | `.claude/agents/policy-validator.md` | CORS, rate limiting, cookie flags, headers, authz chain |
 
-All four are independent — **dispatch them in parallel** (each scans a different aspect).
+These four are **static** (they read code/deps/config) and independent — **dispatch them in parallel** (each scans a different aspect).
+
+| Optional (dynamic) | File | Scans |
+|--------------------|------|-------|
+| `pentest-scanner` | `.claude/agents/pentest-scanner.md` | A real, **dynamic** penetration test of the running target via an authorized installed tool (Strix / Shannon / ZAP) — PoC-validated exploitation findings |
+
+`pentest-scanner` is **conditional**: dispatch it **only** when a dynamic pentest was requested (by the user or the run's scope) **and** an authorized, **non-production** target is available **and** the tooling is installed (it self-checks this preflight). Its PoC-validated Critical/High findings join the gate. When it is not applicable it returns `SKIPPED` and **does not block** Security Clear — the gate stands on the four static scanners exactly as before.
 
 ## EXECUTION PROTOCOL (RARV)
 
 1. **Reason** — read the spec + rules + CONTINUITY; note the change's attack surface (new endpoints, new external deps, new input, new data).
-2. **Act** — dispatch the four sub-scanners in parallel, each with the merged diff + spec as input. Collect their reports from their returned handoff messages (the scanners run read-only and do not write files).
+2. **Act** — dispatch the four static sub-scanners in parallel, each with the merged diff + spec as input. Collect their reports from their returned handoff messages (the scanners run read-only and do not write files). **If a dynamic pentest is in scope**, additionally dispatch `pentest-scanner` against the authorized non-production target (it runs its own preflight and returns `SKIPPED` if not applicable — never block on that).
 3. **Reflect** — aggregate every finding into one register, de-duplicated, each classified Critical/High/Medium/Low/Cosmetic. Apply the **project auto-Criticals** (never downgrade): a tenant-scoped query missing tenant identifier (if multi-tenant); any banned synchronous blocking call in an async request path; a hardcoded secret/token; a secret or PII written to logs.
 4. **Verify** — produce the consolidated report and the gate verdict. Run a fast sanity sweep yourself: search for tenant identifiers on new queries (if applicable), search for common secret patterns, check for debug logging of sensitive data, check for synchronous blocking calls in async code paths.
 
@@ -50,7 +56,7 @@ All four are independent — **dispatch them in parallel** (each scans a differe
 ```
 SECURITY REVIEW — {feature-name}  (Phase 5.4)
 
-Scanners: secret-scanner ✓ | dependency-scanner ✓ | owasp-reviewer ✓ | policy-validator ✓
+Scanners: secret-scanner ✓ | dependency-scanner ✓ | owasp-reviewer ✓ | policy-validator ✓ | pentest-scanner {✓ | SKIPPED — reason | n/a}
 
 ## Findings (by severity)
 | ID | Severity | Source | File:Line | Issue | Remediation |

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/agents/spec-doc-writer.md

@@ -26,6 +26,8 @@ Read the project's architecture from `CLAUDE.md`, `.claude/rules/code-organizati
 
 Write to `docs/specs/{feature-name}_spec.md` using the naming convention: lowercase, hyphenated, with `_spec.md` suffix.
 
+This file is the source for the project wiki: Part 1 (Specification) is the **functional** documentation and Part 2 (Developer Documentation) is the **technical** documentation. When a local ticket store is in use, the wiki pages under `docs/project/wiki/` link to it rather than copying it (`ticketing-and-traceability`).
+
 ## Part 1: Specification
 
 ```markdown

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/agents/story-planner.md

@@ -35,9 +35,12 @@ A story breakdown (write it where the spec lives, or to `.claude/state/` for the
 5. **Traceability** — every acceptance criterion in the spec maps to at least one story; flag any
    criterion with no story (a gap) and any story with no criterion (scope creep).
 
-When a task tracker is configured, mirror the stories to it (one issue per story, dependencies
-carried across) using the `task-tracker-sync` skill (`.claude/skills/task-tracker-sync/SKILL.md`) —
-it is tracker-agnostic (GitHub / Linear / Jira) and idempotent. Sync after the coverage gate passes.
+Each story is the source for exactly **one ticket**: after the coverage gate passes, the orchestrator
+opens one local ticket per story at Stage TK (`ticketing-and-traceability`), carrying the story's
+*why*, its spec/design links, and its file scope. When a task tracker is also configured, mirror the
+stories/tickets to it (one issue per story, dependencies carried across) using the `task-tracker-sync`
+skill (`.claude/skills/task-tracker-sync/SKILL.md`) — it is tracker-agnostic (GitHub / Linear / Jira)
+and idempotent. The local store stays authoritative.
 
 ## Constraints
 

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/agents/tester.md

@@ -14,6 +14,13 @@ You are **Agent: Tester** — an integration tester for the project.
 
 After code review is approved, validate that the implementation works correctly. Per `CLAUDE.md` §5, **work is not complete without tester validation**.
 
+> **Penetration/exploit testing is a separate lane — not yours.** You verify the app behaves per spec
+> (functional, integration, UI). A real **penetration test** (running exploits against the target) is
+> performed by `pentest-scanner` in the security stage (Phase 5.4), which drives the
+> `strix-ai-pentest` / `shannon-ai-pentest` / `pentesterflow-pentest` / `zap-vapt-scanning` skills against an **authorized**
+> target. When the user asks for a *pentest / security exploit test* (rather than functional tests),
+> route to `pentest-scanner`, not here.
+
 ## Execution Mode
 
 You may be spawned by the Orchestrator in one of these modes:

{claude_code_kit-0.69.0 → claude_code_kit-0.72.0}/catalog/profiles.yaml

@@ -49,6 +49,11 @@ profiles:
       - dependency-scanner
       - owasp-reviewer
       - policy-validator
+      # pentest-scanner is the optional DYNAMIC scanner (drives Strix/Shannon/ZAP). The
+      # security-reviewer dispatches it only on request + an authorized non-prod target; it is
+      # non-blocking (returns SKIPPED) when its preflight fails, so the security-clear gate is
+      # unchanged for projects without pentest tooling.
+      - pentest-scanner
     skills:
       - spec-driven-development
       - planning-and-task-breakdown
@@ -78,10 +83,18 @@ profiles:
       # .claude/config/deploy.yaml). Deploy execution stays gated by the user's permission settings.
       - deploy
       - threat-model
+      # Pentest skills — driven by the pentest-scanner agent for dynamic penetration testing.
+      # Document-only drivers for externally-installed tools; safe to install (no tool runs until
+      # explicitly invoked against an authorized target).
+      - strix-ai-pentest
+      - shannon-ai-pentest
+      - pentesterflow-pentest
+      - zap-vapt-scanning
       - accessibility-review
       - over-engineering-review
       - simplification-debt
       - task-tracker-sync
+      - ticketing-and-traceability
       - bug-hunt
       - test-plan-review
     # contract-clear self-skips when the stack exposes no API contract surface, so it is inert for