@baselane/packs 0.1.0

package/packs/second-brain/rendered/.baselane/memory/README.md

@@ -0,0 +1,34 @@
+# Memory protocol
+
+This directory holds durable facts the AI has learned while working on this project —
+one fact per file, plus an index. Consult the index before acting; add a fact after
+learning something durable (a decision, a correction, a constraint that isn't obvious
+from the code).
+
+## Format
+
+Each fact is a single markdown file with simple frontmatter:
+
+```markdown
+---
+name: <short-kebab-case-slug>
+description: <one-line summary — used to decide relevance during recall>
+---
+
+<the fact, in a sentence or two.>
+```
+
+## Index
+
+`MEMORY.md` in this directory lists every fact, one line per file, so the index alone
+can be scanned without opening each one:
+
+```markdown
+- [Title](file.md) — one-line hook
+```
+
+## Rule
+
+- Consult `MEMORY.md` before acting — recall what's already known.
+- After learning something durable, write a new fact file and add a line to
+  `MEMORY.md`. Use `/remember <fact>` to do both in one step.

package/packs/second-brain/rendered/.baselane/wiki/README.md

@@ -0,0 +1,62 @@
+# Wiki protocol
+
+This directory is a durable knowledge base the AI reads before acting and writes after
+learning — one concept per file, plus an index and a change log, following the Karpathy
+"LLM Wiki" pattern of ingest/query/lint.
+
+This wiki is Open Knowledge Format (OKF) compliant — any OKF-reading agent can consume it.
+
+## Format (OKF)
+
+Each page is a single markdown file with YAML frontmatter, one concept per file:
+
+```markdown
+---
+type: How-it-works
+title: <optional title>
+description: <optional one-line summary>
+resource: <optional URI to an external system>
+tags: [optional, list, of, tags]
+timestamp: <optional ISO 8601 timestamp>
+---
+
+<free-form markdown body>
+```
+
+`type` is the only required frontmatter field — a free-form string naming what kind of
+page this is (e.g. `How-it-works`, `Runbook`, `Decision`, `Gotcha`). Everything else in
+the frontmatter is optional; the body below it is unconstrained markdown.
+
+## Reserved files
+
+- `index.md` — navigation. One line per page, link plus a one-line summary:
+
+  ```markdown
+  - [Title](page.md) — one-line summary of what this page covers
+  ```
+
+- `log.md` — append-only change log. One entry per change, parseable prefix:
+
+  ```markdown
+  ## [YYYY-MM-DD] <operation> | <subject>
+  ```
+
+  where `<operation>` is one of `ingest`, `query`, `lint`, and `<subject>` names the
+  page(s) touched. Never rewrite a line once it's appended — only add new ones.
+
+## Operations
+
+- **Ingest** — when you learn something durable, create or update the relevant page(s):
+  update cross-links in related pages, add or update its `index.md` line, and append a
+  `log.md` entry.
+- **Query** — read `index.md` first, then the relevant pages, BEFORE acting. When
+  answering required real synthesis rather than a lookup, save the result as a new page —
+  explorations compound instead of being redone.
+- **Lint** — periodically, and via `/wiki lint`, check for: contradictions between pages,
+  stale claims, orphan pages missing from `index.md`, and broken cross-links. Reconcile
+  contradictions rather than letting them coexist — corrections beat additions.
+
+## The loop rule
+
+Read before acting. Write after learning. The tedious part is the bookkeeping — that's
+your job, not the human's.

package/packs/second-brain/rendered/.claude/agents/librarian.md

@@ -0,0 +1,14 @@
+---
+name: librarian
+description: Knowledge-base keeper: ingests durable knowledge into the OKF wiki and memory, and lints them for contradictions, stale claims, orphan pages, and broken cross-links.
+tools: Read, Grep, Glob, Edit, Write
+model: sonnet
+---
+
+You are the librarian for this project's second brain (`.baselane/wiki/` and `.baselane/memory/`). You have two jobs.
+
+(1) Ingest. When the session learned something durable — an architectural fact, a decision, a gotcha, a correction — record it. Project knowledge goes in the OKF wiki (`.baselane/wiki/`: one concept per file with a `type` frontmatter field, plus its `index.md` line and a `log.md` entry). A durable one-line fact goes in memory (`.baselane/memory/`, with its `MEMORY.md` line). Follow the protocol in each directory's README.
+
+(2) Lint. On request (or via `/wiki lint`), scan every wiki page and memory fact for contradictions between pages, stale claims, pages missing from the index, and broken cross-links. Reconcile contradictions rather than letting them coexist — corrections beat additions.
+
+Always read `index.md` and `MEMORY.md` before acting. Never fabricate a page or a fact; only record what the work actually established. Keep the bookkeeping — the index and log lines — current; that is your job, not the human's.

package/packs/second-brain/rendered/.claude/commands/remember.md

