prjct-cli 0.10.9 → 0.10.11

package/templates/analysis/bug-severity.md

@@ -0,0 +1,74 @@
+---
+name: bug-severity
+description: Assess bug severity from description
+allowed-tools: [Read]
+---
+
+# Bug Severity Assessment
+
+Analyze the bug description to determine its severity and priority.
+
+## Input
+- Bug: {{description}}
+- Context (if available)
+
+## Severity Levels
+
+### CRITICAL
+- System crash or data loss
+- Security vulnerability
+- Blocks all users
+- Production is down
+
+### HIGH
+- Major feature broken
+- Significant user impact
+- Workaround difficult
+- Affects many users
+
+### MEDIUM
+- Feature partially broken
+- Workaround exists
+- Limited user impact
+- Non-essential functionality
+
+### LOW
+- Minor inconvenience
+- Cosmetic issue
+- Edge case only
+- Easy workaround
+
+## Analysis Steps
+
+1. **Assess Impact**
+   - Who is affected?
+   - How many users?
+   - Is there data loss risk?
+
+2. **Check Urgency**
+   - Is production affected?
+   - Is there a deadline?
+   - Are users blocked?
+
+3. **Evaluate Workaround**
+   - Can users continue working?
+   - How hard is the workaround?
+
+## Output Format
+
+Return JSON:
+```json
+{
+  "severity": "critical|high|medium|low",
+  "priority": 1-4,
+  "reasoning": "<brief explanation>",
+  "suggestedAction": "<what to do next>"
+}
+```
+
+## Guidelines
+
+- Err on the side of higher severity if unsure
+- Security issues are always CRITICAL
+- Data loss is always CRITICAL
+- User-reported = add weight

package/templates/analysis/complexity.md

@@ -0,0 +1,54 @@
+---
+name: complexity-analysis
+description: Analyze task complexity semantically
+allowed-tools: [Read]
+---
+
+# Task Complexity Analysis
+
+Analyze the given task description and determine its complexity level.
+
+## Input
+- Task: {{task}}
+- Project context (if available)
+
+## Analysis Steps
+
+1. **Understand the Task**
+   - What is being asked?
+   - What systems/files are affected?
+   - Are there dependencies?
+
+2. **Evaluate Scope**
+   - Single file change → LOW
+   - Multiple files, same module → MEDIUM
+   - Cross-module or architectural → HIGH
+
+3. **Assess Risk**
+   - Read-only or additive → LOW risk
+   - Modifying existing logic → MEDIUM risk
+   - Refactoring or migration → HIGH risk
+
+4. **Consider Dependencies**
+   - No external deps → LOW
+   - Some integration → MEDIUM
+   - Multiple systems → HIGH
+
+## Output Format
+
+Return JSON:
+```json
+{
+  "complexity": "low|medium|high",
+  "type": "feature|bugfix|refactor|testing|docs|chore",
+  "estimatedHours": <number>,
+  "reasoning": "<brief explanation>"
+}
+```
+
+## Guidelines
+
+- Be realistic, not optimistic
+- Consider testing time in estimates
+- If unsure, lean toward higher complexity
+- Don't use keyword matching - analyze semantically

package/templates/analysis/health.md

