prjct-cli 2.63.2 → 2.67.0

package/templates/global/STORAGE-SPEC.md

@@ -25,9 +25,9 @@ All reads and writes go through the `prjct` CLI, which manages a SQLite database
 
 ### How to interact with storage
 
-- **Read state**: Use `prjct status`, `prjct dash`, `prjct next` CLI commands
-- **Write state**: Use `prjct` CLI commands (task, done, pause, resume, etc.)
-- **Issue tracker setup**: Use `prjct linear setup` or `prjct jira setup` (MCP/OAuth)
+- **Read state**: Use `prjct status`, `prjct context`, or MCP project tools
+- **Write state**: Use `prjct` CLI commands (`task`, `status`, `capture`, `remember`, etc.)
+- **Issue tracker setup**: Configure Linear/Jira MCP servers in the AI client; prjct has no native tracker CLI verbs
 - **Never** read/write JSON files in `storage/` or `memory/` directories
 
 ---
@@ -307,8 +307,7 @@ Issue tracker integrations are MCP-only.
 
 ### Setup
 
-- `prjct linear setup`
-- `prjct jira setup`
+Configure Linear/Jira MCP servers in the AI client when issue tracker access is needed.
 
 ### Operational Model
 

package/templates/global/WINDSURF.md

@@ -6,7 +6,7 @@ description: "prjct - Context layer for AI coding agents"
 <!-- prjct:start - DO NOT REMOVE THIS MARKER -->
 # p/ — Context layer for AI agents
 
-Skills auto-activate for: task, status, ship, sync, bug, workflow, spec, guard, capture, remember, context, linear, jira
+Skills auto-activate for: task, status, ship, sync, workflow, spec, guard, capture, remember, context
 Other commands: run `prjct <command> --md` and follow CLI output
 
 Flow: idea → spec when warranted → task → work → status done → ship

package/templates/mcp-config.json

@@ -23,7 +23,7 @@
     }
   },
   "integrations": {
-    "linear": "MCP - Run `prjct linear setup`",
-    "jira": "MCP - Run `prjct jira setup`"
+    "linear": "MCP - configure in your AI client",
+    "jira": "MCP - configure in your AI client"
   }
 }

package/templates/windsurf/router.md

@@ -5,5 +5,5 @@ description: "prjct - Context layer for AI coding agents"
 
 # prjct
 
-Core: /sync, /task, /status, /ship, /bug, /workflow, /spec, /guard
+Core: /sync, /task, /status, /ship, /workflow, /spec, /guard
 Other: run `prjct <command> --md` and follow CLI output

package/templates/agentic/checklist-routing.md

@@ -1,98 +0,0 @@
----
-allowed-tools: [Read, Glob]
-description: 'Determine which quality checklists to apply - Claude decides'
----
-
-# Checklist Routing Instructions
-
-## Objective
-
-Determine which quality checklists are relevant for a task by analyzing the ACTUAL task and its scope.
-
-## Step 1: Understand the Task
-
-Read the task description and identify:
-
-- What type of work is being done? (new feature, bug fix, refactor, infra, docs)
-- What domains are affected? (code, UI, API, database, deployment)
-- What is the scope? (small fix, major feature, architectural change)
-
-## Step 2: Consider Task Domains
-
-Each task can touch multiple domains. Consider:
-
-| Domain | Signals |
-|--------|---------|
-| Code Quality | Writing/modifying any code |
-| Architecture | New components, services, or major refactors |
-| UX/UI | User-facing changes, CLI output, visual elements |
-| Infrastructure | Deployment, containers, CI/CD, cloud resources |
-| Security | Auth, user data, external inputs, secrets |
-| Testing | New functionality, bug fixes, critical paths |
-| Documentation | Public APIs, complex features, breaking changes |
-| Performance | Data processing, loops, network calls, rendering |
-| Accessibility | User interfaces (web, mobile, CLI) |
-| Data | Database operations, caching, data transformations |
-
-## Step 3: Match Task to Checklists
-
-Based on your analysis, select relevant checklists:
-
-**DO NOT assume:**
-- Every task needs all checklists
-- "Frontend" = only UX checklist
-- "Backend" = only Code Quality checklist
-
-**DO analyze:**
-- What the task actually touches
-- What quality dimensions matter for this specific work
-- What could go wrong if not checked
-
-## Available Checklists
-
-Located in `templates/checklists/`:
-
-| Checklist | When to Apply |
-|-----------|---------------|
-| `code-quality.md` | Any code changes (any language) |
-| `architecture.md` | New modules, services, significant structural changes |
-| `ux-ui.md` | User-facing interfaces (web, mobile, CLI, API DX) |
-| `infrastructure.md` | Deployment, containers, CI/CD, cloud resources |
-| `security.md` | ALWAYS for: auth, user input, external APIs, secrets |
-| `testing.md` | New features, bug fixes, refactors |
-| `documentation.md` | Public APIs, complex features, configuration changes |
-| `performance.md` | Data-intensive operations, critical paths |
-| `accessibility.md` | Any user interface work |
-| `data.md` | Database, caching, data transformations |
-
-## Decision Process
-
-1. Read task description
-2. Identify primary work domain
-3. List secondary domains affected
-4. Select 2-4 most relevant checklists
-5. Consider Security (almost always relevant)
-
-## Output
-
-Return selected checklists with reasoning:
-
-```json
-{
-  "checklists": ["code-quality", "security", "testing"],
-  "reasoning": "Task involves new API endpoint (code), handles user input (security), and adds business logic (testing)",
-  "priority_items": ["Input validation", "Error handling", "Happy path tests"],
-  "skipped": {
-    "accessibility": "No user interface changes",
-    "infrastructure": "No deployment changes"
-  }
-}
-```
-
-## Rules
-
-- **Task-driven** - Focus on what the specific task needs
-- **Less is more** - 2-4 focused checklists beat 10 unfocused
-- **Security is special** - Default to including unless clearly irrelevant
-- **Explain your reasoning** - Don't just pick, justify selections AND skips
-- **Context matters** - Small typo fix ≠ major refactor in checklist needs

