skillpacks 0.1.1 → 0.1.2

package/packs/product-design/claude/prototype/archive/v0.13/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: prototype
+description: Build tangible, runnable prototypes from UX variation and UI specs — static HTML/CSS for UI projects, runnable scripts for CLI, endpoint stubs for API, or minimal configs for infra
+type: execution
+version: v0.13
+argument-hint: "[optional: topic, --variant N]"
+visual_tier: prototype
+---
+
+# Prototype
+
+Invoke as `/prototype`.
+
+Build tangible, runnable prototypes before production spec work begins. Create the first concrete artifact users can interact with, grounded in research and UX variation planning. Prototypes are cheap, disposable, and designed for evaluation — not production readiness. The goal is to give humans something to click, run, or curl so they can form opinions before committing to a direction.
+
+## Gate
+
+Before proceeding, verify the following files exist:
+
+- At least one `specs/ux-variations-*.md` file.
+- At least one `specs/ui-*.md` file (e.g., `specs/ui-[topic].md`, `specs/ui-layout-variations-[topic].md`, or `specs/ui-requirements-[topic].md`).
+
+Also read `specs/user-flow-*.md` when present as an upstream screen-ordering and task-sequencing signal. It is preferred evidence, not a hard prerequisite for this gate.
+
+If either is missing, halt with a clear message:
+
+> Prototyping requires UX variation planning and UI specification. Missing prerequisites:
+> - `specs/ux-variations-*.md` — run `/ux-variations` to create variation concepts.
+> - `specs/ui-*.md` — run `/ui-interview` to define the interface specification.
+
+Do not proceed past this gate until both prerequisites exist.
+
+## 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. Extract `project_type` for dispatch decisions.
+- Read research documents when present:
+  - `research/idea-brief.md` — assumptions to test, core value proposition, and hypothesis framing.
+  - `research/icp.md` — ideal customer profile; informs copy density, terminology, and information hierarchy.
+  - `research/competitive-analysis.md` — differentiation points the prototype should highlight.
+  - `research/journey-map.md` — screen flow ordering, entry points, and task sequencing.
+- Read variation specs: `specs/ux-variations-[topic].md` for each relevant topic.
+- Read user-flow specs: `specs/user-flow-[topic].md` for screen ordering, entry points, branches, decision points, required states, failure/recovery paths, handoffs, and low-fidelity wireframe notes when present.
+- Read per-variation UI specs: `specs/ui-[topic].md`, `specs/ui-layout-variations-[topic].md`, and `specs/ui-requirements-[topic].md` when present.
+- If an argument is provided, use it as the topic filter. Otherwise, identify the topic from available specs.
+
+### 2. Research integration
+
+Before building, extract actionable signals from research:
+
+- **ICP** (`research/icp.md`): Determine copy density (expert vs. novice), terminology choices, information hierarchy, and default density (compact vs. spacious). The prototype should feel like it was built for the target user, not a generic audience.
+- **Journey map** (`research/journey-map.md`): Derive screen flow ordering. The prototype's navigation and page sequence should follow the user's natural task progression, not an arbitrary menu order.
+- **User-flow map** (`specs/user-flow-[topic].md`): Derive concrete screen order, route inventory, branches, required states, failure/recovery behavior, and low-fidelity wireframe structure. The prototype should preserve the approved task sequence unless a variation spec explicitly changes it.
+- **Competitive analysis** (`research/competitive-analysis.md`): Identify differentiation points the prototype must highlight. If the product's thesis is "faster than X" or "simpler than Y," the prototype should make that advantage viscerally obvious.
+- **Idea brief** (`research/idea-brief.md`): Surface assumptions the prototype is designed to test. Each prototype variation should help validate or invalidate at least one idea-brief assumption.
+
+Document which research signals influenced which prototype decisions in a brief `## Research Integration` section at the top of the hub page.
+
+### 3. Project type dispatch
+
+Determine the project type from `.agents/project.json` `project_type` field. If the field is absent, infer from repository signals (package.json scripts, Dockerfile presence, CLI entry points, route files, etc.). Dispatch to one of the following modes:
+
+#### UI mode (business-app, or default when no project_type)
+
+Build static HTML/CSS prototypes for each variation:
+
+- One self-contained HTML file per variation at `prototypes/{topic}/variation-{N}/index.html`.
+- Inline CSS and minimal inline JS (no build tools, no bundler, no framework dependencies).
+- Fake but realistic data — use plausible names, dates, amounts, and content that matches the ICP.
+- Clickable navigation between pages/views within the variation. Use anchor links, hash routing, or multiple HTML files as appropriate.
+- Responsive layout when the UI spec defines responsive behavior.
+- Visual states: show default, empty, loading (static representation), and error states where the spec defines them.
+- Do not use CDN-hosted frameworks or libraries. The prototype must work offline from a file:// URL.
+- Include a brief `<!-- Variation N: [Name] — [Thesis] -->` comment at the top of each HTML file.
+
+#### CLI mode (devtool with CLI focus)
+
+Build runnable script prototypes for each variation:
+
+- One executable script per variation at `prototypes/{topic}/variation-{N}/demo.sh` (or `.py`, `.js`, etc., matching the project's primary language).
+- Include fixture data files alongside the script.
+- Demonstrate one core workflow end-to-end: the user runs a single command (or short sequence) and sees realistic output.
+- Include inline comments explaining which variation thesis this demonstrates.
+- Scripts must be runnable with standard tooling (bash, node, python) without additional dependencies.
+
+#### API mode (devtool with API focus)
+
+Build endpoint stub prototypes for each variation:
+
+- One lightweight server or mock per variation at `prototypes/{topic}/variation-{N}/server.{ext}`.
+- Fixture JSON responses for each endpoint.
+- A `curl-examples.sh` file with annotated curl commands demonstrating the core workflow.
+- Include a brief README in each variation directory explaining the API design thesis.
+- Endpoints return fixture data; no database or persistence required.
+
+#### Infra mode
+
+Build minimal configuration prototypes for each variation:
+
+- One `docker-compose.yml` or equivalent config per variation at `prototypes/{topic}/variation-{N}/`.
+- Include `.env.example`, config files, and documentation sufficient to understand the infrastructure concept.
+- Do not require running services; use placeholder images or mock services where possible.
+- Include a brief README explaining the infrastructure thesis and what a user would observe if they ran it.
+
+### 4. Scope rule (non-UI modes)
+
+For CLI, API, and Infra modes, build exactly one core workflow demo with fixture data per variation. Do not attempt full API coverage, complete CLI help systems, or production-ready infrastructure. The prototype exists to make the variation thesis tangible, not to implement the product.
+
+### 5. Build each variation
+
+For each variation defined in `specs/ux-variations-[topic].md`:
+
+1. Read the variation's thesis, target user, layout/flow model, and prototype scope from the spec.
+2. Read the corresponding UI spec details from `specs/ui-[topic].md` or `specs/ui-layout-variations-[topic].md`.
+3. Build the prototype artifact in `prototypes/{topic}/variation-{N}/`.
+4. Name the directory using the variation number from the spec (1-indexed).
+5. Ensure the prototype is immediately usable: open the HTML file, run the script, curl the endpoint, or read the config.
+
+### 6. Build the hub page
+
+Create a hub page at `prototypes/{topic}/index.html` that:
+
+- Lists every variation with its name, thesis, and a direct link to the variation's entry point.
+- Includes the research integration summary (which research signals drove which decisions).
+- Provides brief instructions for evaluating each variation.
+- For UI mode: links open the variation's `index.html` in the same browser.
+- For CLI/API/Infra modes: the hub page is a simple HTML document with copy-pasteable commands to run each variation.
+- After writing or updating the hub page, attempt to open `prototypes/{topic}/index.html` in the browser and report whether the browser open succeeded or was blocked. A blocked browser open does not make the prototype fail when the files were written correctly.
+
+### 7. `--variant N` flag
+
+When the user provides `--variant N` (or says "rebuild variation N", "only variation N", etc.):
+
+- Build or rebuild only variation N, preserving all other existing variations and the hub page.
+- Update the hub page to reflect any changes to the rebuilt variation.
+- Do not delete or modify other variation directories.
+
+## Output
+
+The skill produces the following file structure:
+
+```
+prototypes/{topic}/
+  index.html                    # Hub page listing all variations
+  variation-1/
+    index.html (or demo.sh, server.js, docker-compose.yml)
+    [supporting files: fixtures, styles, curl-examples, README]
+  variation-2/
+    index.html (or demo.sh, server.js, docker-compose.yml)
+    [supporting files]
+  variation-N/
+    ...
+```
+
+## Next Step
+
+After prototypes are built, recommend:
+
+> Recommended next command: `/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)
+
+The user should interact with each prototype variation hands-on before consolidating. UAT variant evaluation provides a structured comparison framework to capture evidence for each variation's strengths, friction points, and rejection signals.
+
+## Constraints
+
+- Do not introduce build tools, bundlers, package managers, or framework dependencies into prototypes. Prototypes must be immediately usable without installation steps.
+- Do not connect to real databases, APIs, or external services. All data must be fixture/fake data.
+- Do not build production-quality code. Prototypes are disposable artifacts for evaluation, not starting points for implementation.
+- Do not skip variations. Build all variations defined in the spec unless `--variant N` is provided.
+- Do not choose a winning variation or recommend consolidation. That is the user's decision after UAT evaluation.
+- Do not modify specs, research documents, or task files. Only create files in the `prototypes/` directory.
+- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, recommend `npx skillpacks install <pack-name>` from the project shell, before the target skill.
+
+## 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/prototype-{topic}.html`.
+
+Prototype files may be created before the alignment page because the review needs runnable artifacts. After building or updating prototype files, build and attempt to open `alignment/prototype-{topic}.html` before downstream routing, UAT handoff, consolidation, spec updates, research updates, or task/roadmap changes.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/product-design/claude/spec-interview/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: deep` (Deep interview). Gather repo/project context before asking, present an assumptions manifest when the contract requires it, ask focused questions, and confirm coverage before building review artifacts.
+
 **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-spec-interview-research.md`; product-path mode uses `research/{slug}/_working/preliminary-spec-interview-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-spec-interview-research.md`; product-path mode uses `research/{slug}/_working/preliminary-spec-interview-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.
 
 **Spec-specific gates.** Render surfaced assumptions, scope/non-goals, candidate decisions, acceptance coverage, output-location/change-scope decisions, and post-approval route as gates before writing or replacing specs. 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-design/claude/spec-interview/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## v0.14 - 2026-06-13
+
+- Updated post-prototype spec interviews to consume `design/user-flow-*`, `design/ux-variations-*`, `design/ui-*`, and scoped flow-tree manifests as upstream design evidence.
+- Clarified that `spec-interview` keeps finalized production implementation specs in `specs/` and does not write pre-prototype design artifacts.
+
+## v0.13 - 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.12 - 2026-06-11
 
 - Added npm-aware install-route wording for pack, customer-lifecycle, and cross-pack recommendations while preserving Claude `/pack install ...` routes.

package/packs/product-design/claude/spec-interview/SKILL.md

@@ -2,14 +2,14 @@
 name: spec-interview
 description: Post-prototype production deep dive — walks through consolidated prototype screen by screen to extract production specifications
 type: planning
-version: v0.12
+version: v0.14
 argument-hint: "[optional-topic-override] [--ideas]"
-interview_depth: full
+context_intake: deep
 ---
 
 ## 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>` inside Claude Code, or `npx skillpacks install <pack>` from the project shell, 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>` from the project shell, 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.
 
 ## Prototype Gate
 
@@ -46,12 +46,12 @@ When product path `{slug}` is active, read and write research under `research/{s
    - For `business-app`, read `research/icp.md` when present and ground solution decisions against the ICP.
    - For `game`, read game research artifacts when present: `research/game-audience.md`, `research/game-fantasy.md`, `research/game-core-loop.md`.
    - For `devtool`, read devtool research artifacts when present: `research/devtool-user-map.md`, `research/devtool-dx-journey.md`, `research/devtool-integration-map.md`.
-   - If project type is missing or mismatched, recommend `/pack recommend`, `/pack install <pack>` inside Claude Code, or `npx skillpacks install <pack>` from the project shell before doing domain-specific planning.
+   - If project type is missing or mismatched, recommend `/pack recommend`, `npx skillpacks install <pack>` from the project shell before doing domain-specific planning.
    - If `research/idea-brief.md`, `research/icp.md`, or `research/journey-map.md` exists in a business-app project, treat them as source evidence: does this implementation fit the concept constraints, user and customer journey, path to aha, conversion path, retention loop, champion dynamics, technical sophistication, and provisioning/onboarding model?
-   - If lifecycle evidence is missing and the `customer-lifecycle` pack is not enabled, recommend `/pack install customer-lifecycle` inside Claude Code, or `npx skillpacks install customer-lifecycle` from the project shell, before `/journey-map`.
+   - If lifecycle evidence is missing and the `customer-lifecycle` pack is not enabled, recommend `npx skillpacks install customer-lifecycle` from the project shell, before `/journey-map`.
    - When the user proposes something that conflicts with the ICP or journey map, flag it — e.g., "The journey map says the buyer needs a demo before sign-up — does this self-serve-only onboarding fit?"
    - Do not re-interview on concept, ICP, or journey topics already covered — focus on technical solution design.
-   - Read `specs/user-flow-*.md` when present as upstream evidence for screen order, route inventory, branch decisions, state coverage, failure/recovery paths, handoffs, and low-fidelity wireframe intent.
+   - Read `design/user-flow-*.md`, `design/ux-variations-*.md`, `design/ui-*.md`, and `design/**/flow-tree-*.yaml` when present as upstream pre-prototype design evidence for screen order, route inventory, branch decisions, state coverage, failure/recovery paths, handoffs, selected UX variation branches, UI approval state, and low-fidelity wireframe intent.
 
 2. **Surface a prototype-grounded assumptions checkpoint before probing:**
    - After reading the consolidated prototype and research context but **before** asking deep probing questions, present a concise **Assumptions Checkpoint** grounded in what the prototype reveals.
@@ -95,6 +95,7 @@ When product path `{slug}` is active, read and write research under `research/{s
 
 6. **Write outputs:**
    - Write the completed specification to `specs/[topic].md` (create the `specs/` directory if it doesn't exist) where `topic` is a short kebab-case summary.
+   - Keep `specs/` as the canonical output directory for finalized post-prototype implementation specifications. Do not write pre-prototype flow maps, UX variation plans, UI branch packets, or flow-tree manifests from this skill; those remain design-phase artifacts under `design/`.
    - The spec must use these canonical section headings (unnumbered):
      - `## Overview`
      - `## Goals`
@@ -126,7 +127,7 @@ When this skill produces durable deliverables (research, specs, plans, reports,
 - One to three focused questions per turn, not more.
 - Do not re-interview on ICP topics already covered in `research/icp.md`.
 - Do not conclude the interview without explicit user confirmation that all areas are addressed.
-- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, recommend `/pack install <pack-name>` inside Claude Code, or `npx skillpacks install <pack-name>` from the project shell, before the target skill.
+- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, recommend `npx skillpacks install <pack-name>` from the project shell, before the target skill.
 
 ## Ideas Mode (`--ideas`)
 

package/packs/product-design/claude/spec-interview/archive/v0.12/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: spec-interview
+description: Post-prototype production deep dive — walks through consolidated prototype screen by screen to extract production specifications
+type: planning
+version: v0.12
+argument-hint: "[optional-topic-override] [--ideas]"
+interview_depth: full
+---
+
+## 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>` inside Claude Code, or `npx skillpacks install <pack>` from the project shell, 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.
+
+## Prototype Gate
+
+Before starting the interview process, verify:
+
+1. A consolidated prototype exists at `prototypes/{topic}/consolidated/`. If missing, halt and recommend `/consolidate-variations` first.
+2. All research tasks from the `--post-prototype` pass are completed — check `tasks/todo.md` for unchecked items under `## Priority Documentation Todo` that reference post-prototype research. If unchecked post-prototype items remain, halt and recommend completing those first.
+
+If both gates pass, proceed with the interview.
+
+# Spec Interview
+
+Interview the user to validate, refine, and complete an implementation specification from a consolidated prototype and research context. For half-formed product ideas, run `/idea-scope-brief` before this skill.
+
+## 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. **Read consolidated prototype and research context:**
+   - Read the consolidated prototype directory at `prototypes/{topic}/consolidated/` as the primary input. Walk through every screen, component, and interaction in the prototype to understand the current state.
+   - If `.agents/project.json` exists, read `project_type` and `enabled_packs` before choosing a research frame.
+   - For `business-app`, read `research/icp.md` when present and ground solution decisions against the ICP.
+   - For `game`, read game research artifacts when present: `research/game-audience.md`, `research/game-fantasy.md`, `research/game-core-loop.md`.
+   - For `devtool`, read devtool research artifacts when present: `research/devtool-user-map.md`, `research/devtool-dx-journey.md`, `research/devtool-integration-map.md`.
+   - If project type is missing or mismatched, recommend `/pack recommend`, `/pack install <pack>` inside Claude Code, or `npx skillpacks install <pack>` from the project shell before doing domain-specific planning.
+   - If `research/idea-brief.md`, `research/icp.md`, or `research/journey-map.md` exists in a business-app project, treat them as source evidence: does this implementation fit the concept constraints, user and customer journey, path to aha, conversion path, retention loop, champion dynamics, technical sophistication, and provisioning/onboarding model?
+   - If lifecycle evidence is missing and the `customer-lifecycle` pack is not enabled, recommend `/pack install customer-lifecycle` inside Claude Code, or `npx skillpacks install customer-lifecycle` from the project shell, before `/journey-map`.
+   - When the user proposes something that conflicts with the ICP or journey map, flag it — e.g., "The journey map says the buyer needs a demo before sign-up — does this self-serve-only onboarding fit?"
+   - Do not re-interview on concept, ICP, or journey topics already covered — focus on technical solution design.
+   - Read `specs/user-flow-*.md` when present as upstream evidence for screen order, route inventory, branch decisions, state coverage, failure/recovery paths, handoffs, and low-fidelity wireframe intent.
+
+2. **Surface a prototype-grounded assumptions checkpoint before probing:**
+   - After reading the consolidated prototype and research context but **before** asking deep probing questions, present a concise **Assumptions Checkpoint** grounded in what the prototype reveals.
+   - Tag each assumption with its source:
+     - `[from spec]` — explicitly stated in the draft or spec document
+     - `[from codebase]` — derived from reading existing code, config, or infrastructure
+     - `[from research]` — derived from research docs (ICP, audience, journey maps)
+     - `[from prototype]` — derived from the consolidated prototype
+     - `[inferred]` — not stated anywhere; you filled in a default or made a judgment call
+   - Keep the checkpoint short enough to preserve interview momentum: normally 3 to 7 bullets, grouped only when useful. Do not dump a comprehensive manifest unless the user explicitly asks to review assumptions first.
+   - Bias the checkpoint toward assumptions that are uncertain, risky, contradicted by evidence, or likely to change data/API/architecture choices. Omit obvious restatements that can be captured later in the spec.
+   - Focus the checkpoint on what the prototype assumes vs what production needs:
+     - What the prototype assumes about **data model** — what's fake/fixture vs what needs real persistence
+     - What the prototype assumes about **auth** — none? mock? real?
+     - What **fake data needs to become real** — hardcoded lists, mock APIs, placeholder content
+     - What **missing infrastructure** is needed — database, auth, payments, analytics, deployment
+     - What **error/empty states** the prototype skips vs what production needs
+   - Deliver the checkpoint inline as the final message text of its own turn — never only as mid-turn text in a turn that ends with a tool call. In the next turn, use AskUserQuestion to ask the user to confirm or correct it and include the first 1 to 3 focused interview questions so momentum is kept. Option previews may mirror the checkpoint as a supplement but are never the sole channel. Do not stop at the assumptions checkpoint unless the user explicitly asks to pause and review assumptions first.
+   - If any `[inferred]` assumption is corrected, note the correction — these corrections are high-signal for downstream risk and must appear in the interview log.
+
+3. **Screen-by-screen prototype walkthrough:**
+   - Walk through each screen/page in the consolidated prototype. For each screen, use AskUserQuestion to probe:
+     - **Data model?** What entities, relationships, persistence does this screen need?
+     - **API calls?** What endpoints, payloads, error responses?
+     - **Auth?** What permissions, roles, access control apply to this screen?
+     - **Empty/error states?** What happens when data is missing, requests fail, or the user has no content yet?
+     - **Performance?** Loading states, pagination, caching needs?
+     - **Analytics?** What events should be tracked on this screen?
+   - Ask one to three focused questions per turn.
+   - **Research and recommend by default.** For each decision point, use web search, upstream research docs (`research/*.md`), and codebase analysis to gather evidence before asking the user. Present your findings with data, state your recommendation with reasoning, and ask the user to approve, adjust, or override. When a decision point genuinely has multiple viable approaches, list each option with a clear rationale, pros/cons, and your recommendation with reasoning. For the recommended option, explain how the con can be mitigated if feasible. Only ask the user to choose without a recommendation when the decision genuinely requires insider knowledge (internal constraints, personal preferences, strategic bets). Do not manufacture choices.
+
+4. **Iterative prototype updates:**
+   - When the interview reveals gaps in the prototype (missing screens, unclear flows, absent states), use AskUserQuestion: "Should I update the prototype to add [gap]? This may warrant re-running upstream steps."
+   - If the consolidated prototype exposes missing or unclear screen flow, branch coverage, state coverage, failure/recovery behavior, or handoff structure, recommend `/user-flow-map [topic]` as the upstream remediation before continuing production-spec work.
+   - The user decides per-update whether to update the prototype now or note it for production implementation only.
+   - If the user approves a prototype update, make the change and note it in the interview log before continuing.
+
+5. **Cover all areas:**
+   - Continue until you have thoroughly covered: implementation goals, technical architecture, data models, APIs/contracts, migrations, edge cases, security, performance, observability, test strategy, and scope boundaries.
+   - **Coverage checkpoint** — Before concluding, present a structured summary inline as the final message text of its own turn: list each area covered with the key decisions made and the evidence or reasoning that supported each decision. In the next turn, use AskUserQuestion to ask: "Does this cover everything? Any areas we should revisit or that I missed?"
+
+6. **Write outputs:**
+   - Write the completed specification to `specs/[topic].md` (create the `specs/` directory if it doesn't exist) where `topic` is a short kebab-case summary.
+   - The spec must use these canonical section headings (unnumbered):
+     - `## Overview`
+     - `## Goals`
+     - `## Non-Goals`
+     - `## Detailed Design` (architecture, data models, APIs, UI flows)
+     - `## Edge Cases`
+     - `## Test Plan`
+     - `## Acceptance Criteria`
+     - `## Open Questions`
+     - `## Assumptions & Risks` (the checkpoint output)
+     Additional topic-specific sections (e.g. `## Data Model`, `## Security`) may appear between Detailed Design and Edge Cases. Do not number sections.
+   - Append an **Assumptions & Risks** section to the end of the spec listing: each checkpoint assumption that was confirmed, corrected, or left unresolved during the interview, its source tag, and the downstream risk if the assumption turns out to be wrong later. Flag any `[inferred]` assumptions that were never explicitly confirmed by the user.
+   - Create an interview log file named `[topic]-interview.md` recording each turn of the interview including questions asked, options presented with pros/cons, and user selections. The log must include the Assumptions Checkpoint as presented, user corrections, and a summary of significant deviations from the original spec.
+
+## Output
+
+Two files written:
+
+- `specs/[topic].md` — the completed specification
+- `[topic]-interview.md` — full interview log with deviation summary
+
+### 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/spec-interview-{topic}.html`.
+
+## Constraints
+
+- Use AskUserQuestion for all interview turns — do not assume answers.
+- One to three focused questions per turn, not more.
+- Do not re-interview on ICP topics already covered in `research/icp.md`.
+- Do not conclude the interview without explicit user confirmation that all areas are addressed.
+- When recommending a skill from another pack, verify the pack is installed via `.agents/project.json` `enabled_packs`. If not installed, recommend `/pack install <pack-name>` inside Claude Code, or `npx skillpacks install <pack-name>` from the project shell, before the target skill.
+
+## Ideas Mode (`--ideas`)
+
+When `$ARGUMENTS` contains `--ideas`, read `tasks/ideas.md` and run the interview process for each idea sequentially.
+
+### Process
+
+1. Read `tasks/ideas.md` and extract every distinct idea entry. If `$ARGUMENTS` includes a filter keyword (beyond `--ideas`), limit to matching ideas.
+2. Show the user the list and ask them to confirm, skip any, or reorder.
+3. For each idea, run the standard interview process using the idea's title and description as the initial implementation draft. If an idea is still only a raw concept, route it to `/idea-scope-brief` first.
+4. Write deliverables (`specs/[topic].md` and `[topic]-interview.md`) for each completed idea.
+5. After each idea, summarize decisions and move to the next. The user may say "skip" to move on.
+
+If the user stops partway through, write deliverables for completed ideas and note which remain.
+
+## 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.
+- Keep any existing user approval requirement before overwriting or replacing a document; archiving does not replace asking when the skill already requires approval.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.