skilldrop-cli 0.16.34 → 0.16.36

package/README.md

@@ -32,6 +32,7 @@ Install one pack. Every role pack also brings `core` (intake, critique, review c
 - **Data and analytics:** `data-analytics` — metric definitions, SQL review, dashboard specs. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/data-analytics/)
 - **Governance, risk and compliance:** `grc` — DPIAs, SOC 2 evidence maps, risk registers, security questionnaire answers. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/grc/)
 - **Infrastructure as code:** `infra-as-code` — Terraform modules with secure defaults, and plan reviews before apply. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/infra-as-code/)
+- **Frontend:** `frontend` — what makes a page slow for real users, and how each route should be rendered. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/frontend/)
 - **Writing agent skills:** `skill-engineering` — author a portable skill with evals, and review one before it ships. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/skill-engineering/)
 - **Applying for a job:** `career` — an honest fit check against the posting, a tailored resume and cover letter that claim nothing you didn't, and the application form's answers. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/career/)
 - **Everyone:** `core` on its own. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/core/)

package/agents/README.md

@@ -23,8 +23,11 @@ npx skilldrop-cli install --agent devils-advocate --ide kiro   # .kiro/agents/*.
 | [`devils-advocate`](devils-advocate.md) | Correctness — edge cases, broken assumptions, staff-engineer pushback, test-coverage gaps | "Will this break?" |
 | [`code-quality`](code-quality.md) | Craft — naming, structure, duplication, needless complexity, readability | "Will the next engineer hate this?" |
 | [`security-reviewer`](security-reviewer.md) | Security — authz, injection, secret exposure, SSRF, unsafe deserialization, weak crypto, risky deps | "What can an attacker do with this?" |
+| [`test-reviewer`](test-reviewer.md) | The tests themselves — which ones would still pass with the bug back in, mocks that return the answer, snapshots nobody read, the few missing tests that matter | "Would these tests catch it?" |
+| [`docs-reviewer`](docs-reviewer.md) | Docs against the change — statements now false, examples that fail if copied, new behaviour with no doc | "Do the docs still tell the truth?" |
+| [`finding-adjudicator`](finding-adjudicator.md) | The panel's findings — each checked against the code, duplicates merged, contradictions settled, one ranked list | "Which of these must the author actually fix?" |
 
-They are deliberately **split, not merged.** A single "review my code" agent dilutes all three — bug-hunting, craft, and exploitability pull in different directions. Run them as separate passes; together they are the reviewer panel [`feature-implement-loop`](../packs/dev-team/skills/feature-implement-loop/SKILL.md) drives after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../packs/dev-team/skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
+The first three are the core panel; `test-reviewer` and `docs-reviewer` join it when a change claims to be tested or touches documented behaviour, and `finding-adjudicator` runs last, over everyone's findings. They are deliberately **split, not merged.** A single "review my code" agent dilutes all three — bug-hunting, craft, and exploitability pull in different directions. Run them as separate passes; together they are the reviewer panel [`feature-implement-loop`](../packs/dev-team/skills/feature-implement-loop/SKILL.md) drives after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../packs/dev-team/skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
 
 ## Fire them as a panel
 

package/agents/docs-reviewer.md

@@ -0,0 +1,47 @@
+---
+name: docs-reviewer
+description: Checks that the documentation a change touches still tells the truth after it. Compares READMEs, guides, API docs, docstrings, comments, CHANGELOG entries and help text against what the code now does, and names every statement that is now wrong, every new behaviour left undocumented, and every example that would fail if copied. Delegate to it before merging a change to behaviour, configuration, commands or an API.
+tools: Read, Grep, Glob, Bash
+model: inherit
+---
+
+You are a technical writer with an engineer's habits, reviewing **the docs against the
+change**: the diff, and every document, docstring, comment and help string that describes what
+the diff changed.
+
+## The rule
+
+**A doc is wrong when following it now fails.** For each statement about changed behaviour
+(a command, a flag, a default, a config key, an endpoint, an error message, a file path), check
+the code. A copied example that no longer runs, a default that changed, a removed flag still
+listed: these are bugs, not style.
+
+## What you look for
+
+- **Statements the change made false:** renamed flags, changed defaults, new required settings,
+  removed endpoints, different error text, moved files.
+- **Examples that fail if copied.** Run them when it's safe: read-only commands, `--help`,
+  `--dry-run`. Otherwise trace them through the code.
+- **New behaviour with no doc:** a new flag, config key, environment variable, permission or
+  failure mode that a user would hit and couldn't find.
+- **Missing release notes:** the CHANGELOG or release-notes entry says nothing a user must do
+  (a migration, a breaking change, a new requirement).
+- **Comments and docstrings that now describe the old code**, which mislead the next engineer
+  more than no comment would.
+
+## How you report
+
+- Lead with the answer: are the docs safe to ship with this change, and the most misleading
+  statement in one sentence.
+- Then each problem with `file:line` of the doc, what it says, what the code now does (with
+  `file:line`), and the corrected text, written to drop in.
+- Then what's undocumented, as the sentence or section to add and where it goes.
+- Say which examples you ran and which you only traced.
+
+## Rules
+
+- ❌ Don't rewrite docs for tone or style. Truth first; style only if it causes a misreading.
+- ❌ Don't document internals a user never sees.
+- ❌ Invent nothing: no flags, defaults or behaviour you didn't confirm in the code.
+- ❌ Don't run anything that writes, deletes, deploys or calls a paid service to test an
+  example.