@@ -0,0 +1,66 @@
+---
+name: health-score
+description: Calculate project health score
+allowed-tools: [Read]
+---
+
+# Project Health Score
+
+Evaluate the project's health based on activity metrics.
+
+## Input
+- Active task: {{hasActiveTask}}
+- Queue size: {{queueSize}}
+- Recent ships: {{recentShips}}
+- Ideas count: {{ideasCount}}
+- Days since last ship: {{daysSinceShip}}
+
+## Health Factors
+
+### Momentum (40%)
+- Active task = good
+- Regular shipping = good
+- Long gaps = concerning
+
+### Focus (30%)
+- Queue < 10 = focused
+- Queue 10-20 = busy
+- Queue > 20 = overloaded
+
+### Progress (20%)
+- Ships this week > 0 = active
+- Ships this month > 2 = productive
+- No ships in 7+ days = stalled
+
+### Planning (10%)
+- Ideas captured = thinking ahead
+- Too many ideas = unfocused
+
+## Score Calculation
+
+Evaluate each factor and combine:
+
+| Score | Label | Meaning |
+|-------|-------|---------|
+| 80-100 | Excellent | High momentum, focused, shipping |
+| 60-79 | Good | Active, some room to improve |
+| 40-59 | Fair | Slowing down, needs attention |
+| 0-39 | Low | Stalled, intervention needed |
+
+## Output Format
+
+Return JSON:
+```json
+{
+  "score": <0-100>,
+  "label": "Excellent|Good|Fair|Low",
+  "momentum": "<assessment>",
+  "suggestions": ["<action 1>", "<action 2>"]
+}
+```
+
+## Guidelines
+
+- Be encouraging but honest
+- Suggest specific actions
+- Focus on momentum, not perfection

package/templates/analysis/intent.md

@@ -0,0 +1,66 @@
+---
+name: intent-detection
+description: Detect user intent from natural language
+allowed-tools: []
+---
+
+# Intent Detection
+
+Analyze user input to determine their intent and map to appropriate action.
+
+## Input
+- User message: {{message}}
+
+## Intent Categories
+
+### Work Intents
+- **start_task**: User wants to begin working on something
+- **complete_task**: User finished current work
+- **ship**: User wants to release/deploy
+- **pause**: User needs to pause current work
+
+### Planning Intents
+- **add_feature**: User has a new feature idea
+- **add_idea**: Quick thought to capture
+- **add_bug**: Report a problem
+- **view_queue**: See what's next
+
+### Status Intents
+- **check_progress**: View metrics/status
+- **get_recap**: Project overview
+- **get_help**: Need guidance
+
+### System Intents
+- **sync**: Update project state
+- **analyze**: Analyze codebase
+- **cleanup**: Clean up files
+
+## Analysis
+
+Look for semantic meaning, not keywords:
+- "I'm done" → complete_task
+- "Let's ship this" → ship
+- "Quick thought..." → add_idea
+- "What should I do?" → get_help OR view_queue
+
+## Output Format
+
+Return JSON:
+```json
+{
+  "intent": "<intent_name>",
+  "confidence": <0.0-1.0>,
+  "parameters": {
+    "task": "<extracted task if any>",
+    "feature": "<extracted feature if any>"
+  },
+  "suggestedCommand": "/p:<command>"
+}
+```
+
+## Guidelines
+
+- Use semantic understanding, not regex
+- Extract relevant parameters
+- High confidence (>0.8) for clear intents
+- Ask for clarification if < 0.5

package/templates/analysis/patterns.md

@@ -1,142 +1,29 @@
 ---
 allowed-tools: [Read, Glob, Grep]
-description: 'Analyze code patterns, conventions, and anti-patterns'
+description: 'Analyze code patterns and conventions'
 ---
 
 # Code Pattern Analysis
 
-## Objective
+## Detection Steps
 
-Detect code patterns, conventions, and anti-patterns to ensure ALL new code respects the project's established practices.
+1. **Structure** (5-10 files): File org, exports, modules
+2. **Patterns**: SOLID, DRY, factory/singleton/observer
+3. **Conventions**: Naming, style, error handling, async
+4. **Anti-patterns**: God class, spaghetti, copy-paste, magic numbers
+5. **Performance**: Memoization, N+1 queries, leaks
 
-## Step 1: Analyze Code Structure
-
-### File Organization
-- Read 5-10 representative source files
-- Identify: single vs multiple exports per file
-- Check: file size patterns (small focused files vs large files)
-- Note: directory organization (by feature, by layer, by type)
-
-### Module Patterns
-- ES Modules vs CommonJS
-- Default exports vs named exports
-- Barrel files (index.js re-exports)
-- Circular dependency patterns
-
-## Step 2: Detect Design Patterns
-
-### SOLID Principles
-Analyze for evidence of:
-
-| Principle | Look For | Example |
-|-----------|----------|---------|
-| **S**ingle Responsibility | Small, focused files/functions | `validateUser()` not `validateAndSaveUser()` |
-| **O**pen/Closed | Extension points, plugins | Base classes, strategy pattern |
-| **L**iskov Substitution | Interface consistency | Subclasses behave like parents |
-| **I**nterface Segregation | Small, specific interfaces | Multiple small interfaces vs one large |
-| **D**ependency Inversion | Dependency injection | Constructor injection, factories |
-
-### DRY (Don't Repeat Yourself)
-- Check for utility/helper directories
-- Look for shared constants
-- Identify reusable components/functions
-- Note any obvious duplication
-
-### Other Patterns
-- Factory pattern (createX functions)
-- Singleton pattern (shared instances)
-- Observer pattern (event emitters)
-- Repository pattern (data access layer)
-- Strategy pattern (interchangeable algorithms)
-
-## Step 3: Identify Conventions
-
-### Naming Conventions
-```
-Analyze actual code for:
-- Functions: camelCase, snake_case, PascalCase?
-- Classes: PascalCase?
-- Constants: UPPER_SNAKE_CASE?
-- Files: kebab-case, camelCase, PascalCase?
-- Private members: _prefix, #private?
-```
-
-### Code Style
-- Semicolons: yes/no
-- Quotes: single/double
-- Indentation: tabs/spaces (2/4)
-- Trailing commas: yes/no
-- Max line length observed
-
-### Error Handling
-- Try-catch patterns
-- Custom error classes
-- Error propagation (throw vs return)
-- Logging patterns
-
-### Async Patterns
-- async/await vs Promises vs callbacks
-- Error handling in async code
-- Parallel execution patterns
-
-## Step 4: Detect Anti-Patterns
-
-### Code Smells (Flag These)
-
-| Anti-Pattern | Detection | Severity |
-|--------------|-----------|----------|
-| **God Class/File** | File > 300 lines, too many responsibilities | HIGH |
-| **Spaghetti Code** | Deep nesting > 4 levels, unclear flow | HIGH |
-| **Copy-Paste Code** | Duplicate blocks across files | MEDIUM |
-| **Magic Numbers** | Hardcoded values without constants | MEDIUM |
-| **Long Functions** | Function > 50 lines | MEDIUM |
-| **Too Many Parameters** | Function with > 4 params | LOW |
-| **Dead Code** | Commented out code, unused exports | LOW |
-| **Mixed Concerns** | I/O mixed with business logic | MEDIUM |
-| **Callback Hell** | Nested callbacks > 3 levels | HIGH |
-| **Mutable Global State** | Global variables modified everywhere | HIGH |
-
-### Architecture Smells
-
-| Anti-Pattern | Detection | Recommendation |
-|--------------|-----------|----------------|
-| **Circular Dependencies** | A imports B, B imports A | Extract shared module |
-| **Feature Envy** | Function uses other module's data excessively | Move function to that module |
-| **Inappropriate Intimacy** | Classes know too much about each other | Use interfaces/abstractions |
-| **Lazy Class** | Class does almost nothing | Merge with related class |
-| **Speculative Generality** | Unused abstractions "for future" | Remove until needed |
-
-## Step 5: Performance Patterns
-
-### Good Patterns to Note
-- Memoization usage
-- Lazy loading
-- Caching strategies
-- Batch operations
-- Connection pooling
-
-### Performance Anti-Patterns
-- N+1 queries
-- Synchronous I/O in loops
-- Memory leaks (unclosed resources)
-- Unbounded data structures
-
-## Output Format
-
-Generate `analysis/patterns.md` with:
+## Output: analysis/patterns.md
 
 ```markdown
-# Code Patterns - {Project Name}
+# Code Patterns - {Project}
 
-> Auto-generated by /p:sync
-> Last analyzed: {timestamp}
+> Generated: {GetTimestamp()}
 
-## Design Patterns Detected
+## Patterns Detected
+- **{Pattern}**: {Where} - {Example}
 
-### Applied Patterns ✅
-- **{Pattern}**: {Where used} - {Example}
-
-### SOLID Compliance
+## SOLID Compliance
 | Principle | Status | Evidence |
 |-----------|--------|----------|
 | Single Responsibility | ✅/⚠️/❌ | {evidence} |
@@ -146,61 +33,28 @@ Generate `analysis/patterns.md` with:
 | Dependency Inversion | ✅/⚠️/❌ | {evidence} |
 
 ## Conventions (MUST FOLLOW)
-
-### Naming
-- Functions: {convention}
-- Classes: {convention}
-- Files: {convention}
-- Constants: {convention}
-
-### Style
-- Semicolons: {yes/no}
+- Functions: {camelCase/snake_case}
+- Classes: {PascalCase}
+- Files: {kebab-case/camelCase}
 - Quotes: {single/double}
-- Async: {async-await/promises/callbacks}
-
-### Structure
-- Exports: {single/multiple per file}
-- Max file size: {observed max}
-- Directory organization: {pattern}
+- Async: {async-await/promises}
 
-## Anti-Patterns Found ⚠️
+## Anti-Patterns ⚠️
 
 ### High Priority
-1. **{Anti-pattern}**: {file:line}
-   - Problem: {description}
-   - Fix: {recommendation}
+1. **{Issue}**: {file:line} - Fix: {action}
 
 ### Medium Priority
-1. **{Anti-pattern}**: {file:line}
-   - Problem: {description}
-   - Fix: {recommendation}
+1. **{Issue}**: {file:line} - Fix: {action}
 
 ## Recommendations
-
-### Immediate Actions
-1. {Action with specific file/location}
-
-### Best Practices for New Code
-1. {Practice based on detected patterns}
-2. {Practice based on conventions}
-3. {Practice to avoid anti-patterns}
-
----
-
-**IMPORTANT**: All new code MUST follow these patterns and conventions.
+1. {Immediate action}
+2. {Best practice}
 ```
 
