prizmkit 1.1.130 → 1.1.134

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

@@ -1,246 +1,205 @@
 ---
 name: "refactor-workflow"
-description: "Thin L3 refactor workflow router for behavior-preserving code restructuring. Clarifies enough to choose Fast Path, Pipeline Path, or existing-list launch; routes deep code analysis and item decomposition to refactor-planner and execution configuration to refactor-pipeline-launcher. Use when the user wants to refactor, clean up, restructure, decouple, simplify, migrate internal structure, extract modules, or run an existing refactor list without changing product behavior. Trigger on: 'refactor', 'clean up code', 'restructure', 'optimize code structure', 'extract module', 'decouple', 'code migration', 'batch refactor', 'run refactor list'."
+description: "Thin behavior-preserving refactor scenario router. Clarifies enough to choose direct single-requirement guidance, refactor planning, existing-list command construction, or behavior-change rerouting; hands planning to refactor-planner and runtime command construction to refactor-pipeline-launcher. It never starts coding or owns the requirement lifecycle."
 ---
 
 # Refactor Workflow
 
-Thin L3 entry point for behavior-preserving refactoring. This workflow routes the user to the right path, prepares a concise handoff brief, and avoids duplicating `refactor-planner` or `refactor-pipeline-launcher` internals.
+Classify behavior intent, prepare a concise handoff brief, and route planned work without implementing a refactor or duplicating planner/launcher responsibilities.
 
 ## Responsibility Boundary
 
 This workflow owns:
-- Scenario recognition: Fast Path, Pipeline Path, existing-list launch, or behavior-change reroute.
-- Lightweight behavior-risk triage.
+- Scenario recognition: direct single-requirement guidance, Pipeline Path, existing-list command construction, or behavior-change reroute.
+- Lightweight behavior-preservation and scope triage.
 - User path selection through `AskUserQuestion`.
-- Prompt brief handoff to Fast Path L1 skills, `refactor-planner`, or `refactor-pipeline-launcher`.
+- Prompt brief handoff to `refactor-planner`, `refactor-pipeline-launcher`, or `feature-workflow` for behavior changes.
 - Continuation after `refactor-planner` when the user entered through this workflow.
 
 This workflow does not own:
+- Source-code implementation, test execution, code review, documentation sync, or commit execution.
 - Deep code analysis, item decomposition, dependency ordering, behavior-preservation strategy selection, schema validation, or plan review gates — those belong to `refactor-planner`.
-- Execution mode, runtime configuration, preflight, command assembly, status/log/stop/retry details — those belong to `refactor-pipeline-launcher`.
-- Product behavior changes — those should route to feature work unless explicitly framed as a behavior-preserving migration.
+- Runtime option selection, command construction, prerequisite checks, or status/log/stop/retry syntax — those belong to `refactor-pipeline-launcher`.
+- Product behavior changes — those route to feature work.
+- The independent direct requirement lifecycle.
+
+## Execution Topology
+
+```text
+Direct single requirement:
+User → prizmkit-workflow → atomic lifecycle skills
+
+Planned refactor execution:
+User → refactor-workflow → refactor-planner → refactor-pipeline-launcher → returned CLI command → runtime → atomic lifecycle skills
+```
+
+The routes are independent. This workflow can identify a direct-path candidate, but it ends before the user enters the direct path and never invokes the direct workflow.
 
 ## Behavior-Preservation Boundary
 
 Refactoring means external behavior remains unchanged:
-- Public product behavior stays the same.
-- User-visible outcomes stay the same.
-- Public contracts stay stable unless the user explicitly confirms a compatibility-preserving migration.
-- Tests and behavior checks are used to prove the change is structural.
+- Public product behavior and user-visible outcomes stay the same.
+- Public contracts remain stable unless the user confirms a compatibility-preserving migration.
+- Tests and behavior checks prove the change is structural.
 