package/agents/finding-adjudicator.md

@@ -0,0 +1,49 @@
+---
+name: finding-adjudicator
+description: Settles a review panel's findings before anyone acts on them. Takes the findings from several reviewers (devils-advocate, code-quality, security-reviewer, test-reviewer or people), checks each against the code, merges duplicates, resolves contradictions, drops what doesn't survive, and returns one ranked list with a merge recommendation. Delegate to it after a panel review, when the findings are many, overlapping or disagree.
+tools: Read, Grep, Glob, Bash
+model: inherit
+---
+
+You are the engineer who reads every reviewer's findings on a change and decides what the
+author must actually do. Reviewers are deliberately one-sided; you are not. You do not add new
+findings of your own unless checking one turns up something worse next to it.
+
+## The rule
+
+**Every finding is checked against the code before it is kept.** Open the cited `file:line`,
+follow the path the finding describes, and decide:
+
+- **confirmed:** the scenario happens as described;
+- **confirmed, smaller:** real, but the stated impact is overstated, with the correct one;
+- **not reproduced:** a guard, a type, a caller or a test already prevents it, which you cite;
+- **unclear:** it turns on something not in the code (a production setting, a data shape). Say
+  exactly what to check.
+
+## Then
+
+- **Merge duplicates.** Two reviewers describing the same root cause are one finding. Keep the
+  clearest scenario and credit both.
+- **Resolve contradictions.** When one reviewer says add a check and another says it's
+  redundant, decide from the code and say why.
+- **Rank by consequence.** Wrong results, data loss and security holes first; then bugs under
+  realistic conditions; then fragility; style last. A security finding is never ranked down
+  for being less likely without a reason.
+- **Fixes that conflict.** If two kept findings' fixes collide, name the order or the single
+  fix that settles both.
+
+## How you report
+
+- Lead with the recommendation: merge, merge after the listed fixes, or don't merge. Give the
+  reason in one sentence.
+- Then the kept findings, ranked, each with `file:line`, the confirmed scenario, the fix, and
+  which reviewers raised it.
+- Then, briefly, what you dropped and why, so the reviewers can see it was read.
+
+## Rules
+
+- ❌ Don't keep a finding because a reviewer sounded confident, or drop one because it's
+  inconvenient. The code decides.
+- ❌ Don't average severities. Decide each one.
+- ❌ Invent nothing: no behaviour, data or configuration you weren't shown.
+- ❌ You recommend; a person decides the merge.

package/agents/test-reviewer.md

@@ -0,0 +1,52 @@
+---
+name: test-reviewer
+description: Reviews the tests that came with a change, not the change itself. Says which behaviour the tests actually pin down, which they only appear to (mocks that return the answer, assertions on the mock, snapshots nobody reads), which would still pass with the bug back in, and the few missing tests that matter. Delegate to it when a change claims "tested", before merging, or when a suite is green but bugs still reach production.
+tools: Read, Grep, Glob, Bash
+model: inherit
+---
+
+You are a quality engineer reviewing **the tests** of a change: the test files in the diff, the
+tests the author cites, and the code they exercise. Your question is whether these tests would
+fail if the behaviour they claim to cover broke.
+
+## The rule
+
+**A test counts only for what would make it fail.** For each test, name the one change to the
+code under test that turns it red. If you can't name one, it covers nothing, however many
+lines it has. Run the suite when you can, then break the code on purpose, in your head or
+with a throwaway edit you revert: flip a comparison, drop a branch, return early. Report which
+tests notice.
+
+## What you look for
+
+- **Assertions on the mock, not the result.** A mock is configured to return X, and the test
+  asserts the result is X.
+- **Mocked boundaries that hide the bug.** The test mocks the database, clock, queue or HTTP
+  client exactly where the change's risk lies.
+- **Snapshot and golden files approved without reading.** Find the snapshot updated in the same
+  diff as the behaviour change.
+- **Happy path only.** No empty input, error path, boundary value, time zone or concurrency
+  case, and those are where the change can fail.
+- **Tests that pass for the wrong reason.** Fixture data that dodges the bug, an `assert` inside
+  a branch that never runs, a swallowed exception, a test skipped or marked flaky in this diff.
+- **Coverage figures cited as proof.** A line that ran is not a line whose result was checked.
+
+## How you report
+
+- Lead with the answer: do these tests protect the change, yes or no, and the biggest gap in
+  one sentence.
+- Then each weak test, with `file:line`, the code change that should make it fail and doesn't,
+  and the fix: a sharper assertion, a real boundary, an added case.
+- Then the missing tests, at most five, each as a scenario with its expected result, most
+  consequential first.
+- Say what you ran, and what you only read.
+
+## Rules
+
+- ❌ Don't ask for more tests to raise a coverage number. Ask for the ones that would catch a
+  bug this change can have.
+- ❌ Don't review the production code's style or design; that's the **code-quality** agent's
+  job. Bugs in the code itself are the **devils-advocate** agent's job.
+- ❌ Invent nothing: no test names, files, frameworks or results you weren't shown. Say what to
+  check instead.
+- ❌ Leave no throwaway edit behind. Revert every deliberate break before you finish.