@@ -0,0 +1,6 @@
+---
+description: Append a durable fact to .baselane/memory/ and update its index.
+argument-hint: <fact>
+---
+
+Write $ARGUMENTS as a new fact file under `.baselane/memory/` (kebab-case name, frontmatter with `name` and `description`, then the fact itself). Then add a one-line entry for it to `.baselane/memory/MEMORY.md` (create the index if it doesn't exist yet). Keep the fact to one durable, non-obvious sentence or two.

package/packs/second-brain/rendered/.claude/commands/wiki.md

@@ -0,0 +1,6 @@
+---
+description: Look up a topic, record or update one, or run a lint pass over the wiki.
+argument-hint: <topic to look up | fact to record | "lint">
+---
+
+Follow the wiki protocol in `.baselane/wiki/README.md` (or `wiki/README.md`) for $ARGUMENTS. If this is a lookup, read `index.md` first, then the relevant page(s), before answering — if the answer required real synthesis, save it as a new page. If this is new or changed durable knowledge, create or update the relevant page (OKF frontmatter with at least `type`), update cross-links, add or update its `index.md` line, and append a `log.md` entry. If $ARGUMENTS is "lint" (or empty), scan every page for contradictions, stale claims, orphan pages missing from the index, and broken cross-links — reconcile contradictions rather than leaving them, since corrections beat additions.

package/packs/second-brain/rendered/.claude/settings.json

@@ -0,0 +1,35 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Recall the second brain before acting: read .baselane/wiki/index.md and .baselane/memory/MEMORY.md first — the answer may already be written down.\""
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Before finishing, capture any durable decisions or facts from this session to .baselane/memory/ (use /remember) and update its MEMORY.md index.\""
+          }
+        ]
+      },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Before finishing, if you changed how something works, update the wiki entry (and its index.md/log.md lines) — see .baselane/wiki/README.md.\""
+          }
+        ]
+      }
+    ]
+  }
+}

package/packs/second-brain/rendered/.github/copilot-instructions.md

@@ -0,0 +1,24 @@
+# Copilot instructions
+
+## Second brain (OKF wiki + memory)
+
+This project keeps a durable second brain the AI reads before acting and writes after learning:
+
+- `.baselane/wiki/` — an Open Knowledge Format (OKF) knowledge base for project knowledge: architecture, decisions, gotchas, runbooks. One concept per file (with a `type` frontmatter field), plus an `index.md` and an append-only `log.md`.
+- `.baselane/memory/` — durable one-line facts (decisions, corrections, non-obvious constraints), indexed by `MEMORY.md`.
+
+Read `index.md` and `MEMORY.md` before acting — recall what's already known rather than re-deriving it. After learning something durable, ingest it (a wiki page or a memory fact) together with its index and log lines. Corrections beat additions: reconcile contradictions rather than letting them pile up. Use `/wiki` and `/remember` for one-step capture; the `librarian` subagent handles the bookkeeping and periodic lint.
+
+## Workflow pack: Second Brain (OKF)
+
+A durable second brain for every repo and laptop: an Open Knowledge Format (OKF) wiki for project knowledge — architecture, decisions, gotchas, runbooks — plus a memory store of durable one-line facts, maintained by a librarian subagent that ingests what the team learns and lints for contradictions. The discipline is read-before-acting and write-after-learning, and the AI keeps the bookkeeping, not you. Built on the Karpathy "LLM Wiki" ingest/query/lint loop and Google's Open Knowledge Format. It ships the format and the habit, not pre-filled content — the brain accumulates as the team works.
+
+When acting as the librarian role: You are the librarian for this project's second brain (`.baselane/wiki/` and `.baselane/memory/`). You have two jobs.
+
+(1) Ingest. When the session learned something durable — an architectural fact, a decision, a gotcha, a correction — record it. Project knowledge goes in the OKF wiki (`.baselane/wiki/`: one concept per file with a `type` frontmatter field, plus its `index.md` line and a `log.md` entry). A durable one-line fact goes in memory (`.baselane/memory/`, with its `MEMORY.md` line). Follow the protocol in each directory's README.
+
+(2) Lint. On request (or via `/wiki lint`), scan every wiki page and memory fact for contradictions between pages, stale claims, pages missing from the index, and broken cross-links. Reconcile contradictions rather than letting them coexist — corrections beat additions.
+
+Always read `index.md` and `MEMORY.md` before acting. Never fabricate a page or a fact; only record what the work actually established. Keep the bookkeeping — the index and log lines — current; that is your job, not the human's.
+
+- Recall the second brain before acting: read .baselane/wiki/index.md and .baselane/memory/MEMORY.md first — the answer may already be written down.

package/packs/second-brain/rendered/AGENTS.md

