Use three requests to make skill discovery reviewable
A fictional community history team is preparing a small exhibition website. Its organizer wants a clearer event page, a reproducible check of the registration form and a handoff another volunteer can maintain. The organizer does not know the names of available skills. A useful discovery workflow starts with those outputs, not a promise that a particular sentence automatically installs the perfect package. The three situations below preserve the original article's progression: finding an unfamiliar capability, comparing known categories, and noticing a capability gap while a task is already underway. They use original examples and separate search, installation, execution and acceptance. No package was installed or tested for this article. A search result is a candidate, a downloaded directory is an artifact, and a verified task result is a different piece of evidence.
Before the phrases: establish what is actually available
A finder is a method for locating capabilities, not a universal permission grant. Confirm that the intended package is present in the actual agent environment, that its SKILL.md and referenced resources can be read, and that its description matches discovery work. A directory with a plausible name is insufficient evidence. A generic answer to “can you find a skill?” is also insufficient: the agent could answer using ordinary search without loading the intended finder. For SkillPI discovery, identify the official SkillPI Skill Finder source, its pinned revision, license and installation prerequisites before adding it. Keep that provenance distinct from a similarly named marketplace package or the competitor finder described in the originals. This article does not invent a SkillPI catalog identifier for the finder. If the live repository cannot be reached during review, retain the previously recorded revision as historical evidence and state that current availability was not revalidated; do not describe a failed fetch as a fresh verification. Record the agent, environment, project path, candidate destination and expected write scope. Local and remote sessions may see different directories. Inspect helpers and dependencies before execution, particularly scripts that download packages, modify configuration or contact external services. Use the agent's current official installation and invocation guidance. Do not infer that a phrase overrides platform controls, organizational policy, package licensing or per-action approval requirements.
Scenario one: describe a capability whose name you do not know
Use this request: “Find a skill that can help produce an accessible exhibition event page from our approved text. I do not know the package name. Return the strongest suitable candidate, its source and limitations before any installation.” The output should explain the task fit, not just list titles. Include the existing framework, editable deliverable, language, asset rights and a simple acceptance path. An event page that must remain in a React repository is different from a static poster or a hosted page builder. For this particular implementation step, Frontend Design is a verified SkillPI candidate. Its recorded pinned source is Anthropic's skills repository under Apache-2.0. It fits interface implementation and design decisions, given the project context. It does not conduct audience research, supply image rights, establish accessibility conformance or publish a site by itself. That boundary belongs beside the recommendation so the organizer knows what remains to be done. Ask for the smallest useful deliverable: a page section with event title, date, location and a clear registration action using approved content. Establish mobile behavior and keyboard checks before generating code. The finder should explain why this package fits better than a diagram generator or a static graphics package. If none fits the project's constraints, a manual implementation may be the correct outcome. A discovery workflow has not failed merely because it declines to install an unrelated package. Installation intent can be added explicitly: “Install the selected package from the reviewed source into this project's supported skill location, preserve existing work, then continue with the agreed page section.” This clarifies scope but does not eliminate prerequisites. The resulting record should show exact source, destination, resources retained and discovery status. If another approval is required for an unexpected action, explain the concrete action instead of treating a general request as unrestricted authorization.
Scenario two: compare candidates against a known task
Use this request: “I need repeatable checks of the local exhibition registration form. Compare up to three suitable candidates by supported inputs, environment, dependencies, license and evidence quality. Pick the best fit for our acceptance cases; do not rank by install count.” This is a bounded comparison, not an instruction to fill three slots even when only one candidate is plausible. Write the comparison criteria first. The page is local, the server start command is known, fixtures contain no private visitor data, and the goal is to check form behavior rather than scan a public site. The acceptance cases include missing required fields, a successful test submission, server failure feedback and retaining input after an error. Identify separately any need to confirm backend persistence or message delivery. A browser screenshot cannot establish either of those outcomes alone. Webapp Testing fits the local browser path step. Its recorded pinned Anthropic source and Apache-2.0 license have been checked. It supplies Python Playwright-oriented guidance for observing and interacting with a running application and collecting screenshots or logs. Prerequisites include a known startup command, port, dependencies and approved fixtures. It is not a security certification, a complete screen-reader evaluation or an installation manager. A useful recommendation says why the inputs match and what the package cannot prove. An alternative oriented toward static source analysis might help a different question, but would not replace interaction with the prepared form states. If an option requires a cloud account, external upload or a new runtime, include that integration cost instead of hiding it behind a high rating. Never send a private repository or real visitor records to a candidate service merely to complete a comparison. After selection, keep the proposed installation and test plan concrete. Capture the existing baseline, install only the chosen package where supported, confirm discovery and execute the agreed cases. The final evidence should identify the tested revision, fixtures, command or interaction sequence, observed result and remaining gaps. If startup fails, report an unexecuted test rather than a successful skill demonstration.
Scenario three: let the task expose a missing capability
Use this request: “Continue building the exhibition page. If a step requires a capability you do not have, identify the gap and search for a suitable method. Prefer existing tools and packages already available. Keep any new dependency or service within the agreed scope.” This allows proactive reasoning without promising invisible, automatic installation for every task. For example, the agent may finish the page and recognize that it has not checked the error state of the registration form. It should first inspect the current toolset. If the existing browser workflow is adequate, no new package is needed. If reusable local testing guidance would help, propose the matching package with its prerequisites. Distinguish inability to run a browser from lack of a procedural skill: a text package cannot create a missing runtime, credentials or an unavailable server. The output should be a short capability-gap record: the step, missing operation, available alternatives, selected method, expected changes and acceptance condition. If the team has authorized a routine in-scope installation, continue within that authorization. If the candidate introduces a different account, paid service or sensitive-data destination, the original task description does not silently approve it. Proactivity should reduce unnecessary searching and repetition while preserving the real action boundary. Do not reward the agent for installing something when the correct solution is to use an existing capability. Likewise, an automatic recommendation does not prove that a package was read or used. Ask for the applied procedure and its contribution to the output. A finder may route to a method, but the implementation and acceptance evidence still determine whether the exhibition task is complete.
Three refinements that improve the requests
First, separate recommendation from installation intent. “Find a candidate” requests research. “Install the reviewed candidate into this project's skill location and continue” adds a concrete mutation and continuation scope. Neither sentence means that every action mentioned inside third-party instructions is authorized. Second, compare only when comparison answers a real decision. Use a few candidates with an explicit rubric, and allow the result to be no suitable match. Highest popularity, newest update and largest rule count are signals to investigate, not quality verdicts. Inspect documentation, license, maintenance direction, dependencies and the amount of adaptation required for this project. Third, describe the deliverable and acceptance conditions instead of adding a pile of keywords. “Check that the registration form keeps entered data after a simulated server error in our local React app” is more useful than “find automation.” Specify allowed inputs, runtime and what must not change. This makes a recommendation easier to reject when it fits the topic but misses the actual operation.
Troubleshooting and FAQ
How can I confirm that a finder is installed? Check the package path and contents in the running environment, then confirm the agent's discovery or invocation evidence using its supported interface. A folder name alone and a conversational promise are weak signals. Preserve the source revision so a later teammate can reproduce what was installed. Why did the agent recommend instead of install? The request may have asked only for search, installation scope may be missing, the package may require unavailable prerequisites, or a platform control may apply. Diagnose the actual state rather than claiming that one missing phrase is always the cause. If installation was authorized and routine, complete it within scope; if it was not, make the proposed source and destination reviewable. Why did nothing happen after a trigger phrase? Check environment, discovery, metadata, invocation mode and task relevance. A new session can help with stale context but does not repair missing resources or provide a missing browser. Do not repeatedly reinstall an unknown package to see whether something changes. Can the same phrase be used across agents? The intent can be portable, while installation locations, invocation interfaces and tool availability differ. Verify each environment. A package following a common format does not guarantee identical behavior or feature support everywhere. What if no suitable package exists? Broaden the functional description once when useful, inspect the strongest relevant source, and consider a direct procedure with existing tools. If a stable repeated method emerges, a custom skill may be appropriate after its examples and acceptance criteria are known. Do not create an elaborate package just to avoid admitting that the current task needs a simple manual step. Does a finder guarantee safe packages? No. Discovery, source review and runtime behavior are separate. Inspect scripts, data access, network behavior and dependencies. Preserve permissions and use non-sensitive fixtures for the first verification. An open source license permits certain uses; it is not a security audit.
Handoff, sources and association refresh
Deliver the task brief, candidate rationale, source revision, installation evidence if installation occurred, actual execution records and acceptance results. Mark work not performed. The exhibition organizer should be able to see which skill supported page implementation and which supported local form regression without mistaking either for a general discovery engine. The original English article organizes unknown-name search, category comparison, proactive discovery, three prompting tips and FAQ. Those scenarios are retained here without the original popularity figures, anonymous anecdote or guarantee of interruption-free auto-installation. The referenced open source packages were selected for inspectable sources and matching purposes. The official SkillPI finder source remains separate from verified catalog links; current network availability must be checked when adopting it. As the SkillPI catalog grows, refresh these associations by reviewing the public listing, pinned package, license, maintenance state and this exact workflow step. Record the date and reason for replacement. Additional packages are useful only when they improve coverage or reduce a documented limitation, not because an article needs more links.