skillpacks 0.1.1 → 0.1.2

package/packs/product-design/codex/ux-variations/archive/v0.18/SKILL.md

@@ -0,0 +1,267 @@
+---
+name: ux-variations
+description: Interview and plan multiple UX and UI variations for a product, page, or flow, including onboarding, typical workflows, sharing, collaboration, return use, and interface alternatives users can compare before locking a direction — and concrete visual/layout UI variations with UAT before consolidation
+type: planning
+version: v0.18
+argument-hint: "[optional: app, page, flow, feature, or existing UI spec]"
+visual_tier: prototype
+---
+
+# UX Variations
+
+Invoke as `$ux-variations`.
+
+Use this skill when the user wants to explore multiple UX/UI directions before committing to a final experience. In the default product-design tree, this skill expands one specific user flow from `$user-flow-map` into alternate progression branches: different ways users can enter, advance, recover, hand off, complete, or abandon the flow. It then creates variation plans for flow progression, layout implications, navigation models, interaction patterns, component choices, content density, visual tone, and behavior so the user can compare, test, and decide which branch should move into `$ui-interview`.
+
+In the normal AFPS product route, use `$user-flow-map` first to establish the wireframe-tree root and name the user-flow branches. Then run `$ux-variations [specific-user-flow]` to explore alternate ways users can progress through that selected flow. After a variation branch is ready for UI treatment, route that branch to `$ui-interview [specific-ux-variation]` for visual mockup, alignment, approval/rejection, and next-branch routing.
+
+Use `$user-flow-map` first when the interface has no credible flow structure. Use this skill directly only when a user-flow map, current implementation, screenshot, prototype, explicit user prompt, or clear feature scope already identifies the flow being varied. Do not require a finalized UI requirements spec before default UX variation work; the point is to compare alternative progression paths before a single branch becomes a UI proposal.
+
+When invoked with `--layout-mode` (or when the user says "layout mode", "layout variations", or "UI variations"), this skill operates at the concrete component/layout level — it varies HOW the same content is presented visually, not WHAT the user flow is. Layout-mode is an explicit bounded mode for cases where both the flow and content contract are already fixed; otherwise default to progression-path UX variations. Layout-mode takes a fixed flow contract from `specs/user-flow-[topic].md` plus a fixed content contract from `specs/ui-requirements-[topic].md` or equivalent and generates 2-5 concrete visual/spatial approaches. Each variation must be specified well enough to build as a lightweight implementation, then evaluated through `$uat --variant-evaluation` (check `.agents/project.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `npx skillpacks install product-testing` from the project shell, first) before `$consolidate-variations`.
+
+## Process
+
+### 0. Product-Path Scope Resolution
+
+Resolve research scope by product path before using code or app structure as a hint:
+
+1. If `$ARGUMENTS` names a non-archived `research/{slug}/` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product/app name, not the ICP, audience, or segment label.
+2. If `$ARGUMENTS` names only `research/_archive/{slug}/` 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.
+3. Read `research/.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/_archive/` from active target selection.
+4. 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.
+5. If no active manifest target exists, list non-archived product directories under `research/`, excluding `research/_archive/` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.
+6. If no product directories exist, use flat `research/` single-product mode.
+7. Detect monorepo/app/package structure only as a secondary hint. Suggest creating a missing `research/{slug}/` product path when code clearly exposes an app, but do not require code or monorepo detection before using `research/{slug}/`.
+
+When product path `{slug}` is active, read and write research under `research/{slug}/`, specs under `specs/{slug}/`, and treat top-level `research/*.md` files as flat-mode documents or cross-path summaries.
+
+1. **Resolve context**
+   - Read `.agents/project.json` if it exists.
+   - Read `README.md`, `AGENTS.md`, `CLAUDE.md`, relevant `docs/`, `specs/`, `research/`, task files, screenshots, route files, and component implementations when present.
+   - Read `research/.progress.yaml` when present. Normalize `active_path` (singular legacy) to `active_paths` (plural list) when reading; treat legacy `abandoned` as `archived` and exclude archived/deferred/revisit/promoted paths plus `research/_archive/` scopes from active target selection. Use `active_paths` as the product/app focuses and treat deferred `product_paths[]` as parked product directions, not required UX variants.
+   - Prefer existing `specs/user-flow-*.md` as the normal AFPS input and select one named user-flow branch as the variation surface.
+   - Also read `specs/ui-*.md`, product specs, journey maps, ICP research, positioning research, and user feedback as source evidence.
+   - If no credible flow structure exists, run or recommend `$user-flow-map` before developing variants.
+   - If the user explicitly requests layout-mode and no credible content/data/action contract exists, run or recommend `$ui-interview --requirements-only` before developing layout-mode variants.
+
+2. **Define the decision surface**
+   - Identify what the user is deciding: the selected user flow, onboarding, activation, typical workflow, sharing flow, collaboration model, purchase flow, editor, dashboard, settings, mobile experience, page layout, or another bounded surface.
+   - Identify the parent user-flow branch, the upstream `user-flow-map` source, and any sibling user flows or prior UX/UI proposals that this variation must coordinate with.
+   - Identify which dimensions are allowed to vary:
+     - First-run onboarding and activation
+     - Core workflow sequencing
+     - Sharing, invitations, permissions, and collaboration
+     - Return-use loops and re-entry points
+     - Notifications, reminders, and status surfaces
+     - Handoffs between users, roles, devices, or channels
+     - Recovery from errors, empty states, and stalled progress
+     - Information architecture
+     - Navigation
+     - Page layout
+     - Task flow order
+     - Component model
+     - Data density
+     - Visual hierarchy
+     - Motion and transition behavior
+     - Copy tone
+     - Mobile behavior
+   - Identify fixed constraints: brand, stack, design system, must-keep components, accessibility, launch scope, performance, and business requirements.
+   - **Default progression-mode addition**: For each selected user flow, identify which parts may vary: entry route, sequencing, step granularity, user choice points, system automation, handoff points, review/edit loops, save-for-later behavior, cancellation, recovery, permissions, notifications, and completion criteria. Preserve the parent flow boundary while allowing progression branches to differ meaningfully.
+   - **Layout-mode addition**: In layout-mode, read `specs/user-flow-[topic].md` as the fixed screen-flow contract and `specs/ui-requirements-[topic].md` as the fixed content contract. The WHAT and flow order are locked; only the HOW varies. Layout dimensions that can vary:
+     - Container pattern: card grid, data table, list, kanban, timeline, tree, masonry
+     - Detail pattern: sidebar panel, full-page route, modal, drawer, inline expand, popover
+     - Navigation: top-nav, side-nav, tab-based, breadcrumb-driven, command-palette, hybrid
+     - Density: compact, comfortable, spacious
+     - Hierarchy: content-first, chrome-first, action-first
+     - Responsive strategy: reflow, collapse, separate mobile layout, progressive disclosure
+
+3. **Surface assumptions before probing**
+   - Present a UX Variation Assumptions Manifest before deep questioning.
+   - Tag assumptions with `[from spec]`, `[from codebase]`, `[from research]`, `[from artifact]`, or `[inferred]`.
+   - Cover:
+     - Target users and usage context
+     - Parent user flow and selected branch scope
+     - Primary job or workflow
+     - First-run moment, activation event, and "aha" threshold
+     - Typical repeat-use workflow
+     - Sharing, collaboration, and permission assumptions
+     - Return triggers, notifications, and re-engagement assumptions
+     - Cross-device, cross-role, or external handoff assumptions
+     - Existing pain points or uncertainty
+     - Decisions that are locked versus open, including which parts of the parent flow may vary
+     - Evaluation criteria
+     - Required variants and desired breadth
+     - Prototype fidelity and implementation budget
+     - Success metrics and selection method
+   - Ask the user to confirm, correct, or flag assumptions before proceeding.
+   - Deliver every manifest/checklist/checkpoint the user must confirm inline as the final message text of its own turn; ask the confirmation question in the next turn (consistent with the one-question-per-turn cadence). Never emit it only as mid-turn text in a turn that ends with a tool or command call — harness rendering does not guarantee mid-turn text is shown. A confirmation question must never reference content the user has not been shown.
+
+4. **Interview for variation goals**
+   - Codex interview cadence is one primary decision question per turn by default. Use short follow-up bullets only when they clarify the same variation decision, not to batch unrelated questions.
+   - Default to maximally contrasting archetypes. Do not ask how different variants should be — assume dramatic contrast unless the user explicitly requests graduated steps.
+   - Default evaluation method is: build each variation, then run `$uat --variant-evaluation` (check `.agents/project.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `npx skillpacks install product-testing` from the project shell, first) so the user has task-based evidence before consolidation.
+   - When presenting a design decision with 3+ plausible answers during the interview, always include "Make this a variant axis (test all approaches)" as an option. When the user has already chosen "test all" for a prior question in the same session, default subsequent ambiguous decisions to variant axes without asking.
+   - Establish:
+     - Assume solo evaluator building and gut-checking unless the user states otherwise
+     - Which user flow from the wireframe tree is being expanded
+     - What they must be able to accomplish
+     - Which progression moments can vary: entry, sequencing, decision points, handoffs, recovery, completion, and re-entry
+     - How a new user arrives, signs up, understands the product, and reaches first value
+     - What the normal repeat workflow looks like after onboarding
+     - What users create, save, share, export, invite others into, or hand off
+     - What roles or permission levels exist, and how collaboration should feel
+     - What notifications, reminders, status updates, or activity feeds users expect
+     - How users resume work after hours, days, or weeks away
+     - What happens when a workflow is abandoned, blocked, invalid, offline, or partially complete
+     - Which current interface parts are working
+     - Which current interface parts feel wrong, uncertain, slow, confusing, too dense, too sparse, or too generic
+     - What would make a variant unacceptable
+     - What evidence will decide the winner
+   - When the user is unsure, recommend a practical default and explain why.
+   - **Layout-mode interview additions**: When in layout-mode, also ask:
+     - What is the primary user task on this page? (scan, search, create, compare, monitor, triage)
+     - How much data will typically be visible? (5 items, 50 items, 500 items)
+     - Are there reference apps or pages the user admires for this type of content?
+     - Are any layout patterns explicitly off the table?
+     - What is the build budget per variation? (quick prototype, medium fidelity, production-ready)
+     - What must the user do in each built variant before they are ready to consolidate?
+
+5. **Create distinct variation concepts**
+   - Produce 5 variations by default. Present the concepts for adjustment — do not ask the user to choose a count first.
+   - Each variation must be meaningfully different, not just a color or spacing change.
+   - At this stage, keep each concept lightweight: name, thesis, archetype, best-fit user/context, core workflow difference, major tradeoff, and rough complexity. Do not fully specify screens, controls, or implementation details yet.
+   - Useful archetypes include:
+     - Task-first workflow
+     - Data-dense operator console
+     - Guided step-by-step flow
+     - Onboarding-first activation path
+     - Collaboration-first workspace
+     - Sharing-first artifact flow
+     - Notification/status-driven workflow
+     - Role-based handoff workflow
+     - Visual canvas or board
+     - Command/search-first interface
+     - Mobile-first progressive disclosure
+     - Familiar SaaS dashboard
+     - Editorial or showcase layout
+   - Only choose archetypes that fit the product and user context.
+   - **Layout-mode archetypes** (use these instead of the UX-flow archetypes above when in layout-mode):
+     - Card grid: visual items in a responsive grid, good for browsing and scanning
+     - Data table: dense rows with sortable/filterable columns, good for operators and power users
+     - List + detail panel: master list on left, detail sidebar on right, good for email/messaging patterns
+     - Full-page detail: list view navigates to full-page item view, good for content-heavy items
+     - Kanban / board: columns representing states or categories, good for workflow and status tracking
+     - Timeline / feed: chronological stream, good for activity, logs, and social patterns
+     - Dashboard mosaic: mixed widget grid with charts, lists, and stats, good for monitoring and overview
+     - Split-pane workspace: resizable panels for parallel content, good for editors and comparison
+     - Command-first minimal: search/command bar with minimal chrome, good for keyboard-heavy power users
+     - Sidebar-driven: persistent sidebar navigation with content area, good for settings and multi-section apps
+
+6. **Concept selection checkpoint**
+   - Before fully specifying any variant, ask the user to adjust the concept set.
+   - Use bounded wording such as: "How should I adjust these UX variants before writing the final spec?"
+   - Present clear options:
+     - Keep all concepts
+     - Make one concept bolder or more extreme
+     - Add another concept
+   - Do not ask the user to remove or merge concepts before they have been built. Pre-build narrowing is consistently rejected.
+   - Ask the user to name the affected concept and briefly describe the change when they choose anything other than keeping all concepts.
+   - Recommend a practical default when evidence supports it; do not imply that variants have already been built or committed.
+   - Revise the concept set based on the answer before moving on.
+
+7. **Specify each approved variation enough to build**
+   - For each variation, define:
+     - Name and design thesis
+     - Target user fit
+     - Parent user flow and branch relationship
+     - Page and flow changes
+     - Progression model: how the user advances through the flow and how this differs from sibling variations
+     - Onboarding and activation model
+     - Typical workflow sequence
+     - Sharing, collaboration, and permissions model
+     - Return-use and notification model
+     - Failure recovery and abandoned-workflow behavior
+     - Navigation model
+     - Screen-by-screen layout
+     - Key components and controls
+     - Button and link behavior
+     - Spatial density, sizing, and hierarchy
+     - Responsive behavior
+     - Visual tone
+     - Strengths, risks, and failure modes
+     - Implementation complexity
+     - What to prototype first
+     - What user signal would make this branch ready for `$ui-interview`
+   - **Layout-mode variation spec additions**: In layout-mode, each variation spec must also include:
+     - Content-to-component mapping: which content requirement maps to which UI component
+     - Page regions with approximate proportions (e.g., sidebar 280px, content fluid, detail panel 400px)
+     - Primary content component
+     - Detail view pattern
+     - Action placement
+     - Navigation pattern and placement
+     - Responsive behavior at 3 breakpoints (mobile <=640px, tablet <=1024px, desktop >1024px)
+     - Density approach
+     - States rendering
+     - Implementation file list
+     - Estimated build time
+     - Variant evaluation task: the user task to perform in this variation before consolidation
+     - Evidence to capture: screenshots, notes, time-to-complete, friction points, and acceptance/rejection signals
+
+8. **Plan experimentation**
+   - Recommend serial full buildout of all approved variants when the user is using layout-mode or explicitly wants to compare built interfaces. Do not recommend building a subset first unless the user asks for a smaller experiment.
+   - For prototype-stage product or feature work, prefer numerous small route-based experiments over one merged prototype when multiple workflows, layouts, densities, copy approaches, navigation models, or interaction patterns remain plausible. Name the route for each experiment, such as `/experiments/table-first`, `/experiments/command-first`, or the project's equivalent, and keep shared production infrastructure out of those routes unless explicitly approved.
+   - If route experiments imply materially different products, apps, ICPs, or product lines, update `research/.progress.yaml` with experiment product-path entries instead of making every divergent path a required UX variation. Include `id`, `label`, `source_skill: ux-variations`, `scope_path`, `status`, `reason`, `archive_reason`, `archived_at`, `promoted_at`, `evidence_refs`, `revisit_trigger`, `next_skill`, `pipeline_stage: ux-variations`, and `last_touched`.
+   - After progression variants are specified, route the next selected branch to `$ui-interview [specific-ux-variation]` for visual mockup and approval/rejection. If variants are built before UI interview, recommend `$uat --variant-evaluation` (check `.agents/project.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `npx skillpacks install product-testing` from the project shell, first) before `$consolidate-variations`. Consolidation is premature until evaluation evidence exists or the user explicitly says they reviewed the variants and is ready to converge.
+   - Define the cheapest useful validation method:
+     - Static mockups for visual direction
+     - Clickable prototype for navigation and flow
+     - Feature-flagged implementation for real usage
+     - A/B test only when traffic and metrics are credible
+     - Human UAT when target-user acceptance is the question
+   - Define comparison criteria before selecting a winner.
+   - Include a lock-in checklist so the chosen direction becomes a decision record, not a vague preference.
+   - Include a UAT handoff checklist:
+     - Target task for each variant
+     - Success criteria and non-acceptance signals
+     - Side-by-side comparison questions
+     - Evidence to capture
+     - Tradeoffs to notice
+     - Readiness criteria for `$consolidate-variations`
+
+9. **Coverage checkpoint**
+   - Before concluding, summarize the variants, the decision criteria, and the proposed experiment plan inline as the final message text of its own turn.
+   - In the next turn, ask whether any decision criteria, risks, validation steps, or implementation constraints are missing before writing deliverables.
+
+## Deliverables
+
+- Write the variation plan to `specs/ux-variations-[topic].md`.
+- Write the interview log to `ux-variations-[topic]-interview.md`.
+- Update `research/.progress.yaml` only when variant or route experiments create materially different product paths; downstream research remains active-path-only until a path is activated.
+- Include a branch-routing section that names the parent user flow, each UX variation branch, sibling flow/variation dependencies, and the recommended next `$ui-interview [specific-ux-variation]` branch.
+
+### Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/ux-variations-{topic}.html`.
+
+## Constraints
+
+- Do not present superficial variants that differ only by color palette, typography, or decorative treatment.
+- Do not treat default UX variation work as only visual layout exploration. Default variations should compare different ways users progress through a named user flow.
+- Do not choose a winner for the user unless the evidence clearly supports it and the user asked for a recommendation.
+- Do not defer all decisions to testing. State a recommended variant or experiment when evidence is sufficient.
+- Do not ignore implementation cost. A compelling variation still needs a prototype path and selection criteria.
+- Do not route directly from built UI variants to `$consolidate-variations`; insert `$uat --variant-evaluation` (check `.agents/project.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `npx skillpacks install product-testing` from the project shell, first) unless the user explicitly confirms they have already evaluated the variants.
+- Do not skip `$ui-interview` for a UX variation branch that needs a proposed UI, HTML visual mockup, or approval/rejection decision.
+- Do not enforce shared design constraints across variations. Each variation independently decides layout, density, color, navigation, and component choices. Only technical stack is shared unless the user explicitly locks a shared constraint.
+
+## Archive-First Replacement Policy
+
+- Before replacing or substantively rewriting an existing canonical research/spec document (`research/**/*.md`, `specs/**/*.md`, or `docs/specifications/**/*.md`), copy the current file to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-relative-path>`.
+- Preserve the archived snapshot exactly as it existed before the change; do not edit the archived copy after creating it.
+- After the archive snapshot exists, write the updated document to the original canonical path.
+- Report both the archive path and the updated canonical path in the final output.
+- New files do not need archive snapshots. Append-only updates do not need archive snapshots unless an existing section is regenerated or rewritten.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/product-testing/claude/dogfood/ALIGNMENT-PAGE.md

@@ -9,6 +9,8 @@ When this skill produces durable deliverables (research, specs, plans, reports,
 
 The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected by the upgrade script). The bundled ALIGNMENT-PAGE.md receives tier-appropriate rendering guidance from the generator.
 
+**Context intake.** This skill declares `context_intake: artifact_only` (Artifact-driven). Work from concrete artifacts, data, logs, or existing instructions by default; ask concise clarification questions only when the available artifacts are missing, contradictory, or unsafe to interpret.
+
 **Alignment lifecycle.** Alignment pages have three lifecycle states. `review` is the draft/pre-approval page: it contains the complete deliverable preview, evidence, required inline gate questions, section feedback controls, local section-feedback YAML only after a section feedback choice is selected, and one bottom `Compile Responses` control. `confirmed` is the post-approval page after the agent has consumed final compiled response YAML, made any approved user-requested edits, and written or updated the approved canonical artifacts. A confirmed page is finished and current for the completed alignment cycle, but it remains amendable when later research changes or extends the conclusions. `amended` is a future revision of a confirmed page: archive the previous confirmed page first, mark what changed, preserve the prior approval record, and highlight the new evidence, decisions, or scope that changed the earlier conclusion.
 
 **Central alignment index.** When a research-producing skill writes or updates an HTML alignment page, also maintain the repository's central alignment index. Look for `alignment/index.html` at the repository root; if the target repo documents a different central alignment-index path, use that path and report it. If the index does not exist, create it as a self-contained HTML page that works from `file://`, links to every active `alignment/*.html` page except itself, and includes the newly written page. Every index entry must include the page's alignment date in a muted meta span after the link, formatted `YYYY-MM-DD`, for example `<a href="page.html">Title</a> <span class="meta">2026-06-09</span>`. The alignment date is the review or confirmed date written inside the page itself; new pages use today's date. If the index exists, update it instead of blindly appending: preserve valid existing entries, metadata, and entry dates; remove duplicate entries for the same page path; keep links repo-relative; and include the new or updated page. When updating an existing index, add a date only to entries that are missing one, deriving it from the page's internal alignment date, or from file history when the page has no internal date. If a `new` marker is used, combine it with the date as `<span class="meta">new · YYYY-MM-DD</span>`, and remove stale `new` markers from entries that are no longer the latest addition.
@@ -57,7 +59,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-dogfood-research.md`; product-path mode uses `research/{slug}/_working/preliminary-dogfood-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-dogfood-research.md`; product-path mode uses `research/{slug}/_working/preliminary-dogfood-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **Glossary Additions gate.** When this research introduces domain-specific terms, acronyms, or concept definitions that a reader outside the project would not know, include a `## Glossary Additions` section in the alignment page. Render a table of proposed terms with columns: Term, Definition, Source (`dogfood`), Category (business/tooling/workflow/technical/domain), and per-term Approve/Edit/Reject/Flag radio controls. Only user-approved terms are appended to the target glossary (`research/glossary.md` or `research/{slug}/glossary.md` for scoped paths) during the confirmed-page write step. When the skill operates in a product-path scope, ask whether each term belongs in the parent or scoped glossary; default to the scoped glossary.
 

package/packs/product-testing/claude/dogfood/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.4 - 2026-06-12
+
+- Standardized active pack and skill install guidance on `npx skillpacks install <pack-or-skill>` instead of agent-native `/pack install` or `$pack install` recommendations.
+
 ## v0.3 - 2026-06-07
 
 - Routed missing-discovery dogfood handoffs from the retired `/icp` executable to `/customer-discovery` while preserving `research/icp.md` as evidence input.

package/packs/product-testing/claude/dogfood/SKILL.md

@@ -2,14 +2,14 @@
 name: dogfood
 description: Derive owner/operator dogfood scenarios from product evidence and active-use cadence, then produce adoption instructions and manual evaluation checks
 type: analysis
-version: v0.3
+version: v0.4
 argument-hint: "[optional: scenario focus, persona, feature, or release]"
-interview_depth: none
+context_intake: artifact_only
 ---
 
 ## Pack Availability Guard
 
-Before telling the user to run a skill from another project-local pack, check `.agents/project.json.enabled_packs`. If the target pack is not enabled, recommend `/pack install <pack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.
+Before telling the user to run a skill from another project-local pack, check `.agents/project.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install <pack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.
 
 # Dogfood
 
@@ -145,8 +145,8 @@ Use this item format in `tasks/manual-todo.md`:
 - Do not duplicate existing unchecked dogfood/manual tasks. Reference existing items when they already cover the same scenario.
 - Prefer evidence-backed owner/operator adoption scenarios over exhaustive coverage.
 - Keep dogfood and UAT separate: use `/dogfood` for owner/operator adoption into the builder's workflow; use `/uat` for target-user acceptance journeys.
-- If no credible user journey, story, spec, or product surface can be found, stop and recommend `/customer-discovery` (business-discovery pack), `/journey-map` (customer-lifecycle pack), 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/project.json` `enabled_packs`, recommend `/pack install <pack>` before the skill.
-- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, prepend `/pack install <pack-name>` to the recommendation.
+- If no credible user journey, story, spec, or product surface can be found, stop and recommend `/customer-discovery` (business-discovery pack), `/journey-map` (customer-lifecycle pack), 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/project.json` `enabled_packs`, recommend `npx skillpacks install <pack>` before the skill.
+- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, prepend `npx skillpacks install <pack-name>` to the recommendation.
 
 ## Alignment Page
 

package/packs/product-testing/claude/dogfood/archive/v0.3/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: dogfood
+description: Derive owner/operator dogfood scenarios from product evidence and active-use cadence, then produce adoption instructions and manual evaluation checks
+type: analysis
+version: v0.3
+argument-hint: "[optional: scenario focus, persona, feature, or release]"
+interview_depth: none
+---
+
+## Pack Availability Guard
+
+Before telling the user to run a skill from another project-local pack, check `.agents/project.json.enabled_packs`. If the target pack is not enabled, recommend `/pack install <pack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.
+
+# Dogfood
+
+Invoke as `/dogfood`.
+
+Create a practical dogfood plan for the app owner or operator. Read the codebase, specs, journey maps, stories, roadmap, and pack-specific research, then tells the operator how to adopt the product into their own workflow so they can understand, evaluate, and improve it through real use.
+
+Dogfood is not UAT. Dogfood asks how the app owner can use the product in their own work and observe what that reveals. UAT asks whether a target user can complete meaningful real-world journeys and would accept the product as fit for use; use `/uat` for that.
+
+This is a human-run product adoption plan, not automated testing. Do not run the product, start servers, drive a browser, call APIs, create accounts, or perform the scenarios yourself.
+
+## Process
+
+### 0. Product-Path Scope Resolution
+
+Resolve research scope by product path before using code or app structure as a hint:
+
+1. If `$ARGUMENTS` names a non-archived `research/{slug}/` directory or a product-path ID whose `scope_path` points there, use that path. Treat `{slug}` as the product/app name, not the ICP, audience, or segment label.
+2. If `$ARGUMENTS` names only `research/_archive/{slug}/` 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.
+3. Read `research/.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/_archive/` from active target selection.
+4. 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.
+5. If no active manifest target exists, list non-archived product directories under `research/`, excluding `research/_archive/` and dot directories. Auto-select only when exactly one exists; ask when multiple exist.
+6. If no product directories exist, use flat `research/` single-product mode.
+7. Detect monorepo/app/package structure only as a secondary hint. Suggest creating a missing `research/{slug}/` product path when code clearly exposes an app, but do not require code or monorepo detection before using `research/{slug}/`.
+
+When product path `{slug}` is active, read and write research under `research/{slug}/`, specs under `specs/{slug}/`, and treat top-level `research/*.md` files as flat-mode documents or cross-path summaries.
+
+1. **Resolve project context**
+   - Read `.agents/project.json` if it exists.
+   - Use `project_type` and `enabled_packs` when present.
+   - If project metadata is missing, infer the project type from repo signals:
+     - business-app: SaaS, marketplace, productivity, workflow, enterprise, or user-facing app
+     - devtool: SDK, CLI, API, library, infrastructure, docs, examples, or package-first developer workflow
+     - game: game engine files, playable prototypes, store assets, or game-specific README/spec language
+     - generic: no strong domain signal
+   - Read `README.md`, `AGENTS.md`, `CLAUDE.md`, relevant `docs/`, `specs/`, `spec.md`, and `tasks/` files when present.
+
+2. **Load journey and story evidence**
+   - Business app: read `research/icp.md`, `research/journey-map.md`, `research/customer-feedback.md`, `research/metrics.md`, and `research/mvp-gap.md` when present.
+   - Devtool: read `research/devtool-user-map.md`, `research/devtool-dx-journey.md`, `research/devtool-integration-map.md`, `research/devtool-adoption.md`, docs, examples, and package manifests when present.
+   - Game: read `research/game-core-loop.md`, `research/game-prototype-test.md`, `research/game-playtest-metrics.md`, `research/game-audience.md`, `research/game-fantasy.md`, and `research/game-comparables.md` when present.
+   - Generic: use specs, README, routes, tests, examples, and task acceptance criteria.
+   - In product-path workspaces with `research/{slug}/` or `specs/{slug}/`, produce product-path-scoped scenarios for the requested app. If no app is specified and multiple apps are plausible, ask the user to choose.
+
+3. **Identify active-use cadence**
+   - Infer how often the app owner or operator should use the product in their own workflow: first session, daily, weekly, per incident, per project, per release, monthly review, or another cadence supported by the docs.
+   - If cadence is unclear, recommend a default and state the assumption in the audit.
+   - Prefer scenarios that exercise owner/operator adoption, repeated use, and product understanding over isolated feature checks.
+
+4. **Create owner/operator scenarios**
+   - Generate 3-7 scenarios unless the user requested a narrower focus.
+   - Cover at least one happy path, one recovery/failure path, and one return-use or retention path when the product evidence supports them.
+   - Each scenario must include:
+     - owner/operator role
+     - active cadence
+     - trigger
+     - setup and preconditions
+     - exact task for the operator to perform in their own workflow
+     - expected success state
+     - acceptance checks
+     - evidence to capture
+     - friction or failure signals
+     - follow-up routing
+   - Use concrete product language from specs and journeys. Avoid vague instructions such as "verify the flow works."
+   - If the scenario is primarily about whether a target user would accept the product, route it to `/uat` instead.
+
+5. **Classify follow-up work**
+   - Operator-run dogfood scenarios go in `tasks/manual-todo.md` under `## Dogfood Operator Scenarios`.
+   - Use `_(after: research/dogfood-audit.md)_` unless the scenario blocks or follows a known roadmap step. If tied to a known step, use `_(blocks: Step N.X)_` or `_(after: Step N.X)_`.
+   - Do not put operator scenarios in `tasks/todo.md`.
+   - Agent-executable implementation fixes discovered after a human run belong in `tasks/todo.md`, but do not invent fixes before the operator has attempted the scenario.
+   - Cadence-based dogfood obligations, such as weekly dogfood or pre-release dogfood, go in `tasks/recurring-todo.md` with cadence, owner/agent, next due, evidence path, and escalation conditions.
+   - If a scenario needs click-by-click help for a human-only external blocker, recommend `/guide` (guided-walkthrough pack).
+
+6. **Present findings before writing when risk is high**
+   - If source material is thin, contradictory, or missing the target user journey, summarize the gap and ask whether to proceed with assumptions.
+   - If source material is sufficient, write the audit and task sections directly.
+
+## Deliverables
+
+- `research/dogfood-audit.md` - scenario matrix, source evidence, owner/operator adoption instructions, evaluation checklist, findings template, and next steps.
+- `tasks/manual-todo.md` - append or replace only the `## Dogfood Operator Scenarios` section.
+- `tasks/recurring-todo.md` - optional, only when a recurring dogfood cadence is useful and not already tracked.
+
+If `tasks/manual-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 dogfood section. Preserve all non-dogfood sections when updating an existing file.
+
+Use this scenario format in `research/dogfood-audit.md`:
+
+```markdown
+### Scenario N: [Name]
+
+- Owner/operator role: [role]
+- Active cadence: [first session/daily/weekly/per incident/per release/etc.]
+- Trigger: [why the user opens the product]
+- Setup: [accounts, data, environment, permissions, or sample state needed]
+- Task: [specific action sequence in the operator's own workflow]
+- Expected success state: [observable result]
+- Acceptance checks:
+  - [ ] [specific check]
+- Evidence to capture: [screenshots, command output, notes, timestamps, records]
+- Friction/failure signals: [what counts as confusion, delay, breakage, or mismatch]
+- Follow-up routing: [manual note, /uat, /customer-discovery (business-discovery pack), /journey-map (customer-lifecycle pack), /guide (guided-walkthrough pack), or task promotion guidance]
+
+#### Operator result log
+
+- Status: Not run | Pass | Fail | Blocked
+- Evidence captured:
+- Notes:
+- Follow-up tasks promoted:
+```
+
+Use this item format in `tasks/manual-todo.md`:
+
+```markdown
+## Dogfood Operator Scenarios
+
+- [ ] Perform dogfood scenario: [Scenario name] for [owner/operator role] ([cadence]) _(after: research/dogfood-audit.md)_ - capture evidence in `research/dogfood-audit.md`.
+```
+
+## Task Classification
+
+- Human/operator scenario execution goes in `tasks/manual-todo.md`.
+- Immediate implementation or documentation fixes confirmed by a completed dogfood run go in `tasks/todo.md`.
+- One-time condition-gated evidence collection goes in `tasks/record-todo.md`.
+- Cadence-based dogfood checks go in `tasks/recurring-todo.md`.
+- Do not put non-blocking records or recurring obligations in `tasks/todo.md` unless they have been explicitly promoted into current execution work.
+
+## Constraints
+
+- Do not run or operate the product in this skill.
+- Do not start dev servers, launch browsers, use Playwright, call APIs, create accounts, or perform CLI workflows.
+- Do not mark scenarios complete; only the human operator can do that after performing them.
+- Do not duplicate existing unchecked dogfood/manual tasks. Reference existing items when they already cover the same scenario.
+- Prefer evidence-backed owner/operator adoption scenarios over exhaustive coverage.
+- Keep dogfood and UAT separate: use `/dogfood` for owner/operator adoption into the builder's workflow; use `/uat` for target-user acceptance journeys.
+- If no credible user journey, story, spec, or product surface can be found, stop and recommend `/customer-discovery` (business-discovery pack), `/journey-map` (customer-lifecycle pack), 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/project.json` `enabled_packs`, recommend `/pack install <pack>` before the skill.
+- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, prepend `/pack install <pack-name>` to the recommendation.
+
+## Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/dogfood-{topic}.html`.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/product-testing/claude/uat/ALIGNMENT-PAGE.md

@@ -9,6 +9,8 @@ When this skill produces durable deliverables (research, specs, plans, reports,
 
 The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected by the upgrade script). The bundled ALIGNMENT-PAGE.md receives tier-appropriate rendering guidance from the generator.
 
+**Context intake.** This skill declares `context_intake: artifact_only` (Artifact-driven). Work from concrete artifacts, data, logs, or existing instructions by default; ask concise clarification questions only when the available artifacts are missing, contradictory, or unsafe to interpret.
+
 **Alignment lifecycle.** Alignment pages have three lifecycle states. `review` is the draft/pre-approval page: it contains the complete deliverable preview, evidence, required inline gate questions, section feedback controls, local section-feedback YAML only after a section feedback choice is selected, and one bottom `Compile Responses` control. `confirmed` is the post-approval page after the agent has consumed final compiled response YAML, made any approved user-requested edits, and written or updated the approved canonical artifacts. A confirmed page is finished and current for the completed alignment cycle, but it remains amendable when later research changes or extends the conclusions. `amended` is a future revision of a confirmed page: archive the previous confirmed page first, mark what changed, preserve the prior approval record, and highlight the new evidence, decisions, or scope that changed the earlier conclusion.
 
 **Central alignment index.** When a research-producing skill writes or updates an HTML alignment page, also maintain the repository's central alignment index. Look for `alignment/index.html` at the repository root; if the target repo documents a different central alignment-index path, use that path and report it. If the index does not exist, create it as a self-contained HTML page that works from `file://`, links to every active `alignment/*.html` page except itself, and includes the newly written page. Every index entry must include the page's alignment date in a muted meta span after the link, formatted `YYYY-MM-DD`, for example `<a href="page.html">Title</a> <span class="meta">2026-06-09</span>`. The alignment date is the review or confirmed date written inside the page itself; new pages use today's date. If the index exists, update it instead of blindly appending: preserve valid existing entries, metadata, and entry dates; remove duplicate entries for the same page path; keep links repo-relative; and include the new or updated page. When updating an existing index, add a date only to entries that are missing one, deriving it from the page's internal alignment date, or from file history when the page has no internal date. If a `new` marker is used, combine it with the date as `<span class="meta">new · YYYY-MM-DD</span>`, and remove stale `new` markers from entries that are no longer the latest addition.
@@ -57,7 +59,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-uat-research.md`; product-path mode uses `research/{slug}/_working/preliminary-uat-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-uat-research.md`; product-path mode uses `research/{slug}/_working/preliminary-uat-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **UAT-specific gates.** Render journey coverage, participant or evaluator assumptions, acceptance verdicts, evidence gaps, output-location/change-scope decisions, and post-approval route as gates. Apply the shared artifact-destination/proposed-file-changes de-duplication rule: combine them into one visual gate when they ask only the same path-destination question, and render separate gates when destination approval differs from downstream mutation scope, timing, or allowed files.
 

package/packs/product-testing/claude/uat/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.11 - 2026-06-12
+
+- Standardized active pack and skill install guidance on `npx skillpacks install <pack-or-skill>` instead of agent-native `/pack install` or `$pack install` recommendations.
+
 ## v0.10 - 2026-06-10
 
 - Converted the hand-authored alignment-page section to the generator-owned stub plus a bundled `ALIGNMENT-PAGE.md`; the page contract now follows the full shared convention (lifecycle states, central alignment index, section feedback, gate/feedback YAML, TTS, browser open) with the uat-specific gates from the generator gate map.

package/packs/product-testing/claude/uat/SKILL.md

@@ -2,14 +2,14 @@
 name: uat
 description: Create user acceptance test journeys from a target user's perspective, with role-based scenarios, acceptance criteria, and evidence capture
 type: analysis
-version: v0.10
+version: v0.11
 argument-hint: "[--variant-evaluation] [optional: persona, feature, release, journey, app, or variation spec]"
-interview_depth: none
+context_intake: artifact_only
 ---
 
 ## Pack Availability Guard
 
-Before telling the user to run a skill from another project-local pack, check `.agents/project.json.enabled_packs`. If the target pack is not enabled, recommend `/pack install <pack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.
+Before telling the user to run a skill from another project-local pack, check `.agents/project.json.enabled_packs`. If the target pack is not enabled, recommend `npx skillpacks install <pack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.
 
 # UAT
 
@@ -70,7 +70,7 @@ When product path `{slug}` is active, read and write research under `research/{s
    - Identify 1-3 target user personas or roles from the evidence.
    - For each selected persona, define the job-to-be-done, context, goal, constraints, and acceptance threshold.
    - Prefer external target users, buyers, evaluators, administrators, developers, or players over the product owner unless the owner is also the target user.
-   - If the target user is unclear, stop and recommend `/customer-discovery` (business-discovery pack), `/journey-map` (customer-lifecycle pack), 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/project.json` `enabled_packs`, recommend `/pack install <pack>` before the skill.
+   - If the target user is unclear, stop and recommend `/customer-discovery` (business-discovery pack), `/journey-map` (customer-lifecycle pack), 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/project.json` `enabled_packs`, recommend `npx skillpacks install <pack>` before the skill.
 
 4. **Create UAT journeys**
    - Generate 3-7 journeys unless the user requested a narrower focus.
@@ -212,7 +212,7 @@ Use this item format in `tasks/manual-todo.md`:
 - Prefer evidence-backed target-user journeys over exhaustive feature coverage.
 - Keep dogfood and UAT separate: use `/dogfood` for owner/operator adoption into the builder's workflow; use `/uat` for target-user acceptance journeys.
 - If no credible user journey, story, spec, or product surface can be found, stop and recommend `/customer-discovery` (business-discovery pack), `/journey-map` (customer-lifecycle pack), or the relevant pack research skill. Apply the Pack Availability Guard for pack-based skills.
-- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, prepend `/pack install <pack-name>` to the recommendation.
+- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, prepend `npx skillpacks install <pack-name>` to the recommendation.
 
 ## Alignment Page