package/templates/agentic/orchestrator.md

@@ -1,68 +0,0 @@
-# Orchestrator
-
-Load project context for task execution.
-
-## Flow
-
-```
-p. {command} → Load Config → Load State → Load Agents → Execute
-```
-
-## Step 1: Load Config
-
-```
-READ: .prjct/prjct.config.json → {projectId}
-SET: {globalPath} = ~/.prjct-cli/projects/{projectId}
-```
-
-## Step 2: Load State
-
-```bash
-prjct dash compact
-# Parse output to determine: {hasActiveTask}
-```
-
-## Step 3: Load Agents
-
-```
-GLOB: {globalPath}/agents/*.md
-FOR EACH agent: READ and store content
-```
-
-## Step 4: Detect Domains
-
-Analyze task → identify domains:
-- frontend: UI, forms, components
-- backend: API, server logic
-- database: Schema, queries
-- testing: Tests, mocks
-- devops: CI/CD, deployment
-
-IF task spans 3+ domains → fragment into subtasks
-
-## Step 5: Build Context
-
-Combine: state + agents + detected domains → execute
-
-## Output Format
-
-```
-🎯 Task: {description}
-📦 Context: Agent: {name} | State: {status} | Domains: {list}
-```
-
-## Error Handling
-
-| Situation | Action |
-|-----------|--------|
-| No config | "Run `p. init` first" |
-| No state | Create default |
-| No agents | Warn, continue |
-
-## Disable
-
-```yaml
----
-orchestrator: false
----
-```

package/templates/agentic/task-fragmentation.md

@@ -1,89 +0,0 @@
-# Task Fragmentation
-
-Break complex multi-domain tasks into subtasks.
-
-## When to Fragment
-
-- Spans 3+ domains (frontend + backend + database)
-- Has natural dependency order
-- Too large for single execution
-
-## When NOT to Fragment
-
-- Single domain only
-- Small, focused change
-- Already atomic
-
-## Dependency Order
-
-1. **Database** (models first)
-2. **Backend** (API using models)
-3. **Frontend** (UI using API)
-4. **Testing** (tests for all)
-5. **DevOps** (deploy)
-
-## Subtask Format
-
-```json
-{
-  "subtasks": [{
-    "id": "subtask-1",
-    "description": "Create users table",
-    "domain": "database",
-    "agent": "database.md",
-    "dependsOn": []
-  }]
-}
-```
-
-## Output
-
-```
-🎯 Task: {task}
-
-📋 Subtasks:
-├─ 1. [database] Create schema
-├─ 2. [backend] Create API
-└─ 3. [frontend] Create form
-```
-
-## Delegation
-
-```
-Task(
-  subagent_type: 'general-purpose',
-  prompt: '
-    Read: {agentsPath}/{domain}.md
-    Subtask: {description}
-    Previous: {previousSummary}
-    Focus ONLY on this subtask.
-  '
-)
-```
-
-## Progress
-
-```
-📊 Progress: 2/4 (50%)
-✅ 1. [database] Done
-✅ 2. [backend] Done
-▶️ 3. [frontend] ← CURRENT
-⏳ 4. [testing]
-```
-
-## Error Handling
-
-```
-❌ Subtask 2/4 failed
-
-Options:
-1. Retry
-2. Skip and continue
-3. Abort
-```
-
-## Anti-Patterns
-
-- Over-fragmentation: 10 subtasks for "add button"
-- Under-fragmentation: 1 subtask for "add auth system"
-- Wrong order: Frontend before backend

