@codewithjuber/forgekit 0.8.0

package/global/tools/cost-guard/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: cost-guard
+description: Reduce token/cost burn on large or exploratory tasks. Use when a task will touch many files, involves broad codebase search, a big migration, or when the user asks to keep cost/context low.
+---
+
+# Cost guard
+
+Playbook for high-performance, low-cost runs. The constraint is the context
+window: performance degrades as it fills, and tokens cost money. Spend context
+deliberately.
+
+## Rules of thumb
+- **Search, don't read.** Use `rg`/`grep`/`glob` to locate, then read only the
+  relevant lines/ranges — not whole files or directories.
+- **Delegate exploration.** For "how does X work / where is Y" questions across
+  many files, spawn the `scout` subagent. It reads in its own context and returns
+  a summary, keeping the main thread lean.
+- **Verify with a fresh model.** For non-trivial diffs, use the `verifier`
+  subagent instead of re-reading everything yourself.
+- **Clear between tasks.** Unrelated work → `/clear`. Long single problems can
+  keep context; switching topics should not.
+- **Compact with intent.** When near limits, `/compact Focus on <the thing that
+  matters>` beats a generic compaction.
+- **Prefer CLIs** (`gh`, cloud CLIs) over pasting large outputs or fetching pages.
+- **Scope investigations.** Never say "investigate X" unbounded — name the files
+  or the question, or hand it to `scout`.
+
+## Model choice + measurement
+- `forge route "<task>"` names the cheapest capable tier before you pick a model;
+  escalate only after an external verifier fails.
+- Cheap model (`scout`) for search/triage/enumeration; reserve the top model for
+  genuinely hard reasoning, not routine edits.
+- `forge cost` shows real per-day spend; **`forge cost --stages`** shows the
+  measured per-stage savings (gate / cache / route / context) from
+  `.forge/metrics.jsonl` — a stage with no events says "no data", never a default.
+- `forge reuse query "<spec>"` before regenerating: a hit is verified code you
+  already paid for.
+
+## Prompt-cache hygiene
+Claude Code caches by exact request *prefix*; a change high in the prefix
+recomputes everything after it. Pick model + MCP servers at session start
+(switching mid-task busts the cache); save `/compact` for natural breaks and
+prefer `/rewind` to abandon a path; don't add bare-tool deny rules mid-session
+(scoped rules like `Bash(rm *)` are cache-safe); watch the status line's `⚡NN%`
+indicator — if it stays low turn after turn, your prefix keeps changing.
+
+## Fan-out for big batches
+For repetitive edits across many files, generate the file list first, test the
+prompt on 2–3 files, then loop `claude -p "<prompt>" --allowedTools "Edit,Bash(git commit *)"`
+over the rest rather than doing all of it in one bloated session.

package/global/tools/design-md/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: design-md
+description: Create and maintain a per-project DESIGN.md that pins the ONE visual direction so UI stays consistent across sessions and screens. Use when starting UI on a project, when look feels inconsistent, or the user mentions design system / DESIGN.md / visual guidelines.
+---
+
+# DESIGN.md
+
+The fix for "UI comes out inconsistent" is a single written source of visual
+truth per project. `ui-workflow` says pick one direction — `DESIGN.md` is where
+that direction lives so every session and screen obeys the same rules.
+`forge taste <style>` writes a managed one from Forge's menu; hand-write it only
+for a bespoke direction.
+
+Create it at the start of UI work, or the first time output drifts. One file at
+repo root; reference it from the project `CLAUDE.md` (`See @DESIGN.md for visual
+rules`) so Claude loads it. Keep it tight: concrete rules and tokens, not
+adjectives — "Primary #4F46E5, 8pt spacing scale, Inter", not "modern and clean".
+
+## Template
+```markdown
+# DESIGN.md — <project>
+
+## Direction
+One sentence + 1-2 reference links/screenshots. The single aesthetic. Don't mix.
+
+## Tokens
+- Color: primary / bg / surface / text / border / success / warn / danger (hex)
+- Type: font family; scale (e.g. 12/14/16/20/24/32); weights
+- Spacing: base unit (e.g. 4px) + scale; radius; shadow levels
+- Breakpoints: mobile / tablet / desktop widths
+
+## Components
+- Library: <project components / component system> — reuse, don't hand-roll
+- Buttons/inputs/cards: variants + states (default/hover/focus/disabled) rules
+- Density, alignment, and layout grid rules
+
+## Do / Don't
+- Do: <3-5 concrete rules>
+- Don't: <3-5 concrete anti-patterns for THIS project>
+
+## Accessibility baseline
+Contrast ≥ 4.5:1 body; visible focus rings; labels on inputs; keyboard nav;
+hit targets ≥ 44px.
+
+## References
+Links to the reference site(s)/Figma this design matches.
+```
+
+## Enforce it (prose steers; the gate checks)
+Once real UI matches the direction, mint its fingerprint:
+`forge uicheck fingerprint <ui files> --mint`. Then `forge uicheck design <files>
+--taste <style>` gates new UI against the taste constraints + project fingerprint
+(a Forge-managed DESIGN.md is picked up automatically). When the user approves a
+new visual decision, update DESIGN.md and re-mint so it sticks.

