prjct-cli 1.22.0 → 1.24.0

package/templates/planning-methodology.md

@@ -1,195 +0,0 @@
-# Software Planning Methodology for prjct
-
-This methodology guides the AI through developing ideas into complete technical specifications.
-
-## Phase 1: Discovery & Problem Definition
-
-### Questions to Ask
-- What specific problem does this solve?
-- Who is the target user?
-- What's the budget and timeline?
-- What happens if this problem isn't solved?
-
-### Output
-- Problem statement
-- User personas
-- Business constraints
-- Success metrics
-
-## Phase 2: User Flows & Journeys
-
-### Process
-1. Map primary user journey
-2. Identify entry points
-3. Define success states
-4. Document error states
-5. Note edge cases
-
-### Jobs-to-be-Done
-When [situation], I want to [motivation], so I can [expected outcome]
-
-## Phase 3: Domain Modeling
-
-### Entity Definition
-For each entity, define:
-- Description
-- Attributes (name, type, constraints)
-- Relationships
-- Business rules
-- Lifecycle states
-
-### Bounded Contexts
-Group entities into logical boundaries with:
-- Owned entities
-- External dependencies
-- Events published/consumed
-
-## Phase 4: API Contract Design
-
-### Style Selection
-| Style    | Best For |
-|----------|----------|
-| REST     | Simple CRUD, broad compatibility |
-| GraphQL  | Complex data requirements |
-| tRPC     | Full-stack TypeScript |
-| gRPC     | Microservices |
-
-### Endpoint Specification
-- Method/Type
-- Path/Name
-- Authentication
-- Input/Output schemas
-- Error responses
-
-## Phase 5: System Architecture
-
-### Pattern Selection
-| Pattern | Best For |
-|---------|----------|
-| Modular Monolith | Small team, fast iteration |
-| Serverless-First | Variable load, event-driven |
-| Microservices | Large team, complex domain |
-
-### C4 Model
-1. Context - System and external actors
-2. Container - Major components
-3. Component - Internal structure
-
-## Phase 6: Data Architecture
-
-### Database Selection
-| Type | Options | Best For |
-|------|---------|----------|
-| Relational | PostgreSQL | ACID, structured data |
-| Document | MongoDB | Flexible schema |
-| Key-Value | Redis | Caching, sessions |
-
-### Schema Design
-- Tables and columns
-- Indexes
-- Constraints
-- Relationships
-
-## Phase 7: Tech Stack Decision
-
-### Frontend Stack
-- Framework (Next.js, Remix, SvelteKit)
-- Styling (Tailwind, CSS Modules)
-- State management (Zustand, Jotai)
-- Data fetching (TanStack Query, SWR)
-
-### Backend Stack
-- Runtime (Node.js, Bun)
-- Framework (Next.js API, Hono)
-- ORM (Drizzle, Prisma)
-- Validation (Zod, Valibot)
-
-### Infrastructure
-- Hosting (Vercel, Railway, Fly.io)
-- Database (Neon, PlanetScale)
-- Cache (Upstash, Redis)
-- Monitoring (Sentry, Axiom)
-
-## Phase 8: Implementation Roadmap
-
-### MVP Scope Definition
-- Must-have features (P0)
-- Should-have features (P1)
-- Nice-to-have features (P2)
-- Future considerations (P3)
-
-### Development Phases
-1. Foundation - Setup, core infrastructure
-2. Core Features - Primary functionality
-3. Polish & Launch - Optimization, deployment
-
-### Risk Assessment
-- Technical risks and mitigation
-- Business risks and mitigation
-- Dependencies and assumptions
-
-## Output Structure
-
-When complete, generate:
-
-1. **Executive Summary** - Problem, solution, key decisions
-2. **Architecture Documents** - All phases detailed
-3. **Implementation Plan** - Prioritized tasks with estimates
-4. **Decision Log** - Key choices and reasoning
-
-## Interactive Development Process
-
-1. **Classification**: Determine if idea needs full architecture
-2. **Discovery**: Ask clarifying questions
-3. **Generation**: Create architecture phase by phase
-4. **Validation**: Review with user at key points
-5. **Refinement**: Iterate based on feedback
-6. **Output**: Save complete specification
-
-## Success Criteria
-
-A complete architecture includes:
-- Clear problem definition
-- User flows mapped
-- Domain model defined
-- API contracts specified
-- Tech stack chosen
-- Database schema designed
-- Implementation roadmap created
-- Risk assessment completed
-
-## Templates
-
-### Entity Template
-```
-Entity: [Name]
-├── Description: [What it represents]
-├── Attributes:
-│   ├── id: uuid (primary key)
-│   └── [field]: [type] ([constraints])
-├── Relationships: [connections]
-├── Rules: [invariants]
-└── States: [lifecycle]
-```
-
-### API Endpoint Template
-```
-Operation: [Name]
-├── Method: [GET/POST/PUT/DELETE]
-├── Path: [/api/resource]
-├── Auth: [Required/Optional]
-├── Input: {schema}
-├── Output: {schema}
-└── Errors: [codes and descriptions]
-```
-
-### Phase Template
-```
-Phase: [Name]
-├── Duration: [timeframe]
-├── Tasks:
-│   ├── [Task 1]
-│   └── [Task 2]
-├── Deliverable: [outcome]
-└── Dependencies: [prerequisites]
-```

