prizmkit 1.1.80 → 1.1.82

package/bundled/skills-windows/recovery-workflow/SKILL.md

@@ -55,30 +55,24 @@ Pipeline commands (for reference — Phase 1.3 will present these as a selectabl
 
 ## Overview
 
-```
-recovery-workflow
-  │
-  ├── Phase 0: Auto-detect
-  │   ├── Read current branch name
-  │   ├── Scan characteristic artifacts
-  │   ├── Match workflow signature → determine workflow type
-  │   ├── Based on artifact presence → infer current phase
-  │   └── No match → reject and guide user
-  │
-  ├── Phase 1: Diagnose + report + user choice
-  │   ├── Check branch and working tree state
-  │   ├── Scan all pipelines for failed/in-progress tasks
-  │   ├── Find residual dev branches from failed tasks
-  │   ├── Display diagnosis + detection results
-  │   ├── If code changes exist → run test suite
-  │   ├── If multiple failed tasks → ask user which to recover
-  │   └── User chooses: run-recovery.ps1 (recommended) | interactive | start fresh
-  │
-  └── Phase 2: Execute remaining steps
-      ├── Read target workflow's SKILL.md
-      ├── Read existing artifacts to restore context
-      └── Execute from inferred phase through completion
-```
+1. **Phase 0: Auto-detect**
+   1. Read current branch name
+   2. Scan characteristic artifacts
+   3. Match workflow signature → determine workflow type
+   4. Based on artifact presence → infer current phase
+   5. No match → reject and guide user
+2. **Phase 1: Diagnose + report + user choice**
+   1. Check branch and working tree state
+   2. Scan all pipelines for failed/in-progress tasks
+   3. Find residual dev branches from failed tasks
+   4. Display diagnosis + detection results
+   5. If code changes exist → run test suite
+   6. If multiple failed tasks → ask user which to recover
+   7. User chooses: run-recovery.ps1 (recommended) | interactive | start fresh
+3. **Phase 2: Execute remaining steps**
+   1. Read target workflow's SKILL.md
+   2. Read existing artifacts to restore context
+   3. Execute from inferred phase through completion
 
 ---
 
@@ -290,53 +284,19 @@ This step replaces the context that was lost when the AI session was interrupted
 
 ---
 
-### 2.1 Bug-Fix-Workflow Recovery
-
-Phase inference table:
+### 2.1 Per-Workflow Phase Inference
 
-| Detected State | Resume From | Actions |
-|---------------|------------|---------|
-| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Deep Bug Diagnosis | Read bug description from `.prizmkit/plans/bug-fix-list.json`. Start interactive diagnosis Q&A |
-| `fix-plan.md` exists, no code changes | Phase 4: Fix | Read fix-plan.md. Implement the fix following the plan |
-| `fix-plan.md` + code changes exist | Phase 5: Review | Invoke `/prizmkit-code-review` on all changes |
-| All docs + review passed | Phase 6: User Verification | Ask user to verify the fix works |
-| All docs + committed | Phase 7: Merge Decision | Ask merge vs keep branch |
+Read `${SKILL_DIR}/references/detection.md` for the per-workflow phase-inference tables (bug-fix / feature / refactor) that map detected state → the phase to resume from and its actions.
 
-**Note**: Bug-fix Phases 1-3 (Diagnosis, Triage, Reproduce) collapse to Phase 1 for detection purposes because these phases don't produce persistent artifacts. If interrupted during these phases, recovery restarts from Phase 1 (diagnosis), which re-derives understanding from available inputs (bug description, code) without interactive Q&A.
-
-**Execution for each remaining phase**: Follow the bug-fix-workflow SKILL.md instructions exactly. Call the same prizmkit sub-commands (`/prizmkit-code-review`, `/prizmkit-committer`) at the same points.
+**Bug-fix execution**: Follow the bug-fix-workflow SKILL.md instructions exactly. Call the same prizmkit sub-commands (`/prizmkit-code-review`, `/prizmkit-committer`) at the same points.
 
 **Special handling**:
 - If resuming from Phase 5 (Review) and tests are failing, fix test failures first (max 3 attempts). If unfixable, ask user whether to continue or restart.
 - If resuming from Phase 4 (Fix), read fix-plan.md to understand the planned approach before writing code.
 
----
+**Feature recovery**: Phases 3-4 are pipeline-driven. The main recovery value is avoiding re-brainstorming (Phase 1) when `.prizmkit/plans/feature-list.json` already exists.
 
-### 2.2 Feature-Workflow Recovery
-
-Phase inference table:
-
-| Detected State | Resume From | Actions |
-|---------------|------------|---------|
-| No `.prizmkit/plans/feature-list.json` | Phase 1: Brainstorm | Cannot recover conversation context. Start requirement clarification, but leverage any workspace content (README, existing code) for context |
-| `.prizmkit/plans/feature-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `feature-pipeline-launcher` to start the pipeline |
-| `.prizmkit/plans/feature-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status via `feature-pipeline-launcher` (Intent B: Check Status) |
-
-**Note**: Feature-workflow recovery is simpler because Phases 3-4 are pipeline-driven. The main recovery value is avoiding re-brainstorming (Phase 1) when `.prizmkit/plans/feature-list.json` already exists.
-
----
-
-### 2.3 Refactor-Workflow Recovery
-
-Phase inference table (mirrors feature-workflow):
-
-| Detected State | Resume From | Actions |
-|---------------|------------|---------|
-| No `.prizmkit/plans/refactor-list.json` | Phase 1: Brainstorm | Start refactoring goal clarification |
-| `.prizmkit/plans/refactor-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `refactor-pipeline-launcher` to start the pipeline |
-| `.prizmkit/plans/refactor-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status |
-
----
+**Refactor recovery**: Mirrors feature-workflow (brainstorm → launch → monitor).
 
 ### 2.4 Post-Recovery Report
 
@@ -388,16 +348,6 @@ Recovery complete.
 
 ---
 
-## Comparison with Previous Version
-
-| Dimension | Previous | Current |
-|-----------|----------|---------|
-| Scope | Feature pipeline only | All 3 interactive workflows |
-| Input | Required `F-XXX` feature ID | No input — fully auto-detect |
-| Detection | Feature-specific (spec/plan/git) | Signature-based (branch + artifacts) |
-| Strategy | Multi-option (5 scenarios × 2-4 options each) | Single path: report → confirm → execute |
-| Intrusion | None | None (zero changes to target workflows) |
-
 ## Output
 
 - Resumed and completed workflow from the breakpoint

package/bundled/skills-windows/refactor-pipeline-launcher/SKILL.md

@@ -156,28 +156,13 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Wait for user confirmation before proceeding.
 
-5. **Ask execution mode** (first user decision — SEPARATE `AskUserQuestion` call):
+5. **Ask execution mode** (first user decision):
 
-   ⛔ **This MUST be its own standalone `AskUserQuestion` call.** Do NOT combine execution mode with step 6 config questions. The execution mode question is asked ALONE, user responds, THEN you proceed to step 6.
+   Present the three execution modes from the **Execution Mode** section above as a single standalone `AskUserQuestion` call (exactly 1 question, multiSelect: false). Wait for the user's response before continuing to step 6.
 
-   Use `AskUserQuestion` with exactly 1 question:
+   Each `AskUserQuestion` round is a genuine gate: callers tend to merge interactive rounds and pre-fill answers, which skips real user decisions and produces wrong configs. Therefore: ask execution mode (step 5) and configuration (step 6) as SEPARATE `AskUserQuestion` calls, in order, and do not assemble or show the final command (step 7) until the user has answered both. If you find yourself writing the final command before the user has answered, STOP — you are violating this rule.
 
-   **Question 1 — Execution mode** (multiSelect: false):
-   - Foreground (Recommended) — pipeline runs in the current session via `run-refactor.ps1 run`. Visible output and direct error feedback.
-   - Background daemon — pipeline runs fully detached via `launch-refactor-daemon.ps1`. Survives AI CLI session closure.
-   - Manual — display the final assembled commands only. Do not execute anything. User runs them on their own.
-
-   ⚠️ STOP HERE and wait for user response before continuing to step 6.
-
-6. **Ask configuration options** ⚠️ MANDATORY INTERACTIVE STEP — applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 5. You MUST ask the user to configure options and WAIT for their response BEFORE proceeding to step 7.
-
-   ⛔ **HARD STOP**: You MUST call `AskUserQuestion` with the 3 questions below and WAIT for the user's response. You MUST NOT:
-   - Combine step 5 and step 6 into one `AskUserQuestion` call (this is the most common violation — execution mode MUST be asked separately in step 5)
-   - Skip this step and jump to step 7
-   - Merge step 6 and step 7 into one response
-   - Assume default values and show the command without asking
-   - Show the command as text and ask "ready?" without presenting the options
-   If you find yourself writing the final command before the user has answered these 3 questions, STOP — you are violating this rule.
+6. **Ask configuration options** — a SEPARATE `AskUserQuestion` call from step 5, applies to ALL execution modes (Foreground, Background, AND Manual).
 
    Use `AskUserQuestion` to present ALL 3 configuration choices (the full 3-question budget goes to config, NOT shared with execution mode):
 
@@ -196,35 +181,11 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Note: Refactor filter defaults to all refactor items (by priority order). If the user selects "Other" on any option, handle their custom input.
 
-   **If user chose "Yes" to Advanced config**, ask a second round of `AskUserQuestion`:
-
-   **Question 1 — Session timeout** (multiSelect: false):
-   - None (default) — No timeout
-   - 30 min — `SESSION_TIMEOUT=1800`
-   - 1 hour — `SESSION_TIMEOUT=3600`
-   - 2 hours — `SESSION_TIMEOUT=7200`
-
-   **Question 2 — Stop on failure** (multiSelect: false):
-   - Off (default) — Pipeline continues to next task after failure
-   - On — Pipeline halts immediately when a task exhausts all retries (`STOP_ON_FAILURE=1`)
-
-   **Question 3 — Critic review** (multiSelect: false):
-   - Off (default) — Skip adversarial review
-   - On — Enable adversarial critic review: an independent AI agent reviews the refactor plan for completeness and the implementation for regressions, missing edge cases, and behavior violations. Adds ~5-10 min per refactor task.
-
-   **Question 4 — Reasoning effort** (multiSelect: false):
-   - Default (none) — Use CLI default
-   - low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
-   - medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
-   - high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
-   - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
-   - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
-
-   Default Critic to Off unless refactor items have `priority: "critical"` (in which case default to On).
+   **If user chose "Yes" to Advanced config**, run the advanced configuration round (a second `AskUserQuestion` round). It applies to a minority of sessions, so the full question set lives in `${SKILL_DIR}/references/configuration.md` → **Advanced Configuration Round**. Default Critic to Off unless refactor items have `priority: "critical"` (in which case default to On).
 
    **Environment variable mapping** and **advanced environment variables** tables — read `${SKILL_DIR}/references/configuration.md` for the full translation tables (10 config→env mappings + 8 advanced variables).
 
-   ⚠️ STOP HERE and wait for user response before continuing to step 7.
+   STOP HERE and wait for user response before continuing to step 7.
 
 7. **Show final command**: After user confirms configuration in step 6, assemble the complete command from execution mode + user-confirmed configuration, and present it to the user.
 
@@ -373,7 +334,7 @@ Notes:
 
 ### Error Handling
 
-Read `${SKILL_DIR}/references/configuration.md` for the full error handling table (14 entries).
+Read the error-handling table in `${SKILL_DIR}/references/configuration.md` for the full list of errors and recovery actions.
 
 ### Integration Notes
 

package/bundled/skills-windows/refactor-pipeline-launcher/references/configuration.md

@@ -52,3 +52,31 @@ Not exposed in interactive menu, pass via `--env`:
 | `opencli` not installed | Browser verification skipped for opencli refactors (non-blocking). Install opencli for Chrome session-based browser verification |
 | Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/refactor/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |
 | PowerShell execution policy blocks script | Run `Set-ExecutionPolicy -Scope Process Bypass` for the current terminal |
+
+## Advanced Configuration Round
+
+Only run this when the user answered "Yes" to the **Advanced config?** question in step 6. It applies to a minority of sessions.
+
+Ask a second round of `AskUserQuestion` with these 4 questions:
+
+**Question 1 — Session timeout** (multiSelect: false):
+- None (default) — No timeout
+- 30 min — `SESSION_TIMEOUT=1800`
+- 1 hour — `SESSION_TIMEOUT=3600`
+- 2 hours — `SESSION_TIMEOUT=7200`
+
+**Question 2 — Stop on failure** (multiSelect: false):
+- Off (default) — Pipeline continues to next task after failure
+- On — Pipeline halts immediately when a task exhausts all retries (`STOP_ON_FAILURE=1`)
+
+**Question 3 — Critic review** (multiSelect: false):
+- Off (default) — Skip adversarial review
+- On — Enable adversarial critic review: an independent AI agent reviews the refactor plan for completeness and the implementation for regressions, missing edge cases, and behavior violations. Adds ~5-10 min per refactor task.
+
+**Question 4 — Reasoning effort** (multiSelect: false):
+- Default (none) — Use CLI default
+- low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+- medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+- high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+- xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+- max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)

