A skill can guide an agent to read files, create artifacts, install dependencies or run commands. Before giving it a real project, decide which of those actions your task needs. A useful first run has a small input, a separate working folder and an output you can inspect. This checklist uses actual SkillPick demonstrations to make those decisions concrete.
Source review, an example output and agent compatibility answer different questions. A source review describes the instructions and distribution terms inspected. A demonstration shows one application or utility execution. Agent compatibility requires evidence that the particular agent discovered and used the skill successfully. None establishes that every possible future command is safe.
1. Identify the download you are reviewing
Start on the resource detail page. Read the package version, requirements, permissions, review notes and supported-agent status before downloading. Keep the ZIP name and its published SHA-256 together in your notes. A matching hash establishes that your file matches the listed package; it does not establish the absence of malicious instructions or defects.
For example, Marketing Ideas includes its category references. Copying only SKILL.md would remove part of the material used in the weekly content example. Extract the complete skill folder and retain the license and supporting files. The getting-started guide explains the expected folder structure.
2. Read the instructions before enabling tools
Look for actions involving shell commands, network requests, credentials, installations, deletion or publishing. Ask whether each is necessary for your immediate goal. Instructions are material for the agent to interpret; review the actual proposed command and its destination before execution.
With Internal Communications, a supplied fact list is enough to draft an update. The actual text output contains Progress, Plans and Problems for a fictional studio team. Reproducing that task does not require connecting a workplace account or reading a real mailbox. Supply a short approved brief when it meets the task’s needs.
3. Separate local artifacts from external effects
Writing a draft and sending it are different actions. Rendering a page and deploying it are different actions. Keep approval at the point where your work changes an external system, and make the artifact reviewable first.
The weekly marketing plan illustrates this boundary. Its five drafts retain [DEMO_LINK_PENDING]; no campaign was published, no email was sent and no event attendance was recorded. Before adapting it for a real business, verify the product facts, confirm consent for email, replace the destination and obtain editorial approval. A finished-looking document can still contain deliberately unresolved operational details.
4. Check dependencies and the execution environment
Read dependency files and tool versions before installing anything. Use a disposable project for an unfamiliar executable workflow, with only the files the task requires. Keep credentials out of prompts, screenshots and generated artifacts.
Slack GIF Creator has a real generated GIF and recorded utility validation. That evidence covers the small fixture: 128 by 128 pixels, 20 frames and two seconds. It does not demonstrate a Slack upload. HyperFrames CLI has an actual local MP4 render; its tutorial records versions and a browser-download workaround. Check those conditions before expecting the same workflow on another machine.
5. Inspect the result against the input
Review claims, links and missing information, as well as visual appearance. For text, compare each public statement with the supplied facts. For a page, test its controls and inspect narrow layouts. For media, open the final file and check duration, dimensions and audio expectations.
The Frontend Design example has a real page and screenshots, but the studio is fictional and no booking backend is connected. The Theme Factory output applies an explicitly selected palette to a report; it does not establish automatic theme selection. These limits tell you what a useful next test should cover in your own project.
6. Record what actually happened
Keep the prompt, input version, output file, relevant tool versions and the checks you performed. Record failures and workarounds alongside successes. Use specific descriptions such as “opened the HTML at two widths” or “validated GIF frame count,” rather than a blanket “tested” label.
Recheck when the package, agent, dependencies or requested permissions change. A successful fixture remains useful evidence for that fixture, with its date and environment. For choosing a starting task, Agent skills with real examples maps six resources to their actual artifacts and the remaining checks.