package/catalogue.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0034. The catalogue index: pack display order and the outcome browse axis (RFC-0026). Pack metadata lives in packs/<pack>/pack.json; membership is the folders — a skill is in a pack because it sits at packs/<pack>/skills/<name>/.",
   "version": "1.0.0",
-  "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "skill-engineering", "career"],
+  "packs": ["core", "solution-architect", "product-manager", "dev-team", "sre-oncall", "stakeholder-comms", "design", "ai-engineering", "api-builder", "converters", "experience-design", "research", "trackers", "data-analytics", "grc", "infra-as-code", "frontend", "skill-engineering", "career"],
   "outcomes": {
     "decide-what-to-build": {
       "for": "Product managers · founders · strategists",
@@ -18,7 +18,8 @@
         "success-metrics",
         "user-story-splitter",
         "user-journey-map",
-        "feedback-synthesis"
+        "feedback-synthesis",
+        "lean-canvas"
       ]
     },
     "design-the-system": {
@@ -40,7 +41,8 @@
         "subagent-design",
         "agent-budget",
         "terraform-module",
-        "mcp-pairing"
+        "mcp-pairing",
+        "event-contract-draft"
       ]
     },
     "build-and-review-software": {
@@ -65,7 +67,10 @@
         "tracker-brief-sync",
         "dependency-upgrade-review",
         "codebase-tour",
-        "refactor-plan"
+        "refactor-plan",
+        "behaviour-equivalence",
+        "rendering-strategy",
+        "web-performance-review"
       ]
     },
     "build-on-the-claude-api": {
@@ -91,7 +96,8 @@
         "cloud-cost-review",
         "delivery-metrics-report",
         "terraform-plan-review",
-        "rollout-plan"
+        "rollout-plan",
+        "slo-spec"
       ]
     },
     "explain-it-to-decision-makers": {
@@ -116,7 +122,9 @@
         "ai-adoption-rollout",
         "ai-usage-policy",
         "agent-adoption-stage",
-        "ai-usage-report"
+        "ai-usage-report",
+        "agent-config-review",
+        "agent-incident-response"
       ]
     },
     "create-on-brand-collateral": {
@@ -140,7 +148,9 @@
         "md-to-docx",
         "md-to-html",
         "md-to-xlsx",
-        "mermaid-render"
+        "mermaid-render",
+        "md-to-pptx",
+        "md-to-confluence"
       ]
     },
     "design-the-experience": {

package/model-routing.json

@@ -114,6 +114,14 @@
       "tier": "standard",
       "rationale": "Quantitative spec synthesis against a fixed tier vocabulary and degradation ladder. Cap-setting judgment is bounded by the 3-5x rule; escalate via ambiguous-input when the workflow itself is undefined."
     },
+    "agent-config-review": {
+      "tier": "standard",
+      "rationale": "Reading settings, hooks and MCP config against a fixed checklist of over-broad grants; bounded judgment with a verdict that follows from the findings."
+    },
+    "agent-incident-response": {
+      "tier": "standard",
+      "rationale": "A time-ordered containment checklist for a leaked credential or a runaway agent; the order is fixed, the judgment is in scoping what was reachable."
+    },
     "agent-loop-design": {
       "tier": "standard",
       "rationale": "Design synthesis against a fixed state-machine pattern and exit-criteria catalog. The gate-placement judgment is bounded by the blast-radius rule; escalate via ambiguous-input when the task itself is contested."
@@ -166,6 +174,10 @@
       "tier": "standard",
       "rationale": "A script does the counting; the model confirms duplicates by reading, judges readiness and writes a reasoned ordering. Bounded judgment over structured data."
     },
+    "behaviour-equivalence": {
+      "tier": "standard",
+      "rationale": "Designing a golden-master comparison is structured: what to record, what to normalise, and what counts as a difference; the diffing is done by its script."
+    },
     "brand-kit": {
       "tier": "standard",
       "rationale": "Extracts and normalises brand facts from files and pages, then runs a checker. Bounded synthesis."
@@ -254,6 +266,10 @@
       "tier": "standard",
       "rationale": "Reads a SKILL.md and synthesizes eval cases — requires understanding of skill intent but not heavy reasoning."
     },
+    "event-contract-draft": {
+      "tier": "standard",
+      "rationale": "Contract drafting against the AsyncAPI shape with fixed rules on ordering, delivery and versioning; mid tier is enough."
+    },
     "exec-summary": {
       "tier": "standard",
       "rationale": "Compression to one page. Needs to keep the right signal; escalate on very long source docs."
@@ -302,6 +318,10 @@
       "tier": "standard",
       "rationale": "Checks evidence against a fixed checklist. Bounded synthesis, not adversarial review."
     },
+    "lean-canvas": {
+      "tier": "standard",
+      "rationale": "Filling the canvas is structured; the value is in ranking assumptions by risk and naming the cheapest test that could kill the riskiest one."
+    },
     "llm-eval-harness": {
       "tier": "standard",
       "rationale": "Methodology synthesis against a fixed decision tree and pitfall catalog. Grading-method and metric choices need judgment but are bounded; escalate via ambiguous-input on novel task types."
@@ -314,6 +334,10 @@
       "tier": "standard",
       "rationale": "Matching a loop's stages to the context each needs and the narrowest access that provides it is bounded judgment over a short checklist."
     },
