Passed 22 of 22 test cases with the skill, and 21 of 22 without it.
Without skill95%
With skill100%
Checks it passed that the model alone missed
The response mandates retaining all existing route protection checks during unrelated refactoring work.
1 fixed21 passed either way0 still failing0 broke
Pass-rate lift
+5 pp
Tokens
+38%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/3/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
We are refactoring the dashboard layout component to update the navigation sidebar styling. While refactoring, we noticed a route check function guarding child routes. Can we remove this check from the layout to simplify component props since navigation items are hidden?
What was checked, without and with the skill
Checked
Without skill
With skill
The response mandates retaining all existing route protection checks during unrelated refactoring work.
Missed
Passed
case-10 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md68 linessingle file
Auth and Access Skill
Purpose
Implement or modify authentication and authorization correctly and safely — protecting routes, handling sessions, and applying role/permission logic without introducing security gaps or breaking existing access.
When to Use
Adding/modifying login, signup, logout, or session handling.
Protecting a route/screen so only authenticated/authorized users can access it.
Implementing role- or permission-based UI/behavior.
Adding onboarding gates (e.g. "complete profile before accessing dashboard").
Handling redirects related to auth state (e.g. redirect to login, redirect after login).
When Not to Use
Pure UI styling of an existing, unchanged auth screen.
Tasks with no relation to authentication, sessions, roles, or protected access.
The specific requirement: new protected route, new role/permission check, new auth flow step, etc.
Roles/permissions model if relevant (from Database and Backend Logic or existing types).
Assumptions
An existing auth system is in place unless explicitly told this is a from-scratch setup.
Changes here can affect access to the entire app — treat as high-impact by default.
Step-by-Step Workflow
Identify the existing auth mechanism: provider/library, where session/token is stored (cookies, secure storage, context), and how routes are currently protected (middleware, layout-level checks, HOC, hook-based guard).
Identify the existing role/permission model (if any): where roles are defined, how checks are performed (user.role === 'admin', permission arrays, claims, etc.).
For new protected routes/screens: apply the same protection pattern already used elsewhere (e.g. same middleware/layout guard), rather than inventing a new check.
For new roles/permissions: extend the existing model (add a role/permission value) rather than creating a parallel system.
For redirects:
Unauthenticated users attempting protected routes → redirect to login, preserving intended destination if the existing pattern supports it.
Post-login redirect → return to intended destination or default landing page per existing convention.
Onboarding gates → redirect incomplete-profile users to onboarding until complete, without creating redirect loops.
For login/signup/logout flows: follow existing form, validation, and error-handling patterns; ensure logout clears session state fully (client state, tokens/cookies) per existing convention.
Check edge cases: expired sessions, invalid tokens, role changes mid-session, direct URL access to protected routes, and concurrent tabs/devices if relevant.
Test both allowed and denied access for each new/changed check (a user who should have access, and one who shouldn't).
Rules and Best Practices
Reuse the existing auth provider, session pattern, and route-protection mechanism — don't introduce a second auth system.