A library team receives three requests in the same week: investigate a failed commit check, verify next week's event reservations, and review which skills its assistant may load automatically. All three mention the booking site, but the work calls for different inputs and tools. Test each route with a small fixture before enabling automatic dispatch. The goal is to make it possible for the next maintainer to explain why a skill ran and what it actually checked.
Route development work from the failure evidence
Start a bug report with a release or commit identifier, the environment, and the expected behavior. If a CI job failed, collect the job name and the first actionable error. A missing package during installation and a successful build followed by an interaction failure call for different follow-up work. Give the diagnosis step a clear output: the failed stage, a short excerpt, and a command or fixture that can reproduce the failure. If the assistant cannot access the log, have it record the missing input and stop that branch.
For a page that opens but fails when selecting a time slot, use the linked Webapp Testing skill in the browser verification step. Prepare a test account and two fixtures, an open session and a full one. Record the page address, browser settings, sequence of clicks, expected behavior and observed feedback. If the page claims that a reservation succeeded, a maintainer with database access should independently check that the test record exists and that it belongs to the intended session. The browser check supplies evidence of what a visitor sees.
If one ticket asks about both a CI failure and a broken button, collect the two sets of evidence independently. A coordinator can merge the reports after verifying that both used the same version. For example, screenshots from an older build cannot establish whether a newer change fixed the bug. Preserve the build identifier in each result and ask for a matching rerun if the versions differ.
Turn a recurring booking check into a workflow
Agree on the input and output before wiring up a schedule. The input is a versioned list of events with an ID, registration time, time zone and expected booking state. The output lists each tested event, the actual outcome, evidence for failures and the reason for every skip. Start with a fixture for a currently open event, one that opens tomorrow and one that is full. Have the person who owns the calendar confirm the expected outcome for each.
Separate reading the schedule, generating cases, running the browser and reporting results. An ordinary script can turn the schedule into fixtures and organize the returned data. Use Webapp Testing for the browser stage, where the runner needs to interact with the page, wait for a visible result and preserve evidence. If one event opens at 9 a.m. local time, add checks immediately before and after the boundary with a controlled test clock where available. Include the clock and time zone in the report so that a discrepancy can be reproduced.
Run the workflow manually with the same fixture twice. If it creates reservations, tag each test record with its run ID and ensure a replay can clean up or reuse its own records. Keep the fixtures and permissions separate from production. Once the manual run is reliable, record the input version and status of each stage in the scheduled run. A browser outage should leave the finished input preparation intact and mark the check as pending. Treat sending an alert and changing a live event as separate actions with their own authorization.
Load skill instructions when the task calls for them
Keep a short catalog of approved skills. Record the task each can handle, the input it needs, what it produces, and when it should be skipped. Webapp Testing requires a reachable web app and suitable test data when the work involves browser behavior. A request to explain an existing CI error can proceed using the logs alone. Assign each catalog entry an owner who can retest the routing cases when its instructions change.
Use the progressive disclosure pattern from the Agent Skills specification. Compare names and descriptions first, read the full instructions after selecting a candidate, and open supporting resources when a step needs them. Record the distinction between selecting a skill, loading its instructions, and executing a tool. If the only candidate requires an unavailable test account, the right output is a request for that input. A promising entry outside the approved catalog can go to review with its proposed task and required permissions.
Review the routing table with real inputs
Prepare examples for a clear match, a misleading keyword, a request with two goals, and a request with missing data. A ticket saying that the booking button disappears after sign-in should lead to browser reproduction and a request for a test account. A ticket asking for a paragraph about the booking button belongs in a writing workflow. A request to check yesterday's failed build and verify the full-session message should yield separate artifacts for the CI and browser checks. Record the expected route, actual route and observed tool calls for each fixture.
When an unrelated skill runs, find the missing condition. Two similar catalog entries can often be distinguished by an observable requirement such as whether the task needs a browser or only needs a log. After changing the description or route, replay the example that failed and a neighboring one that already passed. Compare both the selected skill and the output it produced.
Troubleshooting and common questions
The route is correct, but the test page does not load. What should I check?
Open the address from the same test environment and determine whether the service timed out, redirected to login or returned a server error. Check that the fixture was loaded and the account has the expected role. Mark the case for retesting if its environment is unavailable, and preserve the error that prevented the check from running.
Can the assistant run several skills at once?
Independent reads can run together. For steps that update the same test record, define the order and which step owns cleanup. Each branch should return an input version and a result keyed to the task. Keep a missing branch visible in the merged report so the operator can resume that branch without guessing which checks already passed.
What if someone explicitly names a skill?
Check the request against the named skill first, then verify prerequisites. An explicit request for browser verification still needs a target page and an expected result. Apply the same environment and permission checks as for automatic selection.
Rehearse the handoff before scheduling
Enter two fixtures with the same display name and different dates. Ask whether registration is open for the Monday event and verify that the runner uses the dated record rather than the first search result. Give it an ambiguous request next. The operator should receive both candidate dates and a request to choose a session. Finally, replace the test URL with a production URL in the fixture and verify that the runner stops before creating a reservation. Retain the event IDs, run IDs and stop reasons together so a different maintainer can repeat the rehearsal.