package/templates/agents/AGENTS.md

@@ -1,67 +0,0 @@
-# AGENTS.md
-
-AI assistant guidance for **prjct-cli** - context layer for AI coding agents. Works with Claude Code, Codex, Gemini CLI, OpenCode, Qwen Code, Cline, Cursor, Windsurf, and any AGENTS.md-aware runtime.
-
-## What This Is
-
-**NOT** project management. NO sprints, story points, ceremonies, or meetings.
-
-**IS** a context layer that gives AI agents the project knowledge they need to work effectively.
-
----
-
-## Agent Contract
-
-Run `prjct <command> --md` and follow the CLI output. Prefer `prjct_*` MCP tools when the active client exposes them.
-
-## Architecture
-
-**Global**: `~/.prjct-cli/projects/{id}/`
-```
-prjct.db   # SQLite database (all state)
-agents/    # domain specialists
-```
-
-**Local**: `.prjct/prjct.config.json` (read-only)
-
-## Commands
-
-| Command | Action |
-|---------|--------|
-| `prjct init` | Initialize |
-| `prjct sync --md` | Analyze + refresh agent context |
-| `prjct task "X" --md` | Start task |
-| `prjct status done --md` | Complete active task |
-| `prjct ship --md` | Ship feature |
-| `prjct status --md` | Show current task/workflow state |
-
-## Intent Detection
-
-| Intent | Command |
-|--------|---------|
-| Start task | `prjct task "<desc>" --md` |
-| Finish | `prjct status done --md` |
-| Ship | `prjct ship --md` |
-| What's active | `prjct status --md` |
-
-## Implementation
-
-- Atomic operations via `prjct` CLI
-- CLI handles all state persistence (SQLite)
-- Handle missing config gracefully
-
-## Crew mode (opt-in)
-
-Projects that want a multi-agent workflow can run `prjct crew install` to drop a leader/implementer/reviewer trio into `.claude/agents/`, a project `CHECKPOINTS.md`, and a CLAUDE.md snippet that locks the main session into orchestrator role. Templates live in `templates/crew/`. Uninstall with `prjct crew uninstall`. Strictly opt-in — not invoked by `init`/`sync`.
-
-### Crew roster
-
-Each member has a stable name + color so you can identify who is acting at a glance, in any LLM. Source of truth: `templates/crew/registry.json`.
-
-| Name | Role | Color |
-|---|---|---|
-| Leader | Orchestrator | blue |
-| Implementer | Worker | purple |
-| Reviewer | Strict auditor | pink |
-
-Crew SUBAGENT DISPATCH is Claude Code only (only Claude Code currently exposes an Agent tool that can spawn typed subagents). In Codex / Gemini / Cursor / Windsurf the roster above is informational — the same session plays whichever role the prompt names; identify it explicitly when you reply ("acting as Implementer").

package/templates/checklists/architecture.md

@@ -1,28 +0,0 @@
-# Architecture Checklist
-
-> Applies to ANY system architecture
-
-## Design Principles
-- [ ] Clear separation of concerns
-- [ ] Loose coupling between components
-- [ ] High cohesion within modules
-- [ ] Single source of truth for data
-- [ ] Explicit dependencies (no hidden coupling)
-
-## Scalability
-- [ ] Stateless where possible
-- [ ] Horizontal scaling considered
-- [ ] Bottlenecks identified
-- [ ] Caching strategy defined
-
-## Resilience
-- [ ] Failure modes documented
-- [ ] Graceful degradation planned
-- [ ] Recovery procedures defined
-- [ ] Circuit breakers where needed
-
-## Maintainability
-- [ ] Clear boundaries between layers
-- [ ] Easy to test in isolation
-- [ ] Configuration externalized
-- [ ] Logging and observability built-in

package/templates/checklists/code-quality.md