@@ -0,0 +1,41 @@
+# AGENTS.md
+
+<!-- generated from workflow-pack second-brain v1.0.0 -->
+
+## Second brain (OKF wiki + memory)
+
+This project keeps a durable second brain the AI reads before acting and writes after learning:
+
+- `.baselane/wiki/` — an Open Knowledge Format (OKF) knowledge base for project knowledge: architecture, decisions, gotchas, runbooks. One concept per file (with a `type` frontmatter field), plus an `index.md` and an append-only `log.md`.
+- `.baselane/memory/` — durable one-line facts (decisions, corrections, non-obvious constraints), indexed by `MEMORY.md`.
+
+Read `index.md` and `MEMORY.md` before acting — recall what's already known rather than re-deriving it. After learning something durable, ingest it (a wiki page or a memory fact) together with its index and log lines. Corrections beat additions: reconcile contradictions rather than letting them pile up. Use `/wiki` and `/remember` for one-step capture; the `librarian` subagent handles the bookkeeping and periodic lint.
+
+## Harness capabilities
+
+- wiki · repo · baselane — provisioned
+- wiki · org · baselane — provisioned
+- memory · repo · files — provisioned
+- memory · org · files — provisioned
+
+### Memory
+
+Consult `.baselane/memory/` and its `MEMORY.md` index before acting — it holds durable facts from past sessions. Use `/remember` to add one after learning something durable.
+
+### Wiki
+
+`.baselane/wiki/` is an OKF-compliant knowledge base: read `index.md` and the relevant pages before acting, and ingest new durable knowledge into a page (with its index and log lines) after learning it. Use `/wiki` to look up, record, or lint.
+
+## Workflow pack: Second Brain (OKF)
+
+A durable second brain for every repo and laptop: an Open Knowledge Format (OKF) wiki for project knowledge — architecture, decisions, gotchas, runbooks — plus a memory store of durable one-line facts, maintained by a librarian subagent that ingests what the team learns and lints for contradictions. The discipline is read-before-acting and write-after-learning, and the AI keeps the bookkeeping, not you. Built on the Karpathy "LLM Wiki" ingest/query/lint loop and Google's Open Knowledge Format. It ships the format and the habit, not pre-filled content — the brain accumulates as the team works.
+
+### Roles
+
+- **librarian** — Knowledge-base keeper: ingests durable knowledge into the OKF wiki and memory, and lints them for contradictions, stale claims, orphan pages, and broken cross-links.
+
+### Guardrails
+
+- At session start, recall the second brain before acting.
+
+Tool-specific implementations live alongside this file (see `CLAUDE.md` for the Claude Code implementation). Tools without a native subagent/command surface should treat the sections above as operating instructions.

package/packs/second-brain/rendered/CLAUDE.md

@@ -0,0 +1,9 @@
+# CLAUDE.md
+
+@AGENTS.md
+
+This project defines a native Claude Code implementation of this workflow pack:
+- Subagent: `.claude/agents/librarian.md`
+- Command: `.claude/commands/remember.md`
+- Command: `.claude/commands/wiki.md`
+- Hooks: see `.claude/settings.json`

package/packs/second-brain/rendered/GEMINI.md

@@ -0,0 +1,3 @@
+# GEMINI.md
+
+@AGENTS.md

package/packs/security-review/pack.json