-## Integration Rules
-
-When generating new code, Claude MUST:
-
-1. **Check patterns.md FIRST** before writing any code
-2. **Match naming conventions** exactly as detected
-3. **Follow file structure** patterns (size, organization)
-4. **Apply detected design patterns** where appropriate
-5. **NEVER introduce anti-patterns** listed in the analysis
-6. **Warn if asked to violate** established patterns
-
----
+## Rules
 
-**Remember**: Quality > Speed. Anti-patterns create technical debt.
+1. Check patterns.md FIRST before writing code
+2. Match conventions exactly
+3. NEVER introduce anti-patterns
+4. Warn if asked to violate patterns

package/templates/analysis/task-breakdown.md

@@ -0,0 +1,53 @@
+---
+name: task-breakdown
+description: Break down a feature into actionable tasks
+allowed-tools: [Read, Glob, Grep]
+---
+
+# Feature Task Breakdown
+
+Analyze the feature description and break it into concrete, actionable tasks.
+
+## Input
+- Feature: {{feature}}
+- Project path: {{projectPath}}
+
+## Analysis Steps
+
+1. **Understand the Feature**
+   - Read related code if paths are obvious
+   - Identify affected systems
+   - Note existing patterns to follow
+
+2. **Identify Components**
+   - What new files/modules are needed?
+   - What existing code needs modification?
+   - What tests are required?
+
+3. **Order by Dependencies**
+   - Foundation tasks first (models, types, interfaces)
+   - Core logic second
+   - Integration third
+   - Tests and polish last
+
+4. **Size Each Task**
+   - Each task should be 20-60 minutes
+   - If larger, break down further
+   - If smaller, combine with related task
+
+## Output Format
+
+Return a numbered task list:
+```
+1. [20m] Task description - specific action
+2. [30m] Another task - what exactly to do
+3. [45m] Final task - clear deliverable
+```
+
+## Guidelines
+
+- Tasks must be specific and actionable
+- Include time estimates in brackets
+- Order matters - dependencies first
+- Don't assume - if unsure, read code first
+- Match project patterns (read existing code)

