A small repair cooperative inherits a ticketing site and a handover note recommending eight skills. The duty team has two immediate jobs. It must reproduce a fault in the appointment form and turn the confirmed workaround into instructions for the front desk. Use those jobs to choose what to install. Leave a record that tells the next shift what each skill does, when it should run, and how to tell whether an update broke it.
Search from the result you need
Replace “help with repair tickets” with a task someone can check. On the test site, open fictional ticket R12, submit the form with the contact window blank, and record the error message and whether the form preserves the other values. The input is an approved test URL, a test account, and a fixture with no resident data. The deliverable is a defect report with a reproducible sequence. The second task starts with a verified workaround and ends with a short instruction for front desk staff.
Search the approved catalog for browser reproduction and document review. Use the linked Webapp Testing skill to replay the form and capture the visible outcome. Use Writing Guidelines to review the resulting instructions for clear headings, complete steps, and consistent names for fields and errors. Verify the facts against the test report before sending the instructions for review. For each candidate, record its prerequisites, inputs, outputs, permissions and when it should skip the task. A candidate that needs production access stays in review while the team checks its basic behavior using synthetic data.
Run a positive and a negative routing case. “Reproduce R12 on the test site” needs a browser. “Rewrite the approved workaround in three steps” can use the supplied text. If the second request still starts a browser, check whether the rule treats any mention of a ticket as sufficient. Require an explicit page interaction and a usable test address, then replay both cases. Save the routing result with its reason so the next shift can distinguish a bad match from a tool failure.
Use rankings to decide what to examine
Keep two snapshots with the same search scope and record the source, date, rank and version where available. Note whether a candidate appeared, remained on the list, or changed position. A single star or download count is one observation. Look at release notes and examples to see whether an update affects form validation, error feedback, or evidence export. A rise in visibility can move a candidate up the reading list. Adoption depends on the trial.
Suppose one candidate added screenshots but does not report whether the form actually submitted. Another records actions and feedback but needs a test account that the team has not configured. Give both the R12 fixture and record whether each can reproduce the fault, whether the environment is ready, and whether a maintainer can act on the output. If a prerequisite is missing, give the row an owner and a condition for retesting. The existing manual check stays available while the candidate is being evaluated.
Set a review date for shortlisted tools. If a new release claims to fix the path that failed, rerun the same fixture and compare its evidence with the earlier run. Record any new permission or dependency separately. A change that improves screenshots can be useful even when it leaves the form checks untouched.
Manage installation, updates and removal
Keep an inventory with skill name, source, pinned version, owner, approved task, and baseline fixture. Try a new version in a disposable workspace first and keep the previously tested version and configuration available. Check whether the install instructions add network access or write to a shared directory. The person responsible for that resource should review any new access before it is used.
After an upgrade, replay one expected success, one request outside the skill's scope, and one known failure. A successful browser run should produce an evidence record. The writing request should skip browser interaction. The incomplete form should report the observed error. If a new version reports success for a failed submission, preserve both reports, restore the previous version, and confirm that the shift can still run its checks. Before removing a skill, identify the scheduled jobs and instructions that depend on it and replay the remaining workflow after those references are updated.
Rehearse the shift handover
Seed an incomplete R12 fixture and a complete form. Submitting the incomplete fixture should keep the typed values and tell the tester which field to fill in. The complete fixture can create a record in the test data. If the first path clears a field after showing the error, record the URL, action order and observed state. After the fix, replay both paths to catch a regression in normal submissions.
Give the verified workaround to someone who did not join the browser trial. Have them follow the draft instructions and identify the entry point and error message. If they cannot find the entry point, add the menu path and repeat the check. Save the environment, skill versions, fixtures and result locations in the handover. A site outage can leave the browser trial pending while the instructions review proceeds using evidence from a completed run.
Common questions
Should we install two skills for the same task?
Start with one that passes the baseline. Add a second if the trial identifies a concrete gap, such as missing page evidence. Define which output each owns so both do not submit the same test form.
What if the rankings produce no suitable candidate?
Search using the required actions and outputs. Split a broad term like “repair assistant” into “reproduce form error” and “review operating instructions.” Record prerequisites the candidates lack and retain a manual path until one meets them.
How do we recover from a failed upgrade?
Restore the last verified version and configuration, replay the same baseline, and check that scheduled jobs point to the restored version. Keep the failure evidence and upgrade time in the inventory for the next review.