@@ -1,28 +0,0 @@
-# Code Quality Checklist
-
-> Universal principles for ANY programming language
-
-## Universal Principles
-- [ ] Single Responsibility: Each unit does ONE thing well
-- [ ] DRY: No duplicated logic (extract shared code)
-- [ ] KISS: Simplest solution that works
-- [ ] Clear naming: Self-documenting identifiers
-- [ ] Consistent patterns: Match existing codebase style
-
-## Error Handling
-- [ ] All error paths handled gracefully
-- [ ] Meaningful error messages
-- [ ] No silent failures
-- [ ] Proper resource cleanup (files, connections, memory)
-
-## Edge Cases
-- [ ] Null/nil/None handling
-- [ ] Empty collections handled
-- [ ] Boundary conditions tested
-- [ ] Invalid input rejected early
-
-## Code Organization
-- [ ] Functions/methods are small and focused
-- [ ] Related code grouped together
-- [ ] Clear module/package boundaries
-- [ ] No circular dependencies

package/templates/checklists/data.md

@@ -1,33 +0,0 @@
-# Data Checklist
-
-> Applies to: SQL, NoSQL, GraphQL, File storage, Caching
-
-## Data Integrity
-- [ ] Schema/structure defined
-- [ ] Constraints enforced
-- [ ] Transactions used appropriately
-- [ ] Referential integrity maintained
-
-## Query Performance
-- [ ] Indexes on frequent queries
-- [ ] N+1 queries eliminated
-- [ ] Query complexity analyzed
-- [ ] Pagination for large datasets
-
-## Data Operations
-- [ ] Migrations versioned and reversible
-- [ ] Backup and restore tested
-- [ ] Data validation at boundary
-- [ ] Soft deletes considered (if applicable)
-
-## Caching
-- [ ] Cache invalidation strategy defined
-- [ ] TTL values appropriate
-- [ ] Cache warming considered
-- [ ] Cache hit/miss monitored
-
-## Data Privacy
-- [ ] PII identified and protected
-- [ ] Data anonymization where needed
-- [ ] Audit trail for sensitive data
-- [ ] Data deletion procedures defined

package/templates/checklists/documentation.md

@@ -1,33 +0,0 @@
-# Documentation Checklist
-
-> Applies to ALL projects
-
-## Essential Docs
-- [ ] README with quick start
-- [ ] Installation instructions
-- [ ] Configuration options documented
-- [ ] Common use cases shown
-
-## Code Documentation
-- [ ] Public APIs documented
-- [ ] Complex logic explained
-- [ ] Architecture decisions recorded (ADRs)
-- [ ] Diagrams for complex flows
-
-## Operational Docs
-- [ ] Deployment process documented
-- [ ] Troubleshooting guide
-- [ ] Runbooks for common issues
-- [ ] Changelog maintained
-
-## API Documentation
-- [ ] All endpoints documented
-- [ ] Request/response examples
-- [ ] Error codes explained
-- [ ] Authentication documented
-
-## Maintenance
-- [ ] Docs updated with code changes
-- [ ] Version-specific documentation
-- [ ] Broken links checked
-- [ ] Examples tested and working

package/templates/checklists/infrastructure.md

@@ -1,33 +0,0 @@
-# Infrastructure Checklist
-
-> Applies to: Cloud, On-prem, Hybrid, Edge
-
-## Deployment
-- [ ] Infrastructure as Code (Terraform, Pulumi, CloudFormation, etc.)
-- [ ] Reproducible environments
-- [ ] Rollback strategy defined
-- [ ] Blue-green or canary deployment option
-
-## Observability
-- [ ] Logging strategy defined
-- [ ] Metrics collection configured
-- [ ] Alerting thresholds set
-- [ ] Distributed tracing (if applicable)
-
-## Security
-- [ ] Secrets management (not in code)
-- [ ] Network segmentation
-- [ ] Least privilege access
-- [ ] Encryption at rest and in transit
-
-## Reliability
-- [ ] Backup strategy defined
-- [ ] Disaster recovery plan
-- [ ] Health checks configured
-- [ ] Auto-scaling rules (if applicable)
-
-## Cost Management
-- [ ] Resource sizing appropriate
-- [ ] Unused resources identified
-- [ ] Cost monitoring in place
-- [ ] Budget alerts configured

package/templates/checklists/performance.md