package/global/tools/dev-radar/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: dev-radar
+description: Pull current, real-world software-dev signal on demand from GitHub trending, Reddit, research papers, and blogs — filtered to the user's stack, hype-filtered, with verified sources. Use when the user asks "what's new/trending", "latest in <tech>", "should I adopt X", or wants a dev digest. Coding topics only.
+disable-model-invocation: true
+---
+
+# Dev radar
+
+On-demand scan of what's actually happening in software dev right now — not
+training-data recall. Signal over noise, coding topics only.
+
+## Sources (fetch live each run)
+
+- **GitHub trending** — [https://github.com/trending?since=daily](https://github.com/trending?since=daily) | weekly | monthly
+(add `&spoken_language_code=` / language filters). Best for real traction.
+Cross-check a repo's health before recommending (last commit, releases, issues,
+license) — trending ≠ maintained.
+- **Reddit** (via WebSearch / old.reddit JSON) — r/programming, r/webdev,
+r/ExperiencedDevs, r/nextjs, r/node, r/LocalLLaMA, r/MachineLearning. Read the
+top comments, not just the headline — Reddit's value is the critique.
+- **Papers** — arXiv (cs.SE, cs.AI), Hugging Face papers (HF MCP), Context7 for
+library docs. Use for AI/ML and algorithmic topics.
+- **Blogs** — WebSearch for Medium/eng-blog posts; treat as opinion, verify claims.
+
+
+
+## Method
+
+1. Scope to the user's stack unless they widen it: Next.js/React, Node, Postgres +
+  pgvector, TypeScript, Python, LLM/agent tooling. Ignore unrelated trends.
+2. Gather from 2-3 sources in parallel; dedupe.
+3. **Hype filter** — drop "X is dead" / "just switch to Y" posts unless there's
+  real evidence (adoption, benchmarks, maintainer signal). Note the counter-view.
+4. For anything actionable, hand it to `tech-selector` before recommending adoption.
+
+
+
+## Output (dated)
+
+A short digest: **What's moving** (3-6 items: repo/paper/thread · one line · link ·
+why it matters to your stack) → **Worth a real look** (1-2, with the trade-off) →
+**Skip / hype** (things being overhyped, and why). Every claim links its source and
+states the date. End with: which items (if any) warrant a `tech-selector` pass.
+
+## Guardrails
+
+- Software/coding only — no general news.
+- Cite sources; never assert currency from memory. If a source didn't load, say so.
+- Trending is a starting signal, not a recommendation. Adoption still needs the
+fit/maintenance/license check.
+
+
+
+## Optional: recurring digest
+
+For a weekly cadence, the user can wire a scheduled run (`claude -p "/dev-radar weekly, my stack"`) via cron or their scheduler, output appended to a notes file.

