Security & Auditing Skills

Invoke this skill (or /rulesense:assay) any time a user wants feedback on rule files they already have. This covers CLAUDE.md and .claude/rules/ — grading, scoring, auditing, reviewing, or critiquing the structural clarity of existing instructions. Trigger broadly: if someone asks "are my rules any good", "look at my rules", "check my CLAUDE.md", "grade my instruction files", "which rules are weak/vague/passive/garbage", "triage this inherited rule set", or "which rules should be hooks instead" — this is the skill. Also trigger when someone references /rulesense:assay with any flags (--json, --fix, --verbose). The core signal is: the user has existing Claude Code rules and wants an opinion on their quality. This skill reads and evaluates — it never creates new rules (that's forge), never reviews code or PRs, and ignores non-Claude-Code config like eslint or prettier.

The before-the-first-line lens for a frontend build: fix what is expensive to reverse before sunk cost exists. Use when starting a frontend product or major feature, or stress-testing a plan that jumped straight to a framework. The three ruling principles: BOUNDARIES > FRAMEWORKS (frameworks get swapped; the network/trust line and state classification fossilize into bedrock); ALLOCATE CAUTION BY REVERSIBILITY (one-way doors earn slow human judgment, two-way doors get a default for agents); and THE SOURCE OF TRUTH LIVES IN THE USER'S MIND, not the database. The one shift: frontend is the one discipline whose correctness spec lives in a brain, so taste is load-bearing and cannot be outsourced. Triggers on "starting a frontend project / from scratch", "which framework / React or X", "how should I architect this UI", "what should the data model be", "do we need realtime / offline / collaboration", "SSR or SPA or RSC", "is this design manipulative / dark pattern", "what metric should we optimize".

The 1-to-N lens for a frontend system that is already alive: the enemy is no longer building, it is ENTROPY — boundaries eroded by one "just this once" cross-import at a time, and the two graphs (component tree vs data dependency) drifting apart. Use when a frontend is in maintenance/scaling, onboarding more people, or showing rot (every change touches everything, the global store keeps growing, only one person dares touch the core). The one move: make the architecture SELF-ENFORCING, so it doesn't depend on everyone remembering the rules — because at scale they won't. Triggers on "the codebase is getting hard to change", "enforce architecture / module boundaries", "lint rules for imports / layering", "circular dependency", "this abstraction is everywhere / should I delete it", "dead code / unused exports / stale feature flags", "Conway's law / team structure", "design system / Storybook / component library", "onboarding / how long until a new hire ships". There is no exit; it is a steady state.

Set up or harden a project's engineering process so quality has an automated floor instead of depending on anyone's discipline — version control & branching, code style, code review, CI/CD, and dependency/build management — tuned for a world where agents write much of the code and have no self-discipline to fall back on. Use when the user is bootstrapping or improving a team's workflow, choosing a branching strategy, setting up CI/CD or pre-commit hooks, defining a code-review process, enforcing lint/format, managing dependencies or reproducible builds, or fixing onboarding. Triggers on "set up CI", "git workflow / branching strategy", "how should we do code review", "add pre-commit hooks", "our builds aren't reproducible", "make this project team-ready".

The open-source discovery lens: find the few repositories worth your time — before you sink hours into the wrong one — in either mode finding happens in: TARGETED (a concrete need — the agent fans out every search seam in parallel and returns a ranked, deduped shortlist) or SERENDIPITOUS (no goal — the agent ranges the high-signal surfaces and brings back orthogonal finds, captured cheaply). The one shift: search-syntax mastery is COMMODITIZED, so your edge is the NEED-SPEC and which seams to mine, and serendipity is HARVESTED, not searched. Use when looking for a library, tool, framework, reference implementation, or alternative; when browsing for interesting projects; or when you keep hitting the same dead high-star repos. Triggers on "find a library/tool for X", "alternative to Y", "what should I use for", "is there a repo that", "show me interesting projects", "good first issue", "discover repos", "browse GitHub", "find open-source projects". Hands its shortlist to touchstone for evaluation.

The advanced visual layer for a frontend build — where icons, imagery, Canvas, WebGL, GPU, and generative technique live, and "three.js because it looks cool" gets decided. Use after the core visual language is set, when auditing the graphics layer, or when a UI has mismatched icons, layout-shifting images, or GPU surfaces that drain the budget. The one shift: the DOM is the default and the budget — you drop to Canvas / SVG / WebGL / GPU only where the DOM genuinely cannot go, always with a fallback and a budget, and icons come from ONE coherent set — the agent reaches for the GPU as a reflex, mixes icon families, and lazy-loads the LCP hero, feeling no wrongness, so these are gated. Triggers on "icon / icon set / SVG icon / aria-hidden", "image / hero / LCP / CLS / srcset / lazy load / AVIF / WebP / blurhash / illustration", "canvas / WebGL / WebGPU / three.js / shader / GLSL / SDF / raymarching / GPU / generative / procedural / data visualization / retina / devicePixelRatio / blurry canvas".

Discover and pin down what to build before building it, with a gated five-stage flow: elicit the real need (not the stated solution), analyze and prioritize, write verifiable requirements, validate shared understanding, and manage change. Use when the user asks for a feature, system, or change — especially a vague or solution-shaped one ("add an export button", "make it faster", "build me an X"); mentions requirements, specs, user stories, acceptance criteria, scope, stakeholders, MoSCoW, or non-functional needs; or before you start coding anything non-trivial whose real goal is not yet nailed down.

Attack your own system — under explicit authorization — to prove its defenses hold, before launch and continuously after: scope and authorize, recon, scan and enumerate, exploit and confirm real vulnerabilities (not scanner false positives), chain them into real impact, then report and re-test. The offensive half of the security pair (the spear) that proves what the aegis skill builds (the shield). Authorized, defensive penetration testing of systems you own or have written permission to test — never anything else. Use when the user wants to penetration-test their own application before launch, validate a fix actually closed a hole, stand up adversarial validation in CI or on a cadence, or learn to test for OWASP-class vulnerabilities on their own staging. Triggers on "pentest my app", "attack my own system", "is this actually exploitable", "pre-launch security test", "red-team my staging", "test for SQL injection / XSS / IDOR", "set up continuous security validation", "OWASP testing".

The distributed-correctness lens: design or audit anything that spans machines. Use when the user designs or reviews RPC, queues, replication, consensus, sharding, fault tolerance, or distributed transactions — or asks whether a design is correct. Triggers on "is this retry safe / exactly-once / idempotency", "ordering / timestamps across servers", "is this replication safe / split-brain", "eventual vs strong consistency / CAP / CP vs AP / linearizability", "do we need consensus / Raft / Paxos / etcd / ZooKeeper", "how should I shard this / partition / shard key / consistent hashing / hot key / rebalancing", "is this fault-tolerant / failure model / graceful degradation / circuit breaker / bulkhead", "two-phase commit / 2PC / saga / compensating transaction", "distributed lock / fencing token", "leader election", "should this even be distributed". The one shift: a remote call has a THIRD outcome — succeed, fail, OR leave you NOT KNOWING which — and the first law is don't distribute until you must.

Keep a software system cheaply changeable over its whole life — the phase that is 60–80% of total cost and most under-resourced — across: classifying and funding it, making technical debt visible and paying it down, refactoring safely under test, defects to root cause, evolving versions/APIs/deps without breaking callers or hitting EOL, and legacy and retirement — tuned for a world where an agent reaches for a rewrite, incurs debt invisibly, refactors without a net, and rots docs. Use when the user is maintaining or evolving an existing system, tackling technical debt or a big-rewrite temptation, refactoring, triaging bugs, evolving a version/API/dependency, or working or retiring a legacy/EOL system. Triggers on "manage technical debt", "should we rewrite this", "refactor safely", "the codebase is a mess", "deprecate this API / semver", "upgrade this dependency", "legacy system with no tests", "characterization tests / strangler fig", "our docs are stale", "bus factor", "sunset / decommission this service".

The visual-craft lens for a frontend build — where the surface gets its color, type, depth, and motion. Use after seaworthy's build works, when establishing or auditing a visual language, or when a UI "looks off". The one shift: a polished interface is not a pile of hand-picked values — every visual value is a TOKEN derived from a small SYSTEM, and ad-hoc values are the entropy that makes a UI look amateur and impossible to re-theme. Taste picks the system; the system enforces it. Triggers on "color / theme / dark mode / oklch / contrast", "typography / font / type scale / spacing", "shadow / elevation / depth / border-radius", "gradient / icon / image", "animation / transition / motion / gesture / spring", "design system / design tokens", "make it look good / polished", "it looks off / cheap / inconsistent". The benchmark is a human nervous system, not a document, so taste is load-bearing and cannot be outsourced; the agent picks plausible-but-incoherent values and feels none of the wrongness.

Design a system's architecture for the agent-assisted era: choose the architecture style, the stack, the module boundaries, the contracts, and the data model — concentrating scarce human judgment on the irreversible decisions and letting agents move fast behind the reversible ones. Use when the user is designing or restructuring a system, choosing between monolith and microservices, picking a tech stack or database, defining APIs or module boundaries, deciding how to realize non-functional requirements (scale, availability, security), writing an ADR, or about to build something structurally non-trivial. Triggers on "design the architecture", "what stack should I use", "monolith or microservices", "how should I structure this", "design the data model / API", "system design".

The delivery-and-observability lens for a frontend build — where the suite's ethics becomes a launch gate. Use when setting up delivery/monitoring, shipping a metric-driven change, or running an A/B test. The mindset shift: shipping is not the finish line but the start of the conversation with reality — so every change is made instantly visible and the real world is instrumented; and the moment the metrics dashboard is born it pulls every decision, so the objective function and guardrails from bearings come back here for their exam. A/B testing is a gradient-descent optimizer: aimed at an engagement metric over a human nervous system it DISCOVERS manipulation as a local optimum — the real villain is the loss function. Triggers on "deploy / CI/CD / preview deploys", "feature flags / progressive rollout / canary", "observability / monitoring / RUM / Web Vitals", "analytics / event tracking", "A/B test / experiment", "which metric should we optimize", "is this metric / experiment ethical", "dark pattern".

Audit code for craft — and write it craft-grade — so it stays cheap to read and change, across: intent-revealing names, small focused functions, why-not-what comments, earned abstraction (DRY but not premature), cohesion and low coupling, SOLID and patterns as guidance not dogma, trust-chain escape hatches (Any/cast/isinstance/getattr) contained at the edges, code smells, and testability as the design litmus — tuned for a world where an agent writes plausible-but-clever code, over-abstracts, names vaguely, rots comments, and is the next reader. The cross-cutting craft/legibility lens. Use when the user wants a code review or quality audit, asks whether code is clean or over-engineered, wants to tame a "clever" module, or mentions code smells, SOLID, patterns, DRY, or refactoring. Triggers on "review this code", "is this clean / readable", "code smells", "this is too clever / over-engineered", "naming", "should I use a design pattern here", "DRY this up", "audit code quality", "make this legible".

Build targeted account or contact lists using Common Room's Prospector. Triggers on 'find companies that match [criteria]', 'build a prospect list', 'find contacts at [type of company]', 'show me companies hiring [role]', or any list-building request.

The results-analysis lens: turn a finished results store into settled claims, mechanism evidence, and paper-grade figures — for any field running experiments to publish (ML, optimization, operations research, systems). Use when the runs are done and you are analyzing the results, or stress-testing an analysis. The one shift: analysis is NOT "compute a mean and see who is bigger" — it is audit, attribution, and the language of evidence. You audit before you read (a too-good number is a bug until proven otherwise); you prove WHY the method wins with mechanism probes; and you defend against the garden of forking paths, which the agent era amplifies because cheap experiments make cheating cheap. Triggers on "analyze the results", "read the main table / the ablation", "is this result significant / real / statistical test / effect size", "which is better", "make the figures / plots", "interpret these numbers / why does my method work", "the result looks too good", "review my results / write up".

The build-it lens for a frontend feature, with one inverted discipline: the happy path is ~40% done, not 90%, so you design the UNHAPPY paths first, not as a polish pass that never gets time. Use when building feature slices (after wellspring's state map), or auditing whether a feature is production-grade. The one shift: what you ship is not "a correct program" but a maintained ILLUSION of direct manipulation over a real, asynchronous, failing system — so loading / error / empty / edge states aren't afterthoughts, they ARE the product, and accessibility and a performance budget are built in from the first slice, not bolted on. Triggers on "build this component / feature", "loading / error / empty states", "optimistic update", "skeleton screen", "animation / transition", "accessibility / a11y / keyboard / screen reader / focus", "performance / Web Vitals / INP / LCP / CLS / bundle size", "it feels janky / slow", "race condition / stale response".

Take a system from "merged" to reliably serving users in production, and keep it there: deployment & release strategy, infrastructure-as-code & config, observability, monitoring & alerting, SLOs & incident response, capacity, cost, and backup/DR — tuned for a world where agents operate production and read a green dashboard as safety and silence as health. Use when the user is deploying or operating a service, choosing a release strategy (canary / blue-green / rolling / feature flags), setting up observability, monitoring or alerting, defining SLOs or an on-call / incident process, planning capacity or autoscaling, hardening backups / disaster recovery, or doing a production-readiness review. Triggers on "deploy / release strategy", "set up monitoring / observability", "our alerts are too noisy", "define SLOs / error budget", "on-call / runbook / postmortem", "canary / blue-green / feature flags", "how do we roll back", "capacity / autoscaling", "disaster recovery / backups", "is this production-ready".

Safety guardrails for autonomous agents. Intercepts destructive actions and vets skills, requires structured approval before irreversible operations, with CLI-backed cryptographic audit trails and policy enforcement.

The repository-evaluation lens: judge whether a repo is worth your time in a few minutes — by SCANNING its dashboards, not reading its code — scoring three axes: ALIVE, HEALTHY, and WELL-BUILT. The one shift: an agent can check fifty repos in seconds but over-trusts the two signals easiest to fake — star count and a polished README — exactly what an abandoned or AI-generated, star-farmed repo wears best; so touchstone INVERTS the weighting, discounting the gameable signals and weighting the un-fakeable ones (commit substance, issue-response quality, bus factor, real "Used by", tests and CI). Use when sizing up a repo or a batch before depending on, contributing to, or learning from it; or to vet a shortlist from forage. Triggers on "is this repo any good", "should I use/trust this library", "evaluate this project", "is this maintained", "is this AI-generated slop", "compare these repos", "vet this dependency", "rate this GitHub project". Hands deep-dive survivors to the engineering suite.

The correctness lens for a frontend build, organized around one question that decides whether your test suite is a safety net or a straitjacket: does this test go red when BEHAVIOR changes (a net — it warns on real regressions) or when the IMPLEMENTATION changes (a shackle — it reddens on every refactor, so you fix tests instead of code, and learn to ignore red). Use after seaworthy's slices exist, when writing or auditing frontend tests, or when a suite is brittle. The one shift: test BEHAVIOR, not internal structure — and put the test budget where frontend bugs actually cluster (integration: the seams, the two-graph drift, state out of sync), which makes the right shape a TESTING TROPHY, not the classic pyramid. Triggers on "what / how should I test this UI", "unit vs integration vs E2E", "testing-library / Playwright / Cypress / Vitest / Jest", "my tests break on every refactor", "snapshot tests", "should I mock this", "test coverage / 100%", "is this test worth keeping", "flaky tests".

The state-architecture lens for a frontend build — the heart of the system. Use after keel's skeleton works, when designing or auditing state, or when "it's out of sync" bugs keep appearing. The one shift: almost all frontend complexity comes from state having MULTIPLE COPIES (DOM, server DB, URL, localStorage) drifting apart — so the craft is to relentlessly CLASSIFY each piece of state into the one bucket that owns it, minimize the source of truth and derive the rest, and model hard interactions as explicit machines. Triggers on "state management", "Redux / Zustand / Context / signals / Jotai", "where should this state live", "derived state / single source of truth", "this keeps getting out of sync", "useEffect to sync state", "prop drilling", "should this be in the URL", "a form's state", "too many boolean flags / loading and error flags". The data-flow shift: the component tree and the data-dependency graph are different shapes, and every state tool is a bypass channel for when they disagree.