package/bundled/skills-windows/refactor-planner/SKILL.md

@@ -78,7 +78,7 @@ Do NOT use this skill when the user wants to:
    - Read `${SKILL_DIR}/references/behavior-preservation.md` for preservation strategy selection
 
 4. **Load on-demand references when triggered**:
-   - Validation errors or interrupted session -> read error recovery patterns (similar to feature-planner)
+   - Validation errors or interrupted session -> see the "Error Recovery & Resume" section below
 
 5. **Define the PowerShell Python helper before running validation scripts**:
    ```powershell
@@ -294,8 +294,6 @@ See `${SKILL_DIR}/references/planning-phases.md` for the full 5-step review chec
 | **CP-RP-5** | Completeness OK | DAG valid, preservation strategies declared, no gaps | 6 |
 | **CP-RP-6** | Output Valid | `.prizmkit/plans/refactor-list.json` passes validation script | 7 |
 
-**Resume Detection**: If existing artifacts found (partial `.prizmkit/plans/refactor-list.json`, draft `refactor-list.draft.json` in `.prizmkit/plans/`), offer to resume from the appropriate checkpoint.
-
 ## Output Rules
 
 `.prizmkit/plans/refactor-list.json` must satisfy:
@@ -363,6 +361,8 @@ Key behaviors:
 
 ### Resume Detection
 
+If existing artifacts are found, offer to resume from the appropriate checkpoint/phase:
+
 | Artifact Found | Resume From |
 |---------------|------------|
 | Nothing | Phase 1: Project Context |
@@ -370,18 +370,16 @@ Key behaviors:
 | Partial `.prizmkit/plans/refactor-list.json` | Phase 6: Completeness Review |
 | Valid `.prizmkit/plans/refactor-list.json` | Mode D: Summary |
 
-## Session Exit Gate
+### Session Exit Gate
 
 Prevent accidental session exit without deliverable completion.
 
-### Trigger Conditions
-Activate exit gate when ALL are true:
+**Trigger conditions** — activate the exit gate when ALL are true:
 - User invoked `/refactor-planner` (not just mentioned refactoring)
 - Current phase < Phase 7 (validation not yet passed)
 - No valid `.prizmkit/plans/refactor-list.json` has been written in this session
 
-### Gate Behavior
-When the session appears to be ending:
+**Gate behavior** — when the session appears to be ending:
 1. **Remind**: "You set out to produce `.prizmkit/plans/refactor-list.json` but we haven't completed it yet."
 2. **Offer 3 options**:
    - **(a) Continue to completion** — resume from current phase

package/bundled/skills-windows/refactor-workflow/SKILL.md

@@ -26,39 +26,12 @@ User says:
 
 ## Overview
 
-```
-refactor-workflow <target / goals>
-   │
-   ├── Phase 1: Brainstorm → clarify type → collect materials → parallel deep read → discuss plan
-   │
-   ├── Phase 2: Plan → refactor-planner → .prizmkit/plans/refactor-list.json
-   │
-   ├── Phase 3: Launch → refactor-pipeline-launcher → pipeline execution
-   │
-   └── Phase 4: Monitor → track progress → report results
-```
-
-### What This Skill Does
-
-| Phase | Action | Result |
-|-------|--------|--------|
-| 1 | **Brainstorm** — clarify type, collect reference materials, parallel deep read code & docs, discuss plan grounded in real code | Fully clarified refactoring goals |
-| 2 | Call `refactor-planner` with clarified goals | `.prizmkit/plans/refactor-list.json` with N refactor items |
-| 3 | Call `refactor-pipeline-launcher` | Pipeline started (execution mode chosen by user via launcher) |
-| 4 | Monitor progress | Status updates, completion report |
-
-### Why This Skill Exists
-
-Without this skill, users must:
-1. Figure out all refactoring goals and scope themselves
-2. Invoke `refactor-planner` → wait for .prizmkit/plans/refactor-list.json
-3. Invoke `refactor-pipeline-launcher` → wait for pipeline start
-4. Manually check progress
+Four phases take a rough refactoring idea to verified, behavior-preserving code so the user doesn't have to manually chain planner → launcher → monitoring:
 
-With this skill, users can:
-1. Say "Refactor the auth module to extract shared middleware" with a rough idea
-2. The skill brainstorms to fill in all gaps (scope, risks, behavior contracts)
-3. All planning + execution happens automatically
+1. **Brainstorm** — clarify type, collect reference materials, parallel deep read code & docs, discuss plan grounded in real code → fully clarified refactoring goals
+2. **Plan** — call `refactor-planner` → `.prizmkit/plans/refactor-list.json` with N refactor items
+3. **Launch** — call `refactor-pipeline-launcher` → pipeline started (execution mode chosen by user via launcher)
+4. **Monitor** — track progress → status updates, completion report
 
 ### Branch Management
 
@@ -80,21 +53,9 @@ Natural language description of the refactoring goals. Can be:
 
 Flow: brainstorm → refactor-planner → refactor-pipeline-launcher → monitor
 
-**Mode B: From existing .prizmkit/plans/refactor-list.json**
+**Mode B: From existing `.prizmkit/plans/refactor-list.json`** — user says "run pipeline from existing file", or the file already exists. Skip ahead per the [Resume table](#resume--interruption-recovery).
 
-When user says "run pipeline from existing file" or .prizmkit/plans/refactor-list.json already exists:
-- Skip brainstorm and `refactor-planner` (file already exists)
-- Invoke `refactor-pipeline-launcher` directly
-- Monitor and report progress
-
-**Mode C: Incremental (add to existing refactor plan)**
-
-When user says "add more refactors" or the project already has a .prizmkit/plans/refactor-list.json:
-- Brainstorm new refactoring goals with the user
-- Invoke `refactor-planner` in incremental mode (reads existing .prizmkit/plans/refactor-list.json)
-- Append new refactor items to existing list
-- Invoke `refactor-pipeline-launcher`
-- Monitor and report progress
+**Mode C: Incremental (add to existing refactor plan)** — user says "add more refactors". Brainstorm new goals, then invoke `refactor-planner` in incremental mode (appends to existing list) → launch → monitor.
 
 ---
 
@@ -176,28 +137,6 @@ After confirming refactoring goals, assess whether this refactor needs the full
 - Existing tests fully cover the affected code paths
 - No risk of behavior change
 
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
-
-```
-AskUserQuestion:
-  question: "This refactoring appears straightforward. How would you like to proceed?"
-  header: "Approach"
-  options:
-    - label: "Refactor now (fast path)"
-      description: "Plan and refactor directly in this session using /prizmkit-plan + /prizmkit-implement"
-    - label: "Add to refactor list (pipeline)"
-      description: "Generate .prizmkit/plans/refactor-list.json via refactor-planner, then launch pipeline for autonomous execution"
-```
-
-- **Refactor now** → Fast Path Workflow:
-  1. Invoke `/prizmkit-plan` with the refactoring goals → generates `spec.md` + `plan.md`
-  2. Invoke `/prizmkit-implement` to execute the plan (behavior preservation verified by tests)
-  3. After implementation, run `/prizmkit-code-review` for quality check
-  4. Commit via `/prizmkit-committer` with `refactor(<scope>):` prefix
-  5. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
-  6. **End workflow** — skip Phase 2/3/4
-- **Add to refactor list** → Continue to Phase 2 (Plan via pipeline)
-
 **Complex refactor → Planning Path** (ANY is true):
 - Cross-module impact (>2 modules affected)
 - Public API or interface changes required
@@ -206,21 +145,21 @@ AskUserQuestion:
 - Insufficient test coverage in target area (risk of hidden behavior changes)
 - Requires coordination with other ongoing work
 
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
+**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options. Tailor the question text to the assessment ("This refactoring appears straightforward…" for simple, "This refactoring is complex and will benefit from structured planning…" for complex), but the two options are always the same:
 
 ```
 AskUserQuestion:
-  question: "This refactoring is complex and will benefit from structured planning. How would you like to proceed?"
+  question: <tailored to simple vs complex assessment>
   header: "Approach"
   options:
-    - label: "Plan and refactor now"
-      description: "Create a plan and refactor in this session using /prizmkit-plan + /prizmkit-implement"
+    - label: "Refactor now (fast path)"
+      description: "Plan and refactor directly in this session using /prizmkit-plan + /prizmkit-implement"
     - label: "Add to refactor list (pipeline)"
       description: "Generate .prizmkit/plans/refactor-list.json via refactor-planner, then launch pipeline for autonomous execution"
 ```
 
-- **Plan and refactor now** → Invoke `/prizmkit-plan` with goals → `/prizmkit-implement` → `/prizmkit-code-review` → `/prizmkit-committer` → `/prizmkit-retrospective`. **End workflow** — skip Phase 2/3/4.
-- **Add to refactor list** → Continue to Phase 2 (Plan via pipeline)
+- **Refactor now** → Fast Path: `/prizmkit-plan` (goals → `spec.md` + `plan.md`) → `/prizmkit-implement` (behavior preservation verified by tests) → `/prizmkit-code-review` → `/prizmkit-committer` (`refactor(<scope>):` prefix) → `/prizmkit-retrospective` (sync `.prizmkit/prizm-docs/`). **End workflow** — skip Phase 2/3/4.
+- **Add to refactor list** → Continue to Phase 2 (Plan via pipeline).
 
 **NEVER proceed without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
 
@@ -251,7 +190,7 @@ AskUserQuestion:
 
 **CHECKPOINT CP-RW-1**: `.prizmkit/plans/refactor-list.json` generated and validated.
 
-**If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely.
+**If `.prizmkit/plans/refactor-list.json` already exists or user says `--from <file>`**: skip ahead per the [Resume table](#resume--interruption-recovery).
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.80",
+  "version": "1.1.82",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {