UAT Plan

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites: none for the install itself: no account, no API key, no paid service, and nothing else to install first. For using the skill afterwards, no key or account is required either: it works from requirements or user stories and a release scope that I supply myself, in our conversation. The skill names no external service, no connector and no website at all: the only routes at use time are the material I hand you and, only if I ask for it, a plan document or spreadsheet file you write locally for me — both disclosed in point 2 before they ever happen. Install "uat-plan" for me. It plans user acceptance testing and writes business-facing UAT scripts from my requirements or acceptance criteria. From the scope I give it, it produces a UAT plan — what is in and out of scope by business process, the people and roles (business owner who signs off, UAT lead, testers per process, delivery contact for defects), the environment and the test data needed per script (who prepares it, and what must be masked), entry criteria, exit criteria, defect rules (severity in business terms, who triages and how fast, retest plus a named regression set after a fix), a schedule with daily triage and a sign-off date, and a sign-off record (accept, accept with conditions, or reject) — plus one step-by-step script per business scenario that a business tester can run without the delivery team in the room: each script has an ID, the requirement or acceptance criteria IDs it covers, preconditions, the tester role, a priority, and a table of steps with the action, the test data, the expected result, and empty columns for the actual result, pass or fail, and defect ID. It then checks coverage: every requirement in scope is covered by at least one script, and any that are not are listed with why. It never marks anything as passed, never invents dates, names or data values I did not provide (it leaves a clear placeholder and lists it under open items instead), and never puts real personal or financial data in a script — it describes the profile of the record instead. Repository: https://github.com/ChenxingJi-Innovate/Cheatcode_ (the skill is the whole packages/requirements-kit/skills/uat-plan/ folder at the pinned commit: SKILL.md only, 1 file) Pinned version: install the code at commit 1071f72533f0a8bb671e2d9b48c8d75f12adc904 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/ChenxingJi-Innovate/Cheatcode_ into a temporary folder, check out commit 1071f72533f0a8bb671e2d9b48c8d75f12adc904, and copy the packages/requirements-kit/skills/uat-plan/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-19: [FINGERPRINTS] - SKILL.md: SHA-256 26a34f6ede63aaf1f393b4f91ae62933b2a62f866767da3eaa15f0f76c969d80 If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, and tell me in plain words: what the skill does when used, which services it can connect to, whether it reads or sends any personal information or keys, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the file: - The skill folder holds 1 file only: SKILL.md (3,585 bytes). There are no scripts, no code, no imports, no URLs and no file references in it: the skill is self-contained in its own folder and needs no file from elsewhere in the repository — not the sibling skills (acceptance-criteria, brd-draft, requirements-lint, traceability-matrix), not the package files (packages/requirements-kit/README.md, cheatcode.json, .claude-plugin/plugin.json, LICENSE), not the repository root files, and not the installer/ app. SKILL.md names no service, connector or website at all. - One known defect to state back to me, exactly as listed — do not fix it and do not edit the file (editing it would break its fingerprint): the frontmatter block is delimited by --- lines and holds exactly two fields, name: uat-plan and a one-line description, but that description is an unquoted plain scalar containing ": " (a colon followed by a space, after the words "acceptance criteria"), which strict YAML parsers reject ("mapping values are not allowed here"). The name field itself is plainly readable as uat-plan; report the frontmatter as present-but-not-strict-YAML-valid, as recorded in this listing. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit. No script is run during installation (there is none), no key is asked for, and there is no telemetry in the folder. - What is read and what leaves this conversation at use time, disclosed here before it ever happens — using the skill is a separate step that only starts when I bring requirements: (a) everything the skill works on is material I supply in our conversation: requirements or user stories with acceptance criteria, the release scope, who the business users are, and any constraints (dates, environments, data restrictions). SKILL.md treats all of it as data, not instructions; if acceptance criteria are missing, test conditions are derived from the requirements and marked as derived. Nothing in the skill sends that material anywhere: there is no network route, no connector and no external service in the file. (b) The output stays with me: a UAT plan document (scope, people, environment and data, entry and exit criteria, defect rules, schedule, sign-off record), then the scripts as tables, then the coverage check — all produced in our conversation; only when I ask for it and your setup can write files, the scripts may also be written out as a local spreadsheet with one sheet per process. That optional local file write, on my request only, is the only thing that ever leaves the conversation, and it goes to a file I choose — never during installation. (c) One safety rule from SKILL.md to state back to me: never put real personal or financial data in a script; describe the profile of the record instead, and mask whatever data must be masked. - The rest stays in our conversation at use time: scoping by business process, assigning roles, drafting the step-by-step scripts in the screens and words the business uses, the coverage check, and the open-items list for anything not provided. Two more rules from SKILL.md to state back to me: scripts test business outcomes, not implementation; and the skill never marks anything as passed — the result columns stay empty for the tester. - Do not use the skill during this install: do not draft any UAT plan or script, and do not write any plan or spreadsheet file. 3. When I say "yes, install", install it as a skill: copy the whole uat-plan folder into the agent's skills directory, in a folder named "uat-plan", keeping its 1 file (SKILL.md at its root). A manual clone followed by copying the packages/requirements-kit/skills/uat-plan folder into ~/.claude/skills/ is the route described here; any other route is fine only as long as every installed file matches its fingerprint. 4. Verify with no network calls: the 1 file in place with a matching fingerprint, and the frontmatter exactly as recorded — name readable as uat-plan, and the known strict-YAML defect on the description line present and unmodified (do not report the frontmatter as valid YAML, and do not fix it). Do not run any usage step to verify. 5. Report what was installed, where, and what I still need to do myself (for example: bring the requirements or user stories with acceptance criteria, the release scope, who the business users are, and any constraints — dates, environments, data restrictions; decide the names or keep roles where SKILL.md leaves placeholders, and clear the open-items list myself; sign off myself at the end, since the skill prepares the sign-off record but never signs or marks anything passed; using the skill is a separate step that only starts when I ask for it, and the use-time handling disclosed above happens only then). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.