+    "md-to-confluence": {
+      "tier": "light",
+      "rationale": "Mechanical conversion to Confluence storage format done by its script, with an optional publish; the model checks what was dropped and what will be overwritten."
+    },
     "md-to-docx": {
       "tier": "standard",
       "rationale": "A stdlib script does the conversion; the model restructures the Markdown so it converts cleanly (heading levels, footnotes, HTML), reads each warning and explains the losses. Bounded editing, no open-ended generation."
@@ -322,6 +346,10 @@
       "tier": "light",
       "rationale": "A deterministic stdlib script does the conversion; the model picks options, fixes a few unsupported Markdown constructs and relays the script's warnings. Little judgment."
     },
+    "md-to-pptx": {
+      "tier": "light",
+      "rationale": "Mechanical conversion done by its script; the model only checks the outline maps to slides and reports what was dropped."
+    },
     "md-to-xlsx": {
       "tier": "standard",
       "rationale": "A stdlib script types and writes the cells; the model shapes tables from the source (headings, units, one header row), decides whether formulas are safe to enable, and checks the per-sheet type counts against the data. Bounded, mostly mechanical judgment."
@@ -382,6 +410,10 @@
       "tier": "standard",
       "rationale": "Classifies commits and rewrites them for a reader. The audience translation needs judgment; escalate via large-input on very long ranges."
     },
+    "rendering-strategy": {
+      "tier": "standard",
+      "rationale": "Choosing static, server, client or incremental rendering per route follows fixed trade-offs (freshness, personalisation, SEO, cost); bounded judgment."
+    },
     "requirements-interview": {
       "tier": "standard",
       "rationale": "Question banks are rubric-shaped, but ranking by design impact and deriving falsification conditions for the specific feature is synthesis — above light."
@@ -434,6 +466,10 @@
       "tier": "standard",
       "rationale": "Outlines a deck to a time budget. Structuring, not deep reasoning."
     },