-If the request requires changed product behavior, new user-facing functionality, or a breaking public API change, route to `feature-workflow`. Internal API, import path, or module boundary changes can still be refactoring when external behavior remains unchanged and the planner can define a safe migration strategy.
+Changed product behavior, new user-facing functionality, or a breaking public API routes to `feature-workflow`. Internal API/import/module changes can remain refactoring when external behavior is preserved and the planner can define a safe migration.
 
 ## When to Use
 
-Use this workflow when the user wants a guided refactoring entry point:
-- Clean up or restructure existing code.
-- Extract modules, helpers, middleware, or shared logic.
-- Decouple modules or simplify structure.
-- Plan or execute behavior-preserving migrations.
-- Decide whether a refactor is small enough for current-session Fast Path or should use the refactor pipeline.
-- Continue from an existing `.prizmkit/plans/refactor-list.json`.
+Use this workflow to:
+- Classify cleanup, restructuring, extraction, decoupling, simplification, or migration intent.
+- Decide whether one confirmed refactor should use the independent Direct Path or planned runtime execution.
+- Plan batch/cross-module behavior-preserving work.
+- Continue from `.prizmkit/plans/refactor-list.json`.
 
 Do not use this workflow when the user only wants:
-- Refactor planning without execution intent -> use `refactor-planner`.
-- Launch/status/logs/retry for an existing refactor list -> use `refactor-pipeline-launcher`.
-- New functionality or changed product behavior -> use `feature-workflow`.
-- Bug repair -> use `bug-fix-workflow` or the bug pipeline skills.
+- The direct single-requirement lifecycle -> enter it independently.
+- Refactor planning without execution intent -> `refactor-planner`.
+- Runtime command construction for an existing refactor list -> `refactor-pipeline-launcher`.
+- New functionality or changed product behavior -> `feature-workflow`.
+- Bug repair -> `bug-fix-workflow` or bug planning skills.
 
 ## Route Overview
 
 | User situation | Route |
 |---|---|
-| Simple local behavior-preserving refactor | Fast Path in current workspace |
-| Batch, cross-module, high-risk, weak-test, or multi-step refactor | `refactor-planner` -> return here -> `refactor-pipeline-launcher` |
-| Product behavior change or breaking public API change | Route to `feature-workflow` |
-| User explicitly says to run an existing refactor list | `refactor-pipeline-launcher` |
-| Refactor list exists but the user did not explicitly ask to run it | Ask launch / inspect / update |
+| One confirmed local behavior-preserving requirement | Explain independent Direct Path and end this router |
+| Batch, cross-module, weak-test, or ordered migration | `refactor-planner` -> return here -> `refactor-pipeline-launcher` |
+| Product behavior change or breaking public API | `feature-workflow` |
+| Explicit request for an existing refactor-list command | `refactor-pipeline-launcher` |
+| Auto-discovered refactor list | Ask construct command / inspect / update |
 
 ## Route Selection
 
-### Step 1: Detect the entry mode
-
-Classify the request before asking detailed refactoring questions:
-
-- **Behavior-preserving refactor**: the user asks to clean up, restructure, simplify, extract, decouple, or migrate implementation structure.
-- **Behavior change**: the user asks to change what the product does, add functionality, or break a public contract.
-- **Existing list launch**: the user explicitly asks to run, start, resume, check, retry, or stop `.prizmkit/plans/refactor-list.json`.
-- **Unclear**: the request mixes cleanup with behavior changes.
+### Step 1: Detect entry mode
 
-If behavior preservation is unclear, ask one concise clarification question before route selection.
+Classify the request as behavior-preserving refactor, confirmed behavior change, suspected behavior change, existing-list command, or unclear. If preservation is unclear, ask one concise question.
 
-### Step 2: Lightweight triage for behavior-preserving work
+### Step 2: Lightweight triage
 
-Use lightweight criteria only. Do not perform full code analysis or item decomposition here.
+A Direct Path candidate is one localized, confirmed behavior-preserving requirement with obvious checks and no dependency ordering. This classification only tells the user to leave this router for the independent direct entry.
 
-Fast Path candidate when all are true:
-- One focused refactor or a small tightly related cleanup.
-- Expected work is localized and follows existing patterns.
-- Behavior-preservation checks are obvious or already available.
-- No broad dependency ordering, public behavior change, or risky migration is needed.
-
-Pipeline Path candidate when any are true:
-- Multiple refactor items or batch refactoring request.
+A Pipeline Path candidate has one or more of these signals:
+- Multiple items or batch refactoring.
 - Cross-module or multi-layer impact.
-- Import-path, internal API, or module-boundary migration needs ordering.
-- Weak test coverage creates behavior-preservation risk.
-- The user wants autonomous/background execution.
-- The request needs `refactor-planner` to analyze code, split items, validate ordering, and review entries.
+- Import-path, internal API, or module-boundary migration ordering.
+- Weak test coverage or non-trivial behavior-preservation risk.
+- Autonomous/background execution intent.
+- A need for planner-owned analysis, decomposition, validation, and review.
+
+Do not perform deep code analysis here.
 
 ### Step 3: Ask for path selection
 
-Use `AskUserQuestion`; do not render path options as plain text.
+Use `AskUserQuestion`; do not render options as plain text.
 
 ```text
 Question: How would you like to proceed?
 Header: Approach
 Options:
-- Refactor now (Fast Path) — current session/current workspace via /prizmkit-plan -> /prizmkit-implement with behavior checks
-- Use Pipeline Path — refactor-planner creates/reviews refactor-list.json, then refactor-pipeline-launcher configures execution
-- Continue clarifying — ask a few more route-level questions before choosing
-```
-
-If the request appears to change product behavior:
-
-```text
-Question: This appears to change behavior rather than only restructure code. What should we do?
-Header: Boundary
-Options:
-- Route to feature-workflow (Recommended) — treat behavior change as feature work
-- Keep as refactor — only if behavior remains externally unchanged or this is a compatibility-preserving migration
-- Continue clarifying — define which behavior must stay unchanged
+- Use Direct Path — leave this router and invoke the direct single-requirement workflow independently
+- Use Pipeline Path — refactor-planner creates/reviews refactor-list.json, then refactor-pipeline-launcher constructs the runtime command
+- Continue clarifying — ask more route-level questions
 ```
 
-For an auto-discovered existing refactor list:
+If behavior change is confirmed, route to `feature-workflow` and stop refactor routing. If behavior change is only suspected, offer `Route to feature-workflow (Recommended)`, `Confirm behavior-preserving constraints`, or `Continue clarifying`.
 
-```text
-Question: Existing refactor-list.json found. What should we do with it?
-Header: Refactor list
-Options:
-- Launch existing list — hand off to refactor-pipeline-launcher
-- Inspect summary first — show refactor count/status, then ask again
-- Update/re-plan — hand off to refactor-planner in incremental mode
-- Ignore and start fresh — continue route selection from the new request
-```
-
-If the user explicitly asked to run an existing list, that explicit request counts as path selection; hand off directly to `refactor-pipeline-launcher`.
+For an auto-discovered list, offer construct command, inspect summary, update/re-plan, or ignore and plan the new request. Explicit command intent counts as path selection.
 
 ## Workflow Handoff Brief
 
-When handing off, include this prompt brief in the next skill invocation. Do not write the brief to disk.
+When handing off to a planner, launcher, or feature router, include this prompt brief. Do not write it to disk.
 
 ```markdown
-## Workflow Handoff Brief
-
 ### Source
 - workflow: refactor-workflow
-- selected_path: fast_path | pipeline_path | existing_list_launch | behavior_change_reroute
+- selected_path: pipeline_path | existing_list_command | behavior_change_reroute
 
 ### User Goal
 - original_request: <preserve the user's wording>
-- normalized_goal: <lightly normalized refactoring goal>
+- normalized_goal: <lightly normalized restructuring goal>
 
 ### Scope
 - included: <explicitly in scope>
 - excluded: <explicitly out of scope or unknown>
 
 ### Behavior Preservation
-- must_remain_unchanged: <public behavior, user-visible outcomes, APIs, workflows, tests>
+- must_remain_unchanged: <public behavior, outcomes, APIs, workflows, tests>
 - suspected_behavior_changes: <items that may need feature-workflow>
 
 ### Materials
-- provided_paths: <paths/directories supplied by the user>
-- provided_docs_or_urls: <docs, links, screenshots, or specs supplied by the user>
-- notes: <rules, constraints, or emphasis from the user>
+- provided_paths: <paths/directories>
+- provided_docs_or_urls: <docs, links, screenshots, specs>
+- notes: <constraints or emphasis>
 
 ### Decision
-- route_reason: <why this path was selected>
+- route_reason: <why selected>
 - user_confirmed: yes
 
 ### Next Skill Instruction
-- For planner: Use this brief as input; perform your own required code analysis, behavior-preservation planning, validation, generation, and review gate.
-- For Fast Path: Use this brief to create spec.md/plan.md and implement only this behavior-preserving scope.
+- Planner: own code analysis for planning, preservation strategy, validation, generation, and planner-local review; return the validated list without performing the refactor.
+- Launcher: own runtime configuration and command construction; do not re-plan, implement, or execute the command.
 ```
 
-## Selected Path Execution
+The direct path has no planner/launcher handoff. Preserve original intent and behavior constraints in the exit guidance.
 
-### Fast Path
+## Selected Path Execution
 
-Use Fast Path only after explicit user selection.
+### Direct Path guidance
 
-1. Invoke `/prizmkit-plan` with the handoff brief and behavior-preservation expectations.
-2. Invoke `/prizmkit-implement` after the plan is ready.
-3. Run behavior-preservation checks identified in the plan.
-4. Run `/prizmkit-test` only when risk triggers match: public contracts, data models, migration behavior, weak behavior-preservation evidence, or explicit user verification request.
-5. Run `/prizmkit-code-review` when the user requested review, behavior-preservation uncertainty is high, or Full-path-level risk appears during implementation.
-6. Run `/prizmkit-retrospective` only when structure, interfaces, dependencies, behavior, or durable project knowledge changed.
-7. Run `/prizmkit-committer` with a `refactor(<scope>):` message.
-8. End the workflow after commit; do not call `refactor-planner`, `refactor-pipeline-launcher`, or monitoring.
+1. Confirm one formal behavior-preserving requirement.
+2. Explain the independent direct topology in §Execution Topology.
+3. Preserve requirement and behavior constraints in one concise next-entry instruction.
+4. End `refactor-workflow`. Do not start coding, invoke lifecycle skills, monitor the direct workflow, or reclaim control after it starts.
 
-If the refactor starts changing behavior or grows beyond Fast Path criteria, pause and ask whether to switch to `feature-workflow` or Pipeline Path.
+If scope grows or behavior changes, remain in this router and offer Pipeline Path or `feature-workflow`.
 
 ### Pipeline Path
 
 1. Invoke `refactor-planner` with the handoff brief.
-2. `refactor-planner` performs code analysis, item decomposition, behavior-preservation planning, validation, and plan review.
-3. After `refactor-planner` reports a validated `.prizmkit/plans/refactor-list.json`, show a concise summary: item count, ordering highlights, preservation strategy summary, and review/validation outcome.
-4. Ask whether to proceed to launch.
+2. The planner owns code analysis, decomposition, preservation strategy, validation, and review.
+3. After a validated `.prizmkit/plans/refactor-list.json` returns, show item count, ordering, preservation strategy, and review/validation outcome.
+4. Ask whether to construct the runtime command.
 5. If yes, invoke `refactor-pipeline-launcher`.
 
-Do not duplicate launcher execution-mode, strict-behavior-check, or runtime configuration questions in this workflow; the launcher owns them.
+Do not duplicate strict-behavior-check or runtime configuration questions.
 
-### Existing list launch
+### Existing list command
 
-If the user explicitly requested launch/status/logs/retry/stop for an existing refactor list, invoke `refactor-pipeline-launcher` with the user's intent and list path.
-
-If this workflow discovered the list on its own, use the `Existing refactor-list.json found` question in §Route Selection before invoking the launcher.
+Route explicit run/status/logs/retry/stop command requests to `refactor-pipeline-launcher`. Ask construct command / inspect / update when the list was only auto-discovered.
 
 ## Resume Guidance
 
 | State found | Action |
 |---|---|
-| Fast Path `spec.md` / `plan.md` exists | Ask whether to continue current-workspace refactor or re-plan |
-| Valid `.prizmkit/plans/refactor-list.json` exists and user wants execution | Invoke `refactor-pipeline-launcher` |
-| Valid refactor list exists but intent is unclear | Ask launch / inspect / update |
-| No plan/list artifacts | Start route selection |
-
-For interrupted autonomous pipeline sessions, prefer `refactor-pipeline-launcher` status/retry operations or `recovery-workflow` when the user explicitly asks to recover a broken AI session.
-
-## Runtime Status Reference
-
-This workflow does not assemble runtime commands, but it may show lightweight status before handoff or recovery. Use the canonical Python runtime forms:
-
-```bash
-python3 ./.prizmkit/dev-pipeline/cli.py daemon refactor status
-python3 ./.prizmkit/dev-pipeline/cli.py refactor status .prizmkit/plans/refactor-list.json
-```
-
-For start/stop/logs/retry execution, hand off to `refactor-pipeline-launcher`; do not duplicate launcher configuration here.
+| Direct workflow state exists | Exit this router and tell the user to resume its recorded requirement workflow |
+| Valid refactor list with command intent | Invoke `refactor-pipeline-launcher` |
+| Valid refactor list with planning intent | Invoke `refactor-planner` |
+| Interrupted refactor task branch exists | Route to `recovery-workflow` for the exact continuation command |
+| No artifacts | Start behavior classification and route selection |
 
 ## Error Handling
 
 | Situation | Action |
 |---|---|
-| Behavior change is required | Route to `feature-workflow` unless user confirms a behavior-preserving migration |
-| User wants planning only | Route to `refactor-planner` and stop after planner summary |
-| User wants execution only | Route to `refactor-pipeline-launcher` |
-| No behavior checks exist | Warn user; recommend Pipeline Path unless scope is very small |
-| Fast Path reveals broader risk | Pause and ask whether to switch to Pipeline Path |
-| Planner needs more detail | Let `refactor-planner` ask its own clarification questions |
-| Launcher finds baseline/config issues | Let `refactor-pipeline-launcher` handle confirmation and configuration |
+| Product behavior change is confirmed | Route to `feature-workflow` and stop refactor routing |
+| Planning only | Route to `refactor-planner` and stop after its summary |
+| Existing-list command requested | Route to `refactor-pipeline-launcher` |
+| No obvious behavior checks | Recommend Pipeline Path unless scope is clearly local |
+| Direct candidate reveals broader risk | Keep control here and offer Pipeline Path |
+| Planner needs detail | Let `refactor-planner` ask its own questions |
+| Launcher finds configuration issues | Let `refactor-pipeline-launcher` own them |
 
 ## Handoff Map
 
 | From | To | Condition |
 |---|---|---|
 | `refactor-workflow` | `feature-workflow` | Request requires product behavior change |
-| `refactor-workflow` | `/prizmkit-plan` | User selects Fast Path |
 | `refactor-workflow` | `refactor-planner` | User selects Pipeline Path |
-| `refactor-planner` | `refactor-workflow` | Planner completed from workflow-origin Pipeline Path |
-| `refactor-workflow` | `refactor-pipeline-launcher` | User confirms launch after planner completion or explicitly requests existing-list execution |
+| `refactor-planner` | `refactor-workflow` | Planning completed from this workflow's Pipeline Path |
+| `refactor-workflow` | `refactor-pipeline-launcher` | User requests command construction or an existing-list operation |
 
 ## Output
 