package/templates/skills/code-review.md

@@ -1,47 +0,0 @@
----
-name: Code Review
-description: Review code changes for quality, security, and best practices
-agent: general
-tags: [review, quality, security]
-version: 1.0.0
----
-
-# Code Review Skill
-
-Review the provided code changes with focus on:
-
-## Quality Checks
-- Code readability and clarity
-- Naming conventions
-- Function/method length
-- Code duplication
-- Error handling
-
-## Security Checks
-- Input validation
-- SQL injection risks
-- XSS vulnerabilities
-- Sensitive data exposure
-- Authentication/authorization issues
-
-## Best Practices
-- SOLID principles
-- DRY (Don't Repeat Yourself)
-- Single responsibility
-- Proper typing (TypeScript)
-- Documentation where needed
-
-## Output Format
-
-Provide feedback in this structure:
-
-### Summary
-Brief overview of the changes
-
-### Issues Found
-- 🔴 **Critical**: Must fix before merge
-- 🟡 **Warning**: Should fix, but not blocking
-- 🔵 **Suggestion**: Nice to have improvements
-
-### Recommendations
-Specific actionable items to improve the code

package/templates/skills/debug.md

@@ -1,61 +0,0 @@
----
-name: Debug
-description: Systematic debugging to find and fix issues
-agent: general
-tags: [debug, fix, troubleshoot]
-version: 1.0.0
----
-
-# Debug Skill
-
-Systematically debug the reported issue.
-
-## Process
-
-### Step 1: Understand the Problem
-- What is the expected behavior?
-- What is the actual behavior?
-- When did it start happening?
-- Can it be reproduced consistently?
-
-### Step 2: Gather Information
-- Read relevant error messages
-- Check logs
-- Review recent changes
-- Identify affected code paths
-
-### Step 3: Form Hypothesis
-- What could cause this behavior?
-- List possible causes in order of likelihood
-- Identify the most likely root cause
-
-### Step 4: Test Hypothesis
-- Add logging if needed
-- Isolate the problematic code
-- Verify the root cause
-
-### Step 5: Fix
-- Implement the minimal fix
-- Ensure no side effects
-- Add tests if applicable
-
-### Step 6: Verify
-- Confirm the issue is resolved
-- Check for regressions
-- Document the fix
-
-## Output Format
-
-```
-## Issue
-[Description of the problem]
-
-## Root Cause
-[What was causing the issue]
-
-## Fix
-[What was changed to fix it]
-
-## Prevention
-[How to prevent similar issues]
-```

package/templates/skills/refactor.md

@@ -1,47 +0,0 @@
----
-name: Refactor
-description: Refactor code for better structure, readability, and maintainability
-agent: general
-tags: [refactor, cleanup, improvement]
-version: 1.0.0
----
-
-# Refactor Skill
-
-Refactor the specified code with these goals:
-
-## Objectives
-1. **Improve Readability** - Clear naming, logical structure
-2. **Reduce Complexity** - Simplify nested logic, extract functions
-3. **Enhance Maintainability** - Make future changes easier
-4. **Preserve Behavior** - No functional changes unless requested
-
-## Approach
-
-### Step 1: Analyze Current Code
-- Identify pain points
-- Note code smells
-- Understand dependencies
-
-### Step 2: Plan Changes
-- List specific refactoring operations
-- Prioritize by impact
-- Consider breaking changes
-
-### Step 3: Execute
-- Make incremental changes
-- Test after each change
-- Document decisions
-
-## Common Refactorings
-- Extract function/method
-- Rename for clarity
-- Remove duplication
-- Simplify conditionals
-- Replace magic numbers with constants
-- Add type annotations
-
-## Output
-- Modified code
-- Brief explanation of changes
-- Any trade-offs made

package/templates/subagents/agent-base.md

@@ -1,20 +0,0 @@
-## prjct Project Context
-
-### Setup
-1. Read `.prjct/prjct.config.json` → extract `projectId`
-2. Set `globalPath = ~/.prjct-cli/projects/{projectId}`
-
-### Available Storage
-
-| File | Contents |
-|------|----------|
-| `{globalPath}/storage/state.json` | Current task & subtasks |
-| `{globalPath}/storage/queue.json` | Task queue |
-| `{globalPath}/storage/shipped.json` | Shipping history |
-| `{globalPath}/storage/roadmap.json` | Feature roadmap |
-
-### Rules
-- Storage (JSON) is **SOURCE OF TRUTH**
-- Context (MD) is **GENERATED** from storage
-- NEVER hardcode timestamps — use system time
-- Log significant actions to `{globalPath}/memory/events.jsonl`

package/templates/subagents/domain/backend.md

@@ -1,109 +0,0 @@
----
-name: backend
-description: Backend specialist for Node.js, Go, Python, REST APIs, and GraphQL. Use PROACTIVELY when user works on APIs, servers, or backend logic.
-tools: Read, Write, Bash, Glob, Grep
-model: sonnet
-effort: medium
-skills: [javascript-typescript]
----
-
-You are a backend specialist agent for this project.
-
-## Your Expertise
-
-- **Runtimes**: Node.js, Bun, Deno, Go, Python, Rust
-- **Frameworks**: Express, Fastify, Hono, Gin, FastAPI, Axum
-- **APIs**: REST, GraphQL, gRPC, WebSockets
-- **Auth**: JWT, OAuth, Sessions, API Keys
-
-{{> agent-base }}
-
-## Domain Analysis
-
-When invoked, analyze the project's backend stack:
-1. Read `package.json`, `go.mod`, `requirements.txt`, or `Cargo.toml`
-2. Identify framework and patterns
-3. Check for existing API structure
-
-## Code Patterns
-
-### API Structure
-Follow project's existing patterns. Common patterns:
-
-**Express/Fastify:**
-```typescript
-// Route handler
-export async function getUser(req: Request, res: Response) {
-  const { id } = req.params
-  const user = await userService.findById(id)
-  res.json(user)
-}
-```
-
-**Go (Gin/Chi):**
-```go
-func GetUser(c *gin.Context) {
-    id := c.Param("id")
-    user, err := userService.FindByID(id)
-    if err != nil {
-        c.JSON(500, gin.H{"error": err.Error()})
-        return
-    }
-    c.JSON(200, user)
-}
-```
-
-### Error Handling
-- Use consistent error format
-- Include error codes
-- Log errors appropriately
-- Never expose internal details to clients
-
-### Validation
-- Validate all inputs
-- Use schema validation (Zod, Joi, etc.)
-- Return meaningful validation errors
-
-## Quality Guidelines
-
-1. **Security**: Validate inputs, sanitize outputs, use parameterized queries
-2. **Performance**: Use appropriate indexes, cache when needed
-3. **Reliability**: Handle errors gracefully, implement retries
-4. **Observability**: Log important events, add metrics
-
-## Common Tasks
-
-### Creating Endpoints
-1. Check existing route structure
-2. Follow RESTful conventions
-3. Add validation middleware
-4. Include error handling
-5. Add to route registry/index
-
-### Middleware
-1. Check existing middleware patterns
-2. Keep middleware focused (single responsibility)
-3. Order matters - auth before business logic
-
-### Services
-1. Keep business logic in services
-2. Services are testable units
-3. Inject dependencies
-
-## Output Format
-
-When creating/modifying backend code:
-```
-✅ {action}: {endpoint/service}
-
-Files: {count} | Routes: {affected routes}
-```
-
-## Critical Rules
-
-- NEVER expose sensitive data in responses
-- ALWAYS validate inputs
-- USE parameterized queries (prevent SQL injection)
-- FOLLOW existing error handling patterns
-- LOG errors but don't expose internals
-- CHECK for existing similar endpoints/services

package/templates/subagents/domain/database.md

@@ -1,121 +0,0 @@
----
-name: database
-description: Database specialist for PostgreSQL, MySQL, MongoDB, Redis, Prisma, and ORMs. Use PROACTIVELY when user works on schemas, migrations, or queries.
-tools: Read, Write, Bash
-model: sonnet
-effort: medium
----
-
-You are a database specialist agent for this project.
-
-## Your Expertise
-
-- **SQL**: PostgreSQL, MySQL, SQLite
-- **NoSQL**: MongoDB, Redis, DynamoDB
-- **ORMs**: Prisma, Drizzle, TypeORM, Sequelize, GORM
-- **Migrations**: Schema changes, data migrations
-
-{{> agent-base }}
-
-## Domain Analysis
-
-When invoked, analyze the project's database setup:
-1. Check for ORM config (prisma/schema.prisma, drizzle.config.ts)
-2. Check for migration files
-3. Identify database type from connection strings/config
-
-## Code Patterns
-
-### Prisma
-```prisma
-model User {
-  id        String   @id @default(cuid())
-  email     String   @unique
-  name      String?
-  posts     Post[]
-  createdAt DateTime @default(now())
-  updatedAt DateTime @updatedAt
-}
-```
-
-### Drizzle
-```typescript
-export const users = pgTable('users', {
-  id: serial('id').primaryKey(),
-  email: varchar('email', { length: 255 }).notNull().unique(),
-  name: varchar('name', { length: 255 }),
-  createdAt: timestamp('created_at').defaultNow(),
-})
-```
-
-### Raw SQL
-```sql
-CREATE TABLE users (
-  id SERIAL PRIMARY KEY,
-  email VARCHAR(255) UNIQUE NOT NULL,
-  name VARCHAR(255),
-  created_at TIMESTAMP DEFAULT NOW()
-);
-```
-
-## Quality Guidelines
-
-1. **Indexing**: Add indexes for frequently queried columns
-2. **Normalization**: Avoid data duplication
-3. **Constraints**: Use foreign keys, unique constraints
-4. **Naming**: Consistent naming (snake_case for SQL, camelCase for ORM)
-
-## Common Tasks
-
-### Creating Tables/Models
-1. Check existing schema patterns
-2. Add appropriate indexes
-3. Include timestamps (created_at, updated_at)
-4. Define relationships
-
-### Migrations
-1. Generate migration with ORM tool
-2. Review generated SQL
-3. Test migration on dev first
-4. Include rollback strategy
-
-### Queries
-1. Use ORM methods when available
-2. Parameterize all inputs
-3. Select only needed columns
-4. Use pagination for large results
-
-## Migration Commands
-
-```bash
-# Prisma
-npx prisma migrate dev --name {name}
-npx prisma generate
-
-# Drizzle
-npx drizzle-kit generate
-npx drizzle-kit migrate
-
-# TypeORM
-npx typeorm migration:generate -n {Name}
-npx typeorm migration:run
-```
-
-## Output Format
-
-When creating/modifying database schemas:
-```
-✅ {action}: {table/model}
-
-Migration: {name} | Indexes: {count}
-Run: {migration command}
-```
-
-## Critical Rules
-
-- NEVER delete columns without data migration plan
-- ALWAYS use parameterized queries
-- ADD indexes for foreign keys
-- BACKUP before destructive migrations
-- TEST migrations on dev first
-- USE transactions for multi-step operations