prizmkit 1.1.79 → 1.1.80

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

@@ -139,59 +139,11 @@ Record everything the user provides — these become inputs for Step 1.3.
 
 ### Step 1.3: Parallel Deep Reading
 
-**Goal**: Build comprehensive understanding of the target code and context before discussing plans. Spawn multiple agents in parallel to read all relevant materials simultaneously.
-
-**Parallel reading tasks** (launch concurrently):
-
-| Agent | What to read | Purpose |
-|-------|-------------|---------|
-| Agent A | User-provided code paths — read full source files | Understand current structure, interfaces, dependencies |
-| Agent B | User-provided documents — design docs, proposals, wiki pages | Understand intended direction and constraints |
-| Agent C | `.prizmkit/prizm-docs/` for affected modules — L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
-| Agent D | Test files for the target area — find and read existing tests | Understand current test coverage and behavior contracts |
-
-**Also gather** (can be included in any agent's task):
-- `.prizmkit/config.json` → tech stack preferences
-- Directory structure of the target area
-- Dependency relationships (imports/exports between target and other modules)
-
-**After all agents complete**: Synthesize findings into a coherent understanding before proceeding to discussion.
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Step 1.3 for the parallel agent dispatch procedure — spawn 4 agents (A: code paths, B: documents, C: prizm-docs, D: test files) to build comprehensive understanding before discussion. Synthesize findings before proceeding.
 
 ### Step 1.4: Discuss Refactoring Plan
 
-**Now** — with deep knowledge of the actual code and documents — discuss the refactoring plan with the user. This discussion is grounded in real code, not abstract questions.
-
-Present what you learned from the parallel reading:
-- Current code structure and its problems (with specific file/function references)
-- Existing test coverage status (which areas are safe, which are risky)
-- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
-- Dependencies and potential impact on other modules
-
-Then ask targeted questions based on what you read. **Adapt question depth to the refactoring complexity** — a simple extract-method refactor needs fewer questions than a full module decomposition.
-
-**Code Structure:**
-- "I see the current structure does X — is the target state Y, or something different?"
-- What's the target state? What should the code look like after refactoring?
-- Are there specific code smells you've noticed? (duplication, deep nesting, god classes, tight coupling)
-
-**Scope:**
-- Based on the code I read, these modules are affected: [list]. Anything else in/out of scope?
-- For incremental refactoring: what's the order of priority?
-
-**Behavior Preservation:**
-- "These public APIs/interfaces exist: [list]. Which must remain unchanged?"
-- "I found these tests: [list]. Are they passing currently?"
-- Any undocumented behavior that callers depend on?
-
-**Risk Assessment:**
-- "I found these TRAPS in .prizmkit/prizm-docs/: [list]. Any other known gotchas?"
-- Does this code have external consumers (other teams, published APIs)?
-- Any concurrent development happening in the target area?
-
-**Constraints:**
-- Timeline or urgency? (affects whether to do incremental vs comprehensive)
-- Team coordination needed? (other developers working in the same area)
-- Deployment concerns? (feature flags, backward compatibility, migration)
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Step 1.4 for the full discussion framework — code structure, scope, behavior preservation, risk assessment, and constraints. Present what was learned from parallel reading, then ask targeted questions grounded in real code. **Adapt question depth to the refactoring complexity.**
 
 ### Step 1.5: Confirm and Supplement
 
@@ -202,62 +154,11 @@ After the discussion:
 3. **Identify gaps** — if any areas are still unclear, list them explicitly and ask follow-up questions
 4. **Repeat** until the user confirms: "That covers everything" or "Let's proceed"
 
-**Signs that brainstorming is complete:**
-- All refactoring goals have concrete target state descriptions
-- Scope boundaries are clearly defined (in/out)
-- Behavior preservation contracts are identified
-- Risk areas are acknowledged and mitigation is discussed
-- The user has confirmed the summary is accurate
-
-**Signs that more questions are needed:**
-- User's answers contain vague terms ("clean it up", "make it better", "fix the structure")
-- Scope is undefined ("refactor everything" without specifics)
-- No awareness of test coverage for the target area
-- Risk areas are handwaved ("it should be fine")
-- User says "I'm not sure" — help them think through it with concrete options
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Completion Signs for the full checklist of when brainstorming is complete vs when more questions are needed.
 
 ### Step 1.6: Requirements Summary
 
-Once brainstorming is complete, produce a structured goals summary:
-
-```markdown
-## Refactoring Goals Summary
-
-### Target: [Module/area name]
-
-### Refactoring Type: [Incremental / Comprehensive / Targeted]
-
-### Refactoring Objectives
-- [Bullet list of what structural changes are needed and why]
-
-### Current Problems
-- [What's wrong with the current structure — with specific code references]
-
-### Target State
-- [What the code should look like after refactoring]
-
-### Scope
-- **In scope**: [files, modules, directories]
-- **Out of scope**: [explicitly excluded areas]
-
-### Behavior Preservation Contracts
-- [What behavior must remain unchanged]
-- [Key APIs/interfaces that must be preserved]
-- [Existing test coverage status]
-
-### Risk Assessment
-- [Risk]: [Mitigation strategy]
-
-### Reference Materials Reviewed
-- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
-
-### Constraints
-- [Timeline, coordination, deployment concerns]
-
-### Confirmed by user: ✓
-```
-
-Present this summary to the user and get explicit confirmation before proceeding.
+Once brainstorming is complete, produce a structured goals summary. Read `${SKILL_DIR}/references/brainstorm-guide.md` §Refactoring Goals Summary Template for the structured output format. Present the summary to the user and get explicit confirmation before proceeding.
 
 **CHECKPOINT CP-RW-0**: Refactoring goals fully clarified and confirmed by user.
 

package/bundled/skills-windows/refactor-workflow/references/brainstorm-guide.md

@@ -0,0 +1,116 @@
+# Brainstorm Guide — Refactoring Context
+
+Procedural details for deep code analysis and discussion during refactor-workflow Phase 1.
+
+## Step 1.3: Parallel Deep Reading
+
+**Goal**: Build comprehensive understanding of the target code and context before discussing plans. Spawn multiple agents in parallel to read all relevant materials simultaneously.
+
+**Parallel reading tasks** (launch concurrently):
+
+| Agent | What to read | Purpose |
+|-------|-------------|---------|
+| Agent A | User-provided code paths — read full source files | Understand current structure, interfaces, dependencies |
+| Agent B | User-provided documents — design docs, proposals, wiki pages | Understand intended direction and constraints |
+| Agent C | `.prizmkit/prizm-docs/` for affected modules — L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
+| Agent D | Test files for the target area — find and read existing tests | Understand current test coverage and behavior contracts |
+
+**Also gather** (can be included in any agent's task):
+- `.prizmkit/config.json` → tech stack preferences
+- Directory structure of the target area
+- Dependency relationships (imports/exports between target and other modules)
+
+**After all agents complete**: Synthesize findings into a coherent understanding before proceeding to discussion.
+
+## Step 1.4: Discuss Refactoring Plan
+
+**Now** — with deep knowledge of the actual code and documents — discuss the refactoring plan with the user. This discussion is grounded in real code, not abstract questions.
+
+Present what you learned from the parallel reading:
+- Current code structure and its problems (with specific file/function references)
+- Existing test coverage status (which areas are safe, which are risky)
+- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
+- Dependencies and potential impact on other modules
+
+Then ask targeted questions based on what you read. **Adapt question depth to the refactoring complexity** — a simple extract-method refactor needs fewer questions than a full module decomposition.
+
+### Code Structure
+- "I see the current structure does X — is the target state Y, or something different?"
+- What's the target state? What should the code look like after refactoring?
+- Are there specific code smells you've noticed? (duplication, deep nesting, god classes, tight coupling)
+
+### Scope
+- Based on the code I read, these modules are affected: [list]. Anything else in/out of scope?
+- For incremental refactoring: what's the order of priority?
+
+### Behavior Preservation
+- "These public APIs/interfaces exist: [list]. Which must remain unchanged?"
+- "I found these tests: [list]. Are they passing currently?"
+- Any undocumented behavior that callers depend on?
+
+### Risk Assessment
+- "I found these TRAPS in .prizmkit/prizm-docs/: [list]. Any other known gotchas?"
+- Does this code have external consumers (other teams, published APIs)?
+- Any concurrent development happening in the target area?
+
+### Constraints
+- Timeline or urgency? (affects whether to do incremental vs comprehensive)
+- Team coordination needed? (other developers working in the same area)
+- Deployment concerns? (feature flags, backward compatibility, migration)
+
+## Completion Signs
+
+**Signs that brainstorming is complete:**
+- All refactoring goals have concrete target state descriptions
+- Scope boundaries are clearly defined (in/out)
+- Behavior preservation contracts are identified
+- Risk areas are acknowledged and mitigation is discussed
+- The user has confirmed the summary is accurate
+
+**Signs that more questions are needed:**
+- User's answers contain vague terms ("clean it up", "make it better", "fix the structure")
+- Scope is undefined ("refactor everything" without specifics)
+- No awareness of test coverage for the target area
+- Risk areas are handwaved ("it should be fine")
+- User says "I'm not sure" — help them think through it with concrete options
+
+## Refactoring Goals Summary Template
+
+Once brainstorming is complete, produce a structured goals summary using this template:
+
+```markdown
+## Refactoring Goals Summary
+
+### Target: [Module/area name]
+
+### Refactoring Type: [Incremental / Comprehensive / Targeted]
+
+### Refactoring Objectives
+- [Bullet list of what structural changes are needed and why]
+
+### Current Problems
+- [What's wrong with the current structure — with specific code references]
+
+### Target State
+- [What the code should look like after refactoring]
+
+### Scope
+- **In scope**: [files, modules, directories]
+- **Out of scope**: [explicitly excluded areas]
+
+### Behavior Preservation Contracts
+- [What behavior must remain unchanged]
+- [Key APIs/interfaces that must be preserved]
+- [Existing test coverage status]
+
+### Risk Assessment
+- [Risk]: [Mitigation strategy]
+
+### Reference Materials Reviewed
+- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
+
+### Constraints
+- [Timeline, coordination, deployment concerns]
+
+### Confirmed by user: ✓
+```

package/package.json

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