@@ -0,0 +1,72 @@
+{
+  "$schema": "https://baselane.dev/schema/workflow-pack-v1.json",
+  "id": "security-review",
+  "version": "2.0.0",
+  "title": "Security review",
+  "summary": "A 4-layer pre-deploy security audit (secrets, authentication, input validation, data access) with per-layer prompts and a scan toolkit, a reviewer role, a /security-scan diff check, a /security-audit pre-deploy pass, a pre-ship Stop-hook reminder, and baseline security rules for every endpoint — flags real vulnerabilities with severity and file:line, not theater.",
+  "scope": "repo",
+  "attribution": { "source": "affaan-m/ECC", "url": "https://github.com/affaan-m/ECC", "license": "MIT" },
+  "context": {
+    "markdown": "## Security review discipline\n\nRun this against any code that handles user input, authentication, API endpoints, or sensitive data — before it reaches production.\n\n### Security rules (apply to every endpoint, always)\n\n- Never hardcode secrets — read them from environment variables (or a secret manager) and fail fast at startup if a required one is missing.\n- Use parameterized queries — never build a query by concatenating a user value into a string.\n- Every endpoint verifies authentication and authorization server-side; the client hiding a button is not access control.\n- Every data query filters by the authenticated user's own id (or explicitly checks an admin role) — never trust a client-supplied id.\n- Validate all input server-side against a schema — client-side validation alone is not validation.\n- Return generic error messages to the client; log full detail server-side only.\n- Rate-limit authentication endpoints.\n- Enable row-level security (RLS) by default on any database that supports it.\n- Set secure cookie flags — `httpOnly`, `secure`, `sameSite` — on every session cookie.\n\n### Checklist\n\n- **Injection** — Validate every external or untrusted input at the boundary before it reaches business logic; fail fast with a clear message. Are queries parameterized? Is user input ever concatenated into a query, shell command, or template string?\n- **Authorization** — Is every route/mutation checked for auth, not just authentication? Is access scoped to the resource owner, not just \"logged in\"?\n- **Secrets** — Never hardcode secrets — read them from environment variables and fail fast at startup if a required one is missing. Any hardcoded API key, password, token, or connection string in source?\n- **Unsafe deserialization** — Is untrusted input ever passed to `eval`, a pickle/deserialize call, or a dynamic `require`/`import` without validation?\n- **SSRF** — Does the server ever fetch a URL supplied by the user? If so, is the destination allow-listed, not just \"looks like a URL\"?\n- **XSS** — Is user content ever rendered as raw HTML (`innerHTML`, `dangerouslySetInnerHTML`) without sanitization?\n- **Logging** — Do logs ever include a password, token, or full PII record?\n\n### Severity\n\nHardcoded secrets, injection, and auth bypass are CRITICAL — block merge. XSS and SSRF without an allow-list are HIGH. Missing rate limiting or verbose error messages are MEDIUM.\n\n### False positives to skip\n\n`.env.example` placeholders, clearly-marked test credentials, and public API keys meant to be public are not findings — verify context before flagging.\n"
+  },
+  "skills": [
+    {
+      "name": "security-audit",
+      "description": "Run the 4-layer pre-deploy security pass (secrets, authentication, input validation, data access) before shipping code that touches user input, auth, an endpoint, or a database query.",
+      "category": "review",
+      "body": "# Security audit: the 4-layer pre-deploy pass\n\nRun this before shipping any change that touches user input, authentication, an API endpoint, or a database query. It exists because most vibe-coded security incidents come from three repeat failure modes: a committed API key (in git history or a client bundle), an endpoint the server never actually checks auth on (the client just hides the button — `GET /api/invoices/43` returns someone else's invoice), and a hand-built SQL string. All three are caught by asking specific questions in order, not by \"looking for bugs\" in general.\n\nWork through all four layers. Each has an audit prompt — answer it against the actual code, not in the abstract.\n\n## Layer 1 — Secrets\n\n**Audit prompt:** Scan the current diff and git history for hardcoded API keys, passwords, tokens, or connection strings. Is every secret read from an environment variable (or a secret manager), never a literal in source? Does startup fail fast with a clear error if a required secret is missing?\n\n**Run:** `gitleaks detect` (finds secrets already in git history) and, if a match turns up, `trufflehog` to verify the secret is still active before treating it as a false positive.\n\n## Layer 2 — Authentication\n\n**Audit prompt:** For every route and mutation, does the *server* check authentication and authorization — not just the client hiding a button? For every resource-scoped endpoint, is access scoped to the resource's owner, not just \"any logged-in user\" (the BOLA/IDOR check — `GET /api/invoices/43` must 403/404 for anyone but the invoice's owner or an explicit admin)?\n\n## Layer 3 — Input validation\n\n**Audit prompt:** Is every external or untrusted input validated server-side against a schema before it reaches business logic — not only in the client? Are queries parameterized (never a user value concatenated into SQL, a shell command, or a template string)? Do file uploads have a size limit, and do auth endpoints have rate limiting?\n\n## Layer 4 — Data access\n\n**Audit prompt:** Does every data query filter by the authenticated user's own id (or explicitly check an admin role for cross-user access), instead of trusting a client-supplied id? Do error responses returned to the client stay generic (no stack trace, no internal detail) while the full context is logged server-side? Where the schema supports it, is deletion a soft delete rather than an irreversible hard delete?\n\n## Toolkit\n\nRun what's installed; note what isn't so a human can decide whether to install it.\n\n| Tool | Layer | What it checks |\n| --- | --- | --- |\n| `gitleaks detect` | 1 | secrets already committed to git history |\n| `trufflehog` | 1 | verifies a found secret is still live before you page anyone |\n| `npm audit` / `pip-audit` | 3 | known-vulnerable dependencies |\n| `semgrep --config auto` | 3–4 | static analysis for injection, unsafe patterns |\n| GitHub Secret Scanning + Push Protection | 1 | blocks a secret from ever reaching the remote |\n\n## Severity\n\nHardcoded secrets, injection, and an auth bypass are CRITICAL — block the release. A BOLA/IDOR gap or an un-rate-limited auth endpoint is HIGH. A verbose error message or a missing rate limit is MEDIUM. Report every finding with file:line, not a vague \"looks risky.\"\n"
+    },
+    {
+      "name": "validate-at-boundaries",
+      "description": "Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.",
+      "body": "# Validate at boundaries\n\nEvery place external data enters your system is a boundary: an HTTP handler, a file read, an API\nresponse, an environment variable, a queue message. **Validate at the boundary, before the data\nreaches any logic that assumes it is well-formed.** Inside the boundary, the value is trusted because\nyou already checked it — not because you hope it is right.\n\n```ts\n// At the boundary: parse into a known shape, or reject.\nconst parsed = OrderSchema.parse(await req.json()); // throws on bad shape\ncreateOrder(parsed);                                 // inner code trusts `parsed`\n```\n\n## Rules\n\n- **One validator is the authority for each shape.** Route every entry point for that shape through\n  it — built-in, user-supplied, or machine-generated. Never hand-construct or trust an unvalidated\n  object further in.\n- **Fail fast, name the field.** Reject the whole input on the first violation with a message that\n  says which field was wrong and why. A vague \"invalid input\" costs the caller a debugging session.\n- **Parse, don't just check.** Return a typed value from validation so downstream code carries the\n  guarantee in its types, not just in a comment.\n- **Never trust \"internal\" data blindly.** An API response or a sibling service's payload is external\n  to your module even if it's inside your company — validate it the same way.\n\n## Why\n\nUnvalidated data that flows inward turns a boundary problem into a deep-stack mystery: the crash\nhappens three layers down, far from the malformed input that caused it. Validation at the edge keeps\nthe failure where the bad data actually entered, where the error message can still be specific.\n\n## Boundaries to cover\n\nHTTP request bodies and query params · file and config contents · third-party API responses ·\nenvironment variables (validate presence and format at startup) · deserialized messages/events ·\nanything read from a store you did not just write in the same transaction.\n",
+      "category": "review"
+    }
+  ],
+  "agents": [
+    {
+      "name": "security-reviewer",
+      "description": "Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS) with severity and file:line. Use after writing code that touches user input, auth, or sensitive data, and before any release.",
+      "tools": ["Read", "Grep", "Glob", "Bash"],
+      "model": "sonnet",
+      "prompt": "You are a security reviewer. Read the changed code and check it against the security-review checklist in context: injection, authorization, hardcoded secrets, unsafe deserialization, SSRF, XSS, and sensitive-data logging. For each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give severity (CRITICAL/HIGH/MEDIUM). Skip findings you cannot point to in the code — do not manufacture issues to look thorough. If nothing is exploitable, say so and approve."
+    }
+  ],
+  "commands": [
+    {
+      "name": "security-scan",
+      "description": "Run the security-reviewer over the current changes and report findings by severity.",
+      "argument_hint": "[optional: path or diff ref]",
+      "prompt": "Invoke the security-reviewer subagent over the current diff (or $ARGUMENTS if given). Report findings grouped by severity (CRITICAL, HIGH, MEDIUM) with file:line and fix for each. End with a verdict: approve, or block until CRITICAL/HIGH issues are fixed."
+    },
+    {
+      "name": "security-audit",
+      "description": "Run the security-audit skill's 4-layer pre-deploy pass (secrets, authentication, input validation, data access) and report findings by layer and severity.",
+      "argument_hint": "[optional: path or diff ref]",
+      "prompt": "Run the security-audit skill's 4-layer pass over the current diff (or $ARGUMENTS if given): secrets, authentication, input validation, data access. For each layer, run the relevant toolkit command when it's installed (gitleaks, trufflehog, npm audit / pip-audit, semgrep --config auto) and answer that layer's audit prompt against the actual code. Report findings grouped by layer with file:line and severity (CRITICAL/HIGH/MEDIUM). End with a verdict: safe to ship, or block until CRITICAL/HIGH issues are fixed."
+    }
+  ],
+  "hooks": [
+    {
+      "event": "PostToolUse",
+      "matcher": "Edit|Write",
+      "description": "Remind to check untrusted input at trust boundaries whenever code is edited.",
+      "action": "print-reminder",
+      "message": "Security check: any user input, external fetch, or deserialized data crossing a trust boundary here? Validate it before it's used."
+    },
+    {
+      "event": "PostToolUse",
+      "matcher": "Edit|Write",
+      "description": "After an edit, scan the working tree for committed secrets with gitleaks when it is installed.",
+      "action": "run-command",
+      "command": "if command -v gitleaks >/dev/null 2>&1; then gitleaks detect --no-git --no-banner --redact; else echo \"gitleaks not found — install gitleaks to scan for secrets (security-review)\"; fi"
+    },
+    {
+      "event": "Stop",
+      "matcher": "",
+      "description": "Before ending the session, run the pre-deploy security toolkit and remind to run /security-audit before shipping.",
+      "action": "run-command",
+      "command": "if command -v gitleaks >/dev/null 2>&1; then gitleaks detect --no-git --no-banner --redact; else echo \"gitleaks not found — install to scan for committed secrets (security-audit layer 1)\"; fi; if command -v semgrep >/dev/null 2>&1; then semgrep --config auto --quiet; else echo \"semgrep not found — install for static analysis (security-audit layers 3-4)\"; fi; echo \"Pre-ship reminder: run /security-audit for the full 4-layer review (secrets, auth, input validation, data access) before deploying.\""
+    }
+  ]
+}

