Conciseness

The body is dense and assumes competence (no re-explanation of what XSS or SQL injection are) and mostly earns its tokens with project-specific rules, but it carries inline time-sensitive material — 'On 2026-04-29 the previous one-arg resolveCredential…', 'the 2026-04 cross-tenant leak class', 'MCP 2026 hosts' — outside any old-patterns/deprecated section, plus long incident narratives and guard-allowlist enumerations that could be tightened. Not 4 because the dated history and guard minutia are noticeable padding that could move to a reference file.

Actionability

Every rule ships copy-paste-ready executable code: defineAction with Zod schema, parameterized Drizzle/SQL, ssrfSafeFetch with options, resolveCredential with request context, getSession/401 handlers, accessFilter/runWithRequestContext route pattern, authorize and needsApproval examples. Runnable verification commands ('pnpm action db-check-scoping', 'pnpm prep' guards) and bad/good code contrasts cover the common cases.

Workflow Clarity

The custom-routes section gives a clear numbered 1-2-3 sequence, a closing checklist consolidates the rules, and CI guards plus db-check-scoping provide validation checkpoints. Not 5 because there are no explicit validate-fail-fix-retry loops, and the multi-section rule layout (appropriate for this reference-style skill) is not a single sequenced workflow.

Progressive Disclosure

Well-organized single file with clear section headers and clearly signaled one-level-deep pointers to related skills ('storing-data', 'actions', 'authentication') and spec files; no bundle files exist so everything is inline. Not 5 because at ~340 lines the guard-allowlist details and historical incident notes are content that could split into reference files, keeping the core rules leaner; not 3 because navigation is easy and references are explicit, not buried.

Specificity

Enumerates concrete capability areas — 'input validation, SQL injection, XSS, secrets, data scoping, and auth' — which names the domain with several specific practices rather than generic claims. Not 5 because these are topic areas rather than fully concrete actions and coverage has minor gaps (e.g. SSRF and approval gating are in the body but absent here); not 3 because the list is comprehensive and domain-anchored, not just 1-2 actions.

Completeness

Explicitly answers both: what ('Secure coding practices for agent-native apps: input validation, SQL injection, XSS, secrets, data scoping, and auth') and when ('Use when writing any action, route, or component that touches user data or external input') with concrete trigger phrases. Matches the 5 anchor directly.

Trigger Term Quality

Includes natural phrases users would actually say — 'SQL injection', 'XSS', 'secrets', 'auth', 'user data', 'external input'. Not 5 because common variations and synonyms ('vulnerability', 'hardening', 'exploit', 'injection attack') are missing; not 3 because the terms present are the natural vocabulary, not jargon-only.

Distinctiveness Conflict Risk

Clear niche (security for this agent-native framework) with distinct triggers tied to 'action, route, or component that touches user data or external input'. Minimal conflict risk — it scopes itself to the framework's security primitives rather than overlapping generic document/file skills.