A community repair workshop has a local appointment demo. Its maintainer can already ask Claude Code to write a function, but wants a repeatable path from changing an arrival instruction to checking the page and handing the result to a colleague. Use fictional appointments and an isolated branch. The exercise should produce a configuration record, a narrowly scoped review assistant and a browser check another maintainer can repeat. Judge progress by those artifacts and their observed behavior.
Establish one task and a working baseline
Record the Claude Code version, operating system, working directory, app startup instructions and existing check command. Choose an observable change: replace “Drop in anytime” with “Please arrive during your appointment window” and verify that the sentence remains readable on a narrow screen. Identify the copy file, component and relevant test that may change. Keep real bookings, payments and customer notifications outside this rehearsal. Start the unmodified demo and run its existing check once. Save the revision and a screenshot of the original page so a later failure can be compared with the baseline.
Write three acceptance conditions. The new sentence is visible, the appointment form still works, and a colleague can reproduce the verification from the handoff. Ask the assistant to trace the sentence to its current source before proposing an edit. If it cannot locate the entry point, supply the repository instructions or a verified search result. More extensions will not resolve an ambiguous requirement by themselves. Include the current branch and existing uncommitted changes in the task card so another session can distinguish this work from unrelated edits.
Rehearse a hook with an observable result
Decide what event should be observed, then consult the current official Hooks documentation for its configuration scope, input and return contract. Begin with a project-scoped handler that records a timestamp, task identifier, event category and outcome. Keep it in the practice project and preserve the previous configuration and a way to restore it. Inspect commands and paths from examples against this operating system. Treat a downloaded template as material to review before using it in a live project.
First make the handler produce a recognizable rehearsal marker. Edit the designated copy and observe whether that marker appears. Only then connect the repository's existing formatting check. Give execution a deadline and preserve the exit status and useful output. Exercise a successful check, a deliberately invalid practice edit and a missing dependency. If the handler can format files, specify its allowed paths and inspect the resulting diff. Check whether overlapping configuration scopes cause the same operation to run more than once. Keep each invocation tied to the task identifier.
When a hook does not behave as expected, separate an event that never fired from a handler that failed and a check that found a code problem. Confirm which configuration this session loaded and whether its command is executable on this host. Inspect whether the handler receives the documented input and whether a later process overwrites the useful output. Temporarily restoring the previous configuration and repeating the same task helps establish whether the new handler caused the change. The deliverable is a configuration diff, observed successful and failing runs, and restoration instructions.
Give a review subagent a bounded assignment
Perform the review manually once before choosing the repeatable part to delegate. A review assistant needs an objective, a specific input revision, a permitted tool scope and an output format. Use the current Claude Code subagent documentation to choose the appropriate personal or project configuration. For this exercise, assign a read-only review of the appointment-copy diff. Require findings to identify a file, trigger, practical consequence and a verification method. Submission, deployment and changes to appointment data remain outside that role.
Provide the diff, local page address and acceptance conditions. Ask the reviewer to identify the files it actually inspected. If it suspects that the longer sentence can cover the submit button on a narrow screen, it should point to the relevant component and viewport condition. A reviewer that has not opened a browser should label that as a proposed check. The main session can inspect the preview under the stated condition, record the observation and decide whether the layout needs a change. Keep recommendations, executed actions and results distinct in the handoff.
Test the role with a practice diff containing a known defect and another that should pass. Check whether it catches the former without inventing a problem in the latter. Withhold the copy source in a third trial and require it to report missing input rather than guess a location. If an essential tool is unavailable, that limitation belongs in its result. After the maintainer changes a file, return the new revision for review. A finding tied to an earlier diff should not silently become approval of later edits.
Discover a skill against the remaining capability gap
Describe the gap in terms of a task and artifact: reproduce the form behavior on the local appointment page after the copy edit and save browser evidence. Look for candidates that support that host, environment and output. Open the listing and inspect the upstream package, pinned version, license, dependencies, file access and external destinations. A title containing “expert” does not establish who maintains it or whether it fits the project. Review supporting scripts and assets as well as the main instructions before running them.
For the browser acceptance step, Webapp Testing is a relevant candidate. The verified listing describes Python and Playwright checks against a running local application, with scripts, screenshots and browser logs as outputs. Give it the isolated demo address, fictional test data and acceptance conditions. Prepare app startup instructions and browser dependencies, review the execution scope and trial one case. Its browser result addresses the page behavior exercised; hook configuration and subagent boundaries require their own checks.
After installation, distinguish discovery, invocation and a useful result. Follow the current host documentation for the loading location and invocation method. Check the skill name and description for conflicts with existing packages, then record the version, location, command and outcome of the trial. When moving to another agent host, verify directories, metadata, tool interfaces and configuration again. Reuse the same acceptance task. Reading a SKILL.md file is only one part of establishing that the workflow works on another host.
Combine the pieces in one reviewable handoff
The main session reads the task card, locates the old sentence and edits only the agreed files. Inspect the diff and observe the hook marker and formatting result. Invoke the limited reviewer and resolve findings against the current revision. Use Webapp Testing on the running local demo to inspect the sentence, narrow-screen layout and relevant form behavior. Preserve actual evidence and distinguish checks that were suggested from checks that ran. After an adjustment, repeat the affected check and update the same task record.
Give a colleague the diff, configuration revision, review findings, startup instructions, test data and unresolved items. Have them reproduce the critical check without the full conversation. Record where they needed clarification. Compare the complete rehearsal time and rework with the original manual flow before claiming an improvement. Extra retrieval, instructions and assistant runs can add overhead. Following a repository or host upgrade, replay this small task before expanding automation to a larger workflow.
Common questions
Can everyone finish this in a weekend?
The environment, prior experience and project determine the time needed. Start with one reproducible task and add automation only after the baseline works. Understanding a failure and restoring the previous configuration are useful outcomes even when the complete workflow needs more practice.
Does an open-source skill guarantee a free or cheaper run?
The license, host subscription, model usage and external service charges are separate questions. Review the particular package and dependencies, then measure the rehearsal. Additional calls may increase usage; a saving needs a comparison under the same conditions.
Can a beginner paste a hook template directly?
First identify its commands, file access and external calls in a practice copy. Start with the visible marker and add one behavior at a time. Ask a maintainer to review commands you cannot explain and preserve restoration instructions.
Should a missing skill be reinstalled immediately?
Check the active host and session, loading directory, file format, naming conflicts and available loading messages first. After discovery succeeds, run the small task to verify invocation. Repair the installation when evidence identifies a missing or damaged package.
Is a discovery tool required for manual installation?
Use the host's supported installation method for a selected package if preferred. The source, version, license and runtime prerequisites still need checking. Discovery narrows candidates; the project rehearsal supplies evidence for the final choice.