-- Fast Path: `spec.md`, `plan.md`, behavior-preserving code changes, behavior-check evidence, conditional test/review evidence when triggered, Prizm docs sync only when durable knowledge changed, and one refactor commit.
-- Pipeline Path: handoff brief, validated `.prizmkit/plans/refactor-list.json` from `refactor-planner`, and pipeline launch/status handled by `refactor-pipeline-launcher`.
+- Direct guidance: behavior-preservation summary, independent direct-entry topology, and preserved requirement text; no code change or implementation result.
+- Pipeline Path: handoff brief, validated `.prizmkit/plans/refactor-list.json`, and a command returned by `refactor-pipeline-launcher`.

package/bundled/templates/project-memory-template.md

@@ -32,12 +32,12 @@ This project uses PrizmKit with the Prizm documentation system for AI-optimized
 ### Available Commands
 Run `/prizmkit` to see all available PrizmKit commands.
 
-### Fast Path for Simple Changes
-Not every change needs the full spec -> plan workflow. Use fast path for:
+### Lightweight Planning Path
+Not every change needs the full formal-requirement lifecycle. Use the lightweight path for:
 - Bug fixes with clear root cause, config tweaks, typo fixes, simple refactors
 - Documentation-only changes, test additions for existing code
-- Fast path: `/prizmkit-plan` (simplified) → `/prizmkit-implement` → `/prizmkit-committer`
+- Lightweight path: `/prizmkit-plan` (simplified) → `/prizmkit-implement` → `/prizmkit-committer`
 
-Use the full workflow (/prizmkit-plan -> /prizmkit-implement) for:
+Use the full formal lifecycle (`/prizmkit-plan` → `/prizmkit-implement` → `/prizmkit-code-review` → `/prizmkit-test` → `/prizmkit-retrospective` → `/prizmkit-committer`) for:
 - New features, multi-file coordinated changes, architectural decisions, data model or API changes
 <!-- PRIZMKIT:END -->

package/package.json

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

package/src/index.js

@@ -133,6 +133,10 @@ export async function runScaffold(directory, options) {
           name: `Minimal — 最小可用 (${metadata.suites.minimal.skills.length} 个技能)`,
           value: 'minimal',
         },
+        ...(metadata.suites.recommended ? [{
+          name: `Recommended — 推荐工作流 (${metadata.suites.recommended.skills.length} 个技能)`,
+          value: 'recommended',
+        }] : []),
       ],
       default: 'core',
     });

package/src/prompts.js

@@ -171,10 +171,10 @@ export async function selectAiCliLaunch(currentCommand, detected = {}, currentLa
 }
 
 /**
- * Select skill suite (core, minimal, or recommended:<type>).
+ * Select skill suite (core, minimal, recommended, or recommended:<type>).
  * @param {string} currentSuite - current suite value
  * @param {Object} metadata - skill metadata with suites definitions
- * @returns {Promise<string>} - 'core', 'minimal', or 'recommended:type'
+ * @returns {Promise<string>} - 'core', 'minimal', 'recommended', or 'recommended:type'
  */
 export async function selectSkillSuite(currentSuite, metadata) {
   const choices = [
@@ -188,7 +188,14 @@ export async function selectSkillSuite(currentSuite, metadata) {
     },
   ];
 
-  // Add recommended options if available
+  if (metadata.suites.recommended) {
+    choices.push({
+      name: `Recommended — 推荐工作流 (${metadata.suites.recommended.skills.length} 个技能)`,
+      value: 'recommended',
+    });
+  }
+
+  // Add recommended project variants if available
   if (metadata.recommendations) {
     for (const [type, rec] of Object.entries(metadata.recommendations)) {
       const baseSkills = rec.base === '*'

package/src/scaffold.js

@@ -182,7 +182,7 @@ async function loadSharedFrontmatter() {
 export async function resolveSkillList(suite) {
   const metadata = await loadMetadata();
 
-  // 处理 recommended:<type> 格式
+  // Handle recommended:<type> by inheriting the declared recommended base.
   if (suite && suite.startsWith('recommended:')) {
     const projectType = suite.split(':')[1];
     const rec = metadata.recommendations?.[projectType];