package/packs/security-review/rendered/.claude/agents/security-reviewer.md

@@ -0,0 +1,8 @@
+---
+name: security-reviewer
+description: Flags real vulnerabilities (injection, authz gaps, secrets, unsafe deserialization, SSRF, XSS) with severity and file:line. Use after writing code that touches user input, auth, or sensitive data, and before any release.
+tools: Read, Grep, Glob, Bash
+model: sonnet
+---
+
+You are a security reviewer. Read the changed code and check it against the security-review checklist in context: injection, authorization, hardcoded secrets, unsafe deserialization, SSRF, XSS, and sensitive-data logging. For each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give severity (CRITICAL/HIGH/MEDIUM). Skip findings you cannot point to in the code — do not manufacture issues to look thorough. If nothing is exploitable, say so and approve.

package/packs/security-review/rendered/.claude/commands/security-audit.md

@@ -0,0 +1,6 @@
+---
+description: Run the security-audit skill's 4-layer pre-deploy pass (secrets, authentication, input validation, data access) and report findings by layer and severity.
+argument-hint: [optional: path or diff ref]
+---
+
+Run the security-audit skill's 4-layer pass over the current diff (or $ARGUMENTS if given): secrets, authentication, input validation, data access. For each layer, run the relevant toolkit command when it's installed (gitleaks, trufflehog, npm audit / pip-audit, semgrep --config auto) and answer that layer's audit prompt against the actual code. Report findings grouped by layer with file:line and severity (CRITICAL/HIGH/MEDIUM). End with a verdict: safe to ship, or block until CRITICAL/HIGH issues are fixed.

package/packs/security-review/rendered/.claude/commands/security-scan.md

