Six Backend AI Skills: Review an Inventory API with Evidence

Treat a skill as instructions, not an installed service

A skill file supplies instructions that a compatible assistant may follow when you give it a task and context. It does not itself create an endpoint, apply a migration, start containers or verify authorization. This guide uses six entries in the skill directory to review an invented inventory API. The aim is to prepare changes someone can inspect and test, rather than grant an agent unrestricted access to production. Read the actual file and the host application's supported loading method before using it; an instruction path shown in one example is not a promise of compatibility with every assistant version.

Prepare an owned inventory scenario

Our example has two users and items with an owner identifier, a label and an enabled flag. User Ada owns a notebook; user Bo owns a lamp. The endpoint must return only the caller's items, and filtering enabled items must not convert false into true. Write those acceptance examples before requesting a review. Include a small schema, representative request and expected response, plus any actual framework constraints. Do not send a production dump or authentication secrets simply because an agent asks for more context. A synthetic fixture can expose the decision without putting another person's inventory into the review transcript.

Review the schema without granting migration authority

The Database Schema Reviewer can guide inspection of ownership relationships, nullability and deletion behavior. Ask which observation supports each proposed constraint and what existing rows would violate it. A recommendation to cascade deletion is a decision to review, not a harmless formatting preference. For our example, decide explicitly what should happen to an item when its owner is deleted and how an item without an owner is handled. Prepare a migration diff and representative data checks, but do not let an explanatory skill file stand in for a backup, rollback plan or authorized production migration.

Design the endpoint around the trust boundary

Use the REST API Endpoint Designer with a concrete contract: the authenticated caller's identity comes from trusted middleware, not an ownerId supplied by the browser. Ask for successful, invalid and unauthorized examples. A request from Ada that includes Bo's identifier must not expose the lamp. A nonempty JSON response alone does not test that property. Define status behavior for missing identity and malformed filters, then check it in the actual server implementation. Generated route code can still omit an authorization condition even when its surrounding explanation uses appropriate security terminology.

Check SQL results before discussing speed

The SQL Query Optimizer should receive the database type, query and relevant schema, with an execution plan when available. For the owned fixture, filter by both owner and the intended boolean condition, and compare the returned item identifiers before and after any rewrite. An optimization that returns Bo's lamp to Ada is incorrect regardless of its plan cost. An index suggestion needs evidence from the actual workload rather than a claim that every foreign key requires the same index strategy. The local example checks result membership and false values; it does not claim a production speedup or benchmark.

Keep container output reviewable

The Docker Compose Generator can organize a proposed development setup, but generated text is not a running or secured deployment. Check exposed ports, mounted directories, environment variable names and how data survives container replacement. Use invented credentials in an example file and supply real secrets through the approved environment mechanism. A dependency starting before another process is not evidence that the dependency is ready for requests. If Docker is unavailable, label the output as an unexecuted configuration proposal rather than reporting a successful startup. Keep production service changes outside this article exercise.

Make cache ownership part of correctness

Ask the Caching Strategy Advisor to explain cache keys, invalidation and the acceptable age of a result. In our inventory scenario, an items key with no caller identity could return Ada's cached list to Bo. An owned fixture uses distinct keys such as items:Ada and items:Bo and checks the retrieved value for each caller. That demonstrates separation for the small example, not a complete design for sessions, permissions or distributed invalidation. Specify what happens after an item changes and who may read cached data before adopting a faster-looking implementation.

Review authentication as a flow, not a label

The Auth Flow Planner can help enumerate sign-in, expiry and denial cases. Ask where identity is verified, which component attaches it to a request and what happens when a session expires during an action. Keep authentication distinct from authorization: recognizing Ada does not allow Ada to read every item. Have the agent identify its assumptions and unresolved provider settings rather than inventing a secure-by-default configuration. A document describing tokens is not a penetration test, and a generated checklist cannot establish that an existing production system implements the described flow.

Preserve attribution and judge the final diff

The linked source skills are mirrored from SimplyUtils' OpenAgentSkills repository, with source and license notices available on their pages. This article adds an independent inventory example and review sequence; it does not alter the upstream files or claim professional certification. Keep notices with redistributed source instructions and check the licenses of separate dependencies. Review the smallest proposed code diff, run owned success and denial cases, and record what remains untested. Sharing a skill with an assistant also shares whatever project context you provide under that assistant's settings, so remove confidential data before asking it to investigate further.

Published by .

Try the tools from this guide