query-patterns

Implement read queries — paginated lists, search/filter/sort, and single-entity fetches — the FSH way (DbContext LINQ + PagedResponse). Use when adding GET endpoints. See also add-feature.

Quality

89%

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

Quality

Content

90%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.

An excellent single-file pattern skill: dense, project-specific, non-obvious guidance with complete template code, explicit negative patterns (what does not exist in this codebase), and clear decision boundaries for the Specification alternative. It would benefit only marginally from splitting the Specification/endpoint detail into a reference file and from an explicit ordering of the implementation steps.

Suggestions

Move the Specification section and possibly the endpoint-binding detail into a one-level-deep reference file (e.g. references/specifications.md) to keep SKILL.md as a lean overview.

Add a brief numbered implementation order (contract → handler → validator → endpoint) so the pattern's implicit sequence becomes an explicit workflow.

Dimension	Reasoning	Score
Conciseness	The body never explains concepts Claude already knows (no LINQ/EF/pagination primers) and concentrates on non-obvious project knowledge: "Tenant + soft-delete filters apply automatically — don't re-filter them", "overflow-safe offset", and the warning that there is "no generic repository and no PaginatedListAsync". Every token earns its place, matching the lean anchor 5.	5 / 5
Actionability	Complete, structurally copy-paste-ready C# for the search handler, single-entity handler, endpoint bindings, and the validator contract ("PageNumber >= 1, PageSize in [1,100]) — enforced by Architecture.Tests"), covering all common read cases. The {Entity}/{X} placeholders are the skill's substitution mechanism rather than pseudocode, so this fits the fully executable anchor 5.	5 / 5
Workflow Clarity	The material is clearly organized with explicit decision guidance ("When to use a Specification instead") and validation requirements stated, but it is a ~110-line pattern reference without an explicit multi-step sequence or feedback checkpoints. It exceeds the under-50-line simple-skill exception, so it fits anchor 4 (clear with minor gaps) rather than anchor 5's explicit checkpointed sequence.	4 / 5
Progressive Disclosure	The file has no bundle references but is well-sectioned (search query, single entity, endpoints, Specification guidance) and stays an appropriate single-file size. The Specification section and endpoint detail could be split into one-level-deep reference files, leaving minor organization gaps that fit anchor 4 rather than the well-signaled reference structure of anchor 5.	4 / 5
	Total	18 / 20 Passed

Description

83%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.

A strong description: it names three concrete capability areas with specific technology bindings, includes an explicit 'Use when' trigger, and clearly demarcates itself from the sibling write-path skill. The only weakness is a single narrow trigger phrase, which leaves a few natural trigger variations uncovered.

Suggestions

Broaden the 'Use when' clause with one or two natural trigger variations, e.g. "Use when adding GET endpoints, listing/paging endpoints, or search/filter/sort queries".

Include a common synonym or two (e.g. "list", "paging") so users phrasing the request differently still hit the trigger.

Dimension	Reasoning	Score
Specificity	"paginated lists, search/filter/sort, and single-entity fetches" lists multiple concrete action types with full coverage of the read-query scope, reinforced by concrete tech specifics ("DbContext LINQ + PagedResponse"). No minor gaps in coverage remain, so it matches the anchor 5 rather than 4.	5 / 5
Completeness	Both parts are present: a clear "what" ("Implement read queries — paginated lists, search/filter/sort, and single-entity fetches") and an explicit "when" ("Use when adding GET endpoints"). The "when" is a single trigger without variations or alternate phrasings, so it sits at anchor 4 rather than the multi-phrase concrete triggers of anchor 5.	4 / 5
Trigger Term Quality	Natural developer phrases like "read queries", "paginated", "search/filter/sort", and "GET endpoints" give good trigger coverage, but common synonyms such as "list endpoints", "paging", or "browse" are missing. Good coverage with a few natural terms missing fits anchor 4, not the comprehensive synonym coverage of anchor 5.	4 / 5
Distinctiveness Conflict Risk	The description is scoped to read-only queries in a named framework style ("the FSH way (DbContext LINQ + PagedResponse)") and explicitly partitions write work via "See also add-feature", giving it a clear niche with minimal conflict risk. This matches anchor 5 rather than the minor-overlap anchor 4.	5 / 5
	Total	18 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: fullstackhero/dotnet-starter-kit
Path: .agents/skills/query-patterns/SKILL.md
Commit: 0bd98e3

Reviewed: 4 days 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.