Compare documented permissions and data boundaries with actual code to find meaningful gaps. Produce findings that connect each documented rule to implementation evidence, identify who could exploit it and who is affected, and propose a concrete fix.
The method for finding the gap between what a system is supposed to do and what the code actually does — the class of bug generic scanners miss because they have no model of intent. Defines what counts as documented intent, what counts as implementation evidence, which mismatches matter, and how to avoid hand-wavy findings. Use when auditing AI-built code, reviewing access control against documented permissions, or checking whether a codebase matches its own documentation.
Review the instructions the agent will receive before you install.
A linter scans code in a vacuum. It can tell you the code is internally consistent; it cannot tell you the code does what you meant, because it has no model of your intent. The highest-value security and correctness bugs live in that gap — a permission documented but never enforced, a "cron-only" endpoint anyone can call, a field marked public-only that leaks private data.
This skill is the method for finding that gap. It is the differentiator: it only works when intent has been written down first (see the shipping-artifacts skill), and that's exactly why commodity tools can't replicate it.
Use this when documented intent exists — permissions.md, architecture.md, variables.md, etc., or the repo's own equivalents under whatever names it uses. If those docs are absent or stale, that absence is itself the first finding: you cannot audit intent you never recorded. Recommend documenting first, then auditing.
Establish intent. Read the system docs, wherever the repo keeps them (documentation/*.md by default; see the shipping-artifacts skill), as the source of truth for what should be true: who may access what, which boundaries are trusted, which data is public. Treat the docs as claims to verify, not as proof.
Gather implementation evidence. Read the code that enforces (or fails to enforce) each claim. Evidence is a cited file and line — the actual authorization check, the actual query filter, the actual sanitizer. "It's probably handled upstream" is not evidence; the code path is.
Compare claim to code, one boundary at a time. For each documented rule, ask: does an enforcement point actually implement it, on the server, on every path? Distrust comments like "internal only," "admin only," or "validated elsewhere" — verify them in code.
Classify each mismatch by whether it matters. A mismatch matters when crossing it lets a real actor reach data, money, infrastructure, or another tenant they shouldn't. It does not matter when the only person affected is the actor themselves on their own data. Drop cosmetic drift; keep boundary-crossing drift.
Avoid hand-wavy findings. Every finding names: the documented intent (quote the doc), the implemented reality (cite the code), the attacker and victim, and the concrete fix. If you cannot cite both sides of the gap, it is a question to investigate, not a finding to report.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Analyze A/B test results to decide whether to launch a change, extend testing, stop, or investigate further. Check sample size, statistical significance, uncertainty ranges, and effects on other important metrics, then summarize the recommendation and next steps.
Organize customer feature requests into themes and rank the top three against product goals, customer value, effort, and risk. For each recommendation, explain the underlying need, possible alternatives, uncertain assumptions, and simple ways to test them.
Compare growth options across existing and new products and markets using the Ansoff Matrix, a four-part planning framework. Assess opportunities, resources, competition, and risks, then develop market launch plans and a phased roadmap for priority options.
Choose the first customer segment for a product launch by comparing urgent needs, willingness to pay, achievable market share, and referral potential. Get scored recommendations, a priority segment, a 90-day acquisition plan, and expansion options.
Plan low-effort experiments to check assumptions about an existing product before building a feature. Compare prototypes, A/B tests, and other methods, with a clear assumption, procedure, metric, and success threshold for each experiment.
Turn a new product idea into a testable hypothesis and two or three simple experiments. Define target customers, expected actions, measurement methods, and success thresholds to assess demand through behavior such as sign-ups, pre-orders, or paid commitments.