skillpacks 0.1.1 → 0.1.2

package/packs/teardown/claude/decommission/ALIGNMENT-PAGE.md

@@ -57,7 +57,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-decommission-research.md`; product-path mode uses `research/{slug}/_working/preliminary-decommission-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-decommission-research.md`; product-path mode uses `research/{slug}/_working/preliminary-decommission-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.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/teardown/claude/desk-flip/ALIGNMENT-PAGE.md

@@ -57,7 +57,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-desk-flip-research.md`; product-path mode uses `research/{slug}/_working/preliminary-desk-flip-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-desk-flip-research.md`; product-path mode uses `research/{slug}/_working/preliminary-desk-flip-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.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/teardown/claude/desk-flip/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## v0.5 - 2026-06-12
+
+- Updated fresh-start product routing to use the AFPS prototype flow tree: `/user-flow-map` -> `/ux-variations [specific-user-flow]` -> `/ui-interview [specific-ux-variation]`, with requirements-only/layout-mode as explicit bounded detours.
+
+## 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 post-bootstrap fresh-start guidance from retired `/icp` to `/customer-discovery`.

package/packs/teardown/claude/desk-flip/SKILL.md

@@ -2,7 +2,7 @@
 name: desk-flip
 description: Autopsy a stuck project, extract salvageable artifacts, and route to a fresh start via /bootstrap-repo reset or new-repo bootstrap
 type: execution
-version: v0.3
+version: v0.5
 argument-hint: "<project-path>"
 ---
 
@@ -65,8 +65,8 @@ Always desk-flip. If the user invoked it, the decision to restart is already mad
    - Show the user a terminal summary of the report.
    - Recommend the appropriate `/bootstrap-repo` (repo-maintenance pack) command with the recommended bootstrap input from the report.
    - Do NOT create the new repo or run `/bootstrap-repo` — the user does this.
-   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `/customer-discovery` to define who this is for, `/competitive-analysis` to map the market, `/journey-map` to map lifecycle and task flow, `/positioning` to lock the product direction, `/user-flow-map` to map screen flow, `/ui-interview --requirements-only` to define content/actions/states, `/ux-variations --layout-mode` to explore layouts, then prototype work, `/uat --variant-evaluation`, and `/consolidate-variations` before `/spec-interview` or `/roadmap`.
-   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `/pack install business-discovery` and `/pack install customer-lifecycle` before the research sequence.
+   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `/customer-discovery` to define who this is for, `/competitive-analysis` to map the market, `/journey-map` to map lifecycle and task flow, `/positioning` to lock the product direction, `/user-flow-map` to map screen flow, `/ux-variations [specific-user-flow]` to explore progression branches, `/ui-interview [specific-ux-variation]` to render and approve/reject a branch mockup, then prototype work, `/uat --variant-evaluation`, and `/consolidate-variations` before `/spec-interview` or `/roadmap`. Use `/ui-interview --requirements-only` and `/ux-variations --layout-mode` only when the user explicitly needs a fixed content contract and layout-only alternatives.
+   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `npx skillpacks install business-discovery` and `npx skillpacks install customer-lifecycle` before the research sequence.
 
 ## Output
 
@@ -89,7 +89,7 @@ Desk-flipped: <project name>
 - Do not commit or push (the report is informational, not a meaningful mutation to ship).
 - Do not delete, archive, or rename anything in the old repo during desk-flip. Only the downstream `/bootstrap-repo --reset-existing` step may perform archival after the user chooses that route.
 - If the project has no specs, docs, or meaningful git history, produce the report anyway but note the thin evidence in each section.