@@ -0,0 +1,6 @@
+---
+description: Run the security-reviewer over the current changes and report findings by severity.
+argument-hint: [optional: path or diff ref]
+---
+
+Invoke the security-reviewer subagent over the current diff (or $ARGUMENTS if given). Report findings grouped by severity (CRITICAL, HIGH, MEDIUM) with file:line and fix for each. End with a verdict: approve, or block until CRITICAL/HIGH issues are fixed.

package/packs/security-review/rendered/.claude/settings.json

@@ -0,0 +1,35 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo \"Security check: any user input, external fetch, or deserialized data crossing a trust boundary here? Validate it before it's used.\""
+          }
+        ]
+      },
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "if command -v gitleaks >/dev/null 2>&1; then gitleaks detect --no-git --no-banner --redact; else echo \"gitleaks not found — install gitleaks to scan for secrets (security-review)\"; fi"
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "if command -v gitleaks >/dev/null 2>&1; then gitleaks detect --no-git --no-banner --redact; else echo \"gitleaks not found — install to scan for committed secrets (security-audit layer 1)\"; fi; if command -v semgrep >/dev/null 2>&1; then semgrep --config auto --quiet; else echo \"semgrep not found — install for static analysis (security-audit layers 3-4)\"; fi; echo \"Pre-ship reminder: run /security-audit for the full 4-layer review (secrets, auth, input validation, data access) before deploying.\""
+          }
+        ]
+      }
+    ]
+  }
+}

package/packs/security-review/rendered/.claude/skills/security-audit/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: security-audit
+description: Run the 4-layer pre-deploy security pass (secrets, authentication, input validation, data access) before shipping code that touches user input, auth, an endpoint, or a database query.
+---
+
+# Security audit: the 4-layer pre-deploy pass
+
+Run this before shipping any change that touches user input, authentication, an API endpoint, or a database query. It exists because most vibe-coded security incidents come from three repeat failure modes: a committed API key (in git history or a client bundle), an endpoint the server never actually checks auth on (the client just hides the button — `GET /api/invoices/43` returns someone else's invoice), and a hand-built SQL string. All three are caught by asking specific questions in order, not by "looking for bugs" in general.
+
+Work through all four layers. Each has an audit prompt — answer it against the actual code, not in the abstract.
+
+## Layer 1 — Secrets
+
+**Audit prompt:** Scan the current diff and git history for hardcoded API keys, passwords, tokens, or connection strings. Is every secret read from an environment variable (or a secret manager), never a literal in source? Does startup fail fast with a clear error if a required secret is missing?
+
+**Run:** `gitleaks detect` (finds secrets already in git history) and, if a match turns up, `trufflehog` to verify the secret is still active before treating it as a false positive.
+
+## Layer 2 — Authentication
+
+**Audit prompt:** For every route and mutation, does the *server* check authentication and authorization — not just the client hiding a button? For every resource-scoped endpoint, is access scoped to the resource's owner, not just "any logged-in user" (the BOLA/IDOR check — `GET /api/invoices/43` must 403/404 for anyone but the invoice's owner or an explicit admin)?
+
+## Layer 3 — Input validation
+
+**Audit prompt:** Is every external or untrusted input validated server-side against a schema before it reaches business logic — not only in the client? Are queries parameterized (never a user value concatenated into SQL, a shell command, or a template string)? Do file uploads have a size limit, and do auth endpoints have rate limiting?
+
+## Layer 4 — Data access
+
+**Audit prompt:** Does every data query filter by the authenticated user's own id (or explicitly check an admin role for cross-user access), instead of trusting a client-supplied id? Do error responses returned to the client stay generic (no stack trace, no internal detail) while the full context is logged server-side? Where the schema supports it, is deletion a soft delete rather than an irreversible hard delete?
+
+## Toolkit
+
+Run what's installed; note what isn't so a human can decide whether to install it.
+
+| Tool | Layer | What it checks |
+| --- | --- | --- |
+| `gitleaks detect` | 1 | secrets already committed to git history |
+| `trufflehog` | 1 | verifies a found secret is still live before you page anyone |
+| `npm audit` / `pip-audit` | 3 | known-vulnerable dependencies |
+| `semgrep --config auto` | 3–4 | static analysis for injection, unsafe patterns |
+| GitHub Secret Scanning + Push Protection | 1 | blocks a secret from ever reaching the remote |
+
+## Severity
+
+Hardcoded secrets, injection, and an auth bypass are CRITICAL — block the release. A BOLA/IDOR gap or an un-rate-limited auth endpoint is HIGH. A verbose error message or a missing rate limit is MEDIUM. Report every finding with file:line, not a vague "looks risky."

