[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FYSA4SC1SX15NKRFVBPCBY":3,"skill-same:01M6FYSA4SC1SX15NKRFVBPCBY":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6FYSA4SC1SX15NKRFVBPCBY","uat",null,"Create user acceptance test journeys from a target user's perspective, with role-based scenarios, acceptance criteria, and evidence capture","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-testing\u002Fcodex\u002Fuat\u002Farchive\u002Fv0.15\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"alignment","acceptance test","with","app","feature","logic","artifact","journey","acceptance criteria","design","evidence","only","page","loop","persona","analysis","acceptance","create","test","2026-11-10 10:12:30",false,"---\nname: uat\ndescription: Create user acceptance test journeys from a target user's perspective, with role-based scenarios, acceptance criteria, and evidence capture\ntype: analysis\nversion: v0.15\nrequired_conventions: [alignment-page, design-tree-loop]\nargument-hint: \"[--variant-evaluation] [optional: persona, feature, release, journey, app, or variation spec]\"\ncontext_intake: artifact_only\ninvocation: sub-skill\nparent: logic-wiring\n---\n\n## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install \u003Cpack>` instead of the target skill. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend `npx skillpacks install \u003Cpack-or-skill>`; for unavailable base skills, recommend `npx skillpacks init` before the skill.\n\n# UAT\n\nInvoke as `$uat`.\n\nCreate a user acceptance testing plan from the perspective of a potential or target user. Read the product surface, specs, journeys, stories, roadmap, and relevant research, then produces realistic end-to-end user journeys that validate whether the product satisfies user goals.\n\nUAT is not dogfooding. Dogfood asks how the app owner can adopt the product into their own workflow to understand and evaluate it. UAT asks whether a target user can complete meaningful real-world journeys and would accept the product as fit for use.\n\nThis is a human-run acceptance plan, not automated testing. Do not start servers, drive browsers, call APIs, create accounts, or perform the scenarios yourself.\n\nWhen invoked with `--variant-evaluation` (or when the user asks to test\u002Freview UI variants), create a hands-on evaluation plan for built UX\u002FUI variants before any consolidation decision. This mode helps the user try each variant in a comparable way and capture enough evidence to form a defensible consolidation opinion.\n\nFollow `DESIGN-TREE-LOOP.md` for prototype-phase routing, state storage, approval boundaries, and task classification. Human-run prototype\u002FUAT evaluation belongs in `tasks\u002Fmanual-todo.md`; confirmed implementation fixes may enter `tasks\u002Ftodo.md` only after human evidence exists.\n\n## Design-Tree Role\n\n`uat` is a **sub-skill** in the design-tree loop (`DESIGN-TREE-LOOP.md`). Its `parent:` is `logic-wiring`, and it is also invoked inline by `consolidate-prototypes` (variant evaluation) and by the execution loop (release\u002Fjourney UAT). It enters at its own **checklist\u002Fevaluation stage** — building hands-on journeys and capturing human evidence — and does **no pipeline routing of its own**: it returns evidence to the invoking parent, which owns the handoff. Its existing recommendations (e.g. `$consolidate-prototypes`, `$customer-discovery`) are fallback suggestions, not design-tree branch routing.\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve research scope by product path before using code or app structure as a hint:\n\n1. If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product\u002Fapp name, not the ICP, audience, or segment label.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` or legacy `status: abandoned`, stop and warn that the path is archived; do not write or update scoped outputs there.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths` on read and write back `active_paths` on manifest updates. Treat legacy `abandoned` as `archived`; exclude `archived`, `abandoned`, `deferred`, `revisit_candidate`, `promoted`, and any `scope_path` under `research\u002F_archive\u002F` from active target selection.\n4. If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target unless this skill explicitly supports cross-path output.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F`, excluding `research\u002F_archive\u002F` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat `research\u002F` single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint. Suggest creating a missing `research\u002F{slug}\u002F` product path when code clearly exposes an app, but do not require code or monorepo detection before using `research\u002F{slug}\u002F`.\n\nWhen product path `{slug}` is active, read and write research under `research\u002F{slug}\u002F`, read pre-prototype design artifacts under `design\u002F{slug}\u002F`, read finalized implementation specs under `specs\u002F{slug}\u002F`, and treat top-level `research\u002F*.md` and `design\u002F*.md` files as flat-mode documents or cross-path summaries.\n\n1. **Resolve project context**\n   - Read `.agents\u002Fproject.json` if it exists.\n   - Use `project_type` and `enabled_packs` when present.\n   - If project metadata is missing, infer the project type from repo signals:\n     - business-app: SaaS, marketplace, productivity, workflow, enterprise, or user-facing app\n     - devtool: SDK, CLI, API, library, infrastructure, docs, examples, or package-first developer workflow\n     - game: game engine files, playable prototypes, store assets, or game-specific README\u002Fspec language\n     - generic: no strong domain signal\n   - Read `README.md`, `AGENTS.md`, `CLAUDE.md`, relevant `docs\u002F`, `specs\u002F`, `spec.md`, and `tasks\u002F` files when present.\n\n2. **Load user evidence**\n   - Business app: read `research\u002Ficp.md`, `research\u002Fjourney-map.md`, `research\u002Fcustomer-feedback.md`, `research\u002Fmetrics.md`, and `research\u002Fmvp-gap.md` when present.\n   - Devtool: read `research\u002Fdevtool-user-map.md`, `research\u002Fdevtool-dx-journey.md`, `research\u002Fdevtool-integration-map.md`, docs, examples, and package manifests when present.\n   - Game: read `research\u002Fgame-audience.md`, `research\u002Fgame-fantasy.md`, `research\u002Fgame-core-loop.md`, `research\u002Fgame-prototype-test.md`, and `research\u002Fgame-playtest-metrics.md` when present.\n   - Generic: use specs, README, routes, tests, examples, issue descriptions, and task acceptance criteria.\n   - In product-path workspaces with `research\u002F{slug}\u002F` or `specs\u002F{slug}\u002F`, produce product-path-scoped UAT journeys for the requested app. If no app is specified and multiple apps are plausible, ask the user to choose.\n\n2b. **Variant evaluation mode**\n   - Trigger this branch when invoked with `--variant-evaluation`, when `design\u002Fui-layout-variations-*.md`, `design\u002Fux-variations-*.md`, or product-path-scoped equivalents exist for the requested topic, or when the user asks how to test\u002Freview built variants. Legacy `specs\u002Fui-layout-variations-*.md` may also trigger this branch during migration.\n   - Read `design\u002Fui-layout-variations-[topic].md`, `design\u002Fux-variations-[topic].md`, `design\u002Fui-requirements-[topic].md`, `design\u002F**\u002Fflow-tree-*.yaml`, `design\u002Fprototype-build-plan-[topic].md`, product-path-scoped equivalents, built prototype directories under `prototypes\u002F{topic}\u002F`, built variant routes\u002Fcomponents, and any existing `research\u002Fuat-variant-evaluation-[topic].md`.\n   - Treat legacy `specs\u002Fui-layout-variations-[topic].md`, `specs\u002Fux-variations-[topic].md`, and `specs\u002Fui-requirements-[topic].md` as fallback evidence only when the corresponding `design\u002F` artifact is missing.\n   - Identify each variant, its intended thesis, implementation location, and the target user task it should support.\n   - Create comparable journeys that make the user perform the same core task in every variant, then capture variant-specific strengths, friction, confidence, and rejection signals.\n   - Include a side-by-side comparison matrix and a \"Ready for `$consolidate-prototypes`?\" checklist.\n   - In the variant inventory and readiness output, distinguish these four statuses explicitly: `built + evaluated`, `built + not run`, `approved but unbuilt\u002Fdeferred`, and `explicitly excluded from MVP`.\n   - Human execution still belongs in `tasks\u002Fmanual-todo.md`; this skill writes the plan and manual tasks, but does not run the variants.\n   - While any built variant result log is `Not run`, recommend manual UAT\u002Fevidence capture rather than `$consolidate-prototypes`.\n   - Mention `$consolidate-prototypes` only after result logs record evidence and either every MVP-scope approved variant is evaluated or the user explicitly chooses a single-variant MVP and excludes, defers, or marks all other approved unbuilt branches as spec-only references.\n   - Stop after this branch. Do not generate generic target-user acceptance journeys unless the user also requested them.\n\n3. **Define acceptance perspective**\n   - Identify 1-3 target user personas or roles from the evidence.\n   - For each selected persona, define the job-to-be-done, context, goal, constraints, and acceptance threshold.\n   - Prefer external target users, buyers, evaluators, administrators, developers, or players over the product owner unless the owner is also the target user.\n   - If the target user is unclear, stop and recommend `$customer-discovery`, `$journey-map`, or the relevant pack research skill. For `$customer-discovery`, `$journey-map`, and other pack-based skills, apply the Pack Availability Guard — if the target skill's pack is not in `.agents\u002Fproject.json` `enabled_packs`, recommend `npx skillpacks install \u003Cpack>` before the skill.\n\n4. **Create UAT journeys**\n   - Generate 3-7 journeys unless the user requested a narrower focus.\n   - Cover at least one critical happy path, one realistic obstacle or recovery path, and one return-use or handoff path when supported by the product evidence.\n   - Each journey must include:\n     - target user\n     - user goal\n     - real-world trigger\n     - setup and preconditions\n     - end-to-end task sequence\n     - expected user-visible success state\n     - acceptance criteria\n     - non-acceptance signals\n     - evidence to capture\n     - tester notes prompt\n     - follow-up routing\n   - Use concrete product language from specs and journeys. Avoid vague instructions such as \"verify the feature works.\"\n\n5. **Classify follow-up work**\n   - Human-run UAT journeys go in `tasks\u002Fmanual-todo.md` under `## UAT Journeys`.\n   - Use `_(after: research\u002Fuat-plan.md)_` unless the journey blocks or follows a known roadmap step. If tied to a known step, use `_(blocks: Step N.X)_` or `_(after: Step N.X)_`.\n   - Do not put human-run UAT journeys in `tasks\u002Ftodo.md`.\n   - Implementation or documentation fixes discovered after a completed UAT run belong in `tasks\u002Ftodo.md`, but do not invent fixes before the user journey has been attempted.\n   - One-time evidence collection belongs in `tasks\u002Frecord-todo.md`.\n   - Recurring release acceptance checks belong in `tasks\u002Frecurring-todo.md` only when there is a clear release cadence.\n   - If a journey needs click-by-click help for a human-only external blocker, recommend `$guide`.\n\n6. **Present findings before writing when risk is high**\n   - If source material is thin, contradictory, or missing target-user evidence, summarize the gap and ask whether to proceed with assumptions.\n   - If source material is sufficient, write the plan and task sections directly.\n\n## Deliverables\n\n- `research\u002Fuat-plan.md` - persona assumptions, journey matrix, source evidence, acceptance checklist, result log template, and follow-up guidance.\n- In variant evaluation mode: `research\u002Fuat-variant-evaluation-[topic].md` - variant inventory, task script, comparison matrix, result logs, and consolidation readiness checklist.\n- `tasks\u002Fmanual-todo.md` - append or replace only the `## UAT Journeys` section.\n- `tasks\u002Frecurring-todo.md` - optional, only when recurring UAT is useful and not already tracked.\n\nIf `tasks\u002Fmanual-todo.md` does not exist, create it with a `# Manual Tasks - [Project Name]` title, a short note that these items require human-only action, and the UAT section. Preserve all non-UAT sections when updating an existing file.\n\nUse this journey format in `research\u002Fuat-plan.md`:\n\n```markdown\n### Journey N: [Name]\n\n- Target user: [persona or role]\n- User goal: [what the user is trying to accomplish]\n- Trigger: [real-world reason the user starts]\n- Setup: [accounts, data, environment, permissions, or sample state needed]\n- Task sequence:\n  - [step the human tester performs as the target user]\n- Expected success state: [observable user-visible result]\n- Acceptance criteria:\n  - [ ] [specific criterion]\n- Non-acceptance signals: [confusion, delay, missing affordance, incorrect result, trust issue, or blocker]\n- Evidence to capture: [screenshots, recordings, notes, timestamps, records, command output, or artifacts]\n- Tester notes prompt: [question that captures whether the target user would accept this]\n- Follow-up routing: [manual note, $customer-discovery, $journey-map, $guide, or task promotion guidance]\n\n#### UAT result log\n\n- Status: Not run | Pass | Fail | Blocked\n- Evidence captured:\n- Tester notes:\n- Follow-up tasks promoted:\n```\n\nUse this variant evaluation format in `research\u002Fuat-variant-evaluation-[topic].md`:\n\n```markdown\n## Variant Evaluation Plan\n\n### Variant Inventory\n\n| Variant | Implementation location | Thesis | Primary task |\n|---|---|---|---|\n\n### Variant Readiness Inventory\n\n| Variant | Branch status | UAT status | MVP scope decision | Notes |\n|---|---|---|---|---|\n| [Variant name] | built + evaluated | Pass | in MVP scope | [evidence link] |\n| [Variant name] | built + not run | Not run | undecided | manual UAT required before consolidation |\n| [Variant name] | approved but unbuilt\u002Fdeferred | Not run | undecided | build\u002Fevaluate, explicitly exclude\u002Fdefer, or include as spec-only reference before consolidation |\n| [Variant name] | explicitly excluded from MVP | Skipped | excluded | explicit user decision required |\n\n### Shared Evaluation Script\n\n- Target user:\n- Scenario:\n- Setup:\n- Core task sequence:\n- Success criteria:\n- Non-acceptance signals:\n- Evidence to capture:\n\n### Per-Variant Result Log\n\n#### [Variant name]\n\n- Status: Not run | Pass | Fail | Blocked\n- Evidence captured:\n- What worked:\n- What felt wrong:\n- Time\u002Ffriction notes:\n- Keep for consolidation:\n- Reject for consolidation:\n- Confidence: Low | Medium | High\n\n### Side-by-Side Comparison Matrix\n\n| Dimension | Variant A | Variant B | Variant C | Current preference | Evidence |\n|---|---|---|---|---|---|\n\n### Ready for `$consolidate-prototypes`?\n\n- [ ] Every built MVP-scope variant has been tried and has evidence in its result log.\n- [ ] No built MVP-scope result log is still `Not run`.\n- [ ] Every approved but unbuilt\u002Fdeferred branch is explicitly excluded from MVP, deferred from MVP, or marked spec-only by the user.\n- [ ] If converging from one built variant, the user explicitly chose a single-variant MVP and named how all other approved branches are handled.\n- [ ] Evidence exists for each kept\u002Frejected design element.\n- [ ] Open blockers are documented.\n- [ ] The user has enough confidence to converge.\n```\n\nUse this item format in `tasks\u002Fmanual-todo.md`:\n\n```markdown\n## UAT Journeys\n\n- [ ] Run UAT journey: [Journey name] as [target user] _(after: research\u002Fuat-plan.md)_ - capture evidence in `research\u002Fuat-plan.md`.\n```\n\n## Task Classification\n\n- Human UAT journey execution goes in `tasks\u002Fmanual-todo.md`.\n- Variant evaluation tasks go in `tasks\u002Fmanual-todo.md` under `## UAT Journeys` and should reference `research\u002Fuat-variant-evaluation-[topic].md`.\n- Immediate implementation or documentation fixes confirmed by completed UAT go in `tasks\u002Ftodo.md`.\n- One-time condition-gated evidence collection goes in `tasks\u002Frecord-todo.md`.\n- Release-cadence UAT checks go in `tasks\u002Frecurring-todo.md`.\n- Do not put non-blocking records or recurring obligations in `tasks\u002Ftodo.md` unless they have been explicitly promoted into current execution work.\n\n## Constraints\n\n- Do not run or operate the product in this skill.\n- Do not start dev servers, launch browsers, use Playwright, call APIs, create accounts, or perform CLI workflows.\n- Do not mark journeys complete; only a human tester can do that after performing them.\n- Do not recommend `$consolidate-prototypes` before variant evaluation evidence exists and no built MVP-scope result log is `Not run`.\n- Do not recommend `$consolidate-prototypes` while approved UX\u002FUI branches remain unbuilt or deferred unless the user explicitly excludes or defers them from MVP scope, marks them spec-only, or explicitly chooses a single-variant MVP from the current built set.\n- Do not duplicate existing unchecked UAT or manual tasks. Reference existing items when they already cover the same journey.\n- Prefer evidence-backed target-user journeys over exhaustive feature coverage.\n- Keep dogfood and UAT separate: use `$dogfood` for owner\u002Foperator adoption into the builder's workflow; use `$uat` for target-user acceptance journeys.\n- If no credible user journey, story, spec, or product surface can be found, stop and recommend `$customer-discovery`, `$journey-map`, or the relevant pack research skill. Apply the Pack Availability Guard for pack-based skills.\n\n## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Fuat-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install \u003Cpack>` instead of the target skill. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend `npx skillpacks install \u003Cpack-or-skill>`; for unavailable base skills, recommend `npx skillpacks init` before the skill.\n\n# UAT\n\nInvoke as `$uat`.\n\nCreate a user acceptance testing plan from the perspective of a potential or target user. Read the product surface, specs, journeys, stories, roadmap, and relevant research, then produces realistic end-to-end user journeys that validate whether the product satisfies user goals.\n\nUAT is not dogfooding. Dogfood asks how the app owner can adopt the product into their own workflow to understand and evaluate it. UAT asks whether a target user can complete meaningful real-world journeys and would accept the product as fit for use.\n\nThis is a human-run acceptance plan, not automated testing. Do not start servers, drive browsers, call APIs, create accounts, or perform the scenarios yourself.\n\nWhen invoked with `--variant-evaluation` (or when the user asks to test\u002Freview UI variants), create a hands-on evaluation plan for built UX\u002FUI variants before any consolidation decision. This mode helps the user try each variant in a comparable way and capture enough evidence to form a defensible consolidation opinion.\n\nFollow `DESIGN-TREE-LOOP.md` for prototype-phase routing, state storage, approval boundaries, and task classification. Human-run prototype\u002FUAT evaluation belongs in `tasks\u002Fmanual-todo.md`; confirmed implementation fixes may enter `tasks\u002Ftodo.md` only after human evidence exists.\n\n## Design-Tree Role\n\n`uat` is a **sub-skill** in the design-tree loop (`DESIGN-TREE-LOOP.md`). Its `parent:` is `logic-wiring`, and it is also invoked inline by `consolidate-prototypes` (variant evaluation) and by the execution loop (release\u002Fjourney UAT). It enters at its own **checklist\u002Fevaluation stage** — building hands-on journeys and capturing human evidence — and does **no pipeline routing of its own**: it returns evidence to the invoking parent, which owns the handoff. Its existing recommendations (e.g. `$consolidate-prototypes`, `$customer-discovery`) are fallback suggestions, not design-tree branch routing.\n\n## Process\n\n### 0. Product-Path Scope Resolution\n\nResolve research scope by product path before using code or app structure as a hint:\n\n1. If `$ARGUMENTS` names a non-archived `research\u002F{slug}\u002F` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product\u002Fapp name, not the ICP, audience, or segment label.\n2. If `$ARGUMENTS` names only `research\u002F_archive\u002F{slug}\u002F` or a manifest entry with `status: archived` or legacy `status: abandoned`, stop and warn that the path is archived; do not write or update scoped outputs there.\n3. Read `research\u002F.progress.yaml` when present. Normalize legacy `active_path` to `active_paths` on read and write back `active_paths` on manifest updates. Treat legacy `abandoned` as `archived`; exclude `archived`, `abandoned`, `deferred`, `revisit_candidate`, `promoted`, and any `scope_path` under `research\u002F_archive\u002F` from active target selection.\n4. If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target unless this skill explicitly supports cross-path output.\n5. If no active manifest target exists, list non-archived product directories under `research\u002F`, excluding `research\u002F_archive\u002F` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.\n6. If no product directories exist, use flat `research\u002F` single-product mode.\n7. Detect monorepo\u002Fapp\u002Fpackage structure only as a secondary hint. Suggest creating a missing `research\u002F{slug}\u002F` product path when code clearly exposes an app, but do not require code or monorepo detection before using `research\u002F{slug}\u002F`.\n\nWhen product path `{slug}` is active, read and write research under `research\u002F{slug}\u002F`, read pre-prototype design artifacts under `design\u002F{slug}\u002F`, read finalized implementation specs under `specs\u002F{slug}\u002F`, and treat top-level `research\u002F*.md` and `design\u002F*.md` files as flat-mode documents or cross-path summaries.\n\n1. **Resolve project context**\n   - Read `.agents\u002Fproject.json` if it exists.\n   - Use `project_type` and `enabled_packs` when present.\n   - If project metadata is missing, infer the project type from repo signals:\n     - business-app: SaaS, marketplace, productivity, workflow, enterprise, or user-facing app\n     - devtool: SDK, CLI, API, library, infrastructure, docs, examples, or package-first developer workflow\n     - game: game engine files, playable prototypes, store assets, or game-specific README\u002Fspec language\n     - generic: no strong domain signal\n   - Read `README.md`, `AGENTS.md`, `CLAUDE.md`, relevant `docs\u002F`, `specs\u002F`, `spec.md`, and `tasks\u002F` files when present.\n\n2. **Load user evidence**\n   - Business app: read `research\u002Ficp.md`, `research\u002Fjourney-map.md`, `research\u002Fcustomer-feedback.md`, `research\u002Fmetrics.md`, and `research\u002Fmvp-gap.md` when present.\n   - Devtool: read `research\u002Fdevtool-user-map.md`, `research\u002Fdevtool-dx-journey.md`, `research\u002Fdevtool-integration-map.md`, docs, examples, and package manifests when present.\n   - Game: read `research\u002Fgame-audience.md`, `research\u002Fgame-fantasy.md`, `research\u002Fgame-core-loop.md`, `research\u002Fgame-prototype-test.md`, and `research\u002Fgame-playtest-metrics.md` when present.\n   - Generic: use specs, README, routes, tests, examples, issue descriptions, and task acceptance criteria.\n   - In product-path workspaces with `research\u002F{slug}\u002F` or `specs\u002F{slug}\u002F`, produce product-path-scoped UAT journeys for the requested app. If no app is specified and multiple apps are plausible, ask the user to choose.\n\n2b. **Variant evaluation mode**\n   - Trigger this branch when invoked with `--variant-evaluation`, when `design\u002Fui-layout-variations-*.md`, `design\u002Fux-variations-*.md`, or product-path-scoped equivalents exist for the requested topic, or when the user asks how to test\u002Freview built variants. Legacy `specs\u002Fui-layout-variations-*.md` may also trigger this branch during migration.\n   - Read `design\u002Fui-layout-variations-[topic].md`, `design\u002Fux-variations-[topic].md`, `design\u002Fui-requirements-[topic].md`, `design\u002F**\u002Fflow-tree-*.yaml`, `design\u002Fprototype-build-plan-[topic].md`, product-path-scoped equivalents, built prototype directories under `prototypes\u002F{topic}\u002F`, built variant routes\u002Fcomponents, and any existing `research\u002Fuat-variant-evaluation-[topic].md`.\n   - Treat legacy `specs\u002Fui-layout-variations-[topic].md`, `specs\u002Fux-variations-[topic].md`, and `specs\u002Fui-requirements-[topic].md` as fallback evidence only when the corresponding `design\u002F` artifact is missing.\n   - Identify each variant, its intended thesis, implementation location, and the target user task it should support.\n   - Create comparable journeys that make the user perform the same core task in every variant, then capture variant-specific strengths, friction, confidence, and rejection signals.\n   - Include a side-by-side comparison matrix and a \"Ready for `$consolidate-prototypes`?\" checklist.\n   - In the variant inventory and readiness output, distinguish these four statuses explicitly: `built + evaluated`, `built + not run`, `approved but unbuilt\u002Fdeferred`, and `explicitly excluded from MVP`.\n   - Human execution still belongs in `tasks\u002Fmanual-todo.md`; this skill writes the plan and manual tasks, but does not run the variants.\n   - While any built variant result log is `Not run`, recommend manual UAT\u002Fevidence capture rather than `$consolidate-prototypes`.\n   - Mention `$consolidate-prototypes` only after result logs record evidence and either every MVP-scope approved variant is evaluated or the user explicitly chooses a single-variant MVP and excludes, defers, or marks all other approved unbuilt branches as spec-only references.\n   - Stop after this branch. Do not generate generic target-user acceptance journeys unless the user also requested them.\n\n3. **Define acceptance perspective**\n   - Identify 1-3 target user personas or roles from the evidence.\n   - For each selected persona, define the job-to-be-done, context, goal, constraints, and acceptance threshold.\n   - Prefer external target users, buyers, evaluators, administrators, developers, or players over the product owner unless the owner is also the target user.\n   - If the target user is unclear, stop and recommend `$customer-discovery`, `$journey-map`, or the relevant pack research skill. For `$customer-discovery`, `$journey-map`, and other pack-based skills, apply the Pack Availability Guard — if the target skill's pack is not in `.agents\u002Fproject.json` `enabled_packs`, recommend `npx skillpacks install \u003Cpack>` before the skill.\n\n4. **Create UAT journeys**\n   - Generate 3-7 journeys unless the user requested a narrower focus.\n   - Cover at least one critical happy path, one realistic obstacle or recovery path, and one return-use or handoff path when supported by the product evidence.\n   - Each journey must include:\n     - target user\n     - user goal\n     - real-world trigger\n     - setup and preconditions\n     - end-to-end task sequence\n     - expected user-visible success state\n     - acceptance criteria\n     - non-acceptance signals\n     - evidence to capture\n     - tester notes prompt\n     - follow-up routing\n   - Use concrete product language from specs and journeys. Avoid vague instructions such as \"verify the feature works.\"\n\n5. **Classify follow-up work**\n   - Human-run UAT journeys go in `tasks\u002Fmanual-todo.md` under `## UAT Journeys`.\n   - Use `_(after: research\u002Fuat-plan.md)_` unless the journey blocks or follows a known roadmap step. If tied to a known step, use `_(blocks: Step N.X)_` or `_(after: Step N.X)_`.\n   - Do not put human-run UAT journeys in `tasks\u002Ftodo.md`.\n   - Implementation or documentation fixes discovered after a completed UAT run belong in `tasks\u002Ftodo.md`, but do not invent fixes before the user journey has been attempted.\n   - One-time evidence collection belongs in `tasks\u002Frecord-todo.md`.\n   - Recurring release acceptance checks belong in `tasks\u002Frecurring-todo.md` only when there is a clear release cadence.\n   - If a journey needs click-by-click help for a human-only external blocker, recommend `$guide`.\n\n6. **Present findings before writing when risk is high**\n   - If source material is thin, contradictory, or missing target-user evidence, summarize the gap and ask whether to proceed with assumptions.\n   - If source material is sufficient, write the plan and task sections directly.\n\n## Deliverables\n\n- `research\u002Fuat-plan.md` - persona assumptions, journey matrix, source evidence, acceptance checklist, result log template, and follow-up guidance.\n- In variant evaluation mode: `research\u002Fuat-variant-evaluation-[topic].md` - variant inventory, task script, comparison matrix, result logs, and consolidation readiness checklist.\n- `tasks\u002Fmanual-todo.md` - append or replace only the `## UAT Journeys` section.\n- `tasks\u002Frecurring-todo.md` - optional, only when recurring UAT is useful and not already tracked.\n\nIf `tasks\u002Fmanual-todo.md` does not exist, create it with a `# Manual Tasks - [Project Name]` title, a short note that these items require human-only action, and the UAT section. Preserve all non-UAT sections when updating an existing file.\n\nUse this journey format in `research\u002Fuat-plan.md`:\n\n```markdown\n### Journey N: [Name]\n\n- Target user: [persona or role]\n- User goal: [what the user is trying to accomplish]\n- Trigger: [real-world reason the user starts]\n- Setup: [accounts, data, environment, permissions, or sample state needed]\n- Task sequence:\n  - [step the human tester performs as the target user]\n- Expected success state: [observable user-visible result]\n- Acceptance criteria:\n  - [ ] [specific criterion]\n- Non-acceptance signals: [confusion, delay, missing affordance, incorrect result, trust issue, or blocker]\n- Evidence to capture: [screenshots, recordings, notes, timestamps, records, command output, or artifacts]\n- Tester notes prompt: [question that captures whether the target user would accept this]\n- Follow-up routing: [manual note, $customer-discovery, $journey-map, $guide, or task promotion guidance]\n\n#### UAT result log\n\n- Status: Not run | Pass | Fail | Blocked\n- Evidence captured:\n- Tester notes:\n- Follow-up tasks promoted:\n```\n\nUse this variant evaluation format in `research\u002Fuat-variant-evaluation-[topic].md`:\n\n```markdown\n## Variant Evaluation Plan\n\n### Variant Inventory\n\n| Variant | Implementation location | Thesis | Primary task |\n|---|---|---|---|\n\n### Variant Readiness Inventory\n\n| Variant | Branch status | UAT status | MVP scope decision | Notes |\n|---|---|---|---|---|\n| [Variant name] | built + evaluated | Pass | in MVP scope | [evidence link] |\n| [Variant name] | built + not run | Not run | undecided | manual UAT required before consolidation |\n| [Variant name] | approved but unbuilt\u002Fdeferred | Not run | undecided | build\u002Fevaluate, explicitly exclude\u002Fdefer, or include as spec-only reference before consolidation |\n| [Variant name] | explicitly excluded from MVP | Skipped | excluded | explicit user decision required |\n\n### Shared Evaluation Script\n\n- Target user:\n- Scenario:\n- Setup:\n- Core task sequence:\n- Success criteria:\n- Non-acceptance signals:\n- Evidence to capture:\n\n### Per-Variant Result Log\n\n#### [Variant name]\n\n- Status: Not run | Pass | Fail | Blocked\n- Evidence captured:\n- What worked:\n- What felt wrong:\n- Time\u002Ffriction notes:\n- Keep for consolidation:\n- Reject for consolidation:\n- Confidence: Low | Medium | High\n\n### Side-by-Side Comparison Matrix\n\n| Dimension | Variant A | Variant B | Variant C | Current preference | Evidence |\n|---|---|---|---|---|---|\n\n### Ready for `$consolidate-prototypes`?\n\n- [ ] Every built MVP-scope variant has been tried and has evidence in its result log.\n- [ ] No built MVP-scope result log is still `Not run`.\n- [ ] Every approved but unbuilt\u002Fdeferred branch is explicitly excluded from MVP, deferred from MVP, or marked spec-only by the user.\n- [ ] If converging from one built variant, the user explicitly chose a single-variant MVP and named how all other approved branches are handled.\n- [ ] Evidence exists for each kept\u002Frejected design element.\n- [ ] Open blockers are documented.\n- [ ] The user has enough confidence to converge.\n```\n\nUse this item format in `tasks\u002Fmanual-todo.md`:\n\n```markdown\n## UAT Journeys\n\n- [ ] Run UAT journey: [Journey name] as [target user] _(after: research\u002Fuat-plan.md)_ - capture evidence in `research\u002Fuat-plan.md`.\n```\n\n## Task Classification\n\n- Human UAT journey execution goes in `tasks\u002Fmanual-todo.md`.\n- Variant evaluation tasks go in `tasks\u002Fmanual-todo.md` under `## UAT Journeys` and should reference `research\u002Fuat-variant-evaluation-[topic].md`.\n- Immediate implementation or documentation fixes confirmed by completed UAT go in `tasks\u002Ftodo.md`.\n- One-time condition-gated evidence collection goes in `tasks\u002Frecord-todo.md`.\n- Release-cadence UAT checks go in `tasks\u002Frecurring-todo.md`.\n- Do not put non-blocking records or recurring obligations in `tasks\u002Ftodo.md` unless they have been explicitly promoted into current execution work.\n\n## Constraints\n\n- Do not run or operate the product in this skill.\n- Do not start dev servers, launch browsers, use Playwright, call APIs, create accounts, or perform CLI workflows.\n- Do not mark journeys complete; only a human tester can do that after performing them.\n- Do not recommend `$consolidate-prototypes` before variant evaluation evidence exists and no built MVP-scope result log is `Not run`.\n- Do not recommend `$consolidate-prototypes` while approved UX\u002FUI branches remain unbuilt or deferred unless the user explicitly excludes or defers them from MVP scope, marks them spec-only, or explicitly chooses a single-variant MVP from the current built set.\n- Do not duplicate existing unchecked UAT or manual tasks. Reference existing items when they already cover the same journey.\n- Prefer evidence-backed target-user journeys over exhaustive feature coverage.\n- Keep dogfood and UAT separate: use `$dogfood` for owner\u002Foperator adoption into the builder's workflow; use `$uat` for target-user acceptance journeys.\n- If no credible user journey, story, spec, or product surface can be found, stop and recommend `$customer-discovery`, `$journey-map`, or the relevant pack research skill. Apply the Pack Availability Guard for pack-based skills.\n\n## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Fuat-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":39,"parent":48,"version":49,"invocation":50,"description":7,"argument-hint":51,"context_intake":52,"required_conventions":53},"logic-wiring","v0.15","sub-skill","[--variant-evaluation] [optional: persona, feature, release, journey, app, or variation spec]","artifact_only",[54,55],"alignment-page","design-tree-loop","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-testing\u002Fcodex\u002Fuat\u002Farchive\u002Fv0.15",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill uat",{"tool":72,"command":73},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill uat",{"tool":75,"command":76},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill uat","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-testing\u002Fcodex\u002Fuat\u002Farchive\u002Fv0.15\u002FSKILL.md",true,[],[81,93,103,115,128,139],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":43},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[88,89,90,35,91,92],"source checkout allowed","checkout","fixture","v0","valid",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":43},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[100,101,102,92,90,91],"deck install valid","deck","install",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":43},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[110,111,112,92,113,114,90,91],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":124,"publishedAt":43},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[125,126,92,113,91,127,90],"codex missing skill valid","missing","fallback",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":43},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[134],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},[92,113,127,136,137,138,91,90],"base skill","codex base skill fallback valid","base",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":43},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[92,112,111,146,114,91,90],"claude pack guard valid"]