package/global/tools/explore-plan-code/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: explore-plan-code
+description: Structured workflow for non-trivial features or unfamiliar code — explore, then plan, then implement, then verify. Use when a change spans multiple files, the approach is uncertain, or the user asks for a spec/plan first.
+---
+
+# Explore → Plan → Code → Verify
+
+Separate research from execution so you don't build the wrong thing.
+
+1. **Explore (read-only).** Enter plan mode or use the `scout` subagent. Read the
+   relevant files and existing patterns. Answer: where does this live, what
+   conventions apply, what will change. No edits yet.
+2. **Plan.** Produce a concrete plan naming the exact files/interfaces to touch,
+   what's out of scope, and an end-to-end verification step. For big features,
+   interview the user with `AskUserQuestion`, then write it to `SPEC.md` and start
+   a fresh session to implement against it.
+3. **Code.** Implement against the plan. Follow existing patterns; add no new deps
+   without cause.
+4. **Verify.** Run the check (tests/build/lint) and show the output. For risky
+   diffs, hand to the `verifier` subagent. Iterate until it actually passes —
+   don't assert success without evidence.
+
+Skip this whole flow for one-line or obviously-scoped fixes; the ceremony isn't
+worth it there.

package/global/tools/lean/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: lean
+description: Forge's minimalism discipline. Use for any "add X" / "build Y" / refactor / bug-fix — before writing code, to choose the smallest change that actually solves the problem. Reuse over rewrite, delete over add, boring over clever.
+---
+
+# lean — the smallest change that works
+
+The best code is the code you never write; the second best already exists in this
+repo. `lean` is a reflex applied AFTER you understand the problem, never instead of
+understanding it.
+
+## The Lean Path (stop at the first step that holds)
+1. **Need?** Does this need to exist at all? Speculative "for later" → skip it and
+   say so in one line. (YAGNI)
+2. **Here already?** A util, component, type, or pattern that already lives in this
+   repo → reuse or extend it. Look before you write.
+3. **Platform / stdlib?** The language stdlib, a native platform feature, or an
+   already-installed dependency covers it → use it. Never add a dependency for what
+   a few lines do.
+4. **One small change.** The smallest diff that fits the file's style. Fewest files.
+   Boring over clever — clever is what someone decodes at 3am.
+5. **Root, not symptom.** A report names a symptom. Fix it once in the shared
+   function all callers route through — not in each caller.
+
+## Rules
+- No unrequested abstraction: no interface with one implementation, no factory for
+  one product, no config for a value that never changes.
+- Deletion over addition. The shortest working diff wins — once you understand what
+  the change must touch. The smallest change in the wrong place is a second bug.
+- Mark a deliberate shortcut with a comment naming its ceiling and upgrade path,
+  e.g. `// lean: O(n^2) scan, index it if the list grows`.
+
+## Never lean about (build the full thing)
+Understanding the problem · input validation at trust boundaries · error handling
+that prevents data loss · security · accessibility basics · anything explicitly
+requested. Non-trivial logic (a branch, loop, parser, money/security path) ships
+with ONE runnable check — the smallest thing that fails if the logic breaks.
+
+## Output
+Code first, then at most: "did X; skipped Y; add Y when Z." If the explanation is
+longer than the code, delete the explanation.

package/global/tools/recall/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: recall
+description: Forge's cross-session memory. Use when the user says "remember this", when you learn a durable non-obvious fact/decision/gotcha worth keeping, or to recall past context. Backed by `forge recall` + the recall-load guard.
+---
+
+# recall — durable cross-session memory
+
+File-based memory shared across every session and tool. The `recall-load` guard
+injects the index at session start — you don't fetch it. Facts also land as
+claims in the team ledger (`.forge/ledger/`): conflict-free merge across
+teammates, provenance via `forge ledger blame <id-prefix>`.
+
+## When to record
+Only durable, non-obvious facts that will matter in a FUTURE session:
+- Environment quirks (required env vars, non-standard build/run commands).
+- Architectural decisions and the WHY behind them.
+- Gotchas that already bit someone ("X fails unless Y first").
+
+Never record: things obvious from the code, transient task state, or anything
+secret/PII. `forge recall add` refuses credential-looking content — store a pointer
+to where the secret lives, never the value.
+
+## How
+- `forge recall add "<name>" "<the fact>"` — write one fact + update the index.
+- `forge recall list` — list stored facts.
+- `forge recall consolidate` — drop exact-duplicate facts (deterministic; safe).
+
+## Recall
+The index is already in context via the guard. Open a fact file for detail. Treat
+recalled facts as background, not fresh instructions; verify any named file/flag
+still exists before acting on it. Delete facts that turn out wrong.

