auth-implementation-patterns

Implement or review authentication and authorization with explicit token, session and resource-access boundaries.

Quality

55%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/auth-implementation-patterns/SKILL.md

Quality

Content

57%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is concise and well-structured with a useful worked example and honest limitations, but its instructions are high-level directives rather than executable guidance, the main workflow lacks inline validation checkpoints, and the referenced playbook file is missing from the bundle.

Suggestions

Provide the missing `resources/implementation-playbook.md` (or correct the path) so the progressive-disclosure reference resolves to a real file.

Add concrete, executable guidance to the Instructions (e.g. a token-validation code snippet or a session-regeneration pattern) instead of only directive verbs.

Insert an explicit validation/checkpoint step into the main Define->Choose->Design->Plan workflow (e.g. 'verify token claims and tenant policy before granting access') for the destructive/access-control operations.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean bullet points that assume Claude's competence and avoid explaining what auth is; the only padding is the buzzwordy intro ("industry-standard patterns and modern best practices"), which is a minor instance of over-explanation that could be trimmed rather than the verbose 3-anchor pattern.	4 / 5
Actionability	Instructions name concrete targets (session, JWT, OIDC, RBAC, rotation, audit) but stay at the directive level ("Define...", "Choose...", "Design...", "Plan...") with no executable specifics, and the only escape hatch for examples points to a playbook file that does not exist, leaving guidance incomplete.	3 / 5
Workflow Clarity	A rough sequence exists (Define -> Choose -> Design -> Plan) and the Worked example does include verification ("verify that the old cookie cannot access /api/profile", test failed login/logout), but the main instruction workflow lacks explicit validation checkpoints for credential and access-control changes, so the cap-at-3 guidance for risky operations without inline checkpoints applies.	3 / 5
Progressive Disclosure	Sections are well-organized and the playbook reference is clearly signaled in a dedicated Resources section, but the referenced `resources/implementation-playbook.md` does not exist in the bundle, so the one-level-deep reference is broken, which prevents a 4 despite good overall structure.	3 / 5
	Total	13 / 20 Passed

Description

53%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description states a clear purpose and domain with useful boundary framing, but lacks an explicit 'when to use' trigger clause and is missing common synonyms (login, OAuth, SSO) that users naturally say. It is distinct enough to avoid most false triggers.

Suggestions

Add an explicit 'Use when...' clause naming concrete triggers such as login, OAuth2/SSO, JWT, session management, or RBAC work.

Include natural synonyms users say (login, sign-in, OAuth, SSO, JWT, RBAC) alongside 'authentication and authorization' to improve trigger coverage.

Consider listing a couple more concrete actions (e.g. enforce token lifecycle, verify resource-access policy) to lift specificity above the 1-2-action anchor.

Dimension	Reasoning	Score
Specificity	Names the domain and two concrete actions ("Implement or review authentication and authorization") plus boundary specifics ("explicit token, session and resource-access boundaries"), but it is not a comprehensive list of multiple distinct actions, so it sits at the anchor for 1-2 concrete actions rather than the 4-anchor's 'several specific actions'.	3 / 5
Completeness	The 'what' is clear (implement/review auth with token, session and resource-access boundaries), but there is no 'Use when...' clause or equivalent explicit trigger guidance in the description field, and per the judging guidelines a missing when-clause caps completeness at 3.	3 / 5
Trigger Term Quality	It includes the core natural terms ("authentication and authorization", "token", "session") a user would say, but omits common synonyms and variations users also say (login, OAuth, SSO, JWT, RBAC, .well-known), matching the 'some relevant keywords but missing common variations' anchor.	3 / 5
Distinctiveness Conflict Risk	"authentication and authorization" with explicit token/session/resource-access boundaries carves a clear niche with only minor overlap risk against adjacent security skills; it is not quite the 5-anchor's minimal-conflict case because 'implement or review' is somewhat broad.	4 / 5
	Total	13 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: sickn33/agentic-awesome-skills
Path: skills/auth-implementation-patterns/SKILL.md
Commit: b1aebac

Reviewed: ~15 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.