-- 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
@@ -100,4 +100,4 @@ When this skill produces durable deliverables (research, specs, plans, reports,
 
 - Do NOT commit or push. The only side effect is `desk-flip-report.md` written to the project root.
 - **Default next-step routing:** when reporting completion, include the two-line pair `**Next work:** <specific task>` and `**Recommended next command:** /bootstrap-repo (repo-maintenance pack) --reset-existing <brief>` for in-place restarts, or `/bootstrap-repo` (repo-maintenance pack) `<brief>` only when a separate new repo is explicitly the right path.
-- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `/customer-discovery`, then `/competitive-analysis`, `/journey-map`, `/positioning`, `/user-flow-map`, `/ui-interview --requirements-only`, `/ux-variations --layout-mode`, and prototype work. Mention `/pack install business-discovery`, `/pack install customer-lifecycle`, or `/pack install product-design` first if those packs are not enabled.
+- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `/customer-discovery`, then `/competitive-analysis`, `/journey-map`, `/positioning`, `/user-flow-map`, `/ux-variations [specific-user-flow]`, `/ui-interview [specific-ux-variation]`, and prototype work. Mention `npx skillpacks install business-discovery`, `npx skillpacks install customer-lifecycle`, or `npx skillpacks install product-design` first if those packs are not enabled.

package/packs/teardown/claude/desk-flip/archive/v0.3/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: desk-flip
+description: Autopsy a stuck project, extract salvageable artifacts, and route to a fresh start via /bootstrap-repo reset or new-repo bootstrap
+type: execution
+version: v0.3
+argument-hint: "<project-path>"
+---
+
+# Desk Flip
+
+Autopsy a stuck project, extract salvageable artifacts (lessons, valid specs, non-code assets), and route the user to a fresh start either in a new repo or by resetting the existing repo with `/bootstrap-repo` (repo-maintenance pack) `--reset-existing`.
+
+Always desk-flip. If the user invoked it, the decision to restart is already made — do not offer incremental migration or attempt to fix the old project in place.
+
+## Process
+
+1. **Identify the stuck project.**
+   - Accept an optional project path from `$ARGUMENTS`; default to the current working directory.
+   - Verify the target is a git repo with existing code (not an empty repo).
+   - If the project appears to already use the new workflow (file-backed specs, prototype-first artifacts, healthy structure), warn the user and confirm before proceeding.
+
+2. **Survey the project.**
+   - Read `CLAUDE.md`, `README.md`, `package.json` or equivalent manifest, and directory structure.
+   - Read `tasks/`, `specs/`, `docs/` directories if they exist.
+   - Scan recent git history (last ~50 commits) for commit patterns and timeline.
+   - Read any existing `tasks/lessons.md` or post-mortem docs.
+
+3. **Run the autopsy** using subagents in parallel:
+   - **Lessons extraction:** What went wrong? Look for evidence of failure modes — infrastructure before prototype, late testing, chat-driven alignment drift, scope creep, untestable architecture. Cite specific commits, files, or timeline evidence.
+   - **Spec/design extraction:** Identify specs, designs, research docs, interview logs, and product briefs that capture valid domain knowledge or user needs — regardless of whether the implementation matched. Mark each as `valid`, `partially valid`, or `stale` with a one-line rationale.
+   - **Asset inventory:** Find non-code assets worth preserving — icons, images, copy, API contracts, design tokens, brand assets, research documents.
+
+   Do NOT extract code, dependencies, database schemas, or infrastructure config.
+
+4. **Write the autopsy report.**
+   - Produce `desk-flip-report.md` in the project root with these sections:
+
+   ```
+   ## Project Summary
+   What the project was and what state it's in now.
+
+   ## What Went Wrong
+   Specific failure modes with evidence (commits, files, timeline).
+
+   ## Salvageable Specs & Designs
+   List with file paths, validity status, and one-line descriptions.
+
+   ## Salvageable Assets
+   Non-code assets with file paths.
+
+   ## Lessons for the Fresh Start
+   Actionable guidance for the new project to avoid the same mistakes.
+
+   ## Recommended Bootstrap Input
+   A condensed brief suitable as input to /bootstrap-repo.
+   ```
+
+5. **Choose the fresh-start path.**
+   - If the user explicitly wants a new repository, route to `/bootstrap-repo` (repo-maintenance pack) `<condensed brief>`.
+   - If the user wants to keep the existing repository, or the current repo name, remotes, issues, deployment linkage, or local tooling are valuable, route to `/bootstrap-repo` (repo-maintenance pack) `--reset-existing <condensed brief>`.
+   - For in-place reset, state that `/bootstrap-repo --reset-existing` (repo-maintenance pack) must archive the old implementation under `archive/` before writing the fresh bootstrap docs. It must not delete the old code outright.
+   - The archive should preserve old implementation and documentation evidence without treating it as reusable foundation code or active source-of-truth docs. The fresh start should continue only from a high-level concept seed derived from the report, plus lessons captured in the report.
+
+6. **Present and route.**
+   - Show the user a terminal summary of the report.
+   - Recommend the appropriate `/bootstrap-repo` (repo-maintenance pack) command with the recommended bootstrap input from the report.
+   - Do NOT create the new repo or run `/bootstrap-repo` — the user does this.
+   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `/customer-discovery` to define who this is for, `/competitive-analysis` to map the market, `/journey-map` to map lifecycle and task flow, `/positioning` to lock the product direction, `/user-flow-map` to map screen flow, `/ui-interview --requirements-only` to define content/actions/states, `/ux-variations --layout-mode` to explore layouts, then prototype work, `/uat --variant-evaluation`, and `/consolidate-variations` before `/spec-interview` or `/roadmap`.
+   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `/pack install business-discovery` and `/pack install customer-lifecycle` before the research sequence.
+
+## Output
+
+```markdown
+Desk-flipped: <project name>
+- Report: desk-flip-report.md written to <project-path>
+- Specs extracted: <count> (<valid>/<partial>/<stale>)
+- Assets found: <count>
+- Lessons captured: <count>
+
+**Next work:** Reset the existing repo by archiving old implementation files, or create a new repo if the user prefers a separate fresh start
+**Recommended next command:** /bootstrap-repo (repo-maintenance pack) --reset-existing <condensed brief from report>
+```
+
+## Constraints
+
+- **Read-only during desk-flip** — no modifications to existing files, no archival, no branch creation. The only file written by this skill is `desk-flip-report.md`.
+- Do not carry forward code, dependencies, infrastructure, old research, old specs, or old task docs from the old project as active files.
+- Do not create the new repo or invoke `/bootstrap-repo` — the user handles that transition.
+- Do not commit or push (the report is informational, not a meaningful mutation to ship).
+- Do not delete, archive, or rename anything in the old repo during desk-flip. Only the downstream `/bootstrap-repo --reset-existing` step may perform archival after the user chooses that route.
+- If the project has no specs, docs, or meaningful git history, produce the report anyway but note the thin evidence in each section.
+- 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/desk-flip-{topic}.html`.
+
+## Default Shipping Contract
+
+- Do NOT commit or push. The only side effect is `desk-flip-report.md` written to the project root.
+- **Default next-step routing:** when reporting completion, include the two-line pair `**Next work:** <specific task>` and `**Recommended next command:** /bootstrap-repo (repo-maintenance pack) --reset-existing <brief>` for in-place restarts, or `/bootstrap-repo` (repo-maintenance pack) `<brief>` only when a separate new repo is explicitly the right path.
+- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `/customer-discovery`, then `/competitive-analysis`, `/journey-map`, `/positioning`, `/user-flow-map`, `/ui-interview --requirements-only`, `/ux-variations --layout-mode`, and prototype work. Mention `/pack install business-discovery`, `/pack install customer-lifecycle`, or `/pack install product-design` first if those packs are not enabled.

package/packs/teardown/claude/desk-flip/archive/v0.4/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: desk-flip
+description: Autopsy a stuck project, extract salvageable artifacts, and route to a fresh start via /bootstrap-repo reset or new-repo bootstrap
+type: execution
+version: v0.4
+argument-hint: "<project-path>"
+---
+
+# Desk Flip
+
+Autopsy a stuck project, extract salvageable artifacts (lessons, valid specs, non-code assets), and route the user to a fresh start either in a new repo or by resetting the existing repo with `/bootstrap-repo` (repo-maintenance pack) `--reset-existing`.
+
+Always desk-flip. If the user invoked it, the decision to restart is already made — do not offer incremental migration or attempt to fix the old project in place.
+
+## Process
+
+1. **Identify the stuck project.**
+   - Accept an optional project path from `$ARGUMENTS`; default to the current working directory.
+   - Verify the target is a git repo with existing code (not an empty repo).
+   - If the project appears to already use the new workflow (file-backed specs, prototype-first artifacts, healthy structure), warn the user and confirm before proceeding.
+
+2. **Survey the project.**
+   - Read `CLAUDE.md`, `README.md`, `package.json` or equivalent manifest, and directory structure.
+   - Read `tasks/`, `specs/`, `docs/` directories if they exist.
+   - Scan recent git history (last ~50 commits) for commit patterns and timeline.
+   - Read any existing `tasks/lessons.md` or post-mortem docs.
+
+3. **Run the autopsy** using subagents in parallel:
+   - **Lessons extraction:** What went wrong? Look for evidence of failure modes — infrastructure before prototype, late testing, chat-driven alignment drift, scope creep, untestable architecture. Cite specific commits, files, or timeline evidence.
+   - **Spec/design extraction:** Identify specs, designs, research docs, interview logs, and product briefs that capture valid domain knowledge or user needs — regardless of whether the implementation matched. Mark each as `valid`, `partially valid`, or `stale` with a one-line rationale.
+   - **Asset inventory:** Find non-code assets worth preserving — icons, images, copy, API contracts, design tokens, brand assets, research documents.
+
+   Do NOT extract code, dependencies, database schemas, or infrastructure config.
+
+4. **Write the autopsy report.**
+   - Produce `desk-flip-report.md` in the project root with these sections:
+
+   ```
+   ## Project Summary
+   What the project was and what state it's in now.
+
+   ## What Went Wrong
+   Specific failure modes with evidence (commits, files, timeline).
+
+   ## Salvageable Specs & Designs
+   List with file paths, validity status, and one-line descriptions.
+
+   ## Salvageable Assets
+   Non-code assets with file paths.
+
+   ## Lessons for the Fresh Start
+   Actionable guidance for the new project to avoid the same mistakes.
+
+   ## Recommended Bootstrap Input
+   A condensed brief suitable as input to /bootstrap-repo.
+   ```
+
+5. **Choose the fresh-start path.**
+   - If the user explicitly wants a new repository, route to `/bootstrap-repo` (repo-maintenance pack) `<condensed brief>`.
+   - If the user wants to keep the existing repository, or the current repo name, remotes, issues, deployment linkage, or local tooling are valuable, route to `/bootstrap-repo` (repo-maintenance pack) `--reset-existing <condensed brief>`.
+   - For in-place reset, state that `/bootstrap-repo --reset-existing` (repo-maintenance pack) must archive the old implementation under `archive/` before writing the fresh bootstrap docs. It must not delete the old code outright.
+   - The archive should preserve old implementation and documentation evidence without treating it as reusable foundation code or active source-of-truth docs. The fresh start should continue only from a high-level concept seed derived from the report, plus lessons captured in the report.
+
+6. **Present and route.**
+   - Show the user a terminal summary of the report.
+   - Recommend the appropriate `/bootstrap-repo` (repo-maintenance pack) command with the recommended bootstrap input from the report.
+   - Do NOT create the new repo or run `/bootstrap-repo` — the user does this.
+   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `/customer-discovery` to define who this is for, `/competitive-analysis` to map the market, `/journey-map` to map lifecycle and task flow, `/positioning` to lock the product direction, `/user-flow-map` to map screen flow, `/ui-interview --requirements-only` to define content/actions/states, `/ux-variations --layout-mode` to explore layouts, then prototype work, `/uat --variant-evaluation`, and `/consolidate-variations` before `/spec-interview` or `/roadmap`.
+   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `npx skillpacks install business-discovery` and `npx skillpacks install customer-lifecycle` before the research sequence.
+
+## Output
+
+```markdown
+Desk-flipped: <project name>
+- Report: desk-flip-report.md written to <project-path>
+- Specs extracted: <count> (<valid>/<partial>/<stale>)
+- Assets found: <count>
+- Lessons captured: <count>
+
+**Next work:** Reset the existing repo by archiving old implementation files, or create a new repo if the user prefers a separate fresh start
+**Recommended next command:** /bootstrap-repo (repo-maintenance pack) --reset-existing <condensed brief from report>
+```
+
+## Constraints
+
+- **Read-only during desk-flip** — no modifications to existing files, no archival, no branch creation. The only file written by this skill is `desk-flip-report.md`.
+- Do not carry forward code, dependencies, infrastructure, old research, old specs, or old task docs from the old project as active files.
+- Do not create the new repo or invoke `/bootstrap-repo` — the user handles that transition.
+- Do not commit or push (the report is informational, not a meaningful mutation to ship).
+- Do not delete, archive, or rename anything in the old repo during desk-flip. Only the downstream `/bootstrap-repo --reset-existing` step may perform archival after the user chooses that route.
+- If the project has no specs, docs, or meaningful git history, produce the report anyway but note the thin evidence in each section.
+- 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
+
+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/desk-flip-{topic}.html`.
+
+## Default Shipping Contract
+
+- Do NOT commit or push. The only side effect is `desk-flip-report.md` written to the project root.
+- **Default next-step routing:** when reporting completion, include the two-line pair `**Next work:** <specific task>` and `**Recommended next command:** /bootstrap-repo (repo-maintenance pack) --reset-existing <brief>` for in-place restarts, or `/bootstrap-repo` (repo-maintenance pack) `<brief>` only when a separate new repo is explicitly the right path.
+- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `/customer-discovery`, then `/competitive-analysis`, `/journey-map`, `/positioning`, `/user-flow-map`, `/ui-interview --requirements-only`, `/ux-variations --layout-mode`, and prototype work. Mention `npx skillpacks install business-discovery`, `npx skillpacks install customer-lifecycle`, or `npx skillpacks install product-design` first if those packs are not enabled.

package/packs/teardown/codex/decommission/ALIGNMENT-PAGE.md

@@ -57,7 +57,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-decommission-research.md`; product-path mode uses `research/{slug}/_working/preliminary-decommission-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-decommission-research.md`; product-path mode uses `research/{slug}/_working/preliminary-decommission-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.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/teardown/codex/desk-flip/ALIGNMENT-PAGE.md

@@ -57,7 +57,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-desk-flip-research.md`; product-path mode uses `research/{slug}/_working/preliminary-desk-flip-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-desk-flip-research.md`; product-path mode uses `research/{slug}/_working/preliminary-desk-flip-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.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/teardown/codex/desk-flip/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## v0.5 - 2026-06-12
+
+- Updated fresh-start product routing to use the AFPS prototype flow tree: `$user-flow-map` -> `$ux-variations [specific-user-flow]` -> `$ui-interview [specific-ux-variation]`, with requirements-only/layout-mode as explicit bounded detours.
+
+## 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 post-bootstrap fresh-start guidance from retired `$icp` to `$customer-discovery`.

package/packs/teardown/codex/desk-flip/SKILL.md

@@ -2,7 +2,7 @@
 name: desk-flip
 description: Autopsy a stuck project, extract salvageable artifacts, and route to a fresh start via $bootstrap-repo reset or new-repo bootstrap
 type: execution
-version: v0.3
+version: v0.5
 argument-hint: "<project-path>"
 ---
 
@@ -67,8 +67,8 @@ Always desk-flip. If the user invoked it, the decision to restart is already mad
    - Show the user a terminal summary of the report.
    - Recommend the appropriate `$bootstrap-repo` command with the recommended bootstrap input from the report.
    - Do not create the new repo or run `$bootstrap-repo`; the user does this.
-   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `$customer-discovery` to define who this is for, `$competitive-analysis` to map the market, `$journey-map` to map lifecycle and task flow, `$positioning` to lock the product direction, `$user-flow-map` to map screen flow, `$ui-interview --requirements-only` to define content/actions/states, `$ux-variations --layout-mode` to explore layouts, then prototype work, `$uat --variant-evaluation`, and `$consolidate-variations` before `$spec-interview` or `$roadmap`.
-   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `$pack install business-discovery` and `$pack install customer-lifecycle` before the research sequence.
+   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `$customer-discovery` to define who this is for, `$competitive-analysis` to map the market, `$journey-map` to map lifecycle and task flow, `$positioning` to lock the product direction, `$user-flow-map` to map screen flow, `$ux-variations [specific-user-flow]` to explore progression branches, `$ui-interview [specific-ux-variation]` to render and approve/reject a branch mockup, then prototype work, `$uat --variant-evaluation`, and `$consolidate-variations` before `$spec-interview` or `$roadmap`. Use `$ui-interview --requirements-only` and `$ux-variations --layout-mode` only when the user explicitly needs a fixed content contract and layout-only alternatives.
+   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `npx skillpacks install business-discovery` and `npx skillpacks install customer-lifecycle` before the research sequence.
 
 ## Output
 
@@ -100,4 +100,4 @@ When this skill produces durable deliverables (research, specs, plans, reports,
 
 - Do not commit or push. The only side effect is `desk-flip-report.md` written to the project root.
 - **Default next-step routing:** when reporting completion, include the two-line pair `**Next work:** <specific task>` and `**Recommended next command:** $bootstrap-repo --reset-existing <brief>` for in-place restarts, or `$bootstrap-repo <brief>` only when a separate new repo is explicitly the right path.
-- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `$customer-discovery`, then `$competitive-analysis`, `$journey-map`, `$positioning`, `$user-flow-map`, `$ui-interview --requirements-only`, `$ux-variations --layout-mode`, and prototype work. Mention `$pack install business-discovery`, `$pack install customer-lifecycle`, or `$pack install product-design` first if those packs are not enabled.
+- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `$customer-discovery`, then `$competitive-analysis`, `$journey-map`, `$positioning`, `$user-flow-map`, `$ux-variations [specific-user-flow]`, `$ui-interview [specific-ux-variation]`, and prototype work. Mention `npx skillpacks install business-discovery`, `npx skillpacks install customer-lifecycle`, or `npx skillpacks install product-design` first if those packs are not enabled.

package/packs/teardown/codex/desk-flip/archive/v0.3/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: desk-flip
+description: Autopsy a stuck project, extract salvageable artifacts, and route to a fresh start via $bootstrap-repo reset or new-repo bootstrap
+type: execution
+version: v0.3
+argument-hint: "<project-path>"
+---
+
+# Desk Flip
+
+Invoke as `$desk-flip`.
+
+Autopsy a stuck project, extract salvageable artifacts (lessons, valid specs, non-code assets), and route the user to a fresh start either in a new repo or by resetting the existing repo with `$bootstrap-repo --reset-existing`.
+
+Always desk-flip. If the user invoked it, the decision to restart is already made. Do not offer incremental migration or attempt to fix the old project in place.
+
+## Process
+
+1. **Identify the stuck project.**
+   - Accept an optional project path from the invocation arguments; default to the current working directory.
+   - Verify the target is a git repo with existing code, not an empty repo.
+   - If the project appears to already use the new workflow (file-backed specs, prototype-first artifacts, healthy structure), warn the user and confirm before proceeding.
+
+2. **Survey the project.**
+   - Read `AGENTS.md`, `CLAUDE.md`, `README.md`, `package.json` or equivalent manifest, and directory structure when present.
+   - Read `tasks/`, `specs/`, and `docs/` directories if they exist.
+   - Scan recent git history (last ~50 commits) for commit patterns and timeline.
+   - Read any existing `tasks/lessons.md` or post-mortem docs.
+
+3. **Run the autopsy.**
+   - **Lessons extraction:** What went wrong? Look for evidence of failure modes: infrastructure before prototype, late testing, chat-driven alignment drift, scope creep, untestable architecture. Cite specific commits, files, or timeline evidence.
+   - **Spec/design extraction:** Identify specs, designs, research docs, interview logs, and product briefs that capture valid domain knowledge or user needs, regardless of whether the implementation matched. Mark each as `valid`, `partially valid`, or `stale` with a one-line rationale.
+   - **Asset inventory:** Find non-code assets worth preserving: icons, images, copy, API contracts, design tokens, brand assets, research documents.
+
+   Do not extract code, dependencies, database schemas, or infrastructure config.
+
+4. **Write the autopsy report.**
+   - Produce `desk-flip-report.md` in the project root with these sections:
+
+   ```markdown
+   ## Project Summary
+   What the project was and what state it's in now.
+
+   ## What Went Wrong
+   Specific failure modes with evidence (commits, files, timeline).
+
+   ## Salvageable Specs & Designs
+   List with file paths, validity status, and one-line descriptions.
+
+   ## Salvageable Assets
+   Non-code assets with file paths.
+
+   ## Lessons for the Fresh Start
+   Actionable guidance for the new project to avoid the same mistakes.
+
+   ## Recommended Bootstrap Input
+   A condensed brief suitable as input to $bootstrap-repo.
+   ```
+
+5. **Choose the fresh-start path.**
+   - If the user explicitly wants a new repository, route to `$bootstrap-repo <condensed brief>`.
+   - If the user wants to keep the existing repository, or the current repo name, remotes, issues, deployment linkage, or local tooling are valuable, route to `$bootstrap-repo --reset-existing <condensed brief>`.
+   - For in-place reset, state that `$bootstrap-repo --reset-existing` must archive the old implementation under `archive/` before writing the fresh bootstrap docs. It must not delete the old code outright.
+   - The archive should preserve old implementation and documentation evidence without treating it as reusable foundation code or active source-of-truth docs. The fresh start should continue only from a high-level concept seed derived from the report, plus lessons captured in the report.
+
+6. **Present and route.**
+   - Show the user a terminal summary of the report.
+   - Recommend the appropriate `$bootstrap-repo` command with the recommended bootstrap input from the report.
+   - Do not create the new repo or run `$bootstrap-repo`; the user does this.
+   - After bootstrap, route product/app restarts into the research-first alignment workflow using the high-level concept seed as input: `$customer-discovery` to define who this is for, `$competitive-analysis` to map the market, `$journey-map` to map lifecycle and task flow, `$positioning` to lock the product direction, `$user-flow-map` to map screen flow, `$ui-interview --requirements-only` to define content/actions/states, `$ux-variations --layout-mode` to explore layouts, then prototype work, `$uat --variant-evaluation`, and `$consolidate-variations` before `$spec-interview` or `$roadmap`.
+   - If the business-discovery or customer-lifecycle packs are not enabled in the fresh repo, recommend `$pack install business-discovery` and `$pack install customer-lifecycle` before the research sequence.
+
+## Output
+
+```markdown
+Desk-flipped: <project name>
+- Report: desk-flip-report.md written to <project-path>
+- Specs extracted: <count> (<valid>/<partial>/<stale>)
+- Assets found: <count>
+- Lessons captured: <count>
+
+**Next work:** Reset the existing repo by archiving old implementation files, or create a new repo if the user prefers a separate fresh start
+**Recommended next command:** $bootstrap-repo --reset-existing <condensed brief from report>
+```
+
+## Constraints
+
+- **Read-only during desk-flip**: no modifications to existing files, no archival, no branch creation. The only file written by this skill is `desk-flip-report.md`.
+- Do not carry forward code, dependencies, infrastructure, old research, old specs, or old task docs from the old project as active files.
+- Do not create the new repo or invoke `$bootstrap-repo`; the user handles that transition.
+- Do not commit or push; the report is informational, not a meaningful mutation to ship.
+- Do not delete, archive, or rename anything in the old repo during desk-flip. Only the downstream `$bootstrap-repo --reset-existing` step may perform archival after the user chooses that route.
+- If the project has no specs, docs, or meaningful git history, produce the report anyway but note the thin evidence in each section.
+
+## 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/desk-flip-{topic}.html`.
+
+## Default Shipping Contract
+
+- Do not commit or push. The only side effect is `desk-flip-report.md` written to the project root.
+- **Default next-step routing:** when reporting completion, include the two-line pair `**Next work:** <specific task>` and `**Recommended next command:** $bootstrap-repo --reset-existing <brief>` for in-place restarts, or `$bootstrap-repo <brief>` only when a separate new repo is explicitly the right path.
+- **Post-bootstrap route:** include in the report that the fresh project should proceed from the high-level concept seed to `$customer-discovery`, then `$competitive-analysis`, `$journey-map`, `$positioning`, `$user-flow-map`, `$ui-interview --requirements-only`, `$ux-variations --layout-mode`, and prototype work. Mention `$pack install business-discovery`, `$pack install customer-lifecycle`, or `$pack install product-design` first if those packs are not enabled.