prjct-cli 0.10.10 → 0.10.12

package/templates/agent-assignment.md

@@ -0,0 +1,72 @@
+---
+name: agent-assignment
+description: Assign the best agent for a task
+allowed-tools: [Read]
+---
+
+# Agent Assignment
+
+Select the best agent for the given task based on semantic understanding.
+
+## Input
+
+- **Task**: {{task}}
+- **Available Agents**: {{agents}}
+- **Project Context**: {{context}}
+
+## Instructions
+
+1. **Understand the Task**
+   - What domain does this task belong to?
+   - What skills are required?
+   - What is the complexity level?
+
+2. **Analyze Available Agents**
+   - Read each agent's expertise and domain
+   - Consider their skills and past success
+   - Match capabilities to task requirements
+
+3. **Select Best Agent**
+   - Choose the agent with highest relevance
+   - If multiple agents fit, prefer the specialist over generalist
+   - If no good match, use 'generalist' or 'full-stack'
+
+## Decision Criteria
+
+- **Domain Match**: Does the agent's domain align with the task?
+- **Skills Match**: Does the agent have the required skills?
+- **Complexity Fit**: Is the agent appropriate for this complexity level?
+
+## Output Format
+
+Return JSON with your decision:
+
+```json
+{
+  "agent": "agent-name",
+  "confidence": 0.85,
+  "reason": "Brief explanation of why this agent was selected",
+  "domain": "detected domain of the task"
+}
+```
+
+## Examples
+
+**Task**: "Implement React login component with form validation"
+**Decision**: `{ "agent": "frontend-specialist", "confidence": 0.95, "reason": "React component work requires frontend expertise", "domain": "frontend" }`
+
+**Task**: "Fix database connection timeout issue"
+**Decision**: `{ "agent": "backend-specialist", "confidence": 0.90, "reason": "Database issues require backend/infrastructure knowledge", "domain": "backend" }`
+
+**Task**: "Write unit tests for user service"
+**Decision**: `{ "agent": "qa-specialist", "confidence": 0.85, "reason": "Testing tasks benefit from QA expertise", "domain": "qa" }`
+
+**Task**: "Update README documentation"
+**Decision**: `{ "agent": "generalist", "confidence": 0.70, "reason": "Documentation is general task, no specialist needed", "domain": "docs" }`
+
+## Guidelines
+
+- Prefer specialists when task clearly fits their domain
+- Use generalist only when no specialist matches
+- Higher confidence = stronger match
+- Always provide a reason for transparency

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