Conciseness

Quotes: the Overview blockquotes 'Keycloak is a single sign on solution for web apps and RESTful web services', 'A realm manages a set of users, credentials, roles, and groups', 'Clients are entities that can request Keycloak to authenticate a user', and Step 3's 'the token endpoint accepts grant_type plus flow-specific params' explain Keycloak/OAuth concepts Claude already knows. The rest (code blocks, anti-patterns table, limitations) is lean, so this sits between anchor 2 ('several unnecessary explanations') and anchor 4 ('minor instances of over-explanation') — the ~18 lines of concept quotes are a real but bounded padding section. Not 4: more than a minor instance of over-explanation; not 2: the majority of the file is efficient executable content.

Actionability

Quotes: a runnable pytest fixture with a pinned image ('quay.io/keycloak:25.0'), a full executable password-grant test with assertions ('assert body["token_type"] == "Bearer"'), a client-credentials test, a jq secret-stripping pipeline, and CI yaml ('pytest tests/integration/auth/ -v'); Steps 5 and 7 delegate to references/endpoint-recipes.md, which exists and contains complete executable tests. Not 5: gaps remain — Step 6 says 'The exact pattern depends on the custom flow - consult the per-flow docs' with no code, and the reference's get_admin_token(keycloak) helper is referenced but never defined. Not 3: the guidance is real executable code, not pseudocode or high-level hints.

Workflow Clarity

Quotes: 'How to use' enumerates Steps 1-8 with cross-references ('Start Keycloak per test class with the Testcontainers module, pinning an explicit image tag (Step 1)'), and the worked example ties them together ('The test class starts ... (Steps 1-2) ... (Step 4) ... (Step 5)'). The sequence is clear and the test assertions serve as validation checkpoints. Not 5: there is no explicit verify step that the realm import succeeded (e.g., poll for realm availability) before tests hit the token endpoint, and Step 6's sequence is underspecified. Not 3: checkpoints are not merely implicit — status-code assertions and the deprecation guard ('use it only for legacy test scenarios') mark decision points.

Progressive Disclosure

Quotes: 'Full recipe: [references/endpoint-recipes.md](references/endpoint-recipes.md)' appears in Steps 5 and 7, the linked file exists with matching content (introspection and admin-API recipes), and sections (Overview, When to use, Steps 1-8, Worked example, Anti-patterns, Limitations, References) make navigation easy. Not 5: the split is thin — only one reference file carries offloaded detail while Steps 3, 4, and 6 keep full recipes inline; a per-topic split (e.g., custom-flow recipes) would match the anchor-5 pattern of well-signaled one-level-deep references across topics. Not 3: structure is good, references are clearly signaled and real, and nothing that clearly belongs in a separate file is deeply buried.

Specificity

Quotes: 'uses Testcontainers Keycloak module to spin up an isolated server per test class, imports realm JSON for fixtures, exercises OIDC discovery / token endpoint / token introspection / admin REST API; tests password / authorization-code / client-credentials / token-exchange flows; covers UMA ... permission tickets.' This lists multiple specific concrete actions with comprehensive coverage, matching the anchor-5 example (which lists several discrete actions). Not 4: anchor 4 is for 'several specific actions; minor gaps' — here the action list spans setup, fixtures, four endpoint surfaces, four flows, and UMA, leaving no notable capability gaps. Voice is consistently third person, so no penalty applies.

Completeness

Quotes: what — 'Authors and runs integration tests against Keycloak... exercises OIDC discovery / token endpoint / token introspection / admin REST API'; when — 'Use when the user works with self-hosted Keycloak and needs unit / integration tests for realms, clients, users, or auth flows.' Both what and when are explicit with concrete trigger phrases, exactly matching the anchor-5 example. Not 4: the when-clause is not merely present but specific (self-hosted, realms/clients/users/auth flows), so the anchor-4 caveat ('when could be more explicit') does not apply.

Trigger Term Quality

Quotes: 'integration tests against Keycloak', 'needs unit / integration tests for realms, clients, users, or auth flows', 'self-hosted Keycloak'. A user would naturally say 'Keycloak', 'integration tests', and 'auth flows', which are all present. Not 5: the anchor-5 example requires comprehensive synonyms/extensions (e.g., 'IdP'/'identity provider', 'SSO', 'testcontainers'); those natural variations are missing. Not 3: coverage goes well beyond 'some relevant keywords' — the closing when-clause enumerates the main nouns users would mention.

Distinctiveness Conflict Risk

Quotes: 'self-hosted Keycloak', 'Testcontainers Keycloak module', 'UMA (User-Managed Access) permission tickets'. This is a clear niche (Keycloak-specific test authoring) with distinct triggers that sibling IdP-testing skills (auth0-tests, okta-tests) would not match. Not 4: the minor-overlap caveat of anchor 4 doesn't apply because the description pins the trigger to 'self-hosted Keycloak' explicitly, minimizing conflict with generic OAuth or other-IdP skills.