A skill card on this site has two halves. The description is the publisher's pitch. The install prompt is the part that actually changes your agent. Most people read the first half and paste the second. That order is backwards.

This guide is the short audit we run before a prompt goes into a working agent. It assumes you already picked a card for a concrete job. If you have not done that yet, start with How to choose an agent skill and come back with one candidate.

Read the prompt as a list of permissions

A prompt cannot do anything the agent could not already do, but it can direct the agent to do it now, on your files, with your session. Read every verb as a permission request.

  • "Read the repository" means the agent will open files in the current workspace.
  • "Check the API" means a network call, and possibly a key from your environment.
  • "Clean up the folder" means writes and deletes.
  • "Review the thread" means pasting a conversation, which may contain other people's messages.
  • "Install the package" means executing code you did not write.

Write the list down. If a verb has no object, the prompt is vague, and a vague prompt is harder to stop. "Improve the document" is not a job you can audit. "Add a summary section to the top of this Markdown file" is.

A prompt that asks for more access than the job needs is not automatically malicious. It is simply unverified. The audit decides whether the extra access is worth the risk for this one task.

Look for instruction conflicts

The dangerous lines are not the ones that mention your job. They are the ones that tell the agent how to behave when something goes wrong.

Skip a prompt that tells the agent to:

  • ignore earlier system or developer instructions;
  • hide its steps, tool calls, or errors from you;
  • continue after a failed check without asking;
  • treat the prompt itself as higher priority than your current request;
  • approve, merge, deploy, or send anything without a human confirmation.

Any one of these removes the signal you need to catch a bad output. Two of them together are a reason to close the card. The directory may still list the skill; that does not make it safe to run.

There is a milder version of the same problem: a prompt with dozens of contradictory rules. One line says "always ask before writing"; another says "finish the task without interruption." The model will pick one, and you will not know which. Prefer a prompt short enough that you can explain its behavior out loud in under a minute.

Check what the output is supposed to be

A useful prompt names an artifact: a diff, a table, a PDF, a lesson plan, a test file. It also says what the agent must not invent.

Look for a refusal. "Do not add citations you cannot verify." "Do not add packages not already in the manifest." "Do not send the file to a remote service." A refusal is a test you can run. A prompt that only lists capabilities will agree with whatever you ask, including a bad idea.

Then check the examples. If the example input is a tidy dataset and your input is a messy export, the prompt has not been tested on your case. That is not a defect by itself, but it changes the first run: use a small, fake input before the real one.

Run the five-minute audit

  1. Copy the prompt into a scratch document. Do not paste it into the agent yet.
  2. Highlight every noun that is an input: file, folder, URL, key, chat history, database.
  3. Highlight every verb that changes state: write, delete, send, post, install, deploy.
  4. Mark every line that changes the agent's default behavior: ignore, skip, hide, auto-approve, continue.
  5. Decide whether the job needs each highlighted item. If not, remove that sentence before the first run.

The output of the audit is a shortened prompt, not a verdict. Removing "also reorganize the rest of the drive" from an office skill usually leaves a better skill. If the prompt stops working when you remove the extra permissions, that tells you what the publisher was actually optimizing for.

Test with an input you can afford to lose

The first run belongs in a scratch folder, a copy of the file, or a throwaway branch. Use an input whose contents you already know, so you can tell whether the output invented something.

Good first inputs are small:

  • three rows of a spreadsheet with one missing unit;
  • a ten-line Markdown file with an obvious typo;
  • a route that returns every row, where the job is to add pagination;
  • a fake customer brief with names removed.

Ask for one artifact. Read the diff or the file before you read the agent's summary. If the summary says it updated three sections and the diff shows one, the summary is the part that lied.

If the skill asks for a credential, use a key scoped to the scratch resource. Never paste a production secret into a chat to test a prompt. A prompt that cannot run without a production key is not a prompt you should test casually.

Decide what to keep

Keep the skill when all of these are true:

  • the artifact matched the job on a real-enough input;
  • the diff or output was limited to what you asked for;
  • no new dependency, file, or network call appeared without a reason;
  • you can remove the prompt and return to your previous setup.

Remove it the same day when any of these happen:

  • it touched files you did not name;
  • it invented a citation, price, or API endpoint;
  • it asked for a key or a file it did not need;
  • it silently retried after a failure instead of reporting it.

Removal is part of the audit, not an admission that you chose badly. The install, update, and remove guide has the cleanup steps.

What the directory can and cannot tell you

The card tells you the publisher, the category, the install prompt, and the upstream link. It does not tell you whether the prompt is safe, current, or right for your repository. Downloads and the directory score tell you the listing has been copied around, not that someone audited it.

When a card carries an editor's note, that note is our writing, and it says who should skip the item. Read it before the publisher description. When there is no note, you are reading the publisher's material, and the audit above is the review.

The point of the audit is not to find a perfect skill. It is to make the first run small enough that a mistake is cheap. A prompt that survives a fake input, a scratch branch, and a removal is a prompt you can consider for real work.