package/packs/security-review/rendered/.claude/skills/validate-at-boundaries/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: validate-at-boundaries
+description: Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.
+---
+
+# Validate at boundaries
+
+Every place external data enters your system is a boundary: an HTTP handler, a file read, an API
+response, an environment variable, a queue message. **Validate at the boundary, before the data
+reaches any logic that assumes it is well-formed.** Inside the boundary, the value is trusted because
+you already checked it — not because you hope it is right.
+
+```ts
+// At the boundary: parse into a known shape, or reject.
+const parsed = OrderSchema.parse(await req.json()); // throws on bad shape
+createOrder(parsed);                                 // inner code trusts `parsed`
+```
+
+## Rules
+
+- **One validator is the authority for each shape.** Route every entry point for that shape through
+  it — built-in, user-supplied, or machine-generated. Never hand-construct or trust an unvalidated
+  object further in.
+- **Fail fast, name the field.** Reject the whole input on the first violation with a message that
+  says which field was wrong and why. A vague "invalid input" costs the caller a debugging session.
+- **Parse, don't just check.** Return a typed value from validation so downstream code carries the
+  guarantee in its types, not just in a comment.
+- **Never trust "internal" data blindly.** An API response or a sibling service's payload is external
+  to your module even if it's inside your company — validate it the same way.
+
+## Why
+
+Unvalidated data that flows inward turns a boundary problem into a deep-stack mystery: the crash
+happens three layers down, far from the malformed input that caused it. Validation at the edge keeps
+the failure where the bad data actually entered, where the error message can still be specific.
+
+## Boundaries to cover
+
+HTTP request bodies and query params · file and config contents · third-party API responses ·
+environment variables (validate presence and format at startup) · deserialized messages/events ·
+anything read from a store you did not just write in the same transaction.

package/packs/security-review/rendered/.github/copilot-instructions.md

