security-pagelisted

# Security Page A security page is the sales asset engineering can ship in a week. Buyers' security reviewers read it before they email you, and a concrete one closes early- and mid-market deals that a badge wall never will. The bar is Tailscale: their page leads with their actual trust model and gets technical fast, because their audience can tell the difference. This skill produces a page that survives vendor review without an auditor. ## Before you start Check for `.agents/devtool-context.md` and read it if present (stage, stack, and buyer persona decide how deep the page goes). If absent, ask: 1. What customer data do you hold, and what's the *worst* thing you could leak or break for a customer? 2. What's actually true today: cloud provider, encryption defaults, who on the team can touch production, which vendors see customer data? 3. Has anyone asked for SOC 2 yet, or is this preemptive? Question 2 matters most: this page can only contain things that are true. The interview surfaces both the claims you can make and the gaps that become the backlog artifact. ## The page, in order of consequence ### 1. Lead with your most sensitive surface Every generic security page opens with "we take security seriously." That phrase is a tell, because reviewers pattern-match it to "nothing specific to say." Ban it. Instead, identify the worst thing you could leak or break for a customer, and open the page with exactly how you protect *that*: - A feature-flag service leads with