@@ -1,33 +0,0 @@
-# Performance Checklist
-
-> Applies to: Backend, Frontend, Mobile, Database
-
-## Analysis
-- [ ] Bottlenecks identified with profiling
-- [ ] Baseline metrics established
-- [ ] Performance budgets defined
-- [ ] Benchmarks before/after changes
-
-## Optimization Strategies
-- [ ] Algorithmic complexity reviewed (O(n) vs O(n²))
-- [ ] Appropriate data structures used
-- [ ] Caching implemented where beneficial
-- [ ] Lazy loading for expensive operations
-
-## Resource Management
-- [ ] Memory usage optimized
-- [ ] Connection pooling used
-- [ ] Batch operations where applicable
-- [ ] Async/parallel processing considered
-
-## Frontend Specific
-- [ ] Bundle size optimized
-- [ ] Images optimized
-- [ ] Critical rendering path optimized
-- [ ] Network requests minimized
-
-## Backend Specific
-- [ ] Database queries optimized
-- [ ] Response compression enabled
-- [ ] Proper indexing in place
-- [ ] Connection limits configured

package/templates/checklists/security.md

@@ -1,33 +0,0 @@
-# Security Checklist
-
-> ALWAYS ON - Applies to ALL applications
-
-## Input/Output
-- [ ] All user input validated and sanitized
-- [ ] Output encoded appropriately (prevent injection)
-- [ ] File uploads restricted and scanned
-- [ ] No sensitive data in logs or error messages
-
-## Authentication & Authorization
-- [ ] Strong authentication mechanism
-- [ ] Proper session management
-- [ ] Authorization checked at every access point
-- [ ] Principle of least privilege applied
-
-## Data Protection
-- [ ] Sensitive data encrypted at rest
-- [ ] Secure transmission (TLS/HTTPS)
-- [ ] PII handled according to regulations
-- [ ] Data retention policies followed
-
-## Dependencies
-- [ ] Dependencies from trusted sources
-- [ ] Known vulnerabilities checked
-- [ ] Minimal dependency surface
-- [ ] Regular security updates planned
-
-## API Security
-- [ ] Rate limiting implemented
-- [ ] Authentication required for sensitive endpoints
-- [ ] CORS properly configured
-- [ ] API keys/tokens secured

package/templates/checklists/testing.md

@@ -1,33 +0,0 @@
-# Testing Checklist
-
-> Applies to: Unit, Integration, E2E, Performance testing
-
-## Coverage Strategy
-- [ ] Critical paths have high coverage
-- [ ] Happy path tested
-- [ ] Error paths tested
-- [ ] Edge cases covered
-
-## Test Quality
-- [ ] Tests are deterministic (no flaky tests)
-- [ ] Tests are independent (no order dependency)
-- [ ] Tests are fast (optimize slow tests)
-- [ ] Tests are readable (clear intent)
-
-## Test Types
-- [ ] Unit tests for business logic
-- [ ] Integration tests for boundaries
-- [ ] E2E tests for critical flows
-- [ ] Performance tests for bottlenecks
-
-## Mocking Strategy
-- [ ] External services mocked
-- [ ] Database isolated or mocked
-- [ ] Time-dependent code controlled
-- [ ] Random values seeded
-
-## Test Maintenance
-- [ ] Tests updated with code changes
-- [ ] Dead tests removed
-- [ ] Test data managed properly
-- [ ] CI/CD integration working

package/templates/checklists/ux-ui.md

@@ -1,37 +0,0 @@
-# UX/UI Checklist
-
-> Applies to: Web, Mobile, CLI, Desktop, API DX
-
-## User Experience
-- [ ] Clear user journey/flow
-- [ ] Feedback for every action
-- [ ] Loading states shown
-- [ ] Error states handled gracefully
-- [ ] Success confirmation provided
-
-## Interface Design
-- [ ] Consistent visual language
-- [ ] Intuitive navigation
-- [ ] Responsive/adaptive layout (if applicable)
-- [ ] Touch targets adequate (mobile)
-- [ ] Keyboard navigation (web/desktop)
-
-## CLI Specific
-- [ ] Help text for all commands
-- [ ] Clear error messages with suggestions
-- [ ] Progress indicators for long operations
-- [ ] Consistent flag naming conventions
-- [ ] Exit codes meaningful
-
-## API DX (Developer Experience)
-- [ ] Intuitive endpoint/function naming
-- [ ] Consistent response format
-- [ ] Helpful error messages with codes
-- [ ] Good documentation with examples
-- [ ] Predictable behavior
-
-## Information Architecture
-- [ ] Content hierarchy clear
-- [ ] Important actions prominent
-- [ ] Related items grouped
-- [ ] Search/filter for large datasets