mcpField
D
docyrus-api-doctor

docyrus-api-doctor

github.com/docyrusTesting & quality1391 installsUpdated 5w ago
Repository

About docyrus-api-doctor

docyrus-api-doctor is a post-implementation checklist skill for developers working with Docyrus API code. It groups checks into bugs, performance, and code quality, with detailed explanations and fix examples in a reference file.

Key features

  1. 01Checks API calls and query parameters
  2. 02Flags performance and data-fetching issues
  3. 03Reviews error handling and cache invalidation
  4. 04Provides detailed checks and fix examples

Use cases

  1. 01Reviewing changed Docyrus API logic
  2. 02Finding invalid query payloads
  3. 03Checking mutation handling and cache updates

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/docyrus/agent-skills --skill docyrus-api-doctor

After installing, type/docyrus-api-doctorin Claude Code to confirm it loaded.

Bundled filesreferences/checklist-details.md

Details

From the project README

Docyrus API Doctor

Post-implementation checklist for Docyrus API code. Run through each applicable check after writing or modifying API logic. Fix every issue found before considering the task complete.

How to use: After implementing API logic, scan the changed code against each check below. Skip checks that don't apply to the code at hand. For detailed explanations and fix examples, read references/checklist-details.md.


BUG — Will Cause Errors

#CheckWhat to look for
B1Missing columns parameterAny .list() or .get() call without a columns property. Without it, only id is returned.
B2limit: 0 in query payloadlimit set to 0 causes an API error. Remove limit entirely or set a positive integer.
B3Child query key not in columnsIf childQueries defines key orders, the string orders must also appear in columns.
B4Formula key not in columnsIf formulas defines key total, the string total must also appear in columns.
B5Aggregation via @ column syntaxUsing count@field or sum@field in columns. Use the calculations parameter instead.
B6distinctColumns with calculationsThese are mutually exclusive. Use calculations for aggregation.
B7Formula extract input countextract blocks must have exactly 1 input.
B8Formula not operand countnot blocks must have exactly 1 operand.
B9Formula and/or operand countand/or blocks must have at least 2 operands.
B10Formula math operand countMath operations (+, -, *, /, %) must have at least 2 operands.
B11Formula case without whencase expressions must have at least 1 when clause.
B12Uncast literal in jsonb_build_objectString literals inside jsonb_build_object need explicit "cast": "text" — auto-cast only works inside concat/concat_ws.

PERFORMANCE — Degrades Speed or Wastes Resources

#CheckWhat to look for
P1Unnecessary limit on aggregation queriesWhen using calculations without needing raw rows, don't send limit. Aggregation returns a single grouped result naturally.
P2fullCount just to get a total countIf you only need the count (not the rows), use calculations: [{ func: 'count', field: 'id', name: 'total' }] instead of fullCount: true with row fetching.
P3Unnecessary columns on calculation-only queriesWhen using calculations and only reading aggregated values, don't send columns. The calculation result is returned without needing column selection.
P4Over-fetching columnsColumns selected in columns but never read in the consuming code. Only select what you render or process.
P5Large limit without paginationlimit > 200 without offset/fullCount pagination risks slow responses and high memory usage.
P6Missing expand causing N+1Rendering relation/enum/user field .name but not including that field in expand. Without expand, you get only the ID.
P7Fetching rows for existence checksFetching records just to check if any exist. Use calculations count instead.
P8Redundant overlapping queriesMultiple queries on the same data source fetching overlapping columns that could be combined into one.

CODE QUALITY — Causes Maintenance Pain

#CheckWhat to look for
Q1Heavy as type assertions on responsesCasting API responses with as Array<...> without runtime validation. Prefer typed collection return types or add validation.
Q2Missing enabled on dependent queriesuseQuery that depends on a runtime value (e.g., recordId) but lacks enabled: !!recordId. The query fires with undefined.
Q3No error handling on mutations.create(), .update(), .delete() calls without try/catch or error feedback to the user.
Q4Missing query invalidation after mutationsAfter create/update/delete, related query keys must be invalidated so lists refresh.
Q5Serial cache invalidationsMultiple await queryClient.invalidateQueries(...) in sequence. Use Promise.all() for independent invalidations.
Q6Using deprecated expandTypesReplace with the expand parameter.
Q7Hardcoded data source pathsRaw client.get('/v1/apps/base/data-sources/project/items') instead of using generated collection hooks.
Q8distinctColumns without orderBydistinctColumns requires orderBy to define which row wins per group.

How to Run

  1. Identify all files changed in this task that contain Docyrus API calls
  2. For each file, scan for .list(, .get(, .create(, .update(, .delete(, client.get(, client.post(, client.patch(, client.delete(
  3. Check each call site against the BUG checks (B1-B12)
  4. Check query payloads against PERFORMANCE checks (P1-P8)
  5. Check surrounding code (hooks, error handling, invalidation) against CODE QUALITY checks (Q1-Q8)
  6. Fix all issues found, starting with BUG category

References

  • references/checklist-details.md — Detailed explanation, detection pattern, and before/after fix example for every check item

Comments

Markdown supported