Reviews a design or change for security before it ships — authentication and authorization, data handling, secrets, dependencies, and the secure-development practices around it. Use this to review an architecture or pull request for security, set secure coding standards, choose or tune SAST and DAST tooling, assess a third-party integration, or decide whether a design is safe to build.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Attention spent in this order finds the most consequential problems first.
1. Authentication. How identity is established, how sessions are represented, how they expire, what happens on password reset and account recovery. Recovery flows are the most commonly weakest path into an account and the least reviewed.
2. Authorization. The one that matters most and gets least attention. For every endpoint and every object: who is allowed, and where is that checked? The characteristic failure is checking on the way in but not on the object itself, so any authenticated user can reach any record by changing an identifier.
Check multi-tenant isolation explicitly and by test, not by reading. Assume every identifier in a request is attacker-controlled, because it is.
3. Data. What is collected, where it goes, where it rests, and who can read it. Sensitive data in logs, in error responses, in analytics payloads, and in client bundles — all four are routine findings.
4. Input and output. Untrusted input reaching a query, a template, a command, a deserializer, or a URL the server fetches. Parameterize rather than escape. Validate against an allowlist rather than a denylist.
5. Secrets. Never in source, never in client bundles, never in build logs. Rotatable, scoped to what needs them, and with a documented rotation path that someone has actually walked.
6. Dependencies and supply chain. What is pulled in, how it is pinned, how updates are reviewed, and what would happen if a maintainer account were compromised. Lockfiles committed, builds reproducible.
Look for: new endpoints without an authorization check, new external input, changed authentication or session logic, new dependencies, anything touching cryptography, and anything that widens what a role can do. Everything else is usually lower yield.
Never write your own cryptography. Use the vetted primitives, and be suspicious of any diff that implements a comparison, a token, or a signature by hand.
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
By name today: Semgrep, CodeQL, or SonarQube for SAST; Snyk, Dependabot, or Trivy for dependencies; Burp Suite or OWASP ZAP for DAST; gitleaks, TruffleHog, or GitHub secret scanning for secrets — and similar in each category.
Automation is a floor, not a review. It finds known patterns, not design flaws — and design flaws are what actually cause the expensive incidents.
What data leaves, under what agreement, with what access, and what happens if they are breached. Scope credentials to the minimum, prefer short-lived tokens, and know how to revoke without an outage.
Findings by severity, each with: the concrete attack, what the attacker gains, whether it blocks release, and the specific fix. A finding with no attack path stated is a preference.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, manage service and machine credentials, or diagnose why permissions have sprawled.
日本語の概要は準備中です。原文の説明を表示しています。
Concentrates marketing and sales effort on a named set of accounts rather than on volume — qualifying whether the model fits your economics at all, building the account list and the buying group inside each, tiering effort against account value, coordinating so the account experiences one campaign rather than several, and measuring account progression instead of leads. Use this to decide whether to run an account-based program, build one, or work out why an existing one produces activity and no pipeline.
日本語の概要は準備中です。原文の説明を表示しています。
Gets new users from signup to first real value — signup flow, onboarding, time-to-value, and the early experience that determines whether someone becomes a user or a lapsed account. Use this to design or fix signup and onboarding, diagnose why signups do not convert to active use, reduce time-to-value, or decide what a new user must accomplish first.
日本語の概要は準備中です。原文の説明を表示しています。
Designs orchestrator-and-subagent hierarchies for a repository — splitting agents by exclusive write surface, pairing every producer with an independent auditor, and enforcing the split with a script that runs in CI. Use this whenever the user wants to set up, expand, audit, or fix a multi-agent or subagent structure for a codebase; asks how to divide work between agents; wants agent charters, roles, or a surface map written; or is hitting agents that collide on the same files, review their own work, or drift from their remit. Also use when sizing a roster or deciding whether a new agent is justified.
日本語の概要は準備中です。原文の説明を表示しています。
Governs models and AI systems in production — intended use, evaluation, monitoring, human oversight, documentation, and the decision to deploy or retire. Use this before deploying a model or AI feature, when defining evaluation criteria, when a model's behavior has drifted, when assessing AI risk or regulatory exposure, or when deciding whether an AI system is fit for a consequential decision.
日本語の概要は準備中です。原文の説明を表示しています。
Produces executive-level research — market sizing, competitor mapping, trend analysis, and strategic intelligence — grounded in cited sources with the confidence in each claim made explicit. Use this to analyze a market or industry, map competitors, evaluate a market-entry or build-versus-buy decision, produce a research brief, or assemble evidence for a decision. Also use when comparing options that need a structured, evidence-based verdict rather than an opinion.
日本語の概要は準備中です。原文の説明を表示しています。