A community film festival is preparing a registration page. Its coordinator wants Claude Code to check the form but does not know which skill to install or how to tell whether an installation actually works. Define a small acceptance task first: fill a local demo with fictional registration data, verify required-field feedback and the success state, and preserve a repeatable script with evidence. Work through discovery, installation and more advanced reuse, leaving a selection record another maintainer can understand.
Discover against a capability requirement
Write a task card identifying Claude Code as the host, a local webpage as the target, a demo address and fictional records as inputs, and a script, screenshots and findings as outputs. List the required fields and expected messages. Keep real registrations and outgoing email outside the rehearsal. Record the operating system, existing browser tools, available dependencies and execution scope. Those details make candidates comparable by their purpose rather than a general popularity list.
If discovery assistance is useful, first check whether SkillPI Skill Finder is already installed. If it is absent, read the installation instructions in the official SkillPI Skill Finder repository and use a method supported by the current host. Use it here to collect candidates and explain their fit. Ask for a short list with source, version, prerequisites, access and expected artifacts. Treat an unknown field as unknown. A directory listing or rank does not establish that this environment has passed a runtime check.
Open each candidate's SkillPI page and upstream package. Compare its name, pinned version and actual instructions. A generic review guide might not operate a browser. A marketplace or a README may describe many packages without being a directly invocable skill. Inspect the SKILL.md, scripts and referenced resources together. Identify how the scripts reach the target and where they write output. Preserve specific rejection reasons, such as suggestion-only output, an unsupported dependency or an external service that does not fit the data constraints. Keep one primary choice and a useful alternative rather than installing every match.
Test one candidate against labeled cases
Webapp Testing fits the registration-page regression step. Its verified public listing describes Python and Playwright checks on a running local application, a server helper and browser scripts, screenshots and logs as artifacts. Prepare the demo startup instructions, browser dependencies and permission to use the test data. Trial it in isolation. Its page checks do not replace the coordinator's responsibility to confirm the registration rules.
Label three cases before execution. An empty submission should show the required-field message. A record missing the contact field should remain on the form. A complete fictional record should reach the demo success state. Preserve the page revision and expected text. Ask the assistant to inspect the rendered controls before choosing stable locators. Give each run a data identifier and keep failure screenshots and browser logs. Separate an actual page defect from a missing service or an inappropriate waiting condition. After changing the script or page, repeat the same case and compare the observed state.
Check the package, discovery and invocation separately
Before installation, preserve the upstream commit and read the license and current host loading rules. Install the complete package using the supported method and retain relative resource paths. Copying only the main instructions can leave referenced helpers unavailable. Record personal and project configuration separately and check whether a same-named skill already exists. Inspect what an installer creates and which dependencies it retrieves. Keep its changes limited to the agreed environment. The first artifact is a source version, installation location and dependency record.
Next confirm that the active session discovers the skill. If it does not, inspect the working directory, loading scope, filename and metadata format, then follow the host's documented refresh behavior. Discovery is separate from use. Explicitly ask for one trial using the skill and record which instructions were read, which tools executed and where output was written. Seeing a name establishes only discovery. A runnable artifact that reaches the expected state supplies evidence for invocation and the exercised task.
Preserve installation errors before changing anything. An unavailable package, a failed download, a host loading problem and a missing runtime dependency belong to different stages. Repeated installation can overwrite correct configuration without addressing the cause. If the retrieved package differs from the version linked on the page, resolve the source mismatch before continuing. When rollback is needed, use the supported host or package-manager procedure to restore the recorded version and replay a previously passing case.
Turn one invocation into a maintained workflow
Package the three cases with their input revision, expected results, execution method and evidence locations. When a control changes, confirm the intended product behavior before updating the locator or assertion. Do not remove a meaningful check just to regain a pass. Ask a second maintainer to start the demo and reproduce the result from the task card. If they cannot tell which screenshot belongs to which build, add a run identifier and page revision. The reusable outcome is an explainable process with traceable artifacts.
Compare upstream changes with the trialed local version periodically. Pay attention to new commands, dependencies and external calls. Upgrade in a practice copy first and replay the same cases before adopting the new package. Preserve unresolved differences and the version that still works. As the catalog grows, search again for a current capability gap and compare a new candidate against the existing method on the same inputs. Replace a relationship when the evidence supports better fit or maintenance, then update the task card and link together.
Keep the layers distinct when extending the workflow. A skill provides task instructions and resources, a hook handles an event supported by the host, and MCP exposes external tool interfaces. Installing one does not verify configuration of the others. Give each layer an input, observable output and failure record. Moving from local page checks to sending real registration confirmations adds a destination and data flow that need their own authorization and acceptance. A local browser pass cannot stand in for that verification.
Common questions
Can the same package be used on another agent host?
Some general instructions may transfer, but loading locations, extended metadata, scripts and tool interfaces need checking on the destination. Replay the labeled cases and distinguish discovery from invocation and result. A common file format is not proof that every host uses the same installation command.
Does a free installation mean a free run?
Check the package license, model subscription and external services separately. Preserve observed calls and execution costs for the trial. Open source does not make every dependency free or establish that the workflow saves tokens.
Should I install every candidate if I cannot choose?
Complete the task card and trial one inspectable candidate first. Broad installation can create naming conflicts, duplicate tools and maintenance work. Record why a case failed and use existing tools when they already meet the requirement.
Does a download count show successful executions?
Interpret a number only under the platform's stated measurement method. Downloads, installations and successful task runs are different events. The festival's evidence is its own labeled input, script, observed state and saved artifacts.
What information helps with troubleshooting?
Provide the host version, operating system, upstream commit, installation location, minimal failing steps and redacted error. Identify whether the failure happened during download, discovery or execution. A synthetic reproduction makes advice more precise without exposing real registrants.