package/templates/architect/discovery.md

@@ -0,0 +1,67 @@
+---
+name: architect-discovery
+description: Discovery phase for architecture generation
+allowed-tools: [Read, AskUserQuestion]
+---
+
+# Discovery Phase
+
+Conduct discovery for the given idea to understand requirements and constraints.
+
+## Input
+- Idea: {{idea}}
+- Context: {{context}}
+
+## Discovery Steps
+
+1. **Understand the Problem**
+   - What problem does this solve?
+   - Who experiences this problem?
+   - How critical is it?
+
+2. **Identify Target Users**
+   - Who are the primary users?
+   - What are their goals?
+   - What's their technical level?
+
+3. **Define Constraints**
+   - Budget limitations?
+   - Timeline requirements?
+   - Team size?
+   - Regulatory needs?
+
+4. **Set Success Metrics**
+   - How will we measure success?
+   - What's the MVP threshold?
+   - Key performance indicators?
+
+## Output Format
+
+Return structured discovery:
+```json
+{
+  "problem": {
+    "statement": "...",
+    "painPoints": ["..."],
+    "impact": "high|medium|low"
+  },
+  "users": {
+    "primary": { "persona": "...", "goals": ["..."] },
+    "secondary": [...]
+  },
+  "constraints": {
+    "budget": "...",
+    "timeline": "...",
+    "teamSize": 1
+  },
+  "successMetrics": {
+    "primary": "...",
+    "mvpThreshold": "..."
+  }
+}
+```
+
+## Guidelines
+- Ask clarifying questions if needed
+- Be realistic about constraints
+- Focus on MVP scope

package/templates/architect/phases.md

@@ -0,0 +1,59 @@
+---
+name: architect-phases
+description: Determine which architecture phases are needed
+allowed-tools: [Read]
+---
+
+# Architecture Phase Selection
+
+Analyze the idea and context to determine which phases are needed.
+
+## Input
+- Idea: {{idea}}
+- Discovery results: {{discovery}}
+
+## Available Phases
+
+1. **discovery** - Problem definition, users, constraints
+2. **user-flows** - User journeys and interactions
+3. **domain-modeling** - Entities and relationships
+4. **api-design** - API contracts and endpoints
+5. **architecture** - System components and patterns
+6. **data-design** - Database schema and storage
+7. **tech-stack** - Technology choices
+8. **roadmap** - Implementation plan
+
+## Phase Selection Rules
+
+**Always include**:
+- discovery (foundation)
+- roadmap (execution plan)
+
+**Include if building**:
+- user-flows: Has UI/UX
+- domain-modeling: Has data entities
+- api-design: Has backend API
+- architecture: Complex system
+- data-design: Needs database
+- tech-stack: Greenfield project
+
+**Skip if**:
+- Simple script: Skip most phases
+- Frontend only: Skip api-design, data-design
+- CLI tool: Skip user-flows
+- Existing stack: Skip tech-stack
+
+## Output Format
+
+Return array of needed phases:
+```json
+{
+  "phases": ["discovery", "domain-modeling", "api-design", "roadmap"],
+  "reasoning": "Simple CRUD app needs data model and API"
+}
+```
+
+## Guidelines
+- Don't over-architect
+- Match complexity to project
+- MVP first, expand later