Soft-prompt the LWC author with three load-bearing architectural questions before they create or substantially edit a Lightning Web Component — Communication, State, Responsibility. Always elaborates *why* each question matters with concrete what-goes-wrong examples, then asks. Skipping is allowed but logged in the response so the choice is conscious. TRIGGER when creating or substantially editing files under `force-app/**/lwc/**`, `examples/**/lwc/**`, or any `*.js` / `*.html` / `*.js-meta.xml` inside an `lwc/` folder. Also TRIGGER when the user mentions "new component", "split this component", "refactor this LWC", "props vs events", "wire vs imperative", "LMS", "pubsub", or "where should this live". Skip on tiny edits (typo fixes, single-line CSS, comment-only changes) — invoke only for changes that touch component contract, data flow, or boundaries.
Salesforce AppExchange Security Review patterns for 2GP managed packages — what manual reviewers accept/reject, anti-patterns to avoid, fix recipes. Derived from a real FlexibleTeamShare rejection (case study in body). TRIGGER when editing Apex (.cls/.trigger) or LWC (.js/.js-meta.xml/.html) in force-app/**, or when the user mentions "security review", "AppExchange", "FLS", "sharing violation", "CRUD", or reads appexchange-artifacts/**. Use to proactively steer code toward review-passing patterns and to flag the recurring anti-patterns that get packages rejected.
Verify every claim in the project's false-positive document (typically SECURITY-SCAN-FALSE-POSITIVES.md) against the actual code. Use when the user asks to "audit the false positive doc", "check FP doc", "verify false positives", or before submitting an AppExchange security review. Also invoke automatically when the user is about to submit, tag a release, or push an AppExchange package version. A real FlexibleTeamShare rejection was caused by a false claim in this doc — treat it as a load-bearing artifact and validate every assertion.
Catch patterns that work in LWR (Lightning Web Runtime) but break, silently misbehave, or get sandbox-rejected in Lightning Locker. Use when editing LWC code, when the user mentions "Locker", "LWR", "Experience Cloud", "Lightning Web Security", "LWS", "managed package", "AppExchange", "two worlds", or runs `/locker-check`. Especially relevant for AppExchange-targeted code where the package may install into orgs running Locker even if your dev org runs LWS/LWR. The runtime mismatch is silent — code passes locally and breaks for the customer — so flag aggressively.