Agents Resources

Choosing and checking a resource

Start with the job you want an agent to do. For a Docker Compose draft, search for Docker and open the generator's instructions; review the suggested services, volumes and environment placeholders against your project. A prompt template asks an agent to produce a draft. It does not install Docker, validate a deployment or establish that the output is ready for production.

Choose the resource type before installing anything. Instructions and prompts are text to read and adapt. MCP configurations can connect an agent to another service, and plugin examples may refer to packages that must be obtained separately. Read the actual commands and requested permissions. Use a disposable project and synthetic data for a first check; avoid adding credentials to downloaded examples.

Search and filter metadata help narrow the list, but a compatibility label is an intended target, not a recorded test result. Open the listing and follow its source link when one is provided. Check the upstream version, installation instructions and license before copying, modifying or sharing material. An author name or an MIT label alone does not establish who owns every included file.

If a source, license, package or required capability cannot be verified, keep the resource out of a production workflow until that gap is resolved. Report the listing URL and the missing information to SimplyUtils through the contact page. Include a small non-confidential example of any instruction that fails, along with the application and version you tested.

For a handoff between two review roles, pass an evidence summary instead of an unexplained confidence label. In the fictional reservation task, the database review can state that the supplied write contract permits one reservation for each room-and-day key and that the owned conflict case rejects the second reservation. A writer can use that statement to explain a conflict response, while still asking for the actual response shape. The handoff must not say that a production migration ran, a customer booking was inspected or the system is universally race-free. This distinction preserves useful knowledge while preventing a bounded exercise from growing into an unsupported implementation claim.

Start with the decision you need a role template to support. For a fictional reservation system, correctness of room-and-day uniqueness belongs in a database review; explaining the accepted conflict response to users belongs in documentation; reviewing the cancellation dialog belongs in an interface review. Choosing one broad agent name for all three jobs can hide the different evidence each task needs. Use separate bounded questions and preserve the original contract when moving between templates.

Prepare a compact review packet before selecting a listing. The reservation packet can contain an empty initial table, two competing requests for room Blue on day 12, the expected one-accepted/one-conflict result and the relevant owned code. It does not need personal booking records. A performance packet for the same feature would instead contain measured durations and collection conditions. A design packet would contain the actual cancellation states. Those packets are not interchangeable merely because the product is the same.

Inspect what the directory gives you: instruction text and metadata that help describe intended use. Opening a role listing does not create a specialist process with credentials, query a database or install its named dependencies. Read the downloaded text before adapting it. If a suggested command or file is absent, write down the missing requirement instead of representing the template as a complete executable agent. The difference matters when a task requires repeatable behavior rather than a useful review outline.

Compare candidate instructions by their evidence demands. A useful database instruction asks for a schema, a workload and current constraints. A useful security instruction asks for the authorization policy and relevant implementation. A useful writer instruction links claims to supplied behavior. Prefer the one that fits the immediate question rather than a title that promises seniority. SimplyUtils organization attribution describes who supplied the example; it does not certify professional credentials or an independent expert review.

Use a small acceptance checklist for the response. In the reservation task, did it preserve the one-booking-per-room-per-day invariant, include the conflicting request and distinguish a test proposal from an executed migration? Did it leave missing engine and transaction details unresolved? In the documentation task, did it describe the conflict without inventing a status or a retry guarantee? These checks make the output inspectable even when you do not accept the generated recommendation.

When two templates disagree, retain the specific conflicting claims and ask for their evidence. A faster availability query does not solve competing writes, and a clearer dialog does not repair a server authorization defect. Separate those issues into the layers that own them. Do not average conflicting answers into a single confidence score or use a second model response as proof that the first one was correct. The project owner still needs to decide and validate an actual change.

Treat selection and execution as separate steps. Directory filters can narrow a reading list, but tags are not permission grants and intended compatibility is not an integration result. Run any adapted instructions in an owned disposable project with the appropriate assistant settings, then record the input, active rules and outcome. If the project is confidential, use synthetic contracts like the room reservation example first and review the selected provider processing before sharing real source.

Report a listing problem with a reproducible observation. Include its URL, the misleading statement or missing requirement and a redacted example showing why it matters. For an unexpected directory result, also include the chosen category, filter and search phrase. This gives an editor enough context to repair the resource without needing your credentials or private repository. Keep source attribution and unconfirmed template redistribution terms distinct from the licenses of applications named in the instructions.

For a concrete handoff review, invent two public notes labelled N1 and N2. The first agent may summarize N1, and the second may compare the completed summary with N1. Neither role may read N2 or publish a message. Keep the role assignment and permissions in a trusted controller rather than in the note text. Record the requested operation, the allowed identifiers and the service decision for each handoff. A second agent's agreement is not independent proof when both agents rely on the same unsupported claim or lack the original note.

Repeat that handoff with a missing note identifier and an instruction embedded in N1 demanding publication. The missing identifier should produce an explicit unresolved result, while the embedded instruction must not expand the controller's allowance. Inspect the actual proposed and accepted operations, not just the agents' conversational replies. If your environment cannot expose those records, state that the permission behavior remains unverified. Keep the invented data and observed outcomes with the template revision so later changes to agent roles, routing or tool access can be evaluated against the same exercise.

• Full-Stack Code Review Instructions - AI-generated pull-request review instructions with a tested stock-allocation counterexample. It does not run tests, inspect a repository or approve merges automatically.
• Application Security Review Instructions - AI-generated review instructions with a synthetic document-authorization exercise, evidence requirements and limits. No scanner or security certification is included.
• PostgreSQL Database Review Instructions - AI-generated database review instructions about schema design, query plans and migration steps. Validate proposed changes against your database and workload.
• Technical Documentation Review Instructions - AI-generated documentation instructions for drafting architecture decisions and API references. Check generated details against the actual implementation.
• Backend Performance Review Instructions - AI-generated inspection instructions about query patterns, memory and runtime performance. Confirm suspected bottlenecks with measurements rather than prompt output alone.
• Interface Review Instructions - AI-generated interface review instructions focused on existing layouts, native controls and accessible names, with a keyboard button exercise. No design or accessibility certification is implied.