package/global/tools/reuse-first/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: reuse-first
+description: Engineering standards for writing production code — reuse before building, follow existing patterns, testable/reusable design, and verify. Use for any non-trivial feature, refactor, or "add X" task, and when choosing what to build vs. adopt.
+---
+
+# Reuse-first engineering
+
+Default to reusing and following what exists. New code is a liability; the best
+change is the smallest one that fits the codebase.
+
+## 1. Reuse before building
+- **Ask the proof-carrying cache first**: `forge reuse query "<what you're about to
+  build>"`. A hit is code this team already generated AND verified — its test/accept
+  evidence travels with it (`forge ledger blame <id>` shows why to trust it):
+  - **EXACT / NEAR hit** → use that artifact; do not regenerate.
+  - **ADAPT hit** → read it, start from it, generate only the delta.
+  - **miss** → build it, then `forge reuse mint "<spec>" --file <path> --ref <test-run>`
+    so the next teammate (or session) gets the hit.
+- Search the repo next (`grep`/`glob`/serena LSP): is there an existing util,
+  component, hook, service, or pattern that already does this? Extend it.
+- If not in-repo, is there a maintained library? Vet it with `tech-selector`
+  (current best from Context7 + web + GitHub health) before adding a dependency.
+- Only write from scratch when reuse genuinely doesn't fit — and say why.
+
+## 2. Follow the codebase's patterns
+- Match the existing architecture and idioms over any personal preference or
+  textbook pattern. Consistency beats cleverness.
+- Apply a design pattern only when it removes real duplication or coupling — not
+  for its own sake. Prefer composition over inheritance; keep modules cohesive and
+  loosely coupled; push side effects to the edges.
+
+## 3. Design for reuse + testability
+- Small, single-purpose functions with typed inputs/outputs. Separate pure logic
+  from I/O so the logic is testable without mocks.
+- No hidden globals; pass dependencies in. Name things for intent.
+
+## 4. Test
+- Write tests with the code, not after. Unit-test the pure logic; cover the edge
+  cases the task named (empty, error, boundary). Prefer real inputs over heavy
+  mocking.
+- For a bug fix, first write a failing test that reproduces it, then fix.
+
+## 5. Verify (don't assert "done")
+- Run the project's tests + typecheck + lint and show the output. UI → screenshot
+  check via `ui-workflow`. Non-trivial diff → `verifier` subagent.
+- Fix root causes; never suppress an error to make a check pass.
+
+## Per-stack starting points (verify currency with `tech-selector` before adopting)
+The dated verified baseline lives in `~/.claude/rules/stack-notes.md` (refresh via
+`/dev-radar`). Quick defaults below — treat as candidates, confirm live per use case:
+- **Web app**: Next.js (App Router) / React; SvelteKit or Astro for content-led.
+- **Styling/UI**: Tailwind + shadcn/ui (Radix) — pull real component code via the
+  shadcn MCP, don't hand-roll.
+- **Data/state**: TanStack Query for server state; Zustand for light client state.
+- **Forms/validation**: React Hook Form + Zod (Zod schemas shared client↔server).
+- **DB/ORM (Node + Postgres/pgvector)**: Drizzle or Prisma; raw SQL for hot paths.
+- **Auth**: the framework's first-party option or a maintained provider — don't
+  roll your own crypto/session logic.
+- **Testing**: Vitest (unit) + Playwright (e2e) for JS; pytest for Python.
+- **Python**: `uv` for env/deps, `ruff` (lint+format), `pydantic` for schemas.
+- **Deploy**: match the project (Vercel for Next.js; your VPS + Cloudflare for
+  Hostlelo services).
+Never present these as settled because they were popular at training time — run
+`tech-selector` and cite the version + date.

