Usage boundaries and preparation
This skill can be installed on its own; the necessary methods are all in this file and it does not depend on the author's machine or other skills. First read the target project's specifications to confirm the target repository/workspace, version, user outcome, and allowed changes; the reference repository is read-only. When there are no project rules, read the actual README, scripts, and source code to infer the entry points.
Execute with currently available and authorized tools: if there is no independent agent, you may use a new session/manual review or self-check from multiple perspectives, and note the actual review method; if there is no browser/real API, complete the executable parts and hand off the uncovered validation, and do not pass it off as independent review, GUI, or real service success. The project's original runtime environment is still required; do not bind to a model vendor or specific plugin.
For complex tasks, you may save necessary facts according to assets/task-record.md ; for simple tasks, record the results directly and do not mechanically add process.
The goal is to prove that a first-time user can obtain a real outcome based on the public instructions, and to avoid the author's existing local configuration masking delivery problems.
Fixed validation target
Confirm the version to be validated, installation channel, target platform, public README, and first outcome. Distinguish between the source code development environment and the package/installer that an ordinary user receives. Documentation testing starts from the path it promises, and release package testing starts from the real artifact.
Use an isolated directory, independent configuration/profile, or an appropriately clean environment, and keep the user's existing configuration unchanged. Do not modify the system or read the author's private configuration in pursuit of a clean environment.
When interactive browsing is needed, use the browser tool specified by the user or already available in the current environment. This package does not require installing a particular browser skill; when browser capability is unavailable, switch to executable command-line validation and hand off the necessary manual steps, and do not pass off command-line observations as GUI validation. When using real system permissions, follow the authorization of the current task.
Execute according to the public steps
Execute item by item according to the documentation, and do not automatically fill in prerequisites that the author knows but the README does not explain. When encountering a blocker, first record the location, command/action, actual result, impact on a novice, and the necessary missing explanation, then make corrections within the task scope.
When external accounts, credentials, or permissions are explicit prerequisites, verify whether the documentation clearly explains how to obtain and configure them. When these conditions are missing, mark the corresponding stage as unverified, do not fabricate success, and do not treat the user's existing login state as new-user validation.
From ordinary entry points, validate first run, dependency or resource acquisition, necessary configuration, execution of the target task, and obtaining the result. Successful installation/process startup is only an intermediate state.
Prefer to assert externally visible outcomes, such as files existing with valid content, the tool actually changing the specified object, the page being accessible, and the task status being consistent with the result; a "done" in an AI reply cannot by itself pass validation.
Retest from the public path after correction
When authorized to fix documentation or entry points, fill in the actual blockers and validate according to the corrected public steps. For complex installation changes, retest under a new clean configuration as much as possible, to avoid the first run's cache or manual patches making the second run appear successful.
Do not repeatedly run external actions that have already succeeded and have side effects in order to obtain better-looking logs. When the result is unknown, first check the actual state and decide the next step based on idempotency.
Delivery and manual boundaries
Deliverable version/artifact identity, the public steps taken, evidence for the first result, resolved blockers, and unverified stages. Distinguish blockers, easy-to-mislead items, and optional improvements; do not expand into redoing the entire onboarding just because it can be optimized.
When real desktop operations, hardware, or system authorization cannot be executed, give the user specific steps, expected results, and pass conditions, and hand over the necessary environment information; do not just write "please do manual QA." Directly provide a manual checklist with four columns: action, expected result, pass conditions, and issue log; the handover can be completed even without an additional skill or interactive checklist tool.