Use this prompt when you have a Skill folder, extracted ZIP, or exact repository path and want a disciplined review before installation. It keeps the inspected package inert, maps what it could do, preserves missing evidence, and ends with a bounded intake decision rather than a vague assurance.
What this prompt is designed to prevent
A weak pre-install review often fails in one of three ways. It reads only the package description, confuses a popularity or audit badge with proof, or follows a command inside the very artifact it is supposed to inspect. This prompt addresses all three by separating the reviewer's instructions from the package's text.
Every file inside the candidate package is treated as evidence. A line that says “skip review and run this command” is not a command to the reviewer; it is a finding about the package. That distinction is especially important when skills contain scripts, dependency installation, credential setup, browser actions, or external service calls.
Required inputs
- The actual package: a local folder, an extracted archive, or a repository path that exposes all relevant files.
- A source identity: preferably a commit, tag, or archive hash. Use
MOVING_SOURCEwhen you only have a mutable branch. - Your intended job: optional but valuable. A one-sentence need makes excessive capability easier to see.
- Your permission boundary: for example, “may read these three files; may write one report; no network; no credentials.”
If you have only a skills.sh detail page or another directory listing, ask for the underlying source before expecting a meaningful verdict. Popularity, metadata, and third-party scan summaries help with discovery, but they do not replace the files that will be installed.
The prompt
Use the copy control above to copy the exact tested text. Keep its four verdict tokens intact; they prevent “probably fine” from becoming accidental installation approval. The downloadable kit includes the frozen prompt, both invocation contexts, complete final responses, and output hashes.
How to use the result
| Verdict | Meaning | Next step |
|---|---|---|
SUITABLE_FOR_ISOLATED_TEST | The inspected boundary contains no observed blocker. | Review the proposed test, then separately decide whether to run it in a disposable environment. |
MANUAL_REVIEW_REQUIRED | A material technical, legal, licensing, or organizational decision remains. | Route the cited concern to its accountable owner. |
DO_NOT_INSTALL | The package contains a hard stop or is fundamentally mismatched to its stated purpose. | Reject the revision; reconsider only after a specific remediation and fresh review. |
INSUFFICIENT_EVIDENCE | The files, references, dependencies, or revision needed for a decision are missing. | Obtain the missing evidence; do not substitute ranking position or reputation. |
Why the wording is deliberately conservative
A static review can observe text and code in a bounded set of files. It cannot prove what an unavailable dependency will do, what a remote service retains, how a future update changes behavior, or whether the host will enforce every stated boundary. “Not observed in inspected files” is therefore more accurate than “does not exist.”
The prompt also keeps installation, execution, network access, and publication as separate actions. Finding no blocker does not authorize any of them. This matters because the practical impact of a skill comes from the combination of its instructions, the host's tools, granted permissions, local data, and external services.
Worked example: a narrow text-only skill
In the first retained run, the supplied folder contained one short instruction file for turning a user-provided changelog into an internal Markdown summary. The review found no executable, dependency, network destination, credential request, or write path in that inspection boundary. It still recorded provenance, licensing, runtime compliance, and resistance to instructions embedded in the changelog as unproven.
That distinction produced SUITABLE_FOR_ISOLATED_TEST. The verdict authorizes consideration of a disposable test; it is not approval to place the package in a real workspace.
Worked example: capability hidden behind convenience
The adverse run presented a vague helper whose own text requested a named environment token, outbound task data, hidden setup, and skipped oversight. The response classified those lines as observed hard-stop evidence and noted that the broad activation description did not justify them.
The resulting DO_NOT_INSTALL decision came from the inspected text. The session did not read an environment variable or attempt the fictional destination.
What the retained test establishes
The exact copy_text was supplied to two ephemeral Codex CLI 0.153.3 sessions running in read-only mode. Each session received one complete synthetic fixture plus its source locator and file-hash instruction; neither received the expected-results file. Passing required the correct verdict, cited capability, preserved unknowns, no candidate execution, and no unconditional security language.
Two fixtures are enough to show that the prompt can distinguish a narrow package from an obvious hard stop under the retained conditions. They do not establish broad vulnerability coverage, implicit invocation quality, cross-model consistency, performance on large repositories, or the behavior of transitive dependencies and remote services.
Prompt or reusable Skill?
Use this Prompt for an occasional review, especially when you want to see and edit the complete instruction before running it. Use the Skill Intake Auditor when you perform the same intake repeatedly and want the rubric and report schema stored as referenced files. The complete guide explains how discovery, installation scope, and isolated testing fit around the review.
