prjct-cli 0.10.10 → 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/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

package/templates/design/api.md

@@ -0,0 +1,95 @@
+---
+name: api-design
+description: Design API endpoints and contracts
+allowed-tools: [Read, Glob, Grep]
+---
+
+# API Design
+
+Design RESTful API endpoints for the given feature.
+
+## Input
+- Target: {{target}}
+- Requirements: {{requirements}}
+
+## Analysis Steps
+
+1. **Identify Resources**
+   - What entities are involved?
+   - What operations are needed?
+   - What relationships exist?
+
+2. **Review Existing APIs**
+   - Read existing route files
+   - Match naming conventions
+   - Use consistent patterns
+
+3. **Design Endpoints**
+   - RESTful resource naming
+   - Appropriate HTTP methods
+   - Request/response shapes
+
+4. **Define Validation**
+   - Input validation rules
+   - Error responses
+   - Edge cases
+
+## Output Format
+
+```markdown
+# API Design: {target}
+
+## Endpoints
+
+### GET /api/{resource}
+**Description**: List all resources
+
+**Query Parameters**:
+- `limit`: number (default: 20)
+- `offset`: number (default: 0)
+
+**Response** (200):
+```json
+{
+  "data": [...],
+  "total": 100,
+  "limit": 20,
+  "offset": 0
+}
+```
+
+### POST /api/{resource}
+**Description**: Create resource
+
+**Request Body**:
+```json
+{
+  "field": "value"
+}
+```
+
+**Response** (201):
+```json
+{
+  "id": "...",
+  "field": "value"
+}
+```
+
+**Errors**:
+- 400: Invalid input
+- 401: Unauthorized
+- 409: Conflict
+
+## Authentication
+- Method: Bearer token / API key
+- Required for: POST, PUT, DELETE
+
+## Rate Limiting
+- 100 requests/minute per user
+```
+
+## Guidelines
+- Follow REST conventions
+- Use consistent error format
+- Document all parameters

package/templates/design/architecture.md

@@ -0,0 +1,77 @@
+---
+name: architecture-design
+description: Design system architecture
+allowed-tools: [Read, Glob, Grep]
+---
+
+# Architecture Design
+
+Design the system architecture for the given requirements.
+
+## Input
+- Target: {{target}}
+- Requirements: {{requirements}}
+- Project context
+
+## Analysis Steps
+
+1. **Understand Requirements**
+   - What problem are we solving?
+   - What are the constraints?
+   - What scale do we need?
+
+2. **Review Existing Architecture**
+   - Read current codebase structure
+   - Identify existing patterns
+   - Note integration points
+
+3. **Design Components**
+   - Core modules and responsibilities
+   - Data flow between components
+   - External dependencies
+
+4. **Define Interfaces**
+   - API contracts
+   - Data structures
+   - Event/message formats
+
+## Output Format
+
+Generate markdown document:
+
+```markdown
+# Architecture: {target}
+
+## Overview
+Brief description of the architecture.
+
+## Components
+- **Component A**: Responsibility
+- **Component B**: Responsibility
+
+## Data Flow
+```
+[Diagram using ASCII or mermaid]
+```
+
+## Interfaces
+### API Endpoints
+- `GET /resource` - Description
+- `POST /resource` - Description
+
+### Data Models
+- `Model`: { field: type }
+
+## Dependencies
+- External service X
+- Library Y
+
+## Decisions
+- Decision 1: Rationale
+- Decision 2: Rationale
+```
+
+## Guidelines
+- Match existing project patterns
+- Keep it simple - avoid over-engineering
+- Document decisions and trade-offs

package/templates/design/component.md

@@ -0,0 +1,89 @@
+---
+name: component-design
+description: Design UI/code component
+allowed-tools: [Read, Glob, Grep]
+---
+
+# Component Design
+
+Design a reusable component for the given requirements.
+
+## Input
+- Target: {{target}}
+- Requirements: {{requirements}}
+
+## Analysis Steps
+
+1. **Understand Purpose**
+   - What does this component do?
+   - Where will it be used?
+   - What inputs/outputs?
+
+2. **Review Existing Components**
+   - Read similar components
+   - Match project patterns
+   - Use existing utilities
+
+3. **Design Interface**
+   - Props/parameters
+   - Events/callbacks
+   - State management
+
+4. **Plan Implementation**
+   - File structure
+   - Dependencies
+   - Testing approach
+
+## Output Format
+
+```markdown
+# Component: {ComponentName}
+
+## Purpose
+Brief description of what this component does.
+
+## Props/Interface
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| id | string | yes | - | Unique identifier |
+| onClick | function | no | - | Click handler |
+
+## State
+- `isLoading`: boolean - Loading state
+- `data`: array - Fetched data
+
+## Events
+- `onChange(value)`: Fired when value changes
+- `onSubmit(data)`: Fired on form submit
+
+## Usage Example
+```jsx
+<ComponentName
+  id="example"
+  onClick={handleClick}
+/>
+```
+
+## File Structure
+```
+components/
+└── ComponentName/
+    ├── index.js
+    ├── ComponentName.jsx
+    ├── ComponentName.test.js
+    └── styles.css
+```
+
+## Dependencies
+- Library X for Y
+- Utility Z
+
+## Testing
+- Unit tests for logic
+- Integration test for interactions
+```
+
+## Guidelines
+- Match project component patterns
+- Keep components focused
+- Document all props