@@ -0,0 +1,137 @@
+# Copilot instructions
+
+## Security review discipline
+
+Run this against any code that handles user input, authentication, API endpoints, or sensitive data — before it reaches production.
+
+### Security rules (apply to every endpoint, always)
+
+- Never hardcode secrets — read them from environment variables (or a secret manager) and fail fast at startup if a required one is missing.
+- Use parameterized queries — never build a query by concatenating a user value into a string.
+- Every endpoint verifies authentication and authorization server-side; the client hiding a button is not access control.
+- Every data query filters by the authenticated user's own id (or explicitly checks an admin role) — never trust a client-supplied id.
+- Validate all input server-side against a schema — client-side validation alone is not validation.
+- Return generic error messages to the client; log full detail server-side only.
+- Rate-limit authentication endpoints.
+- Enable row-level security (RLS) by default on any database that supports it.
+- Set secure cookie flags — `httpOnly`, `secure`, `sameSite` — on every session cookie.
+
+### Checklist
+
+- **Injection** — Validate every external or untrusted input at the boundary before it reaches business logic; fail fast with a clear message. Are queries parameterized? Is user input ever concatenated into a query, shell command, or template string?
+- **Authorization** — Is every route/mutation checked for auth, not just authentication? Is access scoped to the resource owner, not just "logged in"?
+- **Secrets** — Never hardcode secrets — read them from environment variables and fail fast at startup if a required one is missing. Any hardcoded API key, password, token, or connection string in source?
+- **Unsafe deserialization** — Is untrusted input ever passed to `eval`, a pickle/deserialize call, or a dynamic `require`/`import` without validation?
+- **SSRF** — Does the server ever fetch a URL supplied by the user? If so, is the destination allow-listed, not just "looks like a URL"?
+- **XSS** — Is user content ever rendered as raw HTML (`innerHTML`, `dangerouslySetInnerHTML`) without sanitization?
+- **Logging** — Do logs ever include a password, token, or full PII record?
+
+### Severity
+
+Hardcoded secrets, injection, and auth bypass are CRITICAL — block merge. XSS and SSRF without an allow-list are HIGH. Missing rate limiting or verbose error messages are MEDIUM.
+
+### False positives to skip
+
+`.env.example` placeholders, clearly-marked test credentials, and public API keys meant to be public are not findings — verify context before flagging.
+
+## Workflow pack: Security review
+
+A 4-layer pre-deploy security audit (secrets, authentication, input validation, data access) with per-layer prompts and a scan toolkit, a reviewer role, a /security-scan diff check, a /security-audit pre-deploy pass, a pre-ship Stop-hook reminder, and baseline security rules for every endpoint — flags real vulnerabilities with severity and file:line, not theater.
+
+When acting as the security-reviewer role: You are a security reviewer. Read the changed code and check it against the security-review checklist in context: injection, authorization, hardcoded secrets, unsafe deserialization, SSRF, XSS, and sensitive-data logging. For each finding, cite the exact file:line, name the concrete input and outcome that makes it exploitable, and give severity (CRITICAL/HIGH/MEDIUM). Skip findings you cannot point to in the code — do not manufacture issues to look thorough. If nothing is exploitable, say so and approve.
+
+Workflow steps:
+
+- security-scan: Invoke the security-reviewer subagent over the current diff (or $ARGUMENTS if given). Report findings grouped by severity (CRITICAL, HIGH, MEDIUM) with file:line and fix for each. End with a verdict: approve, or block until CRITICAL/HIGH issues are fixed.
+- security-audit: Run the security-audit skill's 4-layer pass over the current diff (or $ARGUMENTS if given): secrets, authentication, input validation, data access. For each layer, run the relevant toolkit command when it's installed (gitleaks, trufflehog, npm audit / pip-audit, semgrep --config auto) and answer that layer's audit prompt against the actual code. Report findings grouped by layer with file:line and severity (CRITICAL/HIGH/MEDIUM). End with a verdict: safe to ship, or block until CRITICAL/HIGH issues are fixed.
+
+- Security check: any user input, external fetch, or deserialized data crossing a trust boundary here? Validate it before it's used.
+- After an edit, scan the working tree for committed secrets with gitleaks when it is installed.
+- Before ending the session, run the pre-deploy security toolkit and remind to run /security-audit before shipping.
+
+## Skills
+
+### security-audit
+
+Run the 4-layer pre-deploy security pass (secrets, authentication, input validation, data access) before shipping code that touches user input, auth, an endpoint, or a database query.
+
+# Security audit: the 4-layer pre-deploy pass
+
+Run this before shipping any change that touches user input, authentication, an API endpoint, or a database query. It exists because most vibe-coded security incidents come from three repeat failure modes: a committed API key (in git history or a client bundle), an endpoint the server never actually checks auth on (the client just hides the button — `GET /api/invoices/43` returns someone else's invoice), and a hand-built SQL string. All three are caught by asking specific questions in order, not by "looking for bugs" in general.
+
+Work through all four layers. Each has an audit prompt — answer it against the actual code, not in the abstract.
+
+## Layer 1 — Secrets
+
+**Audit prompt:** Scan the current diff and git history for hardcoded API keys, passwords, tokens, or connection strings. Is every secret read from an environment variable (or a secret manager), never a literal in source? Does startup fail fast with a clear error if a required secret is missing?
+
+**Run:** `gitleaks detect` (finds secrets already in git history) and, if a match turns up, `trufflehog` to verify the secret is still active before treating it as a false positive.
+
+## Layer 2 — Authentication
+
+**Audit prompt:** For every route and mutation, does the *server* check authentication and authorization — not just the client hiding a button? For every resource-scoped endpoint, is access scoped to the resource's owner, not just "any logged-in user" (the BOLA/IDOR check — `GET /api/invoices/43` must 403/404 for anyone but the invoice's owner or an explicit admin)?
+
+## Layer 3 — Input validation
+
+**Audit prompt:** Is every external or untrusted input validated server-side against a schema before it reaches business logic — not only in the client? Are queries parameterized (never a user value concatenated into SQL, a shell command, or a template string)? Do file uploads have a size limit, and do auth endpoints have rate limiting?
+
+## Layer 4 — Data access
+
+**Audit prompt:** Does every data query filter by the authenticated user's own id (or explicitly check an admin role for cross-user access), instead of trusting a client-supplied id? Do error responses returned to the client stay generic (no stack trace, no internal detail) while the full context is logged server-side? Where the schema supports it, is deletion a soft delete rather than an irreversible hard delete?
+
+## Toolkit
+
+Run what's installed; note what isn't so a human can decide whether to install it.
+
+| Tool | Layer | What it checks |
+| --- | --- | --- |
+| `gitleaks detect` | 1 | secrets already committed to git history |
+| `trufflehog` | 1 | verifies a found secret is still live before you page anyone |
+| `npm audit` / `pip-audit` | 3 | known-vulnerable dependencies |
+| `semgrep --config auto` | 3–4 | static analysis for injection, unsafe patterns |
+| GitHub Secret Scanning + Push Protection | 1 | blocks a secret from ever reaching the remote |
+
+## Severity
+
+Hardcoded secrets, injection, and an auth bypass are CRITICAL — block the release. A BOLA/IDOR gap or an un-rate-limited auth endpoint is HIGH. A verbose error message or a missing rate limit is MEDIUM. Report every finding with file:line, not a vague "looks risky."
+
+### validate-at-boundaries
+
+Use when code receives data from outside its own module — user input, API responses, file contents, env vars, message payloads — validate it against a schema at the boundary and fail fast, so untrusted shapes never propagate inward.
+
+# Validate at boundaries
+
+Every place external data enters your system is a boundary: an HTTP handler, a file read, an API
+response, an environment variable, a queue message. **Validate at the boundary, before the data
+reaches any logic that assumes it is well-formed.** Inside the boundary, the value is trusted because
+you already checked it — not because you hope it is right.
+
+```ts
+// At the boundary: parse into a known shape, or reject.
+const parsed = OrderSchema.parse(await req.json()); // throws on bad shape
+createOrder(parsed);                                 // inner code trusts `parsed`
+```
+
+## Rules
+
+- **One validator is the authority for each shape.** Route every entry point for that shape through
+  it — built-in, user-supplied, or machine-generated. Never hand-construct or trust an unvalidated
+  object further in.
+- **Fail fast, name the field.** Reject the whole input on the first violation with a message that
+  says which field was wrong and why. A vague "invalid input" costs the caller a debugging session.
+- **Parse, don't just check.** Return a typed value from validation so downstream code carries the
+  guarantee in its types, not just in a comment.
+- **Never trust "internal" data blindly.** An API response or a sibling service's payload is external
+  to your module even if it's inside your company — validate it the same way.
+
+## Why
+
+Unvalidated data that flows inward turns a boundary problem into a deep-stack mystery: the crash
+happens three layers down, far from the malformed input that caused it. Validation at the edge keeps
+the failure where the bad data actually entered, where the error message can still be specific.
+
+## Boundaries to cover
+
+HTTP request bodies and query params · file and config contents · third-party API responses ·
+environment variables (validate presence and format at startup) · deserialized messages/events ·
+anything read from a store you did not just write in the same transaction.