prizmkit 1.1.111 → 1.1.113

package/bundled/skills/feature-workflow/references/brainstorm-guide.md

@@ -1,137 +0,0 @@
-# Brainstorm Guide — Detailed Procedures
-
-Procedural details for Phase 1 brainstorming in feature-workflow.
-
-## Step 1.3: Parallel Deep Reading
-
-**Goal**: Build comprehensive understanding of the project context before discussing detailed requirements. 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 existing source files | Understand current architecture, patterns, conventions |
-| Agent B | User-provided documents — design docs, specs, PRDs | Understand intended requirements and constraints |
-| Agent C | `.prizmkit/prizm-docs/` — root.prizm, L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
-| Agent D | Database/schema files + `.prizmkit/config.json` | Understand data model and tech stack preferences |
-
-**Also gather** (can be included in any agent's task):
-- Directory structure of the project
-- Existing test patterns and conventions
-- Dependency relationships between existing modules
-
-**After all agents complete**: Synthesize findings into a coherent understanding before proceeding to discussion.
-
-## Step 1.4: Discuss Requirements
-
-**Now** — with deep knowledge of the actual codebase and documents — discuss the requirements with the user. This discussion is grounded in real context, not abstract questions.
-
-Present what you learned from the parallel reading:
-- Current project structure and patterns (with specific references)
-- Existing data model and schema conventions
-- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
-- Integration points with existing modules
-
-Then ask targeted questions based on what you read. **Adapt question depth to the feature complexity** — a simple CRUD feature needs fewer questions than a real-time collaboration system.
-
-### Functional Requirements
-- What are the core user actions/workflows?
-- What inputs does the system accept? What outputs does it produce?
-- What are the key business rules and validation logic?
-- Are there different user roles with different permissions?
-
-### Data Model & Database (if applicable)
-- What entities/data need to be stored?
-- What are the relationships between entities?
-- Are there existing database tables this feature must integrate with?
-- What fields are required vs optional? What data types?
-- Any unique constraints, indexes, or special query patterns needed?
-- **RULE**: If the project has existing database tables, ALL new table designs must reference and conform to the existing schema style (naming conventions, ID strategy, timestamp patterns, constraint patterns). Ask the user to confirm the data model before proceeding.
-
-### User Experience
-- What does the user see and interact with?
-- What is the expected flow/sequence of actions?
-- How should errors be displayed to the user?
-- Are there any specific UI/UX requirements?
-
-### Integration & Architecture
-- "Based on the existing code, this feature would integrate with [modules]. Does that match your expectations?"
-- Any external APIs or services involved?
-- What authentication/authorization model applies?
-- Any real-time requirements (WebSocket, SSE, polling)?
-
-### Edge Cases & Error Handling
-- What happens when things go wrong? (network failure, invalid input, concurrent access)
-- What are the boundary conditions? (empty states, max limits, permissions denied)
-- Any rate limiting, quotas, or resource constraints?
-
-### Non-Functional Requirements
-- Performance expectations? (response time, throughput)
-- Scalability considerations?
-- Security requirements? (encryption, audit logs, compliance)
-
-## Comparison with Alternative Workflows
-
-| Dimension | feature-workflow | bug-fix-workflow | refactor-workflow |
-|-----------|-----------------|------------------|--------------------|
-| **Purpose** | New features (batch) | Single bug fix (interactive) | Code restructuring (batch) |
-| **Brainstorming** | Yes — collect materials, parallel read, discuss | No (bug report is input) | Yes — clarify type, collect materials, parallel read, discuss |
-| **Planning Skill** | `feature-planner` | None (triage built-in) | `refactor-planner` |
-| **Branch** | Pipeline manages per-feature | `fix/<BUG_ID>-*` | Pipeline manages per-refactor |
-| **Execution** | Foreground or background daemon | In-session, interactive | Foreground or background daemon |
-| **Input** | Rough idea or requirements | Bug report / stack trace | Rough refactoring idea or target |
-| **Output** | Multiple `feat()` commits | Single `fix()` commit | Multiple `refactor()` commits |
-| **Behavior Change** | Expected (new functionality) | Fix behavior | Forbidden (structure only) |
-| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | (this is the batch flow) |
-
-## Completion Signs
-
-**Signs that brainstorming is complete:**
-- All functional requirements have concrete acceptance criteria
-- Data model entities and relationships are defined
-- Edge cases and error handling are addressed
-- Integration points are identified
-- The user has confirmed the summary is accurate
-
-**Signs that more questions are needed:**
-- User's answers contain vague terms ("handle it appropriately", "make it user-friendly", "standard behavior")
-- Core business rules are undefined ("depends on the situation")
-- Data relationships are unclear ("somehow connected")
-- User says "I'm not sure" — help them think through it with concrete options
-
-## Requirements Summary Template
-
-Once brainstorming is complete, produce a structured requirements summary using the following format. Present the summary to the user and get explicit confirmation before proceeding.
-
-```markdown
-## Requirements Summary
-
-### Project/Feature: [Name]
-
-### Core Functionality
-- [Bullet list of what the system does]
-
-### User Roles
-- [Role]: [What they can do]
-
-### Data Model Overview
-- [Entity]: [Key fields, relationships]
-
-### Key Business Rules
-- [Rule 1]
-- [Rule 2]
-
-### Integration Points
-- [External system/API/module]
-
-### Edge Cases & Error Handling
-- [Case]: [Expected behavior]
-
-### Non-Functional Requirements
-- [Requirement]
-
-### Reference Materials Reviewed
-- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
-
-### Confirmed by user: ✓
-```

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

@@ -1,116 +0,0 @@
-# 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: ✓
-```