+    "slo-spec": {
+      "tier": "standard",
+      "rationale": "SLI choice is bounded judgment over user journeys; error-budget and burn-rate arithmetic is done by its script."
+    },
     "soc2-evidence-map": {
       "tier": "standard",
       "rationale": "Maps controls against a fixed criteria set and a known Type I vs Type II evidence pattern. Judgment is needed on coverage and gap status, but the structure is bounded by the reference."
@@ -513,6 +549,10 @@
     "ux-writing": {
       "tier": "standard",
       "rationale": "Short-form writing to fixed slot rules and character budgets, plus a terminology consistency pass. Bounded generation with clear checks."
+    },
+    "web-performance-review": {
+      "tier": "standard",
+      "rationale": "The metrics, opportunities and the elements behind them are read out of the Lighthouse report by its script; the model ranks fixes by what moves the user-facing numbers."
     }
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.16.34",
+  "version": "0.16.36",
   "description": "Portable AI-agent skills, measured against the agent without them. ADRs, PRDs, runbooks, decks and reviews, installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",

package/packs/ai-engineering/skills/agent-config-review/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: agent-config-review
+description: Review a coding agent's configuration for access broader than the work needs and give a verdict — SAFE AS CONFIGURED, TIGHTEN BEFORE USE or DO NOT USE — reading what actually wins across every scope (Claude Code user, project, local and managed settings; permission allow/deny/ask lists, defaultMode, sandbox, hooks, plugins, env; .mcp.json; subagent tool lists; Codex sandbox_mode and approval_policy and the profile in use; Cursor and Copilot agent settings), with each finding's file and line, what it lets happen in plain words, and the exact replacement config. Use when the user asks "is this Claude Code / Codex / Cursor setup safe", "review our .claude/settings.json", "audit our agent permissions", "is Bash(npm:*) OK in the allow list", "check this repo's agent config before we open it", or wants an agent's permissions tightened before use.
+---
+
+# agent-config-review
+
+Reads the configuration a coding agent will actually run with and says whether it is safe to
+use as it stands. The files lie by omission: the effective permission is what every scope adds
+up to, an allow entry means what the command can do rather than what it is called, and the
+settings that run shell without asking (hooks, status lines, MCP servers) sit outside the
+sandbox. The output is a verdict, the findings worst first, and the config that replaces each.
+
+It reviews an existing setup. Choosing which MCP servers a workflow should connect is
+`mcp-pairing`; attacking an agent's design for data-exfiltration paths is `agent-threat-model`.
+
+## How to respond
+
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
+- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
+- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
+- **For this skill:** The verdict is the worst finding's, and it covers only the files read: name each scope not seen. A secret found in a committed file is rotated, not just moved.
+
+1. **Collect every scope before judging one file.** Claude Code reads user (`~/.claude/settings.json`), project (`.claude/settings.json`), local (`.claude/settings.local.json`) and managed policy, plus MCP servers from `.mcp.json`, `~/.claude.json` and plugins. Codex reads `~/.codex/config.toml` and the profile it is launched with. Locations for every tool are in [`reference.md`](reference.md). Spend at most 2 questions, on how the agent is launched (flags, profile) and what work it is for; otherwise tag both `[assumption]`.
+
+2. **List what the files grant, mechanically.**
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/agent_config_scan.py" <project-dir> [--user <home>] [--managed <file>] [--also <file> ...]
+   # Other IDEs (from the skill folder)
+   python3 scripts/agent_config_scan.py <project-dir> [--user <home>] [--managed <file>] [--also <file> ...]
+   ```
+
+   It merges the scopes, prints effective rules, sandbox, hooks, MCP servers, subagents, Codex
+   profiles and masked secrets with file:line, and lists patterns to grade. Pass any token or
+   env file a config references with `--also`. If no script can run, do the merge in step 3 by
+   hand. The script lists; the grading is yours.
+
+3. **Judge what wins, not what one file says.** In Claude Code, `allow`/`ask`/`deny` lists **add up** across scopes and a deny anywhere beats an allow anywhere; a single value (`defaultMode`) comes from the highest scope that sets it: managed > command-line flags > local > project > user. The local file is per-person and is where a loosened mode hides.
+   - ❌ *"defaultMode is acceptEdits, so edits are the only thing that skips a prompt."*
+   - ✅ *"`.claude/settings.local.json:3` sets `bypassPermissions`, which outranks the project's `acceptEdits`: every tool call runs without a prompt."*
+   - In Codex, the profile in use overrides the top level: review `[profiles.<name>]` for the one the user launches with.
+
+4. **Read every allow entry as what it lets run.** An interpreter, package manager, build tool or `git`/`gh`/`docker` with a wildcard is arbitrary code. Table in [`reference.md`](reference.md).
+   - ❌ *"`Bash(npm:*)` is fine, it's just npm."*
+   - ✅ *"`Bash(npm:*)` runs any `package.json` script and `npm exec` downloads and runs any package. Replace with the scripts the work uses:"* `"Bash(npm run test)", "Bash(npm run lint)"`
+   - `bypassPermissions`, `--dangerously-skip-permissions`, Codex `danger-full-access` with `approval_policy = "never"`, and Copilot global auto-approve remove the human entirely.
+
+5. **Test the deny list against the allow list.** A deny list holds only if nothing allowed can do the denied thing another way. `Bash(python3:*)` allowed means `python3 -c` reads `.env` and posts it out while `Read(./.env)` and `Bash(curl:*)` sit in the deny list: those rules bind one tool and one command name, not a process. The only thing that binds every subprocess is the sandbox.
+
+6. **Check the sandbox and what it does not cover.** Strict means `"enabled": true` and `"allowUnsandboxedCommands": false`; with `true`, a command that fails in the sandbox can retry outside it. `excludedCommands` always run outside. `network.allowedDomains` lists only the hosts the work needs: `*.githubusercontent.com` or a paste host lets anyone publish the payload or receive the data. The sandbox covers shell commands only: **hooks, MCP servers and the file and web tools run outside it**, so a strict sandbox fixes none of the findings about them.
+
+7. **Read every command that runs without asking.** Every hook (`SessionStart`, `PreToolUse`, `PostToolUse`, `Stop`, …), `statusLine`, `apiKeyHelper` and similar run shell on an event with no prompt. A hook that downloads and runs code is 🟥: whoever controls that URL runs code on every machine that opens the repo. Replace it with a script committed to the repo, or delete it. Enabled plugins bring hooks and servers these files don't show: list them under "To confirm".
+
+8. **Treat a secret in a committed file as leaked.** A literal token in `env`, `.mcp.json` headers or args, or a connection string with a password, is exposed to everyone with the repo and its history. The fix is **rotate first**, then reference it from the environment (`"${GITHUB_TOKEN}"`) and keep personal files in `.gitignore`. Deleting the line leaves it in git history. Whether the repo was pushed or is public isn't in the files: say so. A plaintext secret in a user-scope file that was never committed (`~/.codex/config.toml`) is moved to the environment, and rotated if a session with no prompts could read it; don't call it committed.
+
+9. **Check each MCP server for pin, publisher, write and mix.** `npx -y pkg` or `pkg@latest` runs whatever the registry serves at start-up; pin an exact version. A publisher the user can't name is unvetted. `enableAllProjectMcpServers: true` starts every server in a cloned repo's `.mcp.json` without approval; `mcp__server` in `allow` approves all its tools, writes included. A server that reads untrusted content (web pages, issues, tickets) in the same session as private data and a way out (shell, write tools, network) is the lethal trifecta: 🟥 when nothing asks.
+
+10. **Check subagents.** A subagent file with no `tools:` line inherits every tool the session has, MCP servers included; give it the list its job needs. `permissionMode: bypassPermissions` on a subagent removes the human for its calls.
+
+11. **Grade, pick the verdict, write the reply.**
+    - 🟥 runs or leaks with no person in the way: a hook or setting that runs downloaded code; a literal secret in a committed file; the human removed, or arbitrary code allowed, without a strict sandbox; the trifecta with nothing asking.
+    - 🟧 broader than the work, held by one control: the same grants inside a strict sandbox; sandbox escape hatches; wide domains; unpinned or unvetted MCP packages; auto-approved servers; a subagent with no tool list; a bypassable deny list; Codex `inherit = "all"`.
+    - 🟨 one change from a hole: a local settings file not git-ignored; `acceptEdits` (edits CI and hook files unprompted).
+    - Any 🟥 → **DO NOT USE** until fixed. Any 🟧 → **TIGHTEN BEFORE USE**. Otherwise **SAFE AS CONFIGURED**.
+
+    The reply: the verdict and the worst finding in one or two sentences; then findings worst first, each `file:line`, what it lets happen in one plain sentence, and the replacement config as a snippet; one line on what is fine; "To confirm" last. Snippets in [`reference.md`](reference.md). A chat question about one rule gets a short answer with the replacement, not a full review.
+
+**Non-interactive runs** (subagent, CI, headless): an unknown launch mode or profile is assumed to be the widest one the files define, and an unknown purpose is assumed to be editing and testing the repo, both tagged `[assumption]`. If no configuration file or setting is given at all, emit `BLOCKED: need the agent's configuration files or settings`, then say in plain words which files to send and what the review will contain.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — where each tool keeps its config and how scopes merge, what each wildcard allow entry really permits, the settings that run shell, replacement snippets for Claude Code, Codex, Cursor and VS Code
+- [`scripts/agent_config_scan.py`](scripts/agent_config_scan.py) — merges scopes and lists effective grants, hooks, servers, subagents and masked secrets (stdlib only)
+- [`examples/python-repo-tighten.md`](examples/python-repo-tighten.md) — worked example: a Python repo with a strict sandbox, a `make` wildcard, an excluded `docker` and an unpinned Slack server; TIGHTEN BEFORE USE
+
+## Quality bar
+
+- **The first line is the verdict** and names the worst finding in plain words.
+- **The effective setting is reviewed,** with the winning scope named; scopes not read are listed under "To confirm".
+- **Every finding has `file:line`, its effect in one sentence, and replacement config** that can be pasted.
+- **Every wildcard allow entry is read as what it can run,** and the deny list is tested against it.
+- **Every hook and command-running setting is quoted and judged;** none is waved through as "tooling".
+- **Every literal secret says rotate,** masked in the reply, never quoted whole.
+- **No invented facts:** no package version, publisher, host, scope or script name the input didn't contain; replacement allow entries use only commands the input shows.
+- **No claim about what wasn't read:** plugins, git history, user or managed scopes are "To confirm".
+
+## When to use this skill
+
+- ✅ "Is this repo's Claude Code setup safe to open?" with `.claude/` and `.mcp.json`
+- ✅ "Review my `~/.codex/config.toml`" or a Cursor or VS Code agent setup
+- ✅ "Is `Bash(npm:*)` OK in our allow list if we deny curl?"
+- ✅ Tightening an agent's permissions before rolling the config out to a team
+
+## When NOT to use this skill
+
+- ❌ Choosing which MCP servers and token scopes a workflow should have — `mcp-pairing`
+- ❌ Threat-modelling an agent's design for prompt injection and exfiltration paths — `agent-threat-model`
+- ❌ Deciding what each subagent should be told and given in a new design — `subagent-design`
+- ❌ Writing the organisation's rules for AI tools and data — `ai-usage-policy`
+- ❌ A token already leaked or an agent already did damage — `agent-incident-response`; review the config after containment
+
+## Anti-patterns to avoid
+
+- ❌ **Reviewing `settings.json` alone.** The local file, user scope and the profile in use decide what runs.
+- ❌ **Trusting the deny list.** `Bash(curl:*)` denied beside `Bash(python3:*)` allowed blocks nothing.
+- ❌ **"The sandbox is on, so it's contained."** Not with `allowUnsandboxedCommands: true`, and never for hooks or MCP servers.
+- ❌ **Moving the token to an env var and calling it fixed.** It was committed; rotate it.
+- ❌ **"Pin it to a safe version"** with a version number the input doesn't show. Say pin to an exact, reviewed version.
+- ❌ **A findings table before the verdict,** or a full audit when the question was one rule.
+- ❌ **Showing the machinery.** Don't mention this skill, its files or its script in the reply.
+- ❌ **A bare `BLOCKED` line.** Keep it, then say in plain words what to send.

package/packs/ai-engineering/skills/agent-config-review/evals/eval_queries.json

@@ -0,0 +1,12 @@
+[
+  {"query": "Can you review our .claude/settings.json and .mcp.json before the team starts using Claude Code on this repo?", "should_trigger": true},
+  {"query": "Is my ~/.codex/config.toml safe? I run it with a profile that skips approvals", "should_trigger": true},
+  {"query": "Is Bash(python3:*) in the allow list a problem if we deny curl?", "should_trigger": true},
+  {"query": "Audit the agent permissions in this repo: hooks, sandbox, subagents, the lot", "should_trigger": true},
+  {"query": "This repo we cloned has a SessionStart hook in its Claude settings. Safe to open it?", "should_trigger": true},
+  {"query": "Which MCP servers should our release loop connect to, and with what token scopes?", "should_trigger": false},
+  {"query": "Threat-model our support agent: it reads tickets, queries the customer DB and can send email", "should_trigger": false},
+  {"query": "Write the policy for which AI coding tools staff may use with client code", "should_trigger": false},
+  {"query": "How should I split this migration across subagents, and what should each one be told?", "should_trigger": false},
+  {"query": "The agent committed our GitHub token to a public repo an hour ago. What do I do?", "should_trigger": false}
+]

package/packs/ai-engineering/skills/agent-config-review/evals/evals.json

@@ -0,0 +1,75 @@
+{
+  "skill_name": "agent-config-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We just cloned dispatch-api from our platform team and it comes with Claude Code already set up: the .claude folder, .mcp.json, package.json and .gitignore are in evals/files/1. Before my team opens it in Claude Code, is this setup safe to use?",
+      "assertions": [
+        "The first lines give a verdict that the setup is not safe to use as configured (DO NOT USE or plainly equivalent) and name the worst finding, before any table or list",
+        "It flags the SessionStart hook in .claude/settings.json that downloads a script from raw.githubusercontent.com and pipes it into bash as critical, says it runs without asking and outside the sandbox, and replaces it with a committed, reviewed local script or removes it",
+        "It says .claude/settings.local.json sets defaultMode bypassPermissions, which outranks the project file's acceptEdits, so the effective mode asks nothing, and notes the file is not git-ignored and so was shared with the clone",
+        "It treats the GitHub token in .mcp.json as leaked and says to rotate it, not only move it, shows it masked rather than in full, and gives a ${VAR} replacement",
+        "It says the deny list (curl, wget, Read of .env) is walked around by the allowed Bash(python3:*) and Bash(npm:*), and replaces the wildcards with exact entries taken from the package.json scripts (such as npm run test and npm run lint)",
+        "It flags allowUnsandboxedCommands: true, the *.githubusercontent.com allowed domain, and the unpinned MCP packages that enableAllProjectMcpServers starts without approval",
+        "It flags the db-migrator subagent for having no tools list, so it inherits every tool including the MCP servers, and does not flag the reviewer subagent, which lists Read, Grep and Glob",
+        "It does not invent package versions, publishers, hosts, token scopes or script names absent from the files, and lists what it could not see (user and managed settings, whether the token was pushed, its scopes) under a closing 'To confirm'"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "I use Codex on the billing service in our monorepo. My ~/.codex/config.toml and the repo's .cursor/mcp.json (some of the team use Cursor) are in evals/files/2. I mostly run `codex --profile fast` because the approvals slow me down. My shell has our Stripe test key and AWS credentials exported. Is my setup OK?",
+      "assertions": [
+        "It opens with a verdict that the setup as launched is not safe (DO NOT USE or plainly equivalent), naming the fast profile's danger-full-access with approval_policy never",
+        "It reviews the fast profile as what actually runs, not the top-level on-request and workspace-write values, and says the top level does not apply when launched with --profile fast",
+        "It gives replacement TOML for the profile that keeps a sandbox (workspace-write) and an approval policy other than never",
+        "It flags shell_environment_policy inherit = \"all\" as handing the Stripe key and AWS credentials to every command, and replaces it with a narrower setting",
+        "It flags the plaintext password in the billing_rw connection string in config.toml, shows it masked, moves it to the environment, and does not claim the file was committed to a repo",
+        "It names the combination of Linear issue text the agent reads, a read-write billing database role, and unrestricted network with no approval, and narrows it (read-only role, no write, or no network)",
+        "It flags the unpinned npx packages in config.toml (server-postgres, mcp-remote) and treats the Cursor billing-db server, pinned and using an environment reference, as fine",
+        "It does not invent token scopes, versions, Cursor app settings or hosts not in the files, and puts what it can't see (Cursor auto-run settings, the Sentry token's scope, any project-level Codex config) under 'To confirm'"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Quick one: is it OK to have Bash(npm:*) and Bash(node:*) in our Claude Code allow list if we deny Bash(curl:*) and Bash(wget:*)? Mostly we just run tests and lint.",
+      "assertions": [
+        "The first sentence answers no (or not as written) without preamble",
+        "It explains that node -e, npm scripts or npm exec can read files and make network requests themselves, so denying curl and wget does not stop data leaving",
+        "It gives exact replacement allow entries for running tests and lint, such as Bash(npm run test) and Bash(npm run lint), instead of the wildcards",
+        "It names a strict sandbox (enabled, allowUnsandboxedCommands false, a narrow allowedDomains list) as the control that actually limits what any process can reach",
+        "It stays a short chat answer: no verdict banner over a full audit, no severity table, no sections about files the user didn't share",
+        "It does not invent script names, hosts or other settings in the user's config beyond what the question states"
+      ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-20",
+      "prompt": "cloned quillstack into ./quillstack so i can send them a small docs PR. it ships a .claude folder and an .mcp.json in the repo. is it safe to just open claude code in there? my own settings are in my-user-settings.json and those are pretty locked down so i think im fine? dont need an essay, just can i open it and what do i turn off",
+      "assertions": [
+        "Answers the actual question directly near the top: no, do not open/trust the folder in Claude Code as committed (verdict TIGHTEN BEFORE USE or DO NOT USE, never SAFE AS CONFIGURED), and says what to change first.",
+        "Flags env.ANTHROPIC_BASE_URL = https://llm-gateway.quillstack.example in quillstack/.claude/settings.json as routing the user's own Claude Code traffic (prompts, code it reads, API credentials) through the project's server.",
+        "Flags the quill-cloud server in quillstack/.mcp.json sending the user's own ${GITHUB_TOKEN} as a Bearer header to https://mcp.quillstack.example/v1, and notes enableAllProjectMcpServers: true plus the mcp__quill-cloud allow entry let it connect and act without a prompt.",
+        "Flags the SessionStart hook (node .claude/hooks/bootstrap.mjs) as repo-controlled code that runs automatically at every session start, and says that script was not among the files provided so it must be read before trusting; it does not describe what the script does.",
+        "Corrects the 'my settings are locked down so I'm fine' belief with how scopes combine: the user's deny rules (Bash(curl:*), Bash(wget:*), Read(~/.ssh/**), Read(~/.aws/**)) still apply because deny wins, but the project's defaultMode acceptEdits overrides the user's default, and the project's allow rules, hooks, env and MCP servers are added on top; and Read() deny rules (including the project's Read(./.env)) do not stop Bash(npm run:*), Bash(npx:*) or Bash(git:*) from reading those files.",
+        "Flags the release-notes subagent in quillstack/.claude/agents/release-notes.md: it has no tools line (so inherits every tool) and instructs `git push origin HEAD:main`, which the Bash(git:*) allow entry lets run without a prompt; suggests a restricted tools list and removing the push step.",
+        "Gives concrete, valid replacement config or exact edits (e.g. delete the env block, hooks, enableAllProjectMcpServers, Bash(npx:*), Bash(git:*), Bash(curl:*), WebFetch and mcp__quill-cloud; keep defaultMode default), sized to the 'dont need an essay' request rather than a long report.",
+        "Invents nothing not in the files: no claimed behaviour for bootstrap.mjs, tools/mcp/docs-server.mjs, scripts/format-staged.mjs or the quill-cloud tools, no files or settings that were not provided, and no made-up CVE numbers or version numbers."
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-20",
+      "prompt": "We're the platform team at Harrow Freight. We want Codex to triage new issues on our dispatch-api repo unattended in CI, using the `ci` profile from our shared config. Attached: codex/config.toml (what we install as ~/.codex/config.toml on the harrow-runner hosts), the repo's AGENTS.md, and .github/workflows/codex-triage.yml. Is the ci profile OK to run unattended? I need a yes/no for the change board on Thursday plus exactly what we'd have to change.",
+      "assertions": [
+        "Gives the change board a direct answer up front: no, not OK to run unattended as deployed (TIGHTEN BEFORE USE or DO NOT USE), followed by the list of required changes.",
+        "Identifies that the workflow runs `codex exec --profile ci -c sandbox_mode=\"danger-full-access\"`, and that the -c override beats the profile's sandbox_mode = \"workspace-write\", so what actually runs is approval_policy = \"never\" with no sandbox; reviewing the ci profile alone is misleading.",
+        "Notes the ci profile inherits the top-level [sandbox_workspace_write] block, and flags writable_roots containing /var/run/docker.sock (root-equivalent on the self-hosted harrow-runner host) and network_access = true.",
+        "Flags shell_environment_policy inherit = \"all\" exposing DEPLOY_TOKEN, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to every command, and connects it to untrusted input: the job fires on issues opened and issue comments from anyone, with ${{ github.event.issue.title }} and ${{ github.event.issue.body }} pasted into the prompt (prompt injection) and straight into the run: shell script (shell injection).",
+        "Flags the hard-coded GITHUB_PERSONAL_ACCESS_TOKEN (ghp_EXAMPLEEXAMPLEEXAMPLE) in [mcp_servers.github]: move it to an environment variable or secret and rotate it if a real token was ever there; and notes the GitHub MCP server is available to the ci run with approval_policy = \"never\".",
+        "Points out the AGENTS.md rules (never push to main, no reading env vars or secrets, no network except github.com, no changes under infra/ or .github/) are instructions and not enforcement; with contents: write and no sandbox nothing stops them being broken, so they need real controls such as branch protection, network off and secrets kept out of the job env.",
+        "Gives exact replacement TOML for the ci run (e.g. sandbox_mode = \"workspace-write\", network_access = false, no docker.sock in writable_roots, shell_environment_policy inherit = \"core\" or an exclude list, no hard-coded token) and the matching workflow change (drop the -c override, take the deploy/AWS secrets out of the job env, pass the issue text via a file or env var instead of inline ${{ }}, run docker-based tests outside the agent step).",
+        "Invents nothing not in the files: no Codex settings, flags or profile names beyond what is shown or well established, no made-up runner details, secret names or ticket numbers other than HF-412, and does not claim branch protection exists or not."
+      ]
+    }
+  ]
+}

package/packs/ai-engineering/skills/agent-config-review/evals/files/1/.claude/agents/db-migrator.md

@@ -0,0 +1,8 @@
+---
+name: db-migrator
+description: Writes and applies database migrations for dispatch-api. Use when a change needs a schema migration.
+model: sonnet
+---
+
+You write SQL migrations for dispatch-api in `migrations/`, numbered in order. Apply them to the
+staging database with `npm run migrate` and report the result. Never edit an applied migration.

package/packs/ai-engineering/skills/agent-config-review/evals/files/1/.claude/agents/reviewer.md

@@ -0,0 +1,9 @@
+---
+name: reviewer
+description: Reviews a diff in dispatch-api for correctness and missing tests. Use before opening a pull request.
+tools: Read, Grep, Glob
+model: sonnet
+---
+
+Read the diff and the files it touches. Report correctness bugs and missing tests, worst first.
+Do not edit files.