package/global/tools/self-improve/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: self-improve
+description: Self-correction and cross-session learning loop. Use when a check fails and needs iterating to green, when the user corrects the same thing more than once, or when a non-obvious fix/gotcha is worth remembering for next time.
+---
+
+# Self-improve
+
+Honest scope: you can't reinforcement-learn a hosted model's weights in a config.
+What works is **experiential learning** — correct within the session, persist
+durable lessons for the next one. Two loops:
+
+## Loop A — self-correct (within a session)
+Close the loop yourself instead of waiting for the user to catch errors:
+1. Run a check that returns pass/fail: tests, build, typecheck, lint, or a
+   screenshot diff (UI).
+2. On fail, read the actual error and diagnose the **root cause** — don't patch
+   the symptom or suppress it. Record it: `forge diagnose "<error>" --file <f>`.
+3. Fix, then re-run the same check. Show the evidence (command + result).
+4. Cap it: `forge diagnose` counts recurrences — the 3rd identical failure
+   signature mints a **diagnosis claim** in the team ledger and says STOP.
+   Don't keep retrying: state the diagnosis (`forge ledger show <id>`), add what
+   you tried, and escalate ONE model tier with the diagnosis at the head of the
+   new prompt — never a bare "try again, but more expensive". Repeated failed
+   patches pollute context and make it worse.
+Use the `verifier` / `frontend-verifier` subagents for an independent check on
+non-trivial diffs.
+
+## Loop B — capture the lesson (across sessions)
+When something was non-obvious — the user corrected you twice on the same point,
+or a fix depended on a project gotcha — record it so it's not re-learned next time:
+- Cortex captures recurring corrections on its own as you work; for explicit
+  facts, `forge recall add "<name>" "<fact>"` (or a one-line entry in the repo's
+  `AGENTS.md`).
+- Keep it a rule, not a story: "In <project>, X fails unless Y — do Y first."
+- Never store secrets/PII. Delete lessons that turn out wrong.
+Lessons and facts land as claims in `.forge/ledger/` — confidence moves only when
+independent oracles (tests, CI, human accept/revert) confirm or refute them, and
+`forge ledger blame <id>` shows that history.
+
+## What "self-evolving" honestly means here
+Code knowledge stays current via the atlas (`forge atlas build`); behaviour
+improves through Loop B, and the ledger demotes lessons that stop earning
+confirmations. Anything promising weight-level RL from a local config is
+overstating it — treat those claims with `tech-selector` skepticism.

package/global/tools/taste/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: taste
+description: Pick a visual design direction for a repo from Forge's menu (minimalist, brutalist, editorial, playful, corporate). Use when starting UI work or when the user wants a specific look. Sets DESIGN.md, which every AI tool then follows.
+---
+
+# taste — choose one design direction
+
+Forge ships a MENU of visual directions; each repo pins exactly ONE.
+
+- `forge taste` — list the available styles.
+- `forge taste <style>` — write that style's spec to this repo's `DESIGN.md`.
+
+The shared rules tell every tool to "follow DESIGN.md if present," so setting a
+taste once steers Claude Code, Cursor, Codex, Gemini, and the rest. Switch anytime
+with `forge taste <other>` (it regenerates DESIGN.md).
+
+Styles: minimalist (restraint) · brutalist (raw/high-contrast) · editorial
+(magazine/typographic) · playful (friendly/rounded) · corporate (trustworthy/AA).
+
+Each style ships machine-readable constraints: prose steers generation, but
+`forge uicheck design <files> --taste <style>` *checks* the result (style
+auto-detected from a Forge-managed DESIGN.md). Mint the project fingerprint from
+approved UI — `forge uicheck fingerprint <files> --mint` — to gate conformance too.
+
+Don't hand-edit a Forge-managed DESIGN.md — re-run `forge taste`, or delete the
+marker line to take it over yourself.

package/global/tools/tech-selector/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: tech-selector
+description: Choose a library, framework, or tool by verifying the CURRENT best option from live sources — not from training data. Use whenever picking a dependency, starting a project, or the user asks "what's the best X for Y", "latest", "which library", or wants an unbiased/current recommendation.
+---
+
+# Tech selector
+
+Training data is stale and biased toward what was popular at cutoff. For any
+"what should I use" decision, verify against live sources before recommending.
+
+## Verify before recommending (don't skip)
+1. **Docs (Context7 MCP)** — `resolve-library-id` then `get-library-docs` for the
+   candidates. Confirms the API is current and the library still exists.
+2. **Web search** — "<use-case> best library <current year>", release notes,
+   "X vs Y". Look for recency; ignore posts older than ~18 months unless canonical.
+3. **GitHub health** (via `gh` or GitHub MCP) — for each finalist check:
+   last commit date, release cadence, open-vs-closed issue ratio, maintainer
+   count, and license. A popular-but-abandoned repo is a trap.
+
+## Decision rubric (fit first, not stars)
+Score finalists on: **fit** to the actual use case > **maintenance** (active,
+recent releases) > **license** compatibility > **DX / docs quality** > **bundle
+/ runtime cost** > **ecosystem & types** > popularity. Popularity breaks ties, it
+doesn't win them.
+
+## Anti-bias rules
+- Don't default to the framework you "know" — name ≥2 real alternatives and say
+  why the pick wins for *this* case.
+- Prefer what the project already uses over introducing a new dependency.
+- State the date of the evidence and the version you verified. If you couldn't
+  verify, say so — don't assert currency from memory.
+
+## Output
+A short table: option · fit · maintenance (last release) · license · why/why-not,
+then a one-line pick with the specific version and the trade-off you accepted.

package/global/tools/ui-workflow/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: ui-workflow
+description: Reliable workflow for building or fixing UI so results look intentional, not generic. Use for any frontend/UI task — new screen, component, redesign, "make it look better", layout, styling, or when the user says UI is the pain point.
+---
+
+# UI workflow
+
+UI is unreliable when taste is vague and there's no check. Fix both: lock ONE
+visual direction, build on the project's real components, then verify with the
+deterministic design gate and a screenshot instead of guessing.
+
+## 0. Pick ONE direction — don't stack taste sources
+Competing taste/design skills produce muddy, inconsistent output. Per project,
+choose **one** source of visual truth: the repo's `DESIGN.md` (create it with
+`forge taste <style>` or the `design-md` tool), or a reference URL/screenshot
+from the user. If none exists, ask.
+
+## 1. Ground the components (current APIs, not memory)
+- Reuse the project's existing components and design tokens first —
+  `forge atlas query <Component>` finds them.
+- Confirm any library's props/API against current docs, not recall; vet new
+  dependencies with `tech-selector`.
+
+## 2. Build
+- Match the project's stack and component system over bespoke CSS.
+- Accessibility is not optional: labels, focus states, contrast, keyboard nav.
+
+## 3. Verify (the step that makes UI reliable)
+- **Deterministic gate first:** `forge uicheck design <files> --taste <style>`
+  (exit 1 on fail) — slop distance to generic templates must stay HIGH,
+  conformance to the project's minted fingerprint must stay LOW, spacing/radius/
+  shadow on scale. Failures are per-feature edits, not a score. If the repo has
+  no fingerprint yet, mint one from approved UI:
+  `forge uicheck fingerprint <files> --mint`.
+- `forge uicheck contrast <fg> <bg>` for exact WCAG math — never eyeball it.
+- **Then screenshot:** render at desktop AND mobile widths, compare against the
+  reference/DESIGN.md, list concrete differences (spacing, hierarchy, color,
+  alignment) and fix. For a second opinion, hand the screenshot + reference to
+  the `frontend-verifier` subagent.
+
+## Done =
+Passes `forge uicheck design`, matches the reference at both breakpoints, passes
+accessibility checks, uses the project's tokens/components, and you've shown the
+final screenshot as evidence.

package/hooks/hooks.json

@@ -0,0 +1,107 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup|resume|clear",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/recall-load.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh session-start"
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh prompt"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh preflight"
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write|MultiEdit|Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/protect-paths.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cost-budget.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/doom-loop.sh"
+          }
+        ]
+      },
+      {
+        "matcher": "Edit|Write|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh pre-edit"
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/format-on-edit.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh capture"
+          }
+        ]
+      },
+      {
+        "matcher": "Bash|Read|Grep",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/secret-redact.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh capture"
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/lean-guard.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/session-learner.sh"
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}\"/global/guards/cortex.sh stop"
+          }
+        ]
+      }
+    ]
+  }
+}