prjct-cli 2.43.3 → 2.44.0

package/dist/templates.json

@@ -1 +1 @@
-{"agentic/checklist-routing.md":"---\nallowed-tools: [Read, Glob]\ndescription: 'Determine which quality checklists to apply - Claude decides'\n---\n\n# Checklist Routing Instructions\n\n## Objective\n\nDetermine which quality checklists are relevant for a task by analyzing the ACTUAL task and its scope.\n\n## Step 1: Understand the Task\n\nRead the task description and identify:\n\n- What type of work is being done? (new feature, bug fix, refactor, infra, docs)\n- What domains are affected? (code, UI, API, database, deployment)\n- What is the scope? (small fix, major feature, architectural change)\n\n## Step 2: Consider Task Domains\n\nEach task can touch multiple domains. Consider:\n\n| Domain | Signals |\n|--------|---------|\n| Code Quality | Writing/modifying any code |\n| Architecture | New components, services, or major refactors |\n| UX/UI | User-facing changes, CLI output, visual elements |\n| Infrastructure | Deployment, containers, CI/CD, cloud resources |\n| Security | Auth, user data, external inputs, secrets |\n| Testing | New functionality, bug fixes, critical paths |\n| Documentation | Public APIs, complex features, breaking changes |\n| Performance | Data processing, loops, network calls, rendering |\n| Accessibility | User interfaces (web, mobile, CLI) |\n| Data | Database operations, caching, data transformations |\n\n## Step 3: Match Task to Checklists\n\nBased on your analysis, select relevant checklists:\n\n**DO NOT assume:**\n- Every task needs all checklists\n- \"Frontend\" = only UX checklist\n- \"Backend\" = only Code Quality checklist\n\n**DO analyze:**\n- What the task actually touches\n- What quality dimensions matter for this specific work\n- What could go wrong if not checked\n\n## Available Checklists\n\nLocated in `templates/checklists/`:\n\n| Checklist | When to Apply |\n|-----------|---------------|\n| `code-quality.md` | Any code changes (any language) |\n| `architecture.md` | New modules, services, significant structural changes |\n| `ux-ui.md` | User-facing interfaces (web, mobile, CLI, API DX) |\n| `infrastructure.md` | Deployment, containers, CI/CD, cloud resources |\n| `security.md` | ALWAYS for: auth, user input, external APIs, secrets |\n| `testing.md` | New features, bug fixes, refactors |\n| `documentation.md` | Public APIs, complex features, configuration changes |\n| `performance.md` | Data-intensive operations, critical paths |\n| `accessibility.md` | Any user interface work |\n| `data.md` | Database, caching, data transformations |\n\n## Decision Process\n\n1. Read task description\n2. Identify primary work domain\n3. List secondary domains affected\n4. Select 2-4 most relevant checklists\n5. Consider Security (almost always relevant)\n\n## Output\n\nReturn selected checklists with reasoning:\n\n```json\n{\n  \"checklists\": [\"code-quality\", \"security\", \"testing\"],\n  \"reasoning\": \"Task involves new API endpoint (code), handles user input (security), and adds business logic (testing)\",\n  \"priority_items\": [\"Input validation\", \"Error handling\", \"Happy path tests\"],\n  \"skipped\": {\n    \"accessibility\": \"No user interface changes\",\n    \"infrastructure\": \"No deployment changes\"\n  }\n}\n```\n\n## Rules\n\n- **Task-driven** - Focus on what the specific task needs\n- **Less is more** - 2-4 focused checklists beat 10 unfocused\n- **Security is special** - Default to including unless clearly irrelevant\n- **Explain your reasoning** - Don't just pick, justify selections AND skips\n- **Context matters** - Small typo fix ≠ major refactor in checklist needs\n","agentic/orchestrator.md":"# Orchestrator\n\nLoad project context for task execution.\n\n## Flow\n\n```\np. {command} → Load Config → Load State → Load Agents → Execute\n```\n\n## Step 1: Load Config\n\n```\nREAD: .prjct/prjct.config.json → {projectId}\nSET: {globalPath} = ~/.prjct-cli/projects/{projectId}\n```\n\n## Step 2: Load State\n\n```bash\nprjct dash compact\n# Parse output to determine: {hasActiveTask}\n```\n\n## Step 3: Load Agents\n\n```\nGLOB: {globalPath}/agents/*.md\nFOR EACH agent: READ and store content\n```\n\n## Step 4: Detect Domains\n\nAnalyze task → identify domains:\n- frontend: UI, forms, components\n- backend: API, server logic\n- database: Schema, queries\n- testing: Tests, mocks\n- devops: CI/CD, deployment\n\nIF task spans 3+ domains → fragment into subtasks\n\n## Step 5: Build Context\n\nCombine: state + agents + detected domains → execute\n\n## Output Format\n\n```\n🎯 Task: {description}\n📦 Context: Agent: {name} | State: {status} | Domains: {list}\n```\n\n## Error Handling\n\n| Situation | Action |\n|-----------|--------|\n| No config | \"Run `p. init` first\" |\n| No state | Create default |\n| No agents | Warn, continue |\n\n## Disable\n\n```yaml\n---\norchestrator: false\n---\n```\n","agentic/task-fragmentation.md":"# Task Fragmentation\n\nBreak complex multi-domain tasks into subtasks.\n\n## When to Fragment\n\n- Spans 3+ domains (frontend + backend + database)\n- Has natural dependency order\n- Too large for single execution\n\n## When NOT to Fragment\n\n- Single domain only\n- Small, focused change\n- Already atomic\n\n## Dependency Order\n\n1. **Database** (models first)\n2. **Backend** (API using models)\n3. **Frontend** (UI using API)\n4. **Testing** (tests for all)\n5. **DevOps** (deploy)\n\n## Subtask Format\n\n```json\n{\n  \"subtasks\": [{\n    \"id\": \"subtask-1\",\n    \"description\": \"Create users table\",\n    \"domain\": \"database\",\n    \"agent\": \"database.md\",\n    \"dependsOn\": []\n  }]\n}\n```\n\n## Output\n\n```\n🎯 Task: {task}\n\n📋 Subtasks:\n├─ 1. [database] Create schema\n├─ 2. [backend] Create API\n└─ 3. [frontend] Create form\n```\n\n## Delegation\n\n```\nTask(\n  subagent_type: 'general-purpose',\n  prompt: '\n    Read: {agentsPath}/{domain}.md\n    Subtask: {description}\n    Previous: {previousSummary}\n    Focus ONLY on this subtask.\n  '\n)\n```\n\n## Progress\n\n```\n📊 Progress: 2/4 (50%)\n✅ 1. [database] Done\n✅ 2. [backend] Done\n▶️ 3. [frontend] ← CURRENT\n⏳ 4. [testing]\n```\n\n## Error Handling\n\n```\n❌ Subtask 2/4 failed\n\nOptions:\n1. Retry\n2. Skip and continue\n3. Abort\n```\n\n## Anti-Patterns\n\n- Over-fragmentation: 10 subtasks for \"add button\"\n- Under-fragmentation: 1 subtask for \"add auth system\"\n- Wrong order: Frontend before backend\n","agents/AGENTS.md":"# AGENTS.md\n\nAI assistant guidance for **prjct-cli** - context layer for AI coding agents. Works with Claude Code, Gemini CLI, and more.\n\n## What This Is\n\n**NOT** project management. NO sprints, story points, ceremonies, or meetings.\n\n**IS** a context layer that gives AI agents the project knowledge they need to work effectively.\n\n---\n\n## Dynamic Agent Generation\n\nGenerate agents during `p. sync` based on analysis:\n\n```javascript\nawait generator.generateDynamicAgent('agent-name', {\n  role: 'Role Description',\n  expertise: 'Technologies, versions, tools',\n  responsibilities: 'What they handle'\n})\n```\n\n### Guidelines\n1. Read `analysis/repo-summary.md` first\n2. Create specialists for each major technology\n3. Name descriptively: `go-backend` not `be`\n4. Include versions and frameworks found\n5. Follow project-specific patterns\n\n## Architecture\n\n**Global**: `~/.prjct-cli/projects/{id}/`\n```\nprjct.db   # SQLite database (all state)\ncontext/   # now.md, next.md\nagents/    # domain specialists\n```\n\n**Local**: `.prjct/prjct.config.json` (read-only)\n\n## Commands\n\n| Command | Action |\n|---------|--------|\n| `p. init` | Initialize |\n| `p. sync` | Analyze + generate agents |\n| `p. task X` | Start task |\n| `p. done` | Complete subtask |\n| `p. ship` | Ship feature |\n| `p. next` | Show queue |\n\n## Intent Detection\n\n| Intent | Command |\n|--------|---------|\n| Start task | `p. task` |\n| Finish | `p. done` |\n| Ship | `p. ship` |\n| What's next | `p. next` |\n\n## Implementation\n\n- Atomic operations via `prjct` CLI\n- CLI handles all state persistence (SQLite)\n- Handle missing config gracefully\n\n## Crew mode (opt-in)\n\nProjects 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`.\n\n### Crew roster\n\nEach 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`.\n\n| Name | Role | Color |\n|---|---|---|\n| Leader | Orchestrator | blue |\n| Implementer | Worker | purple |\n| Reviewer | Strict auditor | pink |\n\nCrew 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\").\n","antigravity/SKILL.md":"---\nname: prjct\ndescription: Use when user mentions p., prjct, task tracking, or workflow commands.\n---\n\n# prjct — Context layer for AI agents\n\nGrammar: `p. <command> [args]` or `prjct <command> --md`\n\nCore commands: sync, task, done, ship, pause, resume, next, bug, workflow, tokens\nIntegrations: linear, jira, enrich\nOther: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nRules:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- All commits include footer: `Generated with [p/](https://www.prjct.app/)`\n- All storage through `prjct` CLI (SQLite internally)\n- Start code tasks with `p. task` and follow Context Contract from CLI output\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n","checklists/architecture.md":"# Architecture Checklist\n\n> Applies to ANY system architecture\n\n## Design Principles\n- [ ] Clear separation of concerns\n- [ ] Loose coupling between components\n- [ ] High cohesion within modules\n- [ ] Single source of truth for data\n- [ ] Explicit dependencies (no hidden coupling)\n\n## Scalability\n- [ ] Stateless where possible\n- [ ] Horizontal scaling considered\n- [ ] Bottlenecks identified\n- [ ] Caching strategy defined\n\n## Resilience\n- [ ] Failure modes documented\n- [ ] Graceful degradation planned\n- [ ] Recovery procedures defined\n- [ ] Circuit breakers where needed\n\n## Maintainability\n- [ ] Clear boundaries between layers\n- [ ] Easy to test in isolation\n- [ ] Configuration externalized\n- [ ] Logging and observability built-in\n","checklists/code-quality.md":"# Code Quality Checklist\n\n> Universal principles for ANY programming language\n\n## Universal Principles\n- [ ] Single Responsibility: Each unit does ONE thing well\n- [ ] DRY: No duplicated logic (extract shared code)\n- [ ] KISS: Simplest solution that works\n- [ ] Clear naming: Self-documenting identifiers\n- [ ] Consistent patterns: Match existing codebase style\n\n## Error Handling\n- [ ] All error paths handled gracefully\n- [ ] Meaningful error messages\n- [ ] No silent failures\n- [ ] Proper resource cleanup (files, connections, memory)\n\n## Edge Cases\n- [ ] Null/nil/None handling\n- [ ] Empty collections handled\n- [ ] Boundary conditions tested\n- [ ] Invalid input rejected early\n\n## Code Organization\n- [ ] Functions/methods are small and focused\n- [ ] Related code grouped together\n- [ ] Clear module/package boundaries\n- [ ] No circular dependencies\n","checklists/data.md":"# Data Checklist\n\n> Applies to: SQL, NoSQL, GraphQL, File storage, Caching\n\n## Data Integrity\n- [ ] Schema/structure defined\n- [ ] Constraints enforced\n- [ ] Transactions used appropriately\n- [ ] Referential integrity maintained\n\n## Query Performance\n- [ ] Indexes on frequent queries\n- [ ] N+1 queries eliminated\n- [ ] Query complexity analyzed\n- [ ] Pagination for large datasets\n\n## Data Operations\n- [ ] Migrations versioned and reversible\n- [ ] Backup and restore tested\n- [ ] Data validation at boundary\n- [ ] Soft deletes considered (if applicable)\n\n## Caching\n- [ ] Cache invalidation strategy defined\n- [ ] TTL values appropriate\n- [ ] Cache warming considered\n- [ ] Cache hit/miss monitored\n\n## Data Privacy\n- [ ] PII identified and protected\n- [ ] Data anonymization where needed\n- [ ] Audit trail for sensitive data\n- [ ] Data deletion procedures defined\n","checklists/documentation.md":"# Documentation Checklist\n\n> Applies to ALL projects\n\n## Essential Docs\n- [ ] README with quick start\n- [ ] Installation instructions\n- [ ] Configuration options documented\n- [ ] Common use cases shown\n\n## Code Documentation\n- [ ] Public APIs documented\n- [ ] Complex logic explained\n- [ ] Architecture decisions recorded (ADRs)\n- [ ] Diagrams for complex flows\n\n## Operational Docs\n- [ ] Deployment process documented\n- [ ] Troubleshooting guide\n- [ ] Runbooks for common issues\n- [ ] Changelog maintained\n\n## API Documentation\n- [ ] All endpoints documented\n- [ ] Request/response examples\n- [ ] Error codes explained\n- [ ] Authentication documented\n\n## Maintenance\n- [ ] Docs updated with code changes\n- [ ] Version-specific documentation\n- [ ] Broken links checked\n- [ ] Examples tested and working\n","checklists/infrastructure.md":"# Infrastructure Checklist\n\n> Applies to: Cloud, On-prem, Hybrid, Edge\n\n## Deployment\n- [ ] Infrastructure as Code (Terraform, Pulumi, CloudFormation, etc.)\n- [ ] Reproducible environments\n- [ ] Rollback strategy defined\n- [ ] Blue-green or canary deployment option\n\n## Observability\n- [ ] Logging strategy defined\n- [ ] Metrics collection configured\n- [ ] Alerting thresholds set\n- [ ] Distributed tracing (if applicable)\n\n## Security\n- [ ] Secrets management (not in code)\n- [ ] Network segmentation\n- [ ] Least privilege access\n- [ ] Encryption at rest and in transit\n\n## Reliability\n- [ ] Backup strategy defined\n- [ ] Disaster recovery plan\n- [ ] Health checks configured\n- [ ] Auto-scaling rules (if applicable)\n\n## Cost Management\n- [ ] Resource sizing appropriate\n- [ ] Unused resources identified\n- [ ] Cost monitoring in place\n- [ ] Budget alerts configured\n","checklists/performance.md":"# Performance Checklist\n\n> Applies to: Backend, Frontend, Mobile, Database\n\n## Analysis\n- [ ] Bottlenecks identified with profiling\n- [ ] Baseline metrics established\n- [ ] Performance budgets defined\n- [ ] Benchmarks before/after changes\n\n## Optimization Strategies\n- [ ] Algorithmic complexity reviewed (O(n) vs O(n²))\n- [ ] Appropriate data structures used\n- [ ] Caching implemented where beneficial\n- [ ] Lazy loading for expensive operations\n\n## Resource Management\n- [ ] Memory usage optimized\n- [ ] Connection pooling used\n- [ ] Batch operations where applicable\n- [ ] Async/parallel processing considered\n\n## Frontend Specific\n- [ ] Bundle size optimized\n- [ ] Images optimized\n- [ ] Critical rendering path optimized\n- [ ] Network requests minimized\n\n## Backend Specific\n- [ ] Database queries optimized\n- [ ] Response compression enabled\n- [ ] Proper indexing in place\n- [ ] Connection limits configured\n","checklists/security.md":"# Security Checklist\n\n> ALWAYS ON - Applies to ALL applications\n\n## Input/Output\n- [ ] All user input validated and sanitized\n- [ ] Output encoded appropriately (prevent injection)\n- [ ] File uploads restricted and scanned\n- [ ] No sensitive data in logs or error messages\n\n## Authentication & Authorization\n- [ ] Strong authentication mechanism\n- [ ] Proper session management\n- [ ] Authorization checked at every access point\n- [ ] Principle of least privilege applied\n\n## Data Protection\n- [ ] Sensitive data encrypted at rest\n- [ ] Secure transmission (TLS/HTTPS)\n- [ ] PII handled according to regulations\n- [ ] Data retention policies followed\n\n## Dependencies\n- [ ] Dependencies from trusted sources\n- [ ] Known vulnerabilities checked\n- [ ] Minimal dependency surface\n- [ ] Regular security updates planned\n\n## API Security\n- [ ] Rate limiting implemented\n- [ ] Authentication required for sensitive endpoints\n- [ ] CORS properly configured\n- [ ] API keys/tokens secured\n","checklists/testing.md":"# Testing Checklist\n\n> Applies to: Unit, Integration, E2E, Performance testing\n\n## Coverage Strategy\n- [ ] Critical paths have high coverage\n- [ ] Happy path tested\n- [ ] Error paths tested\n- [ ] Edge cases covered\n\n## Test Quality\n- [ ] Tests are deterministic (no flaky tests)\n- [ ] Tests are independent (no order dependency)\n- [ ] Tests are fast (optimize slow tests)\n- [ ] Tests are readable (clear intent)\n\n## Test Types\n- [ ] Unit tests for business logic\n- [ ] Integration tests for boundaries\n- [ ] E2E tests for critical flows\n- [ ] Performance tests for bottlenecks\n\n## Mocking Strategy\n- [ ] External services mocked\n- [ ] Database isolated or mocked\n- [ ] Time-dependent code controlled\n- [ ] Random values seeded\n\n## Test Maintenance\n- [ ] Tests updated with code changes\n- [ ] Dead tests removed\n- [ ] Test data managed properly\n- [ ] CI/CD integration working\n","checklists/ux-ui.md":"# UX/UI Checklist\n\n> Applies to: Web, Mobile, CLI, Desktop, API DX\n\n## User Experience\n- [ ] Clear user journey/flow\n- [ ] Feedback for every action\n- [ ] Loading states shown\n- [ ] Error states handled gracefully\n- [ ] Success confirmation provided\n\n## Interface Design\n- [ ] Consistent visual language\n- [ ] Intuitive navigation\n- [ ] Responsive/adaptive layout (if applicable)\n- [ ] Touch targets adequate (mobile)\n- [ ] Keyboard navigation (web/desktop)\n\n## CLI Specific\n- [ ] Help text for all commands\n- [ ] Clear error messages with suggestions\n- [ ] Progress indicators for long operations\n- [ ] Consistent flag naming conventions\n- [ ] Exit codes meaningful\n\n## API DX (Developer Experience)\n- [ ] Intuitive endpoint/function naming\n- [ ] Consistent response format\n- [ ] Helpful error messages with codes\n- [ ] Good documentation with examples\n- [ ] Predictable behavior\n\n## Information Architecture\n- [ ] Content hierarchy clear\n- [ ] Important actions prominent\n- [ ] Related items grouped\n- [ ] Search/filter for large datasets\n","codex/SKILL.md":"---\nname: prjct\ndescription: Use when the user mentions p., prjct, tasks, specs, shipping, or project memory. Routes to the prjct CLI and MCP tools — run commands on demand, do not preload context.\n---\n\n# prjct — project memory & workflow\n\nRun `prjct <command> --md` and follow its output. Pull context on demand; never dump it all.\n\n- Flow: `task` → work → `done` → `ship`\n- Memory: `prjct remember <decision|gotcha|learning|fact> \"<text>\"`, `prjct context memory <topic>` (recall), `prjct guard <file>` (preventive memory before editing)\n- Capture stray thoughts: `prjct capture \"<text>\"`\n- Worktrees: remove only AFTER the PR merges, from the main worktree; never with unpushed work.\n- Run `prjct --help` for the full command list; prefer the prjct MCP tools (`prjct_*`) when available.\n\nCommit footer: `Generated with [p/](https://www.prjct.app/)`\n","config/skill-mappings.json":"{\n  \"version\": \"3.0.0\",\n  \"description\": \"Skill packages from skills.sh for auto-installation during sync\",\n  \"sources\": {\n    \"primary\": {\n      \"name\": \"skills.sh\",\n      \"url\": \"https://skills.sh\",\n      \"installCmd\": \"npx skills add {package}\"\n    },\n    \"fallback\": {\n      \"name\": \"GitHub direct\",\n      \"installFormat\": \"owner/repo\"\n    }\n  },\n  \"skillsDirectory\": \"~/.claude/skills/\",\n  \"skillFormat\": {\n    \"required\": [\"name\", \"description\"],\n    \"optional\": [\"license\", \"compatibility\", \"metadata\", \"allowed-tools\"],\n    \"fileStructure\": {\n      \"required\": \"SKILL.md\",\n      \"optional\": [\"scripts/\", \"references/\", \"assets/\"]\n    }\n  },\n  \"agentToSkillMap\": {\n    \"frontend\": {\n      \"packages\": [\n        \"anthropics/skills/frontend-design\",\n        \"vercel-labs/agent-skills/vercel-react-best-practices\"\n      ]\n    },\n    \"uxui\": {\n      \"packages\": [\"anthropics/skills/frontend-design\"]\n    },\n    \"backend\": {\n      \"packages\": [\"obra/superpowers/systematic-debugging\"]\n    },\n    \"database\": {\n      \"packages\": []\n    },\n    \"testing\": {\n      \"packages\": [\"obra/superpowers/test-driven-development\", \"anthropics/skills/webapp-testing\"]\n    },\n    \"devops\": {\n      \"packages\": [\"anthropics/skills/mcp-builder\"]\n    },\n    \"prjct-planner\": {\n      \"packages\": [\"obra/superpowers/brainstorming\"]\n    },\n    \"prjct-shipper\": {\n      \"packages\": []\n    },\n    \"prjct-workflow\": {\n      \"packages\": []\n    }\n  },\n  \"documentSkills\": {\n    \"note\": \"Official Anthropic document creation skills\",\n    \"source\": \"anthropics/skills\",\n    \"skills\": {\n      \"pdf\": {\n        \"name\": \"pdf\",\n        \"description\": \"Create and edit PDF documents\",\n        \"path\": \"skills/pdf\"\n      },\n      \"docx\": {\n        \"name\": \"docx\",\n        \"description\": \"Create and edit Word documents\",\n        \"path\": \"skills/docx\"\n      },\n      \"pptx\": {\n        \"name\": \"pptx\",\n        \"description\": \"Create PowerPoint presentations\",\n        \"path\": \"skills/pptx\"\n      },\n      \"xlsx\": {\n        \"name\": \"xlsx\",\n        \"description\": \"Create Excel spreadsheets\",\n        \"path\": \"skills/xlsx\"\n      }\n    }\n  }\n}\n","context/dashboard.md":"---\ndescription: 'Template for generated dashboard context'\ngenerated-by: 'p. dashboard'\ndata-source: 'prjct.db (SQLite)'\n---\n\n# Dashboard Context Template\n\nThis template defines the format for `{globalPath}/context/dashboard.md` generated by `p. dashboard`.\n\n---\n\n## Template\n\n```markdown\n# Dashboard\n\n**Project:** {projectName}\n**Generated:** {timestamp}\n\n---\n\n## Health Score\n\n**Overall:** {healthScore}/100\n\n| Component | Score | Weight | Contribution |\n|-----------|-------|--------|--------------|\n| Roadmap Progress | {roadmapScore}/100 | 25% | {roadmapContribution} |\n| Estimation Accuracy | {estimationScore}/100 | 25% | {estimationContribution} |\n| Success Rate | {successScore}/100 | 25% | {successContribution} |\n| Velocity Trend | {velocityScore}/100 | 25% | {velocityContribution} |\n\n---\n\n## Quick Stats\n\n| Metric | Value | Trend |\n|--------|-------|-------|\n| Features Shipped | {shippedCount} | {shippedTrend} |\n| PRDs Created | {prdCount} | {prdTrend} |\n| Avg Cycle Time | {avgCycleTime}d | {cycleTrend} |\n| Estimation Accuracy | {estimationAccuracy}% | {accuracyTrend} |\n| Success Rate | {successRate}% | {successTrend} |\n| ROI Score | {avgROI} | {roiTrend} |\n\n---\n\n## Active Quarter: {activeQuarter.id}\n\n**Theme:** {activeQuarter.theme}\n**Status:** {activeQuarter.status}\n\n### Progress\n\n```\nFeatures:  {featureBar} {quarterFeatureProgress}%\nCapacity:  {capacityBar} {capacityUtilization}%\nTimeline:  {timelineBar} {timelineProgress}%\n```\n\n### Features\n\n| Feature | Status | Progress | Owner |\n|---------|--------|----------|-------|\n{FOR EACH feature in quarterFeatures:}\n| {feature.name} | {statusEmoji(feature.status)} | {feature.progress}% | {feature.agent || '-'} |\n{END FOR}\n\n---\n\n## Current Work\n\n### Active Task\n{IF currentTask:}\n**{currentTask.description}**\n\n- Type: {currentTask.type}\n- Started: {currentTask.startedAt}\n- Elapsed: {elapsed}\n- Branch: {currentTask.branch?.name || 'N/A'}\n\nSubtasks: {completedSubtasks}/{totalSubtasks}\n{ELSE:}\n*No active task*\n{END IF}\n\n### In Progress Features\n\n{FOR EACH feature in activeFeatures:}\n#### {feature.name}\n\n- Progress: {progressBar(feature.progress)} {feature.progress}%\n- Quarter: {feature.quarter || 'Unassigned'}\n- PRD: {feature.prdId || 'None'}\n- Dependencies: {feature.dependencies?.join(', ') || 'None'}\n{END FOR}\n\n---\n\n## Pipeline\n\n```\nPRDs          Features       Active         Shipped\n┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐\n│ Draft   │──▶│ Planned │──▶│ Active  │──▶│ Shipped │\n│  ({draft})  │   │  ({planned}) │   │  ({active})  │   │  ({shipped}) │\n└─────────┘   └─────────┘   └─────────┘   └─────────┘\n     │\n     ▼\n┌─────────┐\n│Approved │\n│  ({approved}) │\n└─────────┘\n```\n\n---\n\n## Metrics Trends (Last 4 Weeks)\n\n### Velocity\n```\nW-3: {velocityW3Bar} {velocityW3}\nW-2: {velocityW2Bar} {velocityW2}\nW-1: {velocityW1Bar} {velocityW1}\nW-0: {velocityW0Bar} {velocityW0}\n```\n\n### Estimation Accuracy\n```\nW-3: {accuracyW3Bar} {accuracyW3}%\nW-2: {accuracyW2Bar} {accuracyW2}%\nW-1: {accuracyW1Bar} {accuracyW1}%\nW-0: {accuracyW0Bar} {accuracyW0}%\n```\n\n---\n\n## Alerts & Actions\n\n### Warnings\n{FOR EACH alert in alerts:}\n- {alert.icon} {alert.message}\n{END FOR}\n\n### Suggested Actions\n{FOR EACH action in suggestedActions:}\n1. {action.description}\n   - Command: `{action.command}`\n{END FOR}\n\n---\n\n## Recent Activity\n\n| Date | Action | Details |\n|------|--------|---------|\n{FOR EACH event in recentEvents.slice(0, 10):}\n| {event.date} | {event.action} | {event.details} |\n{END FOR}\n\n---\n\n## Learnings Summary\n\n### Top Patterns\n{FOR EACH pattern in topPatterns.slice(0, 5):}\n- {pattern.insight} ({pattern.frequency}x)\n{END FOR}\n\n### Improvement Areas\n{FOR EACH area in improvementAreas:}\n- **{area.name}**: {area.suggestion}\n{END FOR}\n\n---\n\n*Generated by prjct-cli | https://prjct.app*\n```\n\n---\n\n## Health Score Calculation\n\n```javascript\nconst healthScore = Math.round(\n  (roadmapProgress * 0.25) +\n  (estimationAccuracy * 0.25) +\n  (successRate * 0.25) +\n  (normalizedVelocity * 0.25)\n)\n```\n\n| Score Range | Health Level | Color |\n|-------------|--------------|-------|\n| 80-100 | Excellent | Green |\n| 60-79 | Good | Blue |\n| 40-59 | Needs Attention | Yellow |\n| 0-39 | Critical | Red |\n\n---\n\n## Alert Definitions\n\n| Condition | Alert | Severity |\n|-----------|-------|----------|\n| `capacityUtilization > 90` | Quarter capacity nearly full | Warning |\n| `estimationAccuracy < 60` | Estimation accuracy below target | Warning |\n| `activeFeatures.length > 3` | Too many features in progress | Info |\n| `draftPRDs.length > 3` | PRDs awaiting review | Info |\n| `successRate < 70` | Success rate declining | Warning |\n| `velocityTrend < -20` | Velocity dropping | Warning |\n| `currentTask && elapsed > 4h` | Task running long | Info |\n\n---\n\n## Suggested Actions Matrix\n\n| Condition | Suggested Action | Command |\n|-----------|------------------|---------|\n| No active task | Start a task | `p. task` |\n| PRDs in draft | Review PRDs | `p. prd list` |\n| Features pending review | Record impact | `p. impact` |\n| Quarter ending soon | Plan next quarter | `p. plan quarter` |\n| Low estimation accuracy | Analyze estimates | `p. dashboard estimates` |\n\n---\n\n## Integration with Linear/Jira/Monday\n\nThe dashboard context maps to PM tool dashboards:\n\n| Dashboard Section | Linear | Jira | Monday |\n|-------------------|--------|------|--------|\n| Health Score | Project Health | Dashboard Gadget | Board Overview |\n| Active Quarter | Cycle | Sprint | Timeline |\n| Pipeline | Workflow Board | Kanban | Board |\n| Velocity | Velocity Chart | Velocity Report | Chart Widget |\n| Alerts | Notifications | Issues | Notifications |\n\n---\n\n## Refresh Frequency\n\n| Data Type | Refresh Trigger |\n|-----------|-----------------|\n| Current Task | Real-time (on state change) |\n| Features | On feature status change |\n| Metrics | On `p. dashboard` execution |\n| Aggregates | On `p. impact` completion |\n| Alerts | Calculated on view |\n","context/roadmap.md":"---\ndescription: 'Template for generated roadmap context'\ngenerated-by: 'p. plan, p. sync'\ndata-source: 'prjct.db (SQLite)'\n---\n\n# Roadmap Context Template\n\nThis template defines the format for `{globalPath}/context/roadmap.md` generated by:\n- `p. plan` - After quarter planning\n- `p. sync` - After roadmap generation from git\n\n---\n\n## Template\n\n```markdown\n# Roadmap\n\n**Last Updated:** {lastUpdated}\n\n---\n\n## Strategy\n\n**Goal:** {strategy.goal}\n\n### Phases\n{FOR EACH phase in strategy.phases:}\n- **{phase.id}**: {phase.name} ({phase.status})\n{END FOR}\n\n### Success Metrics\n{FOR EACH metric in strategy.successMetrics:}\n- {metric}\n{END FOR}\n\n---\n\n## Quarters\n\n{FOR EACH quarter in quarters:}\n### {quarter.id}: {quarter.name}\n\n**Status:** {quarter.status}\n**Theme:** {quarter.theme}\n**Capacity:** {capacity.allocatedHours}/{capacity.totalHours}h ({utilization}%)\n\n#### Goals\n{FOR EACH goal in quarter.goals:}\n- {goal}\n{END FOR}\n\n#### Features\n{FOR EACH featureId in quarter.features:}\n- [{status icon}] **{feature.name}** ({feature.status}, {feature.progress}%)\n  - PRD: {feature.prdId || 'None (legacy)'}\n  - Estimated: {feature.effortTracking?.estimated?.hours || '?'}h\n  - Value Score: {feature.valueScore || 'N/A'}\n  - Dependencies: {feature.dependencies?.join(', ') || 'None'}\n{END FOR}\n\n{END FOR}\n\n---\n\n## Active Work\n\n{FOR EACH feature WHERE status == 'active':}\n### {feature.name}\n\n| Attribute | Value |\n|-----------|-------|\n| Progress | {feature.progress}% |\n| Branch | {feature.branch || 'N/A'} |\n| Quarter | {feature.quarter || 'Unassigned'} |\n| PRD | {feature.prdId || 'Legacy (no PRD)'} |\n| Started | {feature.createdAt} |\n\n#### Tasks\n{FOR EACH task in feature.tasks:}\n- [{task.completed ? 'x' : ' '}] {task.description}\n{END FOR}\n\n{END FOR}\n\n---\n\n## Completed Features\n\n{FOR EACH feature WHERE status == 'completed' OR status == 'shipped':}\n- **{feature.name}** (v{feature.version || 'N/A'})\n  - Shipped: {feature.shippedAt || feature.completedDate}\n  - Actual: {feature.effortTracking?.actual?.hours || '?'}h vs Est: {feature.effortTracking?.estimated?.hours || '?'}h\n{END FOR}\n\n---\n\n## Backlog\n\nPriority-ordered list of unscheduled items:\n\n| Priority | Item | Value | Effort | Score |\n|----------|------|-------|--------|-------|\n{FOR EACH item in backlog:}\n| {rank} | {item.title} | {item.valueScore} | {item.effortEstimate}h | {priorityScore} |\n{END FOR}\n\n---\n\n## Legacy Features\n\nFeatures detected from git history (no PRD required):\n\n{FOR EACH feature WHERE legacy == true:}\n- **{feature.name}**\n  - Inferred From: {feature.inferredFrom}\n  - Status: {feature.status}\n  - Commits: {feature.commits?.length || 0}\n{END FOR}\n\n---\n\n## Dependencies\n\n```\n{FOR EACH feature WHERE dependencies?.length > 0:}\n{feature.name}\n{FOR EACH depId in feature.dependencies:}\n  └── {dependency.name}\n{END FOR}\n{END FOR}\n```\n\n---\n\n## Metrics Summary\n\n| Metric | Value |\n|--------|-------|\n| Total Features | {features.length} |\n| Planned | {planned.length} |\n| Active | {active.length} |\n| Completed | {completed.length} |\n| Shipped | {shipped.length} |\n| Legacy | {legacy.length} |\n| PRD-Backed | {prdBacked.length} |\n| Backlog | {backlog.length} |\n\n### Capacity by Quarter\n\n| Quarter | Allocated | Total | Utilization |\n|---------|-----------|-------|-------------|\n{FOR EACH quarter in quarters:}\n| {quarter.id} | {capacity.allocatedHours}h | {capacity.totalHours}h | {utilization}% |\n{END FOR}\n\n### Effort Accuracy (Shipped Features)\n\n| Feature | Estimated | Actual | Variance |\n|---------|-----------|--------|----------|\n{FOR EACH feature WHERE status == 'shipped' AND effortTracking:}\n| {feature.name} | {estimated.hours}h | {actual.hours}h | {variance}% |\n{END FOR}\n\n**Average Variance:** {averageVariance}%\n\n---\n\n*Generated by prjct-cli | https://prjct.app*\n```\n\n---\n\n## Status Icons\n\n| Status | Icon |\n|--------|------|\n| planned | [ ] |\n| active | [~] |\n| completed | [x] |\n| shipped | [+] |\n\n---\n\n## Variable Reference\n\n| Variable | Source | Description |\n|----------|--------|-------------|\n| `lastUpdated` | roadmap.lastUpdated | ISO timestamp |\n| `strategy` | roadmap.strategy | Strategy object |\n| `quarters` | roadmap.quarters | Array of quarters |\n| `features` | roadmap.features | Array of features |\n| `backlog` | roadmap.backlog | Array of backlog items |\n| `utilization` | Calculated | (allocated/total) * 100 |\n| `priorityScore` | Calculated | valueScore / (effort/10) |\n\n---\n\n## Generation Rules\n\n1. **Quarters** - Show only `planned` and `active` quarters by default\n2. **Features** - Group by status (active first, then planned)\n3. **Backlog** - Sort by priority score (descending)\n4. **Legacy** - Always show separately to distinguish from PRD-backed\n5. **Dependencies** - Only show features with dependencies\n6. **Metrics** - Always include for dashboard views\n\n---\n\n## Integration with Linear/Jira/Monday\n\nThe context file maps to PM tool exports:\n\n| Context Section | Linear | Jira | Monday |\n|-----------------|--------|------|--------|\n| Quarters | Cycles | Sprints | Timelines |\n| Features | Issues | Stories | Items |\n| Backlog | Backlog | Backlog | Inbox |\n| Status | State | Status | Status |\n| Capacity | Estimates | Story Points | Time |\n","crew/CHECKPOINTS.md":"# CHECKPOINTS — End-state criteria\n\n> In multi-agent systems you don't evaluate the path, you evaluate the destination.\n> These are the objective checkboxes a reviewer (human or AI) walks through to decide\n> whether the project is healthy after a session.\n\n> **Customise this file for your project.** The defaults below cover the generic\n> crew invariants. Add project-specific items (lint rules, build commands,\n> deployment gates) under the matching section.\n\n## C1 — The crew is wired\n\n- [ ] `.prjct/prjct.config.json` exists and points to a valid project ID.\n- [ ] The `crew:checkpoints` row exists in kv_store (the gate criteria the reviewer applies — visible via `prjct crew checkpoints`).\n- [ ] `.claude/agents/leader.md`, `implementer.md`, `reviewer.md` are present.\n- [ ] Project `CLAUDE.md` (or equivalent) contains the crew leader-mode block.\n\n## C2 — State is coherent\n\n- [ ] At most **one** task is in `active` status (`prjct status --md`).\n- [ ] No task in `active` is older than the current session without a captured blocker note.\n- [ ] Every task marked `done` has at least one paired test file (or a justified exception in the implementer report).\n\n## C3 — The code respects the architecture\n\n- [ ] Modified files follow the conventions of their neighbouring files (style, naming, imports).\n- [ ] No new runtime dependencies were added without a `prjct capture --tags dep-add` note.\n- [ ] No debug noise: no `console.log` / `print()` / `dbg!` left in source.\n- [ ] No `TODO` without a captured follow-up in `prjct capture`.\n\n## C4 — Verification is real\n\n- [ ] The project's test command was run for this session and exited cleanly.\n- [ ] Every new public function has at least one test covering the happy path.\n- [ ] Every new error path has at least one test asserting the error is raised/returned.\n- [ ] Tests use real temp dirs / real fixtures, not blanket mocks of the filesystem or DB.\n\n## C5 — The session closed cleanly\n\n- [ ] No untracked junk in the worktree (`*.tmp`, scratch logs, accidental binaries, any subdirectory of `.prjct/`).\n- [ ] The implementer replied inline with the summary block (STATUS / PLAN / FILES TOUCHED / VERIFICATION / NOTES).\n- [ ] The reviewer replied inline with `VERDICT: APPROVED` (first line).\n- [ ] The task's status was advanced (`prjct status done` for completed work, `prjct status paused` if intentionally paused).\n\n---\n\n**How to use this file:**\n\nThe `reviewer` subagent reads every checkbox, marks `[x]` for met and `[ ]` for missed,\nand refuses to approve session close if any C1-C5 box remains unchecked. Customise the\nlist with project-specific gates (lint, typecheck, build, deploy preview, etc.).\n","crew/CLAUDE-leader-mode.md":"<!-- prjct:crew:start - DO NOT REMOVE THIS MARKER -->\n## Crew leader mode\n\nThis project is in **crew mode**. The main session always acts as the `leader` subagent (see `.claude/agents/leader.md`). The leader **decomposes and coordinates** — it does not implement.\n\n### This overrides the prjct skill's \"do simple work directly\" rule — FOR CODE\n\nThe prjct skill says most work is simple → go direct, no subagents. In a crew project that rule does **not** mean \"the main session writes the code itself.\" It means the **triage moves inside you, the leader**: a trivial change is a 1-implementer dispatch (no spec, no extra ceremony), not a reason to skip the crew. For ANY work that writes code or tests, you dispatch — every time. The skill's \"go direct\" still applies to non-code turns (captures, memory, Q&A, read-only questions) — handle those yourself without subagents.\n\n### Hard rules for the main session\n\n- ❌ Do not edit application source or test files directly (no Edit, no Write, no Bash that writes to those paths) — no matter how small the change looks. Small ≠ skip-the-crew; small = one implementer.\n- ❌ Do not run `prjct status done` yourself — the implementer does that, but only after the reviewer approves.\n- ✅ For any code task, launch the appropriate subagent via the `Agent` tool:\n  - `subagent_type: \"implementer\"` → writes code and tests for one prjct task. Spawn **as many implementers as the work needs**: independent subtasks with **disjoint file scope** → one implementer per subtask, all dispatched in the SAME message so they run in parallel. You assign each its non-overlapping scope. If the parts can't be cleanly partitioned (they'd touch the same file), run them sequentially instead.\n  - `subagent_type: \"reviewer\"` → validates the implementers' combined work against the project checkpoints (embedded in the reviewer's prompt; manage via `prjct crew checkpoints`) before close. One reviewer over the whole diff, even after a parallel fan-out.\n  - For up-front investigation, launch 2-3 `Explore` (or `general-purpose`) subagents in parallel, each with a narrow question.\n\n### Model per role (perf — set `model:` on every `Agent` call)\n\nYou orchestrate on a small model on purpose; apply the same discipline to what you dispatch. A subagent inherits the parent's model unless its definition or your `Agent` call sets one:\n\n- `implementer` → `model: \"opus\"` — writes code, the only role that gets the max model. Each parallel implementer is its own `opus` call.\n- `reviewer` → `model: \"sonnet\"` — judgment, not implementation.\n- `Explore` / any read-only investigation → `model: \"haiku\"`.\n\n`implementer` and `reviewer` pin their model in their own definitions; set it explicitly for `Explore` and any ad-hoc subagent. Never let a non-implementer run on the max model.\n\n### Keep replies tight\n\nInstruct every subagent to reply with a **one-screen summary** — files touched, verification command + result, blockers — not full diffs or transcripts. You consume the reply directly; never tell subagents to write reports to disk.\n\nIf you need durable state that outlives the session, persist via `prjct` CLI verbs (`prjct spec`, `prjct remember`, `prjct capture`) — SQLite + the regenerated vault are the only allowed persistence surfaces.\n\n### When this role does NOT apply\n\n- Pure exploratory / read-only questions about the repo → answer directly.\n- Edits to docs, configuration files (e.g. `.prjct/prjct.config.json`), or this file → you may edit directly.\n\n### Hard persistence rule\n\nNever write audit, checkpoint, review, deploy, or report markdown into any new file or subdirectory under the prjct state folder, and no scratch `.md` anywhere else in the worktree. The ONLY hand-editable file in that folder is `.prjct/prjct.config.json`. Everything else — checkpoints, audits, decisions, learnings, deploy notes — lives in SQLite + the regenerated vault, written through `prjct` CLI verbs (`prjct crew checkpoints set`, `prjct remember`, `prjct capture`, `prjct spec record-review`). If a subagent reports findings, persist them via `prjct remember` and cite the returned mem id; never tell a subagent to write to disk.\n<!-- prjct:crew:end - DO NOT REMOVE THIS MARKER -->\n","crew/agents/implementer.md":"---\nname: implementer\ndescription: \"Implementer (Worker, purple). Implements exactly ONE prjct task end-to-end. Writes code, writes tests, self-verifies. Never approves its own work.\"\ntools: Read, Write, Edit, Glob, Grep, Bash\nmodel: opus\ncolor: purple\n---\n\n# Implementer\n\nYou are an implementer. Your job is to take **one** prjct task from active to ready-for-review.\n\n## Protocol\n\n1. **Orient.** Run `prjct context --md` to understand task and recent decisions. (The project's checkpoints are enforced by the reviewer at session close — you don't need to walk them yourself.)\n2. **Confirm scope.** Run `prjct status --md` — there must be exactly one active task. If not, stop and report `blocked -> no single active task`.\n3. **Plan.** State a 3-5 bullet plan as the FIRST thing you reply with at the end (files you will touch, tests you will add, verification command). Keep it inline — do not write the plan to disk.\n4. **Implement.** Follow the project's existing conventions (read neighboring files first; do not invent style). Stay within the task scope — if you discover the change touches a separate concern, stop and capture it: `prjct capture \"<text>\" --tags scope-creep`.\n5. **Test.** Every code change is paired with a test before moving on. Use the project's existing test runner.\n6. **Self-verify.** Run the project's tests. If they fail, return to step 4. If they pass, run `prjct check --md` if available; otherwise note the verification command and its outcome inline for your final reply.\n7. **Do not mark `done`.** The reviewer must approve first. Do not run `prjct status done` until the reviewer's reply is `APPROVED`.\n8. **Hand off.** Reply to the leader with a compact summary (≈one screen). The `FILES:` block is parsed by the leader to invoke `prjct crew record-run` — keep it strict: one path per line, no parens, no leading dash, no annotations:\n\n   ```\n   STATUS: ready-for-review\n\n   PLAN: <3-5 bullets from step 3>\n\n   FILES:\n   path/to/a.ts\n   path/to/a.test.ts\n\n   VERIFICATION: bun test path/to/a.test.ts  →  PASS (4 tests)\n\n   NOTES: <surprises, scope-creep captures by mem id, blockers>\n   ```\n\n   The leader will launch a `reviewer` next. Only after the reviewer approves does the implementer (in a follow-up turn) run `prjct status done`.\n\n## Hard rules\n\n- One task per session. If a tool fails unexpectedly, **do not improvise a workaround** — capture the blocker (`prjct capture \"<blocker>\" --tags blocker`) and stop.\n- Every code edit must be accompanied by its test before the next edit.\n- Never declare a task `done` without the reviewer's explicit `APPROVED`.\n- Never write debug `console.log` / `print` / scratch files into source. Clean up before handing off.\n- Never write report files into the working tree — no scratch `.md`, no subdirectory under `.prjct/`. Durable state goes through `prjct` CLI verbs only.\n\n## Keep your reply tight\n\nReply with the summary block above. Do not paste full diffs, do not paste full test output. If something is too long to summarize, capture it with `prjct remember <type> \"<text>\"` and cite the returned mem id in your NOTES line.\n","crew/agents/leader.md":"---\nname: leader\ndescription: \"Leader (Orchestrator, blue). Decomposes the user's request, delegates work to implementer/reviewer subagents, and never edits application code directly.\"\ntools: Read, Glob, Grep, Bash, Agent\nmodel: haiku\ncolor: blue\n---\n\n# Leader (Orchestrator)\n\nYou are the leader of this repository. Your only job is to **decompose and coordinate**, never to implement.\n\n## Boot protocol (run on first request of the session)\n\n1. Run `prjct context --md` to load current task, recent memory, and project state.\n2. Run `prjct status --md` to confirm whether there is an active task.\n3. If there is no active task and the user asked you to work on one, register it with `prjct task \"<description>\"` before delegating.\n4. The project's checkpoints (the gate the reviewer applies at session close) are embedded in the reviewer's prompt — you don't need to read them yourself; `prjct crew checkpoints` will print them if you want to see them.\n\n## How to break work down\n\nFor each request:\n\n1. Identify whether the work fits in **one** task or needs to be split.\n   - If split, register each part with `prjct task` (subtasks) so every implementer owns exactly one.\n2. Trivial change (1 file, no design surface) → 1 `implementer` subagent.\n3. Standard change (2-3 files) → 1 `implementer` then 1 `reviewer`.\n4. Investigation needed first → 2-3 `Explore` subagents in parallel, each with a narrow question, **then** implementer(s), **then** 1 `reviewer`.\n5. Refactor / architectural change → split into subtasks and apply this table again per subtask.\n6. **Independent subtasks → fan out implementers in parallel.** When the work splits into 2+ parts that touch **disjoint files** (no shared file between them), register each as a prjct subtask and launch **one `implementer` per subtask IN THE SAME MESSAGE** (one `Agent` tool-use block each, so they actually run concurrently). You spawn as many implementers as the work genuinely needs — there is no fixed \"one implementer\" rule.\n\n### Partition rule for parallel implementers (MUST)\n\nYou assign the work; the implementers never negotiate scope between themselves. Before fanning out:\n\n- Carve a **non-overlapping file scope** for each implementer and name it in that implementer's dispatch prompt (\"you own `src/auth/*` and its tests; do not touch anything else\").\n- If you **cannot** cleanly partition — two parts would edit the same file — **do NOT parallelize them**. Run those parts sequentially (or merge them into one subtask). Parallel writes to the same file clobber each other; a clean disjoint split is the only safe parallel.\n- One shared concern that several subtasks depend on (a type, a shared util) → do that part FIRST in its own implementer, let it return, THEN fan out the dependents.\n\n### Reviewing a fan-out\n\nAfter all parallel implementers return, launch **one** `reviewer` over the **combined** diff (`git diff --stat` shows every file touched across the fan-out). One reviewer pass validates the whole batch — do not spawn a reviewer per implementer; that burns tokens and the reviewer needs to see cross-subtask interactions anyway.\n\n## Keep subagent replies tight\n\nWhen you launch a subagent, instruct it to reply with a **one-screen summary** — files touched, verification command + outcome, blockers. Not a full diff, not a transcript, not a \"see attached\" file reference. You consume the reply directly.\n\nSubagents must not write reports to disk. Persistence on this project goes through `prjct` CLI verbs only — SQLite + the regenerated vault are the only allowed surfaces.\n\n## Model policy when dispatching (perf — non-negotiable)\n\nYou run on a small model on purpose: you orchestrate, you do not implement. Apply the same discipline to what you dispatch — a subagent inherits your model unless its definition or your Agent call sets one:\n\n- `implementer` → `model: \"opus\"` (it writes code; the only role that gets max).\n- `reviewer` → `model: \"sonnet\"` (judgment, not implementation).\n- `Explore` / any read-only investigation subagent you spawn → set `model: \"haiku\"` in the Agent call — they route information, they don't write code.\n\n`implementer` and `reviewer` already pin their model in their own definitions; you must set it explicitly for `Explore` and any ad-hoc subagent. Never let a non-implementer subagent run on the max model — that is what made tasks crawl.\n\n## Point, don't carry — nothing leaves prjct (MUST)\n\nThe plan, the task, and the memory live in prjct (SQLite + regenerated vault) — never in your dispatch prompt, never in a scratch file. When you delegate, your prompt NAMES where the work lives and the subagent reads it itself in its own window: `prjct context --md` (task + recent decisions), `prjct status --md` (active task), `prjct spec show <id> --md` (the plan), `prjct context memory <topic>` (memory). Do not paste task/plan/memory content into the subagent prompt — pass the command. Subagents persist back only through `prjct` verbs. No plan, memory, or task may exist outside prjct.\n\nExample correct prompt to a subagent:\n\n> \"Investigate how `notes.py` serializes IDs. Reply with up to ~25 lines: the relevant call sites (file:line), the serialization shape, and any surprises. If the answer is bigger, capture details with `prjct remember learning '<summary>'` and reply with the mem id + headline.\"\n\n### Why this is also a prompt-cache + token win (not just hygiene)\n\nPointing instead of carrying is what keeps you cheap:\n\n- Your own window stays lean — you never absorb the files/diffs the subagents read, so the cacheable prefix of YOUR context (system + this leader prompt + prjct state) stays stable across every dispatch and gets reused turn after turn.\n- Each subagent reads project state in ITS OWN fresh window via the `prjct` commands you name — that read is local to it and thrown away when it returns its one-screen summary. Nothing flows back into your context except the summary.\n- Keep dispatch prompts **structurally identical** across implementers (same skeleton: role line → the `prjct` commands to run → the disjoint scope → the output format). Stable, repeated prompt shapes are exactly what the prompt cache rewards; bespoke prose per dispatch defeats it.\n\nBurning tokens looks like: pasting file contents or task/plan/memory bodies into a dispatch, echoing a subagent's full transcript back to the user, or re-reading the same files in your own window that a subagent already read. Don't do any of those.\n\n## Session close protocol\n\nWhen the reviewer replies `VERDICT: APPROVED`:\n\n1. Parse the `FILES:` block (one path per line; no annotations) from EVERY implementer that ran this round and union them into a single comma-joined list (dedupe — a clean fan-out should have no overlap, but be safe). Combine the implementers' one-line summaries into the `--implementer-summary`.\n2. Call `prjct crew record-run` to persist the run as ONE durable DB row + vault page — one row per crew round, whether it was one implementer or a fan-out of several. Idempotent on `--run-id` (so a retry with the same id is safe):\n\n   ```\n   prjct crew record-run \\\n     --spec <spec-id-if-any> \\\n     --task <task-id-if-any> \\\n     --implementer-summary \"<the implementer's summary>\" \\\n     --files \"path/to/a.ts,path/to/a.test.ts\" \\\n     --reviewer-verdict APPROVED \\\n     --reviewer-notes \"<reviewer notes if any>\" \\\n     --md\n   ```\n\n3. Only AFTER `record-run` returns successfully (echoes `run-id=<uuid>`) do you tell the implementer to run `prjct status done`. The order is a gate — never advance the task before recording the run.\n\nIf the reviewer replies `VERDICT: CHANGES_REQUESTED`, do not call `record-run` for that round — pass the reviewer's notes back to the implementer for revision.\n\n## Effort scaling\n\n| Complexity                              | Subagents                                                  |\n|-----------------------------------------|------------------------------------------------------------|\n| Trivial (1 file)                        | 1 implementer                                              |\n| Standard (2-3 files)                    | 1 implementer + 1 reviewer                                 |\n| Independent subtasks (disjoint files)   | N implementers IN PARALLEL → 1 reviewer over combined diff |\n| Refactor / cross-cutting                | 2-3 explorers → implementer(s) → 1 reviewer                |\n| Very complex                            | Split into prjct subtasks; recurse per subtask             |\n\nMatch the implementer count to the work. One subtask → one implementer. Three genuinely independent, disjoint subtasks → three implementers at once. Do not pad the count (parallel `opus` implementers are the most expensive thing you can spawn — only fan out when the parts are truly independent) and do not under-spawn (serializing independent work wastes wall-clock).\n\n## What you do NOT do\n\n- Do not edit files in the application's source/test directories directly.\n- Do not mark a task as `done` yourself — the implementer does that after the reviewer approves.\n- Do not paste full subagent transcripts or diffs back to the user — summarize.\n\n## When this role does NOT apply\n\n- Pure exploration / read-only questions about the repo → answer directly, no subagents.\n- Edits to docs, configuration files (e.g. `.prjct/prjct.config.json`), or this file itself → you may edit directly.\n\n## Hard persistence rule\n\nNever write audit, checklist, review, deploy, or report markdown into any new file or subdirectory under the prjct state folder. The ONLY hand-editable file in that folder is `.prjct/prjct.config.json`. Durable state — checkpoints, audits, reviews, decisions, learnings — goes through `prjct` CLI verbs (`prjct crew checkpoints set`, `prjct remember`, `prjct capture`, `prjct spec record-review`). SQLite + the regenerated vault are the only allowed persistence surfaces.\n","crew/agents/reviewer.md":"---\nname: reviewer\ndescription: \"Reviewer (Strict auditor, pink). Approves or rejects an implementer's work against the project checkpoints and conventions. Never edits code.\"\ntools: Read, Glob, Grep, Bash\nmodel: sonnet\ncolor: pink\n---\n\n# Reviewer\n\nYou are a strict reviewer. Your only function is to **approve or reject** changes. You never edit code.\n\nThe project's checkpoints are inlined below (spliced in by `prjct crew install` from the kv_store row `crew:checkpoints`; manage them via `prjct crew checkpoints set|reset|export`). Walk every checkbox — `[x]` for met, `[ ]` for missed.\n\n## Checkpoints\n\n<!-- prjct:checkpoints:start - DO NOT EDIT (managed by `prjct crew checkpoints set|reset`) -->\n<!-- prjct:checkpoints:end -->\n\n## Protocol\n\n1. The implementer's report is **in the leader's dispatch prompt** — read it from there; do not look for a report file on disk.\n2. Identify the modified files (use `git status --porcelain` and `git diff --stat`). Cross-reference with the implementer's stated file list — flag any discrepancy.\n3. For each modified file, verify:\n   - It respects the project's conventions (style of neighboring files).\n   - Test coverage exists for the new behavior (find the corresponding test file).\n   - No debug noise was left behind (`console.log`, `print`, `TODO` without a captured note).\n4. Run the project's test command. Tests must pass — if any test is red, that is an automatic rejection.\n5. Walk every checkbox in the **Checkpoints** section above. Mark `[x]` for met, `[ ]` for missed.\n6. Reply to the leader with the verdict block (inline, no files).\n\n## Verdict format\n\nReply to the leader inline with this exact shape:\n\n```markdown\nVERDICT: APPROVED | CHANGES_REQUESTED\n\nCHECKPOINTS:\n- C1: [x]\n- C2: [x]\n- C3: [ ]  ← Reason: src/foo.ts imports `lodash`; the project disallows new runtime deps without prior capture\n- C4: [x]\n- C5: [x]\n\nREQUIRED CHANGES (if any):\n1. Remove `import lodash from 'lodash'` from src/foo.ts.\n2. ...\n```\n\nFirst line of the reply must be `VERDICT: APPROVED` or `VERDICT: CHANGES_REQUESTED`. The leader keys off that first token.\n\n## Hard rules\n\n- Never approve with red tests.\n- Never approve with empty checkboxes in C1-C5.\n- Never edit the implementer's code. Your job is to say what fails — not to fix it.\n- Be concrete: cite file paths and line numbers. No generic feedback.\n- Never write your verdict to a file. The reply itself IS the verdict.\n","crew/registry.json":"{\n  \"$schema\": \"./registry.schema.json\",\n  \"version\": 1,\n  \"crew\": [\n    {\n      \"id\": \"leader\",\n      \"name\": \"Leader\",\n      \"role\": \"Orchestrator\",\n      \"color\": \"blue\",\n      \"summary\": \"Decomposes the user's request and delegates to implementer/reviewer subagents. Never edits application code.\"\n    },\n    {\n      \"id\": \"implementer\",\n      \"name\": \"Implementer\",\n      \"role\": \"Worker\",\n      \"color\": \"purple\",\n      \"summary\": \"Takes one prjct task from active to ready-for-review. Writes code, writes tests, self-verifies. Never approves its own work.\"\n    },\n    {\n      \"id\": \"reviewer\",\n      \"name\": \"Reviewer\",\n      \"role\": \"Strict auditor\",\n      \"color\": \"pink\",\n      \"summary\": \"Approves or rejects work against project checkpoints and conventions. Never edits code.\"\n    }\n  ]\n}\n","cursor/commands/ship.md":"# /ship - Ship feature\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct ship {{args}} --md`\nFollow CLI output.\n","cursor/commands/task.md":"# /task - Start a task\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct task {{args}} --md`\nFollow CLI output.\n","cursor/p.md":"# p. Command Router for Cursor IDE\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct {{first_word_of_args}} {{rest_of_args}} --md`\nFollow CLI output.\n","cursor/router.mdc":"---\ndescription: \"prjct - Context layer for AI coding agents\"\nalwaysApply: true\n---\n\n# prjct\n\nCore: /sync, /task, /done, /ship, /pause, /resume, /next, /bug, /workflow\nOther: run `prjct <command> --md` and follow CLI output\n","global/ANTIGRAVITY.md":"<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Antigravity, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","global/CURSOR.mdc":"---\ndescription: \"prjct - Context layer for AI coding agents\"\nalwaysApply: true\n---\n\n<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Cursor, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","global/GEMINI.md":"<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Gemini, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","global/STORAGE-SPEC.md":"# Storage Specification\n\n**Canonical specification for prjct storage format.**\n\nAll storage is managed by the `prjct` CLI which uses SQLite (`prjct.db`) internally. **NEVER read or write JSON storage files directly. Use `prjct` CLI commands for all storage operations.**\n\n---\n\n## Current Storage: SQLite (prjct.db)\n\nAll reads and writes go through the `prjct` CLI, which manages a SQLite database (`prjct.db`) with WAL mode for safe concurrent access.\n\n```\n~/.prjct-cli/projects/{projectId}/\n├── prjct.db            # SQLite database (SOURCE OF TRUTH for all storage)\n├── context/\n│   ├── now.md          # Current task (generated from prjct.db)\n│   └── next.md         # Queue (generated from prjct.db)\n├── config/\n│   └── skills.json     # Agent-to-skill mappings\n├── agents/             # Domain specialists (auto-generated)\n└── sync/\n    └── pending.json    # Events for backend sync\n```\n\n### How to interact with storage\n\n- **Read state**: Use `prjct status`, `prjct dash`, `prjct next` CLI commands\n- **Write state**: Use `prjct` CLI commands (task, done, pause, resume, etc.)\n- **Issue tracker setup**: Use `prjct linear setup` or `prjct jira setup` (MCP/OAuth)\n- **Never** read/write JSON files in `storage/` or `memory/` directories\n\n---\n\n## LEGACY JSON Schemas (for reference only)\n\n> **WARNING**: These JSON schemas are LEGACY documentation only. The `storage/` and `memory/` directories are no longer used. All data lives in `prjct.db` (SQLite). Do NOT read or write these files.\n\n### state.json (LEGACY)\n\n```json\n{\n  \"task\": {\n    \"id\": \"uuid-v4\",\n    \"title\": \"string\",\n    \"type\": \"feature|bug|improvement|refactor|chore\",\n    \"status\": \"active|paused|done\",\n    \"branch\": \"string|null\",\n    \"subtasks\": [\n      {\n        \"id\": \"uuid-v4\",\n        \"title\": \"string\",\n        \"status\": \"pending|done\"\n      }\n    ],\n    \"currentSubtask\": 0,\n    \"createdAt\": \"2024-01-15T10:30:00.000Z\",\n    \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n  }\n}\n```\n\n**Empty state (no active task):**\n```json\n{\n  \"task\": null\n}\n```\n\n### queue.json (LEGACY)\n\n```json\n{\n  \"tasks\": [\n    {\n      \"id\": \"uuid-v4\",\n      \"title\": \"string\",\n      \"type\": \"feature|bug|improvement|refactor|chore\",\n      \"priority\": 1,\n      \"createdAt\": \"2024-01-15T10:30:00.000Z\"\n    }\n  ],\n  \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### shipped.json (LEGACY)\n\n```json\n{\n  \"features\": [\n    {\n      \"id\": \"uuid-v4\",\n      \"name\": \"string\",\n      \"version\": \"1.0.0\",\n      \"type\": \"feature|bug|improvement|refactor|chore\",\n      \"shippedAt\": \"2024-01-15T10:30:00.000Z\"\n    }\n  ],\n  \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### events.jsonl (LEGACY - now stored in SQLite `events` table)\n\nPreviously append-only JSONL. Now stored in SQLite.\n\n```jsonl\n{\"type\":\"task.created\",\"timestamp\":\"2024-01-15T10:30:00.000Z\",\"data\":{\"taskId\":\"uuid\",\"title\":\"string\"}}\n{\"type\":\"task.started\",\"timestamp\":\"2024-01-15T10:30:00.000Z\",\"data\":{\"taskId\":\"uuid\"}}\n{\"type\":\"subtask.completed\",\"timestamp\":\"2024-01-15T10:35:00.000Z\",\"data\":{\"taskId\":\"uuid\",\"subtaskIndex\":0}}\n{\"type\":\"task.completed\",\"timestamp\":\"2024-01-15T10:40:00.000Z\",\"data\":{\"taskId\":\"uuid\"}}\n{\"type\":\"feature.shipped\",\"timestamp\":\"2024-01-15T10:45:00.000Z\",\"data\":{\"featureId\":\"uuid\",\"name\":\"string\",\"version\":\"1.0.0\"}}\n```\n\n**Event Types:**\n- `task.created` - New task created\n- `task.started` - Task activated\n- `task.paused` - Task paused\n- `task.resumed` - Task resumed\n- `task.completed` - Task completed\n- `subtask.completed` - Subtask completed\n- `feature.shipped` - Feature shipped\n\n### learnings.jsonl (LEGACY - now stored in SQLite)\n\nPreviously used for LLM-to-LLM knowledge transfer. Now stored in SQLite.\n\n```jsonl\n{\"taskId\":\"uuid\",\"linearId\":\"PRJ-123\",\"timestamp\":\"2024-01-15T10:40:00.000Z\",\"learnings\":{\"patterns\":[\"Use NestedContextResolver for hierarchical discovery\"],\"approaches\":[\"Mirror existing method structure when extending\"],\"decisions\":[\"Extended class rather than wrapper for consistency\"],\"gotchas\":[\"Must handle null parent case\"]},\"value\":{\"type\":\"feature\",\"impact\":\"high\",\"description\":\"Hierarchical AGENTS.md support for monorepos\"},\"filesChanged\":[\"core/resolver.ts\",\"core/types.ts\"],\"tags\":[\"agents\",\"hierarchy\",\"monorepo\"]}\n```\n\n**Schema:**\n```json\n{\n  \"taskId\": \"uuid-v4\",\n  \"linearId\": \"string|null\",\n  \"timestamp\": \"2024-01-15T10:40:00.000Z\",\n  \"learnings\": {\n    \"patterns\": [\"string\"],\n    \"approaches\": [\"string\"],\n    \"decisions\": [\"string\"],\n    \"gotchas\": [\"string\"]\n  },\n  \"value\": {\n    \"type\": \"feature|bugfix|performance|dx|refactor|infrastructure\",\n    \"impact\": \"high|medium|low\",\n    \"description\": \"string\"\n  },\n  \"filesChanged\": [\"string\"],\n  \"tags\": [\"string\"]\n}\n```\n\n**Why Local Cache**: Enables future semantic retrieval without API latency. Will feed into vector DB for cross-session knowledge transfer.\n\n### skills.json\n\n```json\n{\n  \"mappings\": {\n    \"frontend.md\": [\"frontend-design\"],\n    \"backend.md\": [\"javascript-typescript\"],\n    \"testing.md\": [\"developer-kit\"]\n  },\n  \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### pending.json (sync queue)\n\n```json\n{\n  \"events\": [\n    {\n      \"id\": \"uuid-v4\",\n      \"type\": \"task.created\",\n      \"timestamp\": \"2024-01-15T10:30:00.000Z\",\n      \"data\": {},\n      \"synced\": false\n    }\n  ],\n  \"lastSync\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n---\n\n## Formatting Rules (MANDATORY)\n\nAll agents MUST follow these rules for cross-agent compatibility:\n\n| Rule | Value |\n|------|-------|\n| JSON indentation | 2 spaces |\n| Trailing commas | NEVER |\n| Key ordering | Logical (as shown in schemas above) |\n| Timestamps | ISO-8601 with milliseconds (`.000Z`) |\n| UUIDs | v4 format (lowercase) |\n| Line endings | LF (not CRLF) |\n| File encoding | UTF-8 without BOM |\n| Empty objects | `{}` |\n| Empty arrays | `[]` |\n| Null values | `null` (lowercase) |\n\n### Timestamp Generation\n\n```bash\n# ALWAYS use dynamic timestamps, NEVER hardcode\nbun -e \"console.log(new Date().toISOString())\" 2>/dev/null || node -e \"console.log(new Date().toISOString())\"\n```\n\n### UUID Generation\n\n```bash\n# ALWAYS generate fresh UUIDs\nbun -e \"console.log(crypto.randomUUID())\" 2>/dev/null || node -e \"console.log(require('crypto').randomUUID())\"\n```\n\n---\n\n## Write Rules (CRITICAL)\n\n### Direct Writes Only\n\n**NEVER use temporary files** - Write directly to final destination:\n\n```\nWRONG: Create `.tmp/file.json`, then `mv` to final path\nCORRECT: Use prjctDb.setDoc() or StorageManager.write() to write to SQLite\n```\n\n### Atomic Updates\n\nAll writes go through SQLite which handles atomicity via WAL mode:\n```typescript\n// StorageManager pattern (preferred):\nawait stateStorage.update(projectId, (state) => {\n  state.field = newValue\n  return state\n})\n\n// Direct kv_store pattern:\nprjctDb.setDoc(projectId, 'key', data)\n```\n\n### NEVER Do These\n\n- Read or write JSON files in `storage/` or `memory/` directories\n- Use `.tmp/` directories\n- Use `mv` or `rename` operations for storage files\n- Create backup files like `*.bak` or `*.old`\n- Bypass `prjct` CLI to write directly to `prjct.db`\n\n---\n\n## Cross-Agent Compatibility\n\n### Why This Matters\n\n1. **User freedom**: Switch between Claude and Gemini freely\n2. **Remote sync**: Storage will sync to prjct.app backend\n3. **Single truth**: Both agents produce identical output\n\n### Verification Test\n\n```bash\n# Start task with Claude\np. task \"add feature X\"\n\n# Switch to Gemini, continue\np. done  # Should work seamlessly\n\n# Switch back to Claude\np. ship  # Should read Gemini's changes correctly\n\n# All agents read from the same prjct.db via CLI commands\nprjct status  # Works from any agent\n```\n\n### Remote Sync Flow\n\n```\nLocal Storage: prjct.db (Claude/Gemini)\n        ↓\n    sync/pending.json (events queue)\n        ↓\n    prjct.app API\n        ↓\n    Global Remote Storage\n        ↓\n    Any device, any agent\n```\n\n---\n\n## MCP Issue Tracker Strategy\n\nIssue tracker integrations are MCP-only.\n\n### Rules\n\n- `prjct` CLI does not call Linear/Jira SDKs or REST APIs directly.\n- Issue operations (`sync`, `list`, `get`, `start`, `done`, `update`, etc.) are delegated to MCP tools in the AI client.\n- `p. sync` refreshes project context and agent artifacts, not issue tracker payloads.\n- Local storage keeps task linkage metadata (for example `linearId`) and project workflow state in SQLite.\n\n### Setup\n\n- `prjct linear setup`\n- `prjct jira setup`\n\n### Operational Model\n\n```\nAI client MCP tools <-> Linear/Jira\n          |\n          v\n       prjct workflow state (prjct.db)\n```\n\nThe CLI remains the source of truth for local project/task state.\nIssue-system mutations happen through MCP operations in the active AI session.\n\n---\n\n**Version**: 2.0.0\n**Last Updated**: 2026-02-10\n","global/WINDSURF.md":"---\ntrigger: always_on\ndescription: \"prjct - Context layer for AI coding agents\"\n---\n\n<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Windsurf, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","mcp-config.json":"{\n  \"mcpServers\": {\n    \"context7\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@upstash/context7-mcp@latest\"],\n      \"description\": \"Library documentation lookup\"\n    },\n    \"linear\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mcp-remote\", \"https://mcp.linear.app/mcp\"],\n      \"description\": \"Linear MCP server (OAuth)\"\n    },\n    \"jira\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mcp-remote\", \"https://mcp.atlassian.com/v1/mcp\"],\n      \"description\": \"Atlassian MCP server for Jira (OAuth)\"\n    }\n  },\n  \"usage\": {\n    \"context7\": {\n      \"when\": [\"Looking up library/framework documentation\", \"Need current API docs\"],\n      \"tools\": [\"resolve-library-id\", \"get-library-docs\"]\n    }\n  },\n  \"integrations\": {\n    \"linear\": \"MCP - Run `prjct linear setup`\",\n    \"jira\": \"MCP - Run `prjct jira setup`\"\n  }\n}\n","permissions/default.jsonc":"{\n  // Default permissions preset for prjct-cli\n  // Safe defaults with protection against destructive operations\n\n  \"bash\": {\n    // Safe read-only commands - always allowed\n    \"git status*\": \"allow\",\n    \"git log*\": \"allow\",\n    \"git diff*\": \"allow\",\n    \"git branch*\": \"allow\",\n    \"ls*\": \"allow\",\n    \"pwd\": \"allow\",\n    \"cat*\": \"allow\",\n    \"head*\": \"allow\",\n    \"tail*\": \"allow\",\n    \"grep*\": \"allow\",\n    \"find*\": \"allow\",\n    \"which*\": \"allow\",\n    \"node -e*\": \"allow\",\n    \"bun -e*\": \"allow\",\n    \"npm list*\": \"allow\",\n    \"npx tsc --noEmit*\": \"allow\",\n\n    // Potentially destructive - ask first\n    \"rm -rf*\": \"ask\",\n    \"rm -r*\": \"ask\",\n    \"git push*\": \"ask\",\n    \"git reset --hard*\": \"ask\",\n    \"npm publish*\": \"ask\",\n    \"chmod*\": \"ask\",\n\n    // Always denied - too dangerous\n    \"rm -rf /*\": \"deny\",\n    \"rm -rf ~/*\": \"deny\",\n    \"sudo*\": \"deny\"\n  },\n\n  \"files\": {\n    \"read\": {\n      \"**/*\": \"allow\"\n    },\n    \"write\": {\n      \"**/*\": \"allow\"\n    },\n    \"delete\": {\n      \"**/*\": \"ask\"\n    }\n  },\n\n  \"web\": {\n    \"enabled\": true\n  },\n\n  \"doomLoop\": {\n    \"enabled\": true,\n    \"maxRetries\": 3\n  },\n\n  \"externalDirectories\": \"ask\"\n}\n","permissions/permissive.jsonc":"{\n  // Permissive preset for prjct-cli\n  // For trusted environments - minimal restrictions\n\n  \"bash\": {\n    // Most commands allowed\n    \"git*\": \"allow\",\n    \"npm*\": \"allow\",\n    \"bun*\": \"allow\",\n    \"node*\": \"allow\",\n    \"ls*\": \"allow\",\n    \"cat*\": \"allow\",\n    \"mkdir*\": \"allow\",\n    \"cp*\": \"allow\",\n    \"mv*\": \"allow\",\n    \"rm*\": \"allow\",\n    \"chmod*\": \"allow\",\n\n    // Still protect against catastrophic mistakes\n    \"rm -rf /*\": \"deny\",\n    \"rm -rf ~/*\": \"deny\",\n    \"sudo rm -rf*\": \"deny\",\n    \":(){ :|:& };:*\": \"deny\"\n  },\n\n  \"files\": {\n    \"read\": {\n      \"**/*\": \"allow\"\n    },\n    \"write\": {\n      \"**/*\": \"allow\"\n    },\n    \"delete\": {\n      \"**/*\": \"allow\",\n      \"**/node_modules/**\": \"deny\" // Protect dependencies\n    }\n  },\n\n  \"web\": {\n    \"enabled\": true\n  },\n\n  \"doomLoop\": {\n    \"enabled\": true,\n    \"maxRetries\": 5\n  },\n\n  \"externalDirectories\": \"allow\"\n}\n","permissions/strict.jsonc":"{\n  // Strict permissions preset for prjct-cli\n  // Maximum safety - requires approval for most operations\n\n  \"bash\": {\n    // Only read-only commands allowed\n    \"git status\": \"allow\",\n    \"git log*\": \"allow\",\n    \"git diff*\": \"allow\",\n    \"ls*\": \"allow\",\n    \"pwd\": \"allow\",\n    \"cat*\": \"allow\",\n    \"head*\": \"allow\",\n    \"tail*\": \"allow\",\n    \"which*\": \"allow\",\n\n    // Everything else requires approval\n    \"git*\": \"ask\",\n    \"npm*\": \"ask\",\n    \"bun*\": \"ask\",\n    \"node*\": \"ask\",\n    \"rm*\": \"ask\",\n    \"mv*\": \"ask\",\n    \"cp*\": \"ask\",\n    \"mkdir*\": \"ask\",\n\n    // Always denied\n    \"rm -rf*\": \"deny\",\n    \"sudo*\": \"deny\",\n    \"chmod 777*\": \"deny\"\n  },\n\n  \"files\": {\n    \"read\": {\n      \"**/*\": \"allow\",\n      \"**/.*\": \"ask\", // Hidden files need approval\n      \"**/.env*\": \"deny\" // Never read env files\n    },\n    \"write\": {\n      \"**/*\": \"ask\" // All writes need approval\n    },\n    \"delete\": {\n      \"**/*\": \"deny\" // No deletions without explicit override\n    }\n  },\n\n  \"web\": {\n    \"enabled\": true,\n    \"blockedDomains\": [\"localhost\", \"127.0.0.1\", \"internal\"]\n  },\n\n  \"doomLoop\": {\n    \"enabled\": true,\n    \"maxRetries\": 2\n  },\n\n  \"externalDirectories\": \"deny\"\n}\n","planning-methodology-deep.md":"# Software Planning Methodology for prjct\n\nThis methodology guides the AI through developing ideas into complete technical specifications.\n\n## Phase 1: Discovery & Problem Definition\n\n### Questions to Ask\n- What specific problem does this solve?\n- Who is the target user?\n- What's the budget and timeline?\n- What happens if this problem isn't solved?\n\n### Output\n- Problem statement\n- User personas\n- Business constraints\n- Success metrics\n\n## Phase 2: User Flows & Journeys\n\n### Process\n1. Map primary user journey\n2. Identify entry points\n3. Define success states\n4. Document error states\n5. Note edge cases\n\n### Jobs-to-be-Done\nWhen [situation], I want to [motivation], so I can [expected outcome]\n\n## Phase 3: Domain Modeling\n\n### Entity Definition\nFor each entity, define:\n- Description\n- Attributes (name, type, constraints)\n- Relationships\n- Business rules\n- Lifecycle states\n\n### Bounded Contexts\nGroup entities into logical boundaries with:\n- Owned entities\n- External dependencies\n- Events published/consumed\n\n## Phase 4: API Contract Design\n\n### Style Selection\n| Style    | Best For |\n|----------|----------|\n| REST     | Simple CRUD, broad compatibility |\n| GraphQL  | Complex data requirements |\n| tRPC     | Full-stack TypeScript |\n| gRPC     | Microservices |\n\n### Endpoint Specification\n- Method/Type\n- Path/Name\n- Authentication\n- Input/Output schemas\n- Error responses\n\n## Phase 5: System Architecture\n\n### Pattern Selection\n| Pattern | Best For |\n|---------|----------|\n| Modular Monolith | Small team, fast iteration |\n| Serverless-First | Variable load, event-driven |\n| Microservices | Large team, complex domain |\n\n### C4 Model\n1. Context - System and external actors\n2. Container - Major components\n3. Component - Internal structure\n\n## Phase 6: Data Architecture\n\n### Database Selection\n| Type | Options | Best For |\n|------|---------|----------|\n| Relational | PostgreSQL | ACID, structured data |\n| Document | MongoDB | Flexible schema |\n| Key-Value | Redis | Caching, sessions |\n\n### Schema Design\n- Tables and columns\n- Indexes\n- Constraints\n- Relationships\n\n## Phase 7: Tech Stack Decision\n\n### Frontend Stack\n- Framework (Next.js, Remix, SvelteKit)\n- Styling (Tailwind, CSS Modules)\n- State management (Zustand, Jotai)\n- Data fetching (TanStack Query, SWR)\n\n### Backend Stack\n- Runtime (Node.js, Bun)\n- Framework (Next.js API, Hono)\n- ORM (Drizzle, Prisma)\n- Validation (Zod, Valibot)\n\n### Infrastructure\n- Hosting (Vercel, Railway, Fly.io)\n- Database (Neon, PlanetScale)\n- Cache (Upstash, Redis)\n- Monitoring (Sentry, Axiom)\n\n## Phase 8: Implementation Roadmap\n\n### MVP Scope Definition\n- Must-have features (P0)\n- Should-have features (P1)\n- Nice-to-have features (P2)\n- Future considerations (P3)\n\n### Development Phases\n1. Foundation - Setup, core infrastructure\n2. Core Features - Primary functionality\n3. Polish & Launch - Optimization, deployment\n\n### Risk Assessment\n- Technical risks and mitigation\n- Business risks and mitigation\n- Dependencies and assumptions\n\n## Output Structure\n\nWhen complete, generate:\n\n1. **Executive Summary** - Problem, solution, key decisions\n2. **Architecture Documents** - All phases detailed\n3. **Implementation Plan** - Prioritized tasks with estimates\n4. **Decision Log** - Key choices and reasoning\n\n## Interactive Development Process\n\n1. **Classification**: Determine if idea needs full architecture\n2. **Discovery**: Ask clarifying questions\n3. **Generation**: Create architecture phase by phase\n4. **Validation**: Review with user at key points\n5. **Refinement**: Iterate based on feedback\n6. **Output**: Save complete specification\n\n## Success Criteria\n\nA complete architecture includes:\n- Clear problem definition\n- User flows mapped\n- Domain model defined\n- API contracts specified\n- Tech stack chosen\n- Database schema designed\n- Implementation roadmap created\n- Risk assessment completed\n\n## Templates\n\n### Entity Template\n```\nEntity: [Name]\n├── Description: [What it represents]\n├── Attributes:\n│   ├── id: uuid (primary key)\n│   └── [field]: [type] ([constraints])\n├── Relationships: [connections]\n├── Rules: [invariants]\n└── States: [lifecycle]\n```\n\n### API Endpoint Template\n```\nOperation: [Name]\n├── Method: [GET/POST/PUT/DELETE]\n├── Path: [/api/resource]\n├── Auth: [Required/Optional]\n├── Input: {schema}\n├── Output: {schema}\n└── Errors: [codes and descriptions]\n```\n\n### Phase Template\n```\nPhase: [Name]\n├── Duration: [timeframe]\n├── Tasks:\n│   ├── [Task 1]\n│   └── [Task 2]\n├── Deliverable: [outcome]\n└── Dependencies: [prerequisites]\n```","sdd-canonical-sequence.md":"# SDD canonical sequence — prjct\n\nSpec-Driven Development is prjct's default flow for substantive work. The six stations:\n\n```\nspec ─→ audit-spec ─→ task (--spec <id>) ─→ implement ─→ ship (acceptance gate)\n                                                                  └─→ remember learning\n```\n\n## Stations\n\n### 1. `spec`\n\nThe user describes a feature, fix, or initiative WITH goals or stakes. You don't run `task` yet. You run `prjct spec \"<title>\"` and walk the forcing questions:\n\n- goal (1–3 sentences)\n- eli10 (2–4 sentences)\n- stakes if we ship the wrong thing\n- acceptance criteria (testable, observable list)\n- scope (what's IN)\n- out_of_scope (what's OUT)\n- risks (each with mitigation)\n- test plan\n\nThe CLI persists this in the `specs` table; the vault renders to `_generated/specs/<slug>.md`.\n\n### 2. `audit-spec`\n\nBefore writing any code: harden the spec. Run `prjct audit-spec <id>` — it emits a dispatch prompt for THREE review subagents that you run IN PARALLEL (one tool-use block per reviewer in the SAME message):\n\n- **strategic** — scope sanity. Worth doing? Right size?\n- **architecture** — feasibility. Data flow, failure modes, dependencies.\n- **design** — UX/DX quality. Four dimensions rated 0–10.\n\nEach returns a verdict (pass | fail) + notes. You write each back via `prjct spec record-review`. When all three pass, the spec auto-promotes from `draft` → `reviewed`.\n\nIf any reviewer fails: revise the spec via `prjct spec update`, re-audit. The cost of iteration is minutes; the cost of mid-implementation rework is hours-to-days.\n\n### 3. `task --spec <id>`\n\nNow create the task. The `--spec` flag wires the task to its spec via `linked_spec_id`. Without it, `ship` later has nothing to gate against.\n\n```\nprjct task \"implement rate-limit middleware\" --spec <id>\n```\n\n### 4. implement\n\nNormal coding loop. Mid-flight workflows (`review`, `qa`, `investigate`) still apply. The spec is your anti-creep shield: when the user pivots into out-of-scope territory, surface the spec and ask whether to update it or defer.\n\n### 5. `ship` (with the spec gate)\n\n`prjct ship` reads the linked spec's `acceptance_criteria` and surfaces them as a checklist in the PR description. Walk each one — pass / fail / N/A. If any criterion is unmet → STOP and surface to the user.\n\nOverride path: `prjct ship --no-spec-gate` (use only when the user explicitly accepts).\n\n### 6. `remember learning`\n\nAfter ship, capture what the spec got right and wrong:\n\n```\nprjct remember learning \"spec missed the clock-skew edge case; future rate-limit specs should call out time-source\"\n```\n\nThe next spec is sharper. Compounding effect: the vault accumulates spec-shaped lessons.\n\n## When to bypass SDD\n\nNot every keystroke goes through six stations. Routine work skips `spec`:\n\n- single-file fix with known scope\n- doc tweak / typo\n- inbox capture / GTD dump\n- conversational Q&A\n- re-running a failing test\n- bug fix where root cause is already known\n\nRule of thumb: if the work touches >1 file, ships to users, or takes >30 minutes, default to `spec` first.\n\n## Anti-patterns\n\n- **Skipping straight to `task` because the user said \"let's build X\".** If they said it WITH stakes, the spec is what protects them from scope creep mid-implementation.\n- **Auditing AFTER implementing.** Pre-implementation review is the whole point. Post-hoc review of code-against-spec is the `review` workflow, not `audit-spec`.\n- **Treating the spec as immutable.** Specs evolve. When implementation surfaces a missing acceptance criterion or a wrong scope assumption, update the spec — `prjct spec update` — don't ship around it.\n- **Marking `acceptance_criteria` met without proof.** The criterion exists to be tested. If the test wasn't run, the criterion isn't met.\n","skills/code-review.md":"---\nname: Code Review\ndescription: Review code changes for quality, security, and best practices\nagent: general\ntags: [review, quality, security]\nversion: 1.0.0\n---\n\n# Code Review Skill\n\nReview the provided code changes with focus on:\n\n## Quality Checks\n- Code readability and clarity\n- Naming conventions\n- Function/method length\n- Code duplication\n- Error handling\n\n## Security Checks\n- Input validation\n- SQL injection risks\n- XSS vulnerabilities\n- Sensitive data exposure\n- Authentication/authorization issues\n\n## Best Practices\n- SOLID principles\n- DRY (Don't Repeat Yourself)\n- Single responsibility\n- Proper typing (TypeScript)\n- Documentation where needed\n\n## Output Format\n\nProvide feedback in this structure:\n\n### Summary\nBrief overview of the changes\n\n### Issues Found\n- 🔴 **Critical**: Must fix before merge\n- 🟡 **Warning**: Should fix, but not blocking\n- 🔵 **Suggestion**: Nice to have improvements\n\n### Recommendations\nSpecific actionable items to improve the code\n","skills/debug.md":"---\nname: Debug\ndescription: Systematic debugging to find and fix issues\nagent: general\ntags: [debug, fix, troubleshoot]\nversion: 1.0.0\n---\n\n# Debug Skill\n\nSystematically debug the reported issue.\n\n## Process\n\n### Step 1: Understand the Problem\n- What is the expected behavior?\n- What is the actual behavior?\n- When did it start happening?\n- Can it be reproduced consistently?\n\n### Step 2: Gather Information\n- Read relevant error messages\n- Check logs\n- Review recent changes\n- Identify affected code paths\n\n### Step 3: Form Hypothesis\n- What could cause this behavior?\n- List possible causes in order of likelihood\n- Identify the most likely root cause\n\n### Step 4: Test Hypothesis\n- Add logging if needed\n- Isolate the problematic code\n- Verify the root cause\n\n### Step 5: Fix\n- Implement the minimal fix\n- Ensure no side effects\n- Add tests if applicable\n\n### Step 6: Verify\n- Confirm the issue is resolved\n- Check for regressions\n- Document the fix\n\n## Output Format\n\n```\n## Issue\n[Description of the problem]\n\n## Root Cause\n[What was causing the issue]\n\n## Fix\n[What was changed to fix it]\n\n## Prevention\n[How to prevent similar issues]\n```\n","skills/prjct/SKILL.md":"---\ndescription: \"Project memory + spec-driven runtime: recall and capture decisions/learnings/gotchas, run registered workflows, frame and ship work. Recognize intent in any language (es/en) and run the verb yourself — never make the user type commands. Triage every turn: most work is SIMPLE → go direct (`prjct task` → ship); reserve the spec pipeline for genuinely complex or high-stakes work. Over-routing simple work through spec + reviewers is the main failure mode.\"\nallowed-tools: [\"Bash\", \"Read\", \"Write\", \"Edit\", \"Glob\", \"Grep\", \"Task\"]\nuser-invocable: true\n---\n\n# prjct\n\n## Use when\n\nYou want to:\n- recall prior project decisions, learnings, or shipped features\n- capture a thought, todo, or insight without a commitment\n- run a workflow the project already registered\n- understand your role and the MCPs available in this project\n\n## What's here\n\nThis is the baseline `prjct` skill installed by the CLI on every invocation.\n\nNo project has been initialized in this cwd yet (`.prjct/` missing). When the user\nshows intent (start a task, capture a thought, ship), suggest `prjct init` ONCE\nin one line, then run the verb. Don't gate routine captures on init.\n\nAfter `prjct sync` runs in an initialized project, this file is regenerated with\nproject-specific context (name, stack, velocity, active task, recent shipped,\nknown gotchas). The verb intent map below applies in both states.\n\n\n\n### Agent contract\n\n- prjct remembers project state and shows the path; it does not own the execution.\n- Treat prjct output as durable signals: active task, memories, workflows, specs, risks, and recent learnings.\n- Claude, GPT, and other agents decide the concrete HOW with their own native tools and judgment. Persist meaningful outcomes back through `prjct remember`, `prjct capture`, `prjct task`, and `prjct ship` so the next interaction starts smarter.\n\n### Primitives\n\n- `prjct spec \"<title>\"` — frame work BEFORE coding (Goal/Acceptance/Scope/Risks)\n- `prjct audit-spec <id>` — dispatch parallel strategic/architecture/design review\n- `prjct capture \"<anything>\"` — inbox dump (zero ceremony)\n- `prjct remember <type> \"<content>\" [--tags]` — typed memory entry\n- `prjct search \"<query>\"` — recall project memory (BM25 + semantic + recall); the verb to reach for when you need prior knowledge\n- `prjct context memory [topic]` — same blended retrieval as `search`, plus `learnings`/`wiki` subtools\n- `prjct guard <file>` — preventive memory recorded against a file, before you edit it\n- `prjct workflow list` / `prjct workflow run <name>` — registered workflows\n- `prjct seed list` — active packs (memory types + workflow slots)\n\nBase memory types: `fact · decision · learning · gotcha · pattern · anti-pattern · shipped · inbox · todo · idea · insight · question · source · person · spec`. Any lowercase string works (e.g. `recipe`, `okr`, `stakeholder`).\n\n### Data paths\n\n- `.prjct/wiki/_generated/` — agent-crawlable markdown (regenerated on ship/remember)\n- `.prjct/wiki/captured/` — drop notes with frontmatter, run `prjct context wiki sync` to ingest\n- `.prjct/prjct.config.json` — persona + active packs\n\n## Act: default DIRECT — escalation is the rare exception\n\n**The first move on almost every turn is to just do the work DIRECTLY.** A fix, a one-file change, a capture, a question, anything the user calls \"fix\"/\"hoy\"/\"rápido\"/\"directo\": `prjct task` → implement it yourself → `ship`. **NO spec, NO audit-spec, NO subagents, NO fan-out.** This is the common case and the safe default — when unsure, this is what you pick. Ask at most ONE line; never escalate just to be safe.\n\nEscalate to the spec pipeline ONLY when the test is unambiguous: multi-file + new behavior AND ambiguous scope AND real/irreversible stakes (or the user explicitly frames goals/acceptance/risks). Then, and only then: `spec ─→ audit-spec ─→ task --spec <id> ─→ implement ─→ ship ─→ remember learning`. Forcing simple work through this pipeline is the #1 perf-killer — it burns tokens for zero protection.\n\n**If you ever dispatch a subagent (Agent tool), set `model:` explicitly — never let it inherit yours.** Only the agent that WRITES code gets `model: \"opus\"`. Reviewing/judging (`review`, `security`, `investigate`, audit-spec reviewers) → `model: \"sonnet\"`. Pure routing/orchestration → `model: \"haiku\"`. A non-implementer left on the parent's max model is exactly why a task crawls and burns tokens. Not optional.\n\nHeavy quality workflows (`review`, `qa`, `security`, `investigate`, `audit`, `audit-spec`), the parallel-implementer fan-out rules, decision-briefs, the `prjct prefs` protocol, the spec stations and builder ethos all live in `workflows.md` — **read it on demand when (and only when) you actually run one.** Do not preload it; do not reach for the menu on simple work.\n\n**CONTENT LANGUAGE — author every stored memory in ENGLISH**, regardless of the conversation language. When you `capture`/`remember`, translate the intent into a clean English entry (the user may speak Spanish; the persisted knowledge is English). LLMs comprehend English better and embeddings stay high-quality in one canonical language — mixed-language content produces cross-language retrieval noise.\n\n## Verb intent map — you run the verb, the user never types it\n\nOn every turn ask: \"what is the user trying to accomplish?\" and match to a verb below. Bilingual (es/en) — the verbs are language-agnostic, the intent isn't. These are *signals*, not phrase templates. The **Tier** column governs whether you auto-run or confirm first (see Routing).\n\n| Intent / signal | Verb | Tier |\n|---|---|---|\n| starting a unit of work — \"haceme X\", a fix, a change, picking up a queue item (THE DEFAULT, most turns) | `prjct task \"<desc>\"` (add `--spec <id>` if a spec exists) | 2 |\n| framing genuinely complex work WITH goals/stakes/acceptance criteria (the exception) | `prjct spec \"<title>\"` | 2 |\n| harden / pressure-test an existing spec before any code | `prjct audit-spec <id>` | 2 |\n| need prior project knowledge — \"what did we decide about X\", \"buscá lo de Y\", recall before re-reading source | `prjct search \"<query>\"` | 1 |\n| an interesting thought to keep, no commitment yet | `prjct capture \"<text>\" --tags topic:<x>` | 1 |\n| a non-trivial choice just got resolved (+ its why) | `prjct remember decision \"<choice + one-line why>\"` | 1 |\n| an insight / \"aha\" / new mental model | `prjct remember learning \"<insight>\"` | 1 |\n| a non-obvious trap surfaced (+ how to avoid) | `prjct remember gotcha \"<trap + how to avoid>\"` | 1 |\n| categorize the active task (type/domain/priority) | `prjct tag type:bug domain:auth …` | 1 |\n| about to edit a file — check for known traps | `prjct guard <file>` | 1 |\n| work is done, push it | `prjct ship` | 2 |\n| lifecycle change on the active task | `prjct status done\\|paused\\|active` | 2 |\n| \"is the codebase healthy?\" | `prjct health --md` | 1 |\n| \"what did we accomplish?\" | `prjct retro 7d --md` | 1 |\n| pause / resume the working context | `prjct context-save` / `prjct context-restore --md` | 1 |\n\nDisambiguators: the \"why\" separates a `decision` from an `inbox` dump — if you can't state it in one line, capture as inbox. A bare \"fix X\"/\"hoy\" is `task`, never `spec`. `audit-spec` requires an existing spec. For `ship`, if the active task has a `linked_spec_id`, ship surfaces the spec's acceptance_criteria as a PR checklist — STOP on any unmet criterion (override: `prjct ship --no-spec-gate`).\n\n## Routing — Tier governs auto-run vs confirm (by blast radius)\n\n- **Tier 1 — auto-execute, one-line confirm.** `search`, `capture`, `tag`, `remember`, `guard`, `context-save`, `health`, `retro`, `prefs check/list`. Additive/read-only: run IMMEDIATELY, emit one line (`✓ saved as decision: …`). Do not ask \"want me to save that?\" — just save it; the user corrects afterward. Pausing for permission on routine captures is what makes prjct useless.\n- **Tier 2 — suggest-and-confirm, ONE line.** `task`, `spec`, `audit-spec`, `ship`, `status done|paused`, `prefs set`. State intent + blast radius in one line and wait for a green light (yes/dale/confirma/silence). Never run `ship` without surfacing the plan first — it is un-doable without a force-push.\n- **Tier 3 — decision-brief** (hard forks costing >5 min to undo): `prjct prefs check <id>` first, then the decision-brief format. Both detailed in `workflows.md`.\n\n## Gotchas\n\n- Memory recall is best-effort — an empty result means no match, not \"nothing exists\".\n- Tags are freeform strings — reuse existing vocabulary before inventing new keys.\n- Secret-like content is refused by `remember` and `capture` unless `--force`.\n- Bare `prjct \"<text>\"` routes to `capture` (inbox), not `task`. Use `prjct task` explicitly for work that needs a branch/worktree.\n- Hooks in `~/.claude/settings.json` already inject persona + topical memory on SessionStart / UserPromptSubmit — you rarely need to call prjct by hand at session start.\n- **Worktree hygiene.** If you are working inside a git worktree, clean it up so they don't pile up on the local machine: AFTER the branch's PR is *merged* (not at session end — an open PR keeps its worktree), `git worktree remove <path>` + `git worktree prune`, run from the MAIN worktree (git won't remove the worktree you're standing in). NEVER remove a worktree with uncommitted or unpushed work, and never `--force` over a dirty tree (it silently discards work).\n\n","skills/refactor.md":"---\nname: Refactor\ndescription: Refactor code for better structure, readability, and maintainability\nagent: general\ntags: [refactor, cleanup, improvement]\nversion: 1.0.0\n---\n\n# Refactor Skill\n\nRefactor the specified code with these goals:\n\n## Objectives\n1. **Improve Readability** - Clear naming, logical structure\n2. **Reduce Complexity** - Simplify nested logic, extract functions\n3. **Enhance Maintainability** - Make future changes easier\n4. **Preserve Behavior** - No functional changes unless requested\n\n## Approach\n\n### Step 1: Analyze Current Code\n- Identify pain points\n- Note code smells\n- Understand dependencies\n\n### Step 2: Plan Changes\n- List specific refactoring operations\n- Prioritize by impact\n- Consider breaking changes\n\n### Step 3: Execute\n- Make incremental changes\n- Test after each change\n- Document decisions\n\n## Common Refactorings\n- Extract function/method\n- Rename for clarity\n- Remove duplication\n- Simplify conditionals\n- Replace magic numbers with constants\n- Add type annotations\n\n## Output\n- Modified code\n- Brief explanation of changes\n- Any trade-offs made\n","spec-reviewer-rubrics/architecture.md":"# Architecture reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for engineering feasibility. You receive the spec body verbatim. Apply the questions below; return a structured verdict.\n\n## Questions to ask\n\n1. **Can this be built?** With the team's stack and skill set, in the implied timeframe. If \"no\" or \"yes but only by replacing the database\", fail.\n2. **Is the data flow coherent?** Trace input → state → output. Where does data live? Who writes it? Who reads it? Failure modes at each hop.\n3. **Is the state machine implicit or explicit?** Explicit > implicit. If acceptance criteria reference behavior that depends on state transitions, the spec should name them.\n4. **What edge cases / failure modes are missing?** Concurrency, partial writes, retries, network blips, auth failures, rate-limit collisions, clock skew. Name the top 1–2 that the spec doesn't address.\n5. **What dependencies does this introduce?** New runtime dep? New infra (Redis, queue, cron)? Document it. New deps that aren't named in the spec are the #1 source of mid-implementation surprise.\n6. **Test plan adequate?** A test plan that says \"tests added\" is not a plan. Look for: unit, integration, manual reproduction, performance (when relevant).\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: 2–4 sentences + (when applicable) a short ASCII data flow / state diagram.\n       If pass, name the most load-bearing architectural choice.\n       If fail, name the SINGLE biggest gap and how to close it.\n```\n\n## Examples\n\n**Pass with diagram:**\n\n```\nverdict: pass\nnotes: Token-bucket per IP with 5-minute Redis TTL is the right call — survives restarts, no GC pressure, easy to extend to user-id keys later. The spec correctly limits scope to /auth (no /api yet). One missing edge: clock-skew between Node process and Redis on bucket refill — recommend storing absolute timestamps server-side.\n\n   request → middleware → Redis GETSET (token, ts)\n                            ├── allowed → next()\n                            └── refused → 429 + Retry-After\n```\n\n**Fail:**\n\n```\nverdict: fail\nnotes: Spec references \"real-time updates\" in acceptance_criteria but is silent on transport (WebSocket? SSE? polling?). Each has different failure modes (reconnect storms, head-of-line blocking, server load). Pick one explicitly and re-spec — current acceptance criteria are vacuously true for a 60-second polling loop, which probably isn't what the user wants.\n```\n\n## Anti-patterns to refuse\n\n- Architectural cosplay: \"consider using DDD/hexagonal/CQRS\" without showing why this spec demands it.\n- Failing because \"the spec doesn't say which framework\" when framework is obvious from the project's stack (skill body's project context tells you).\n- Skipping the data flow trace — the most useful thing this rubric produces.\n","spec-reviewer-rubrics/design.md":"# Design reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for design quality (UX for user-facing surfaces, DX for developer-facing surfaces — same rubric, different surface).\n\n## Questions to ask\n\nRate each dimension 0–10 against the spec's described surface (UI, API, CLI, library):\n\n1. **Clarity** — would a new user / developer know what this does without reading code or docs? 0 = inscrutable; 10 = self-documenting.\n2. **Ergonomics** — is the common case fast and the rare case possible? 0 = forces the rare case into every flow; 10 = invisible until needed.\n3. **Consistency** — does it match the surrounding system's conventions? 0 = a foreign body; 10 = indistinguishable from neighboring features.\n4. **Accessibility** — for UI: keyboard / screen-reader / contrast / motion. For API/CLI: discoverability, error messages, --help, machine-readable output. 0 = unusable for entire categories of users; 10 = enables everyone.\n\n## Verdict rule\n\n- All four dimensions ≥ 6 → `pass`.\n- Any dimension < 6 → `fail`.\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: clarity=N ergonomics=N consistency=N accessibility=N\n       Lowest-scoring dimension first, with the SINGLE concrete change that would raise it.\n```\n\n## Examples\n\n**Pass:** \"clarity=8 ergonomics=7 consistency=9 accessibility=6. Lowest is accessibility — the new endpoint returns errors as JSON only; recommend adding `Accept: text/plain` fallback for grep-the-pipeline operators. Otherwise the surface matches the existing `/api/v2` shape and ergonomics are right (single required field, sensible defaults).\"\n\n**Fail:** \"clarity=4 ergonomics=6 consistency=7 accessibility=7. Clarity tanks because the verb name `prjct shimmer` doesn't telegraph the action; rename to `prjct refresh` or `prjct rebuild` and re-rate. Other dimensions are healthy.\"\n\n## Anti-patterns to refuse\n\n- Vague \"looks good\" — every dimension needs a number.\n- Ignoring accessibility for \"internal tools\" — internal users include the colorblind and the blind.\n- Failing on aesthetic taste alone (color, typography). Design rubric is about USE, not opinion.\n- Over-indexing on novelty. Surfaces that surprise users score LOW on consistency, not high.\n","spec-reviewer-rubrics/strategic.md":"# Strategic reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for strategic soundness. You receive the spec body verbatim. Apply the questions below; return a single structured verdict.\n\n## Questions to ask\n\n1. **Is the goal real?** Does this solve a problem the user (or org) actually has? Or is it a tools-team-flavored solution looking for a problem?\n2. **Is the goal worth the cost?** Crude estimate of build cost vs. impact. If goal is small but cost is large, fail.\n3. **Is `out_of_scope` coherent with `goal`?** Goal that says \"fix onboarding\" with `out_of_scope: [\"welcome email\", \"first-login flow\"]` — what's left? Fail if scope evaporates the goal.\n4. **Is the spec OVER-scoped?** Trying to ship a quarter's work in one PR. Boil-the-lake principle says completeness is cheap when it costs minutes — fail when it costs months.\n5. **Is the spec UNDER-scoped?** Acceptance criteria so narrow that shipping doesn't move the needle. Fail when meeting all criteria still leaves the user's problem unsolved.\n6. **Are stakes honest?** \"Users will be frustrated\" is too vague. \"Auth fails for 3% of sessions during peak load\" is testable.\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: 2–4 sentences. If pass, name the strongest framing element. If fail, name the SINGLE\n       biggest gap and how to close it.\n```\n\n## Examples\n\n**Pass:** \"Goal is concrete (sub-200ms p95 on dashboard) and the stakes are measurable (lost engagement on slow widgets). Scope and out_of_scope draw a clean line. The strongest element is the explicit 'no caching layer in this PR' — that's the right anti-creep.\"\n\n**Fail:** \"Goal says 'improve auth UX' but acceptance_criteria all measure backend latency. Either rewrite the goal (this is a perf spec, not UX) or rewrite the criteria (add a usability metric). Currently the spec would pass review on a perf change that didn't move UX at all.\"\n\n## Anti-patterns to refuse\n\n- Praising the spec without naming a strength (`pass: looks good!` — useless).\n- Failing without proposing a fix (the next iteration of the spec needs a path forward).\n- Auto-failing because the spec is \"ambitious\" — strategic review measures soundness, not size.\n","spec-template.md":"# Spec template — `prjct spec`\n\nA spec frames a piece of work BEFORE implementation. Cheap to write, cheap to revise; un-doing implementation isn't.\n\nThe fields below match `core/types/spec.ts`. Validation is enforced by Zod at write time.\n\n---\n\n## Title (one line)\n\nWhat you'd say to a coworker walking by your desk.\n\n## Goal (1–3 sentences)\n\nWhat success looks like. Concrete. Observable.\n\n## ELI10 (2–4 sentences)\n\nPlain English a 16-year-old could follow. Forces you to articulate why this matters without jargon.\n\n## Stakes if we ship the wrong thing (1 sentence)\n\nWhat breaks. Who notices. How fast.\n\n## Acceptance criteria (testable, observable list)\n\nEach line is a sentence ending in a verifiable claim:\n\n- the new endpoint returns 429 after the 11th request in a minute from the same IP\n- the dashboard widget renders within 200ms p95 on a synthetic 4G profile\n- `prjct spec audit <id>` blocks if any reviewer returns `fail`\n\nAnti-patterns:\n\n- \"the system should be fast\" — what threshold, measured how?\n- \"users will love it\" — not testable\n- \"follow industry best practices\" — what specifically?\n\n## Scope (what's IN)\n\nThe pieces this spec commits to. Be specific about file paths, surfaces, modules.\n\n## Out of scope (what's OUT)\n\nThe pieces this spec explicitly DOES NOT cover. This is your anti-creep shield mid-implementation.\n\n## Risks\n\nEach risk has a mitigation. A risk without a mitigation is just a complaint.\n\n- **risk:** legacy endpoints rely on the same rate-limit middleware → **mitigation:** scope key separates `/auth` from `/api`\n- **risk:** Redis dependency raises ops cost → **mitigation:** start with in-memory token bucket; swap to Redis only above 5 RPS\n\n## Test plan\n\nHow you'll prove the acceptance criteria. Includes the unhappy path.\n\n- unit tests for the token bucket math\n- integration test: 11 requests, 11th returns 429\n- load test: 100 RPS sustained for 60s, no memory growth\n- manual: trigger via `curl` and inspect response headers\n\n## Notes (optional)\n\nThings that don't fit anywhere else but matter for context.\n\n---\n\n## Lifecycle\n\n```\ndraft  →  reviewed  →  in_progress  →  shipped\n                                    →  archived\n```\n\n- `draft` — created, not yet audited.\n- `reviewed` — `prjct audit-spec` returned pass on all three reviewers.\n- `in_progress` — at least one task with `linked_spec_id` exists.\n- `shipped` — code merged, criteria met (or override accepted).\n- `archived` — superseded or abandoned.\n\n## Verb cheatsheet\n\n```\nprjct spec \"<title>\"                       # draft — NO `draft` subverb, pass title directly\nprjct spec list [--status <s>]\nprjct spec show <id>\nprjct spec update <id> --json '{...}'      # PATCH content (shallow merge)\nprjct spec audit <id>                      # emit subagent dispatch\nprjct spec record-review <id> --reviewer <name> --verdict <pass|fail> --notes \"...\"\nprjct spec link-task <id> --task-id <task>\nprjct spec ship <id> [--pr <n>]\nprjct spec set-status <id> --status archived\nprjct spec inventory [--md|--json]         # coverage map per module\n```\n\n> **No `draft` subverb.** `prjct spec \"<title>\"` already creates a draft. The CLI tolerates `prjct spec draft|new|create \"<title>\"` as friendly aliases (the leading word is stripped) so `prjct spec draft \"rate limiting\"` and `prjct spec \"rate limiting\"` produce the same spec — but the canonical form has no leading verb.\n","tools/bash.txt":"Execute shell commands in a persistent bash session.\n\nUse this tool for terminal operations like git, npm, docker, build commands, and system utilities. NOT for file operations (use Read, Write, Edit instead).\n\nCapabilities:\n- Run any shell command\n- Persistent session (environment persists between calls)\n- Support for background execution\n- Configurable timeout (up to 10 minutes)\n\nBest practices:\n- Quote paths with spaces using double quotes\n- Use absolute paths to avoid cd\n- Chain dependent commands with &&\n- Run independent commands in parallel (multiple tool calls)\n- Never use for file reading (use Read tool)\n- Never use echo/printf to communicate (output text directly)\n\nGit operations:\n- Never update git config\n- Never use destructive commands without explicit request\n- Always use HEREDOC for commit messages\n","tools/edit.txt":"Edit files using exact string replacement.\n\nUse this tool to make precise changes to existing files. Requires reading the file first to ensure accurate matching.\n\nCapabilities:\n- Replace exact string matches in files\n- Support for replace_all to change all occurrences\n- Preserves file formatting and indentation\n\nRequirements:\n- Must read the file first (tool will error otherwise)\n- old_string must be unique in the file (or use replace_all)\n- Preserve exact indentation from the original\n\nBest practices:\n- Include enough context to make old_string unique\n- Use replace_all for renaming variables/functions\n- Never include line numbers in old_string or new_string\n","tools/glob.txt":"Find files by pattern matching.\n\nUse this tool to locate files using glob patterns. Fast and efficient for any codebase size.\n\nCapabilities:\n- Match files using glob patterns (e.g., \"**/*.ts\", \"src/**/*.tsx\")\n- Returns paths sorted by modification time\n- Works with any codebase size\n\nPattern examples:\n- \"**/*.ts\" - all TypeScript files\n- \"src/**/*.tsx\" - React components in src\n- \"**/test*.ts\" - test files anywhere\n- \"core/**/*\" - all files in core directory\n\nBest practices:\n- Use specific patterns to narrow results\n- Prefer glob over bash find command\n- Run multiple patterns in parallel if needed\n","tools/grep.txt":"Search file contents using regex patterns.\n\nUse this tool to search for code patterns, function definitions, imports, and text across the codebase. Built on ripgrep for speed.\n\nCapabilities:\n- Full regex syntax support\n- Filter by file type or glob pattern\n- Multiple output modes: files_with_matches, content, count\n- Context lines before/after matches (-A, -B, -C)\n- Multiline matching support\n\nOutput modes:\n- files_with_matches (default): just file paths\n- content: matching lines with context\n- count: match counts per file\n\nBest practices:\n- Use specific patterns to reduce noise\n- Filter by file type when possible (type: \"ts\")\n- Use content mode with context for understanding matches\n- Never use bash grep/rg directly (use this tool)\n","tools/read.txt":"Read files from the filesystem.\n\nUse this tool to read file contents before making edits. Always read a file before attempting to modify it to understand the current state and structure.\n\nCapabilities:\n- Read any text file by absolute path\n- Supports line offset and limit for large files\n- Returns content with line numbers for easy reference\n- Can read images, PDFs, and Jupyter notebooks\n\nBest practices:\n- Always read before editing\n- Use offset/limit for files > 2000 lines\n- Read multiple related files in parallel when exploring\n","tools/task.txt":"Launch specialized agents for complex tasks.\n\nUse this tool to delegate multi-step tasks to autonomous agents. Each agent type has specific capabilities and tools.\n\nAgent types:\n- Explore: Fast codebase exploration, file search, pattern finding\n- Plan: Software architecture, implementation planning\n- general-purpose: Research, code search, multi-step tasks\n\nWhen to use:\n- Complex multi-step tasks\n- Open-ended exploration\n- When multiple search rounds may be needed\n- Tasks matching agent descriptions\n\nBest practices:\n- Provide clear, detailed prompts\n- Launch multiple agents in parallel when independent\n- Prefer direct Glob/Grep for simple exploration. Subagents inherit all MCP tool schemas from the parent session and can start heavy — only delegate to Explore when the search is genuinely open-ended and benefits from parallel rounds\n- Use Plan for implementation design\n","tools/webfetch.txt":"Fetch and analyze web content.\n\nUse this tool to retrieve content from URLs and process it with AI. Useful for documentation, API references, and external resources.\n\nCapabilities:\n- Fetch any URL content\n- Automatic HTML to markdown conversion\n- AI-powered content extraction based on prompt\n- 15-minute cache for repeated requests\n- Automatic HTTP to HTTPS upgrade\n\nBest practices:\n- Provide specific prompts for extraction\n- Handle redirects by following the provided URL\n- Use for documentation and reference lookup\n- Results may be summarized for large content\n","tools/websearch.txt":"Search the web for current information.\n\nUse this tool to find up-to-date information beyond the knowledge cutoff. Returns search results with links.\n\nCapabilities:\n- Real-time web search\n- Domain filtering (allow/block specific sites)\n- Returns formatted results with URLs\n\nRequirements:\n- MUST include Sources section with URLs after answering\n- Use current year in queries for recent info\n\nBest practices:\n- Be specific in search queries\n- Include year for time-sensitive searches\n- Always cite sources in response\n- Filter domains when targeting specific sites\n","tools/write.txt":"Write or create files on the filesystem.\n\nUse this tool to create new files or completely overwrite existing ones. For modifications to existing files, prefer the Edit tool instead.\n\nCapabilities:\n- Create new files with specified content\n- Overwrite existing files completely\n- Create parent directories automatically\n\nRequirements:\n- Must read existing file first before overwriting\n- Use absolute paths only\n\nBest practices:\n- Prefer Edit for modifications to existing files\n- Only create new files when truly necessary\n- Never create documentation files unless explicitly requested\n","windsurf/router.md":"---\ntrigger: always_on\ndescription: \"prjct - Context layer for AI coding agents\"\n---\n\n# prjct\n\nCore: /sync, /task, /done, /ship, /pause, /resume, /next, /bug, /workflow\nOther: run `prjct <command> --md` and follow CLI output\n","windsurf/workflows/ship.md":"# /ship - Ship feature\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct ship {{args}} --md`\nFollow CLI output.\n","windsurf/workflows/task.md":"# /task - Start a task\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct task {{args}} --md`\nFollow CLI output.\n"}
+{"agentic/checklist-routing.md":"---\nallowed-tools: [Read, Glob]\ndescription: 'Determine which quality checklists to apply - Claude decides'\n---\n\n# Checklist Routing Instructions\n\n## Objective\n\nDetermine which quality checklists are relevant for a task by analyzing the ACTUAL task and its scope.\n\n## Step 1: Understand the Task\n\nRead the task description and identify:\n\n- What type of work is being done? (new feature, bug fix, refactor, infra, docs)\n- What domains are affected? (code, UI, API, database, deployment)\n- What is the scope? (small fix, major feature, architectural change)\n\n## Step 2: Consider Task Domains\n\nEach task can touch multiple domains. Consider:\n\n| Domain | Signals |\n|--------|---------|\n| Code Quality | Writing/modifying any code |\n| Architecture | New components, services, or major refactors |\n| UX/UI | User-facing changes, CLI output, visual elements |\n| Infrastructure | Deployment, containers, CI/CD, cloud resources |\n| Security | Auth, user data, external inputs, secrets |\n| Testing | New functionality, bug fixes, critical paths |\n| Documentation | Public APIs, complex features, breaking changes |\n| Performance | Data processing, loops, network calls, rendering |\n| Accessibility | User interfaces (web, mobile, CLI) |\n| Data | Database operations, caching, data transformations |\n\n## Step 3: Match Task to Checklists\n\nBased on your analysis, select relevant checklists:\n\n**DO NOT assume:**\n- Every task needs all checklists\n- \"Frontend\" = only UX checklist\n- \"Backend\" = only Code Quality checklist\n\n**DO analyze:**\n- What the task actually touches\n- What quality dimensions matter for this specific work\n- What could go wrong if not checked\n\n## Available Checklists\n\nLocated in `templates/checklists/`:\n\n| Checklist | When to Apply |\n|-----------|---------------|\n| `code-quality.md` | Any code changes (any language) |\n| `architecture.md` | New modules, services, significant structural changes |\n| `ux-ui.md` | User-facing interfaces (web, mobile, CLI, API DX) |\n| `infrastructure.md` | Deployment, containers, CI/CD, cloud resources |\n| `security.md` | ALWAYS for: auth, user input, external APIs, secrets |\n| `testing.md` | New features, bug fixes, refactors |\n| `documentation.md` | Public APIs, complex features, configuration changes |\n| `performance.md` | Data-intensive operations, critical paths |\n| `accessibility.md` | Any user interface work |\n| `data.md` | Database, caching, data transformations |\n\n## Decision Process\n\n1. Read task description\n2. Identify primary work domain\n3. List secondary domains affected\n4. Select 2-4 most relevant checklists\n5. Consider Security (almost always relevant)\n\n## Output\n\nReturn selected checklists with reasoning:\n\n```json\n{\n  \"checklists\": [\"code-quality\", \"security\", \"testing\"],\n  \"reasoning\": \"Task involves new API endpoint (code), handles user input (security), and adds business logic (testing)\",\n  \"priority_items\": [\"Input validation\", \"Error handling\", \"Happy path tests\"],\n  \"skipped\": {\n    \"accessibility\": \"No user interface changes\",\n    \"infrastructure\": \"No deployment changes\"\n  }\n}\n```\n\n## Rules\n\n- **Task-driven** - Focus on what the specific task needs\n- **Less is more** - 2-4 focused checklists beat 10 unfocused\n- **Security is special** - Default to including unless clearly irrelevant\n- **Explain your reasoning** - Don't just pick, justify selections AND skips\n- **Context matters** - Small typo fix ≠ major refactor in checklist needs\n","agentic/orchestrator.md":"# Orchestrator\n\nLoad project context for task execution.\n\n## Flow\n\n```\np. {command} → Load Config → Load State → Load Agents → Execute\n```\n\n## Step 1: Load Config\n\n```\nREAD: .prjct/prjct.config.json → {projectId}\nSET: {globalPath} = ~/.prjct-cli/projects/{projectId}\n```\n\n## Step 2: Load State\n\n```bash\nprjct dash compact\n# Parse output to determine: {hasActiveTask}\n```\n\n## Step 3: Load Agents\n\n```\nGLOB: {globalPath}/agents/*.md\nFOR EACH agent: READ and store content\n```\n\n## Step 4: Detect Domains\n\nAnalyze task → identify domains:\n- frontend: UI, forms, components\n- backend: API, server logic\n- database: Schema, queries\n- testing: Tests, mocks\n- devops: CI/CD, deployment\n\nIF task spans 3+ domains → fragment into subtasks\n\n## Step 5: Build Context\n\nCombine: state + agents + detected domains → execute\n\n## Output Format\n\n```\n🎯 Task: {description}\n📦 Context: Agent: {name} | State: {status} | Domains: {list}\n```\n\n## Error Handling\n\n| Situation | Action |\n|-----------|--------|\n| No config | \"Run `p. init` first\" |\n| No state | Create default |\n| No agents | Warn, continue |\n\n## Disable\n\n```yaml\n---\norchestrator: false\n---\n```\n","agentic/task-fragmentation.md":"# Task Fragmentation\n\nBreak complex multi-domain tasks into subtasks.\n\n## When to Fragment\n\n- Spans 3+ domains (frontend + backend + database)\n- Has natural dependency order\n- Too large for single execution\n\n## When NOT to Fragment\n\n- Single domain only\n- Small, focused change\n- Already atomic\n\n## Dependency Order\n\n1. **Database** (models first)\n2. **Backend** (API using models)\n3. **Frontend** (UI using API)\n4. **Testing** (tests for all)\n5. **DevOps** (deploy)\n\n## Subtask Format\n\n```json\n{\n  \"subtasks\": [{\n    \"id\": \"subtask-1\",\n    \"description\": \"Create users table\",\n    \"domain\": \"database\",\n    \"agent\": \"database.md\",\n    \"dependsOn\": []\n  }]\n}\n```\n\n## Output\n\n```\n🎯 Task: {task}\n\n📋 Subtasks:\n├─ 1. [database] Create schema\n├─ 2. [backend] Create API\n└─ 3. [frontend] Create form\n```\n\n## Delegation\n\n```\nTask(\n  subagent_type: 'general-purpose',\n  prompt: '\n    Read: {agentsPath}/{domain}.md\n    Subtask: {description}\n    Previous: {previousSummary}\n    Focus ONLY on this subtask.\n  '\n)\n```\n\n## Progress\n\n```\n📊 Progress: 2/4 (50%)\n✅ 1. [database] Done\n✅ 2. [backend] Done\n▶️ 3. [frontend] ← CURRENT\n⏳ 4. [testing]\n```\n\n## Error Handling\n\n```\n❌ Subtask 2/4 failed\n\nOptions:\n1. Retry\n2. Skip and continue\n3. Abort\n```\n\n## Anti-Patterns\n\n- Over-fragmentation: 10 subtasks for \"add button\"\n- Under-fragmentation: 1 subtask for \"add auth system\"\n- Wrong order: Frontend before backend\n","agents/AGENTS.md":"# AGENTS.md\n\nAI assistant guidance for **prjct-cli** - context layer for AI coding agents. Works with Claude Code, Gemini CLI, and more.\n\n## What This Is\n\n**NOT** project management. NO sprints, story points, ceremonies, or meetings.\n\n**IS** a context layer that gives AI agents the project knowledge they need to work effectively.\n\n---\n\n## Dynamic Agent Generation\n\nGenerate agents during `p. sync` based on analysis:\n\n```javascript\nawait generator.generateDynamicAgent('agent-name', {\n  role: 'Role Description',\n  expertise: 'Technologies, versions, tools',\n  responsibilities: 'What they handle'\n})\n```\n\n### Guidelines\n1. Read `analysis/repo-summary.md` first\n2. Create specialists for each major technology\n3. Name descriptively: `go-backend` not `be`\n4. Include versions and frameworks found\n5. Follow project-specific patterns\n\n## Architecture\n\n**Global**: `~/.prjct-cli/projects/{id}/`\n```\nprjct.db   # SQLite database (all state)\ncontext/   # now.md, next.md\nagents/    # domain specialists\n```\n\n**Local**: `.prjct/prjct.config.json` (read-only)\n\n## Commands\n\n| Command | Action |\n|---------|--------|\n| `p. init` | Initialize |\n| `p. sync` | Analyze + generate agents |\n| `p. task X` | Start task |\n| `p. done` | Complete subtask |\n| `p. ship` | Ship feature |\n| `p. next` | Show queue |\n\n## Intent Detection\n\n| Intent | Command |\n|--------|---------|\n| Start task | `p. task` |\n| Finish | `p. done` |\n| Ship | `p. ship` |\n| What's next | `p. next` |\n\n## Implementation\n\n- Atomic operations via `prjct` CLI\n- CLI handles all state persistence (SQLite)\n- Handle missing config gracefully\n\n## Crew mode (opt-in)\n\nProjects 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`.\n\n### Crew roster\n\nEach 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`.\n\n| Name | Role | Color |\n|---|---|---|\n| Leader | Orchestrator | blue |\n| Implementer | Worker | purple |\n| Reviewer | Strict auditor | pink |\n\nCrew 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\").\n","antigravity/SKILL.md":"---\nname: prjct\ndescription: Use when user mentions p., prjct, task tracking, or workflow commands.\n---\n\n# prjct — Context layer for AI agents\n\nGrammar: `p. <command> [args]` or `prjct <command> --md`\n\nCore commands: sync, task, done, ship, pause, resume, next, bug, workflow, tokens\nIntegrations: linear, jira, enrich\nOther: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nRules:\n- Persist everything (memories, captures, specs) in ENGLISH, whatever language the user speaks\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- All commits include footer: `Generated with [p/](https://www.prjct.app/)`\n- All storage through `prjct` CLI (SQLite internally)\n- Start code tasks with `p. task` and follow Context Contract from CLI output\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n","checklists/architecture.md":"# Architecture Checklist\n\n> Applies to ANY system architecture\n\n## Design Principles\n- [ ] Clear separation of concerns\n- [ ] Loose coupling between components\n- [ ] High cohesion within modules\n- [ ] Single source of truth for data\n- [ ] Explicit dependencies (no hidden coupling)\n\n## Scalability\n- [ ] Stateless where possible\n- [ ] Horizontal scaling considered\n- [ ] Bottlenecks identified\n- [ ] Caching strategy defined\n\n## Resilience\n- [ ] Failure modes documented\n- [ ] Graceful degradation planned\n- [ ] Recovery procedures defined\n- [ ] Circuit breakers where needed\n\n## Maintainability\n- [ ] Clear boundaries between layers\n- [ ] Easy to test in isolation\n- [ ] Configuration externalized\n- [ ] Logging and observability built-in\n","checklists/code-quality.md":"# Code Quality Checklist\n\n> Universal principles for ANY programming language\n\n## Universal Principles\n- [ ] Single Responsibility: Each unit does ONE thing well\n- [ ] DRY: No duplicated logic (extract shared code)\n- [ ] KISS: Simplest solution that works\n- [ ] Clear naming: Self-documenting identifiers\n- [ ] Consistent patterns: Match existing codebase style\n\n## Error Handling\n- [ ] All error paths handled gracefully\n- [ ] Meaningful error messages\n- [ ] No silent failures\n- [ ] Proper resource cleanup (files, connections, memory)\n\n## Edge Cases\n- [ ] Null/nil/None handling\n- [ ] Empty collections handled\n- [ ] Boundary conditions tested\n- [ ] Invalid input rejected early\n\n## Code Organization\n- [ ] Functions/methods are small and focused\n- [ ] Related code grouped together\n- [ ] Clear module/package boundaries\n- [ ] No circular dependencies\n","checklists/data.md":"# Data Checklist\n\n> Applies to: SQL, NoSQL, GraphQL, File storage, Caching\n\n## Data Integrity\n- [ ] Schema/structure defined\n- [ ] Constraints enforced\n- [ ] Transactions used appropriately\n- [ ] Referential integrity maintained\n\n## Query Performance\n- [ ] Indexes on frequent queries\n- [ ] N+1 queries eliminated\n- [ ] Query complexity analyzed\n- [ ] Pagination for large datasets\n\n## Data Operations\n- [ ] Migrations versioned and reversible\n- [ ] Backup and restore tested\n- [ ] Data validation at boundary\n- [ ] Soft deletes considered (if applicable)\n\n## Caching\n- [ ] Cache invalidation strategy defined\n- [ ] TTL values appropriate\n- [ ] Cache warming considered\n- [ ] Cache hit/miss monitored\n\n## Data Privacy\n- [ ] PII identified and protected\n- [ ] Data anonymization where needed\n- [ ] Audit trail for sensitive data\n- [ ] Data deletion procedures defined\n","checklists/documentation.md":"# Documentation Checklist\n\n> Applies to ALL projects\n\n## Essential Docs\n- [ ] README with quick start\n- [ ] Installation instructions\n- [ ] Configuration options documented\n- [ ] Common use cases shown\n\n## Code Documentation\n- [ ] Public APIs documented\n- [ ] Complex logic explained\n- [ ] Architecture decisions recorded (ADRs)\n- [ ] Diagrams for complex flows\n\n## Operational Docs\n- [ ] Deployment process documented\n- [ ] Troubleshooting guide\n- [ ] Runbooks for common issues\n- [ ] Changelog maintained\n\n## API Documentation\n- [ ] All endpoints documented\n- [ ] Request/response examples\n- [ ] Error codes explained\n- [ ] Authentication documented\n\n## Maintenance\n- [ ] Docs updated with code changes\n- [ ] Version-specific documentation\n- [ ] Broken links checked\n- [ ] Examples tested and working\n","checklists/infrastructure.md":"# Infrastructure Checklist\n\n> Applies to: Cloud, On-prem, Hybrid, Edge\n\n## Deployment\n- [ ] Infrastructure as Code (Terraform, Pulumi, CloudFormation, etc.)\n- [ ] Reproducible environments\n- [ ] Rollback strategy defined\n- [ ] Blue-green or canary deployment option\n\n## Observability\n- [ ] Logging strategy defined\n- [ ] Metrics collection configured\n- [ ] Alerting thresholds set\n- [ ] Distributed tracing (if applicable)\n\n## Security\n- [ ] Secrets management (not in code)\n- [ ] Network segmentation\n- [ ] Least privilege access\n- [ ] Encryption at rest and in transit\n\n## Reliability\n- [ ] Backup strategy defined\n- [ ] Disaster recovery plan\n- [ ] Health checks configured\n- [ ] Auto-scaling rules (if applicable)\n\n## Cost Management\n- [ ] Resource sizing appropriate\n- [ ] Unused resources identified\n- [ ] Cost monitoring in place\n- [ ] Budget alerts configured\n","checklists/performance.md":"# Performance Checklist\n\n> Applies to: Backend, Frontend, Mobile, Database\n\n## Analysis\n- [ ] Bottlenecks identified with profiling\n- [ ] Baseline metrics established\n- [ ] Performance budgets defined\n- [ ] Benchmarks before/after changes\n\n## Optimization Strategies\n- [ ] Algorithmic complexity reviewed (O(n) vs O(n²))\n- [ ] Appropriate data structures used\n- [ ] Caching implemented where beneficial\n- [ ] Lazy loading for expensive operations\n\n## Resource Management\n- [ ] Memory usage optimized\n- [ ] Connection pooling used\n- [ ] Batch operations where applicable\n- [ ] Async/parallel processing considered\n\n## Frontend Specific\n- [ ] Bundle size optimized\n- [ ] Images optimized\n- [ ] Critical rendering path optimized\n- [ ] Network requests minimized\n\n## Backend Specific\n- [ ] Database queries optimized\n- [ ] Response compression enabled\n- [ ] Proper indexing in place\n- [ ] Connection limits configured\n","checklists/security.md":"# Security Checklist\n\n> ALWAYS ON - Applies to ALL applications\n\n## Input/Output\n- [ ] All user input validated and sanitized\n- [ ] Output encoded appropriately (prevent injection)\n- [ ] File uploads restricted and scanned\n- [ ] No sensitive data in logs or error messages\n\n## Authentication & Authorization\n- [ ] Strong authentication mechanism\n- [ ] Proper session management\n- [ ] Authorization checked at every access point\n- [ ] Principle of least privilege applied\n\n## Data Protection\n- [ ] Sensitive data encrypted at rest\n- [ ] Secure transmission (TLS/HTTPS)\n- [ ] PII handled according to regulations\n- [ ] Data retention policies followed\n\n## Dependencies\n- [ ] Dependencies from trusted sources\n- [ ] Known vulnerabilities checked\n- [ ] Minimal dependency surface\n- [ ] Regular security updates planned\n\n## API Security\n- [ ] Rate limiting implemented\n- [ ] Authentication required for sensitive endpoints\n- [ ] CORS properly configured\n- [ ] API keys/tokens secured\n","checklists/testing.md":"# Testing Checklist\n\n> Applies to: Unit, Integration, E2E, Performance testing\n\n## Coverage Strategy\n- [ ] Critical paths have high coverage\n- [ ] Happy path tested\n- [ ] Error paths tested\n- [ ] Edge cases covered\n\n## Test Quality\n- [ ] Tests are deterministic (no flaky tests)\n- [ ] Tests are independent (no order dependency)\n- [ ] Tests are fast (optimize slow tests)\n- [ ] Tests are readable (clear intent)\n\n## Test Types\n- [ ] Unit tests for business logic\n- [ ] Integration tests for boundaries\n- [ ] E2E tests for critical flows\n- [ ] Performance tests for bottlenecks\n\n## Mocking Strategy\n- [ ] External services mocked\n- [ ] Database isolated or mocked\n- [ ] Time-dependent code controlled\n- [ ] Random values seeded\n\n## Test Maintenance\n- [ ] Tests updated with code changes\n- [ ] Dead tests removed\n- [ ] Test data managed properly\n- [ ] CI/CD integration working\n","checklists/ux-ui.md":"# UX/UI Checklist\n\n> Applies to: Web, Mobile, CLI, Desktop, API DX\n\n## User Experience\n- [ ] Clear user journey/flow\n- [ ] Feedback for every action\n- [ ] Loading states shown\n- [ ] Error states handled gracefully\n- [ ] Success confirmation provided\n\n## Interface Design\n- [ ] Consistent visual language\n- [ ] Intuitive navigation\n- [ ] Responsive/adaptive layout (if applicable)\n- [ ] Touch targets adequate (mobile)\n- [ ] Keyboard navigation (web/desktop)\n\n## CLI Specific\n- [ ] Help text for all commands\n- [ ] Clear error messages with suggestions\n- [ ] Progress indicators for long operations\n- [ ] Consistent flag naming conventions\n- [ ] Exit codes meaningful\n\n## API DX (Developer Experience)\n- [ ] Intuitive endpoint/function naming\n- [ ] Consistent response format\n- [ ] Helpful error messages with codes\n- [ ] Good documentation with examples\n- [ ] Predictable behavior\n\n## Information Architecture\n- [ ] Content hierarchy clear\n- [ ] Important actions prominent\n- [ ] Related items grouped\n- [ ] Search/filter for large datasets\n","codex/SKILL.md":"---\nname: prjct\ndescription: Use when the user mentions p., prjct, tasks, specs, shipping, or project memory. Routes to the prjct CLI and MCP tools — run commands on demand, do not preload context.\n---\n\n# prjct — project memory & workflow\n\nRun `prjct <command> --md` and follow its output. Pull context on demand; never dump it all.\n\n- Flow: `task` → work → `done` → `ship`\n- Memory (write in ENGLISH always): `prjct remember <decision|gotcha|learning|fact> \"<text>\"`, `prjct context memory <topic>` (recall), `prjct guard <file>` (preventive memory before editing)\n- Capture stray thoughts: `prjct capture \"<text>\"`\n- Worktrees: remove only AFTER the PR merges, from the main worktree; never with unpushed work.\n- Run `prjct --help` for the full command list; prefer the prjct MCP tools (`prjct_*`) when available.\n\nCommit footer: `Generated with [p/](https://www.prjct.app/)`\n","config/skill-mappings.json":"{\n  \"version\": \"3.0.0\",\n  \"description\": \"Skill packages from skills.sh for auto-installation during sync\",\n  \"sources\": {\n    \"primary\": {\n      \"name\": \"skills.sh\",\n      \"url\": \"https://skills.sh\",\n      \"installCmd\": \"npx skills add {package}\"\n    },\n    \"fallback\": {\n      \"name\": \"GitHub direct\",\n      \"installFormat\": \"owner/repo\"\n    }\n  },\n  \"skillsDirectory\": \"~/.claude/skills/\",\n  \"skillFormat\": {\n    \"required\": [\"name\", \"description\"],\n    \"optional\": [\"license\", \"compatibility\", \"metadata\", \"allowed-tools\"],\n    \"fileStructure\": {\n      \"required\": \"SKILL.md\",\n      \"optional\": [\"scripts/\", \"references/\", \"assets/\"]\n    }\n  },\n  \"agentToSkillMap\": {\n    \"frontend\": {\n      \"packages\": [\n        \"anthropics/skills/frontend-design\",\n        \"vercel-labs/agent-skills/vercel-react-best-practices\"\n      ]\n    },\n    \"uxui\": {\n      \"packages\": [\"anthropics/skills/frontend-design\"]\n    },\n    \"backend\": {\n      \"packages\": [\"obra/superpowers/systematic-debugging\"]\n    },\n    \"database\": {\n      \"packages\": []\n    },\n    \"testing\": {\n      \"packages\": [\"obra/superpowers/test-driven-development\", \"anthropics/skills/webapp-testing\"]\n    },\n    \"devops\": {\n      \"packages\": [\"anthropics/skills/mcp-builder\"]\n    },\n    \"prjct-planner\": {\n      \"packages\": [\"obra/superpowers/brainstorming\"]\n    },\n    \"prjct-shipper\": {\n      \"packages\": []\n    },\n    \"prjct-workflow\": {\n      \"packages\": []\n    }\n  },\n  \"documentSkills\": {\n    \"note\": \"Official Anthropic document creation skills\",\n    \"source\": \"anthropics/skills\",\n    \"skills\": {\n      \"pdf\": {\n        \"name\": \"pdf\",\n        \"description\": \"Create and edit PDF documents\",\n        \"path\": \"skills/pdf\"\n      },\n      \"docx\": {\n        \"name\": \"docx\",\n        \"description\": \"Create and edit Word documents\",\n        \"path\": \"skills/docx\"\n      },\n      \"pptx\": {\n        \"name\": \"pptx\",\n        \"description\": \"Create PowerPoint presentations\",\n        \"path\": \"skills/pptx\"\n      },\n      \"xlsx\": {\n        \"name\": \"xlsx\",\n        \"description\": \"Create Excel spreadsheets\",\n        \"path\": \"skills/xlsx\"\n      }\n    }\n  }\n}\n","context/dashboard.md":"---\ndescription: 'Template for generated dashboard context'\ngenerated-by: 'p. dashboard'\ndata-source: 'prjct.db (SQLite)'\n---\n\n# Dashboard Context Template\n\nThis template defines the format for `{globalPath}/context/dashboard.md` generated by `p. dashboard`.\n\n---\n\n## Template\n\n```markdown\n# Dashboard\n\n**Project:** {projectName}\n**Generated:** {timestamp}\n\n---\n\n## Health Score\n\n**Overall:** {healthScore}/100\n\n| Component | Score | Weight | Contribution |\n|-----------|-------|--------|--------------|\n| Roadmap Progress | {roadmapScore}/100 | 25% | {roadmapContribution} |\n| Estimation Accuracy | {estimationScore}/100 | 25% | {estimationContribution} |\n| Success Rate | {successScore}/100 | 25% | {successContribution} |\n| Velocity Trend | {velocityScore}/100 | 25% | {velocityContribution} |\n\n---\n\n## Quick Stats\n\n| Metric | Value | Trend |\n|--------|-------|-------|\n| Features Shipped | {shippedCount} | {shippedTrend} |\n| PRDs Created | {prdCount} | {prdTrend} |\n| Avg Cycle Time | {avgCycleTime}d | {cycleTrend} |\n| Estimation Accuracy | {estimationAccuracy}% | {accuracyTrend} |\n| Success Rate | {successRate}% | {successTrend} |\n| ROI Score | {avgROI} | {roiTrend} |\n\n---\n\n## Active Quarter: {activeQuarter.id}\n\n**Theme:** {activeQuarter.theme}\n**Status:** {activeQuarter.status}\n\n### Progress\n\n```\nFeatures:  {featureBar} {quarterFeatureProgress}%\nCapacity:  {capacityBar} {capacityUtilization}%\nTimeline:  {timelineBar} {timelineProgress}%\n```\n\n### Features\n\n| Feature | Status | Progress | Owner |\n|---------|--------|----------|-------|\n{FOR EACH feature in quarterFeatures:}\n| {feature.name} | {statusEmoji(feature.status)} | {feature.progress}% | {feature.agent || '-'} |\n{END FOR}\n\n---\n\n## Current Work\n\n### Active Task\n{IF currentTask:}\n**{currentTask.description}**\n\n- Type: {currentTask.type}\n- Started: {currentTask.startedAt}\n- Elapsed: {elapsed}\n- Branch: {currentTask.branch?.name || 'N/A'}\n\nSubtasks: {completedSubtasks}/{totalSubtasks}\n{ELSE:}\n*No active task*\n{END IF}\n\n### In Progress Features\n\n{FOR EACH feature in activeFeatures:}\n#### {feature.name}\n\n- Progress: {progressBar(feature.progress)} {feature.progress}%\n- Quarter: {feature.quarter || 'Unassigned'}\n- PRD: {feature.prdId || 'None'}\n- Dependencies: {feature.dependencies?.join(', ') || 'None'}\n{END FOR}\n\n---\n\n## Pipeline\n\n```\nPRDs          Features       Active         Shipped\n┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐\n│ Draft   │──▶│ Planned │──▶│ Active  │──▶│ Shipped │\n│  ({draft})  │   │  ({planned}) │   │  ({active})  │   │  ({shipped}) │\n└─────────┘   └─────────┘   └─────────┘   └─────────┘\n     │\n     ▼\n┌─────────┐\n│Approved │\n│  ({approved}) │\n└─────────┘\n```\n\n---\n\n## Metrics Trends (Last 4 Weeks)\n\n### Velocity\n```\nW-3: {velocityW3Bar} {velocityW3}\nW-2: {velocityW2Bar} {velocityW2}\nW-1: {velocityW1Bar} {velocityW1}\nW-0: {velocityW0Bar} {velocityW0}\n```\n\n### Estimation Accuracy\n```\nW-3: {accuracyW3Bar} {accuracyW3}%\nW-2: {accuracyW2Bar} {accuracyW2}%\nW-1: {accuracyW1Bar} {accuracyW1}%\nW-0: {accuracyW0Bar} {accuracyW0}%\n```\n\n---\n\n## Alerts & Actions\n\n### Warnings\n{FOR EACH alert in alerts:}\n- {alert.icon} {alert.message}\n{END FOR}\n\n### Suggested Actions\n{FOR EACH action in suggestedActions:}\n1. {action.description}\n   - Command: `{action.command}`\n{END FOR}\n\n---\n\n## Recent Activity\n\n| Date | Action | Details |\n|------|--------|---------|\n{FOR EACH event in recentEvents.slice(0, 10):}\n| {event.date} | {event.action} | {event.details} |\n{END FOR}\n\n---\n\n## Learnings Summary\n\n### Top Patterns\n{FOR EACH pattern in topPatterns.slice(0, 5):}\n- {pattern.insight} ({pattern.frequency}x)\n{END FOR}\n\n### Improvement Areas\n{FOR EACH area in improvementAreas:}\n- **{area.name}**: {area.suggestion}\n{END FOR}\n\n---\n\n*Generated by prjct-cli | https://prjct.app*\n```\n\n---\n\n## Health Score Calculation\n\n```javascript\nconst healthScore = Math.round(\n  (roadmapProgress * 0.25) +\n  (estimationAccuracy * 0.25) +\n  (successRate * 0.25) +\n  (normalizedVelocity * 0.25)\n)\n```\n\n| Score Range | Health Level | Color |\n|-------------|--------------|-------|\n| 80-100 | Excellent | Green |\n| 60-79 | Good | Blue |\n| 40-59 | Needs Attention | Yellow |\n| 0-39 | Critical | Red |\n\n---\n\n## Alert Definitions\n\n| Condition | Alert | Severity |\n|-----------|-------|----------|\n| `capacityUtilization > 90` | Quarter capacity nearly full | Warning |\n| `estimationAccuracy < 60` | Estimation accuracy below target | Warning |\n| `activeFeatures.length > 3` | Too many features in progress | Info |\n| `draftPRDs.length > 3` | PRDs awaiting review | Info |\n| `successRate < 70` | Success rate declining | Warning |\n| `velocityTrend < -20` | Velocity dropping | Warning |\n| `currentTask && elapsed > 4h` | Task running long | Info |\n\n---\n\n## Suggested Actions Matrix\n\n| Condition | Suggested Action | Command |\n|-----------|------------------|---------|\n| No active task | Start a task | `p. task` |\n| PRDs in draft | Review PRDs | `p. prd list` |\n| Features pending review | Record impact | `p. impact` |\n| Quarter ending soon | Plan next quarter | `p. plan quarter` |\n| Low estimation accuracy | Analyze estimates | `p. dashboard estimates` |\n\n---\n\n## Integration with Linear/Jira/Monday\n\nThe dashboard context maps to PM tool dashboards:\n\n| Dashboard Section | Linear | Jira | Monday |\n|-------------------|--------|------|--------|\n| Health Score | Project Health | Dashboard Gadget | Board Overview |\n| Active Quarter | Cycle | Sprint | Timeline |\n| Pipeline | Workflow Board | Kanban | Board |\n| Velocity | Velocity Chart | Velocity Report | Chart Widget |\n| Alerts | Notifications | Issues | Notifications |\n\n---\n\n## Refresh Frequency\n\n| Data Type | Refresh Trigger |\n|-----------|-----------------|\n| Current Task | Real-time (on state change) |\n| Features | On feature status change |\n| Metrics | On `p. dashboard` execution |\n| Aggregates | On `p. impact` completion |\n| Alerts | Calculated on view |\n","context/roadmap.md":"---\ndescription: 'Template for generated roadmap context'\ngenerated-by: 'p. plan, p. sync'\ndata-source: 'prjct.db (SQLite)'\n---\n\n# Roadmap Context Template\n\nThis template defines the format for `{globalPath}/context/roadmap.md` generated by:\n- `p. plan` - After quarter planning\n- `p. sync` - After roadmap generation from git\n\n---\n\n## Template\n\n```markdown\n# Roadmap\n\n**Last Updated:** {lastUpdated}\n\n---\n\n## Strategy\n\n**Goal:** {strategy.goal}\n\n### Phases\n{FOR EACH phase in strategy.phases:}\n- **{phase.id}**: {phase.name} ({phase.status})\n{END FOR}\n\n### Success Metrics\n{FOR EACH metric in strategy.successMetrics:}\n- {metric}\n{END FOR}\n\n---\n\n## Quarters\n\n{FOR EACH quarter in quarters:}\n### {quarter.id}: {quarter.name}\n\n**Status:** {quarter.status}\n**Theme:** {quarter.theme}\n**Capacity:** {capacity.allocatedHours}/{capacity.totalHours}h ({utilization}%)\n\n#### Goals\n{FOR EACH goal in quarter.goals:}\n- {goal}\n{END FOR}\n\n#### Features\n{FOR EACH featureId in quarter.features:}\n- [{status icon}] **{feature.name}** ({feature.status}, {feature.progress}%)\n  - PRD: {feature.prdId || 'None (legacy)'}\n  - Estimated: {feature.effortTracking?.estimated?.hours || '?'}h\n  - Value Score: {feature.valueScore || 'N/A'}\n  - Dependencies: {feature.dependencies?.join(', ') || 'None'}\n{END FOR}\n\n{END FOR}\n\n---\n\n## Active Work\n\n{FOR EACH feature WHERE status == 'active':}\n### {feature.name}\n\n| Attribute | Value |\n|-----------|-------|\n| Progress | {feature.progress}% |\n| Branch | {feature.branch || 'N/A'} |\n| Quarter | {feature.quarter || 'Unassigned'} |\n| PRD | {feature.prdId || 'Legacy (no PRD)'} |\n| Started | {feature.createdAt} |\n\n#### Tasks\n{FOR EACH task in feature.tasks:}\n- [{task.completed ? 'x' : ' '}] {task.description}\n{END FOR}\n\n{END FOR}\n\n---\n\n## Completed Features\n\n{FOR EACH feature WHERE status == 'completed' OR status == 'shipped':}\n- **{feature.name}** (v{feature.version || 'N/A'})\n  - Shipped: {feature.shippedAt || feature.completedDate}\n  - Actual: {feature.effortTracking?.actual?.hours || '?'}h vs Est: {feature.effortTracking?.estimated?.hours || '?'}h\n{END FOR}\n\n---\n\n## Backlog\n\nPriority-ordered list of unscheduled items:\n\n| Priority | Item | Value | Effort | Score |\n|----------|------|-------|--------|-------|\n{FOR EACH item in backlog:}\n| {rank} | {item.title} | {item.valueScore} | {item.effortEstimate}h | {priorityScore} |\n{END FOR}\n\n---\n\n## Legacy Features\n\nFeatures detected from git history (no PRD required):\n\n{FOR EACH feature WHERE legacy == true:}\n- **{feature.name}**\n  - Inferred From: {feature.inferredFrom}\n  - Status: {feature.status}\n  - Commits: {feature.commits?.length || 0}\n{END FOR}\n\n---\n\n## Dependencies\n\n```\n{FOR EACH feature WHERE dependencies?.length > 0:}\n{feature.name}\n{FOR EACH depId in feature.dependencies:}\n  └── {dependency.name}\n{END FOR}\n{END FOR}\n```\n\n---\n\n## Metrics Summary\n\n| Metric | Value |\n|--------|-------|\n| Total Features | {features.length} |\n| Planned | {planned.length} |\n| Active | {active.length} |\n| Completed | {completed.length} |\n| Shipped | {shipped.length} |\n| Legacy | {legacy.length} |\n| PRD-Backed | {prdBacked.length} |\n| Backlog | {backlog.length} |\n\n### Capacity by Quarter\n\n| Quarter | Allocated | Total | Utilization |\n|---------|-----------|-------|-------------|\n{FOR EACH quarter in quarters:}\n| {quarter.id} | {capacity.allocatedHours}h | {capacity.totalHours}h | {utilization}% |\n{END FOR}\n\n### Effort Accuracy (Shipped Features)\n\n| Feature | Estimated | Actual | Variance |\n|---------|-----------|--------|----------|\n{FOR EACH feature WHERE status == 'shipped' AND effortTracking:}\n| {feature.name} | {estimated.hours}h | {actual.hours}h | {variance}% |\n{END FOR}\n\n**Average Variance:** {averageVariance}%\n\n---\n\n*Generated by prjct-cli | https://prjct.app*\n```\n\n---\n\n## Status Icons\n\n| Status | Icon |\n|--------|------|\n| planned | [ ] |\n| active | [~] |\n| completed | [x] |\n| shipped | [+] |\n\n---\n\n## Variable Reference\n\n| Variable | Source | Description |\n|----------|--------|-------------|\n| `lastUpdated` | roadmap.lastUpdated | ISO timestamp |\n| `strategy` | roadmap.strategy | Strategy object |\n| `quarters` | roadmap.quarters | Array of quarters |\n| `features` | roadmap.features | Array of features |\n| `backlog` | roadmap.backlog | Array of backlog items |\n| `utilization` | Calculated | (allocated/total) * 100 |\n| `priorityScore` | Calculated | valueScore / (effort/10) |\n\n---\n\n## Generation Rules\n\n1. **Quarters** - Show only `planned` and `active` quarters by default\n2. **Features** - Group by status (active first, then planned)\n3. **Backlog** - Sort by priority score (descending)\n4. **Legacy** - Always show separately to distinguish from PRD-backed\n5. **Dependencies** - Only show features with dependencies\n6. **Metrics** - Always include for dashboard views\n\n---\n\n## Integration with Linear/Jira/Monday\n\nThe context file maps to PM tool exports:\n\n| Context Section | Linear | Jira | Monday |\n|-----------------|--------|------|--------|\n| Quarters | Cycles | Sprints | Timelines |\n| Features | Issues | Stories | Items |\n| Backlog | Backlog | Backlog | Inbox |\n| Status | State | Status | Status |\n| Capacity | Estimates | Story Points | Time |\n","crew/CHECKPOINTS.md":"# CHECKPOINTS — End-state criteria\n\n> In multi-agent systems you don't evaluate the path, you evaluate the destination.\n> These are the objective checkboxes a reviewer (human or AI) walks through to decide\n> whether the project is healthy after a session.\n\n> **Customise this file for your project.** The defaults below cover the generic\n> crew invariants. Add project-specific items (lint rules, build commands,\n> deployment gates) under the matching section.\n\n## C1 — The crew is wired\n\n- [ ] `.prjct/prjct.config.json` exists and points to a valid project ID.\n- [ ] The `crew:checkpoints` row exists in kv_store (the gate criteria the reviewer applies — visible via `prjct crew checkpoints`).\n- [ ] `.claude/agents/leader.md`, `implementer.md`, `reviewer.md` are present.\n- [ ] Project `CLAUDE.md` (or equivalent) contains the crew leader-mode block.\n\n## C2 — State is coherent\n\n- [ ] At most **one** task is in `active` status (`prjct status --md`).\n- [ ] No task in `active` is older than the current session without a captured blocker note.\n- [ ] Every task marked `done` has at least one paired test file (or a justified exception in the implementer report).\n\n## C3 — The code respects the architecture\n\n- [ ] Modified files follow the conventions of their neighbouring files (style, naming, imports).\n- [ ] No new runtime dependencies were added without a `prjct capture --tags dep-add` note.\n- [ ] No debug noise: no `console.log` / `print()` / `dbg!` left in source.\n- [ ] No `TODO` without a captured follow-up in `prjct capture`.\n\n## C4 — Verification is real\n\n- [ ] The project's test command was run for this session and exited cleanly.\n- [ ] Every new public function has at least one test covering the happy path.\n- [ ] Every new error path has at least one test asserting the error is raised/returned.\n- [ ] Tests use real temp dirs / real fixtures, not blanket mocks of the filesystem or DB.\n\n## C5 — The session closed cleanly\n\n- [ ] No untracked junk in the worktree (`*.tmp`, scratch logs, accidental binaries, any subdirectory of `.prjct/`).\n- [ ] The implementer replied inline with the summary block (STATUS / PLAN / FILES TOUCHED / VERIFICATION / NOTES).\n- [ ] The reviewer replied inline with `VERDICT: APPROVED` (first line).\n- [ ] The task's status was advanced (`prjct status done` for completed work, `prjct status paused` if intentionally paused).\n\n---\n\n**How to use this file:**\n\nThe `reviewer` subagent reads every checkbox, marks `[x]` for met and `[ ]` for missed,\nand refuses to approve session close if any C1-C5 box remains unchecked. Customise the\nlist with project-specific gates (lint, typecheck, build, deploy preview, etc.).\n","crew/CLAUDE-leader-mode.md":"<!-- prjct:crew:start - DO NOT REMOVE THIS MARKER -->\n## Crew leader mode\n\nThis project is in **crew mode**. The main session always acts as the `leader` subagent (see `.claude/agents/leader.md`). The leader **decomposes and coordinates** — it does not implement.\n\n### This overrides the prjct skill's \"do simple work directly\" rule — FOR CODE\n\nThe prjct skill says most work is simple → go direct, no subagents. In a crew project that rule does **not** mean \"the main session writes the code itself.\" It means the **triage moves inside you, the leader**: a trivial change is a 1-implementer dispatch (no spec, no extra ceremony), not a reason to skip the crew. For ANY work that writes code or tests, you dispatch — every time. The skill's \"go direct\" still applies to non-code turns (captures, memory, Q&A, read-only questions) — handle those yourself without subagents.\n\n### Hard rules for the main session\n\n- ❌ Do not edit application source or test files directly (no Edit, no Write, no Bash that writes to those paths) — no matter how small the change looks. Small ≠ skip-the-crew; small = one implementer.\n- ❌ Do not run `prjct status done` yourself — the implementer does that, but only after the reviewer approves.\n- ✅ For any code task, launch the appropriate subagent via the `Agent` tool:\n  - `subagent_type: \"implementer\"` → writes code and tests for one prjct task. Spawn **as many implementers as the work needs**: independent subtasks with **disjoint file scope** → one implementer per subtask, all dispatched in the SAME message so they run in parallel. You assign each its non-overlapping scope. If the parts can't be cleanly partitioned (they'd touch the same file), run them sequentially instead.\n  - `subagent_type: \"reviewer\"` → validates the implementers' combined work against the project checkpoints (embedded in the reviewer's prompt; manage via `prjct crew checkpoints`) before close. One reviewer over the whole diff, even after a parallel fan-out.\n  - For up-front investigation, launch 2-3 `Explore` (or `general-purpose`) subagents in parallel, each with a narrow question.\n\n### Model per role (perf — set `model:` on every `Agent` call)\n\nYou orchestrate on a small model on purpose; apply the same discipline to what you dispatch. A subagent inherits the parent's model unless its definition or your `Agent` call sets one:\n\n- `implementer` → `model: \"opus\"` — writes code, the only role that gets the max model. Each parallel implementer is its own `opus` call.\n- `reviewer` → `model: \"sonnet\"` — judgment, not implementation.\n- `Explore` / any read-only investigation → `model: \"haiku\"`.\n\n`implementer` and `reviewer` pin their model in their own definitions; set it explicitly for `Explore` and any ad-hoc subagent. Never let a non-implementer run on the max model.\n\n### Keep replies tight\n\nInstruct every subagent to reply with a **one-screen summary** — files touched, verification command + result, blockers — not full diffs or transcripts. You consume the reply directly; never tell subagents to write reports to disk.\n\nIf you need durable state that outlives the session, persist via `prjct` CLI verbs (`prjct spec`, `prjct remember`, `prjct capture`) — SQLite + the regenerated vault are the only allowed persistence surfaces.\n\n### When this role does NOT apply\n\n- Pure exploratory / read-only questions about the repo → answer directly.\n- Edits to docs, configuration files (e.g. `.prjct/prjct.config.json`), or this file → you may edit directly.\n\n### Hard persistence rule\n\nNever write audit, checkpoint, review, deploy, or report markdown into any new file or subdirectory under the prjct state folder, and no scratch `.md` anywhere else in the worktree. The ONLY hand-editable file in that folder is `.prjct/prjct.config.json`. Everything else — checkpoints, audits, decisions, learnings, deploy notes — lives in SQLite + the regenerated vault, written through `prjct` CLI verbs (`prjct crew checkpoints set`, `prjct remember`, `prjct capture`, `prjct spec record-review`). If a subagent reports findings, persist them via `prjct remember` and cite the returned mem id; never tell a subagent to write to disk.\n<!-- prjct:crew:end - DO NOT REMOVE THIS MARKER -->\n","crew/agents/implementer.md":"---\nname: implementer\ndescription: \"Implementer (Worker, purple). Implements exactly ONE prjct task end-to-end. Writes code, writes tests, self-verifies. Never approves its own work.\"\ntools: Read, Write, Edit, Glob, Grep, Bash\nmodel: opus\ncolor: purple\n---\n\n# Implementer\n\nYou are an implementer. Your job is to take **one** prjct task from active to ready-for-review.\n\n## Protocol\n\n1. **Orient.** Run `prjct context --md` to understand task and recent decisions. (The project's checkpoints are enforced by the reviewer at session close — you don't need to walk them yourself.)\n2. **Confirm scope.** Run `prjct status --md` — there must be exactly one active task. If not, stop and report `blocked -> no single active task`.\n3. **Plan.** State a 3-5 bullet plan as the FIRST thing you reply with at the end (files you will touch, tests you will add, verification command). Keep it inline — do not write the plan to disk.\n4. **Implement.** Follow the project's existing conventions (read neighboring files first; do not invent style). Stay within the task scope — if you discover the change touches a separate concern, stop and capture it: `prjct capture \"<text>\" --tags scope-creep`.\n5. **Test.** Every code change is paired with a test before moving on. Use the project's existing test runner.\n6. **Self-verify.** Run the project's tests. If they fail, return to step 4. If they pass, run `prjct check --md` if available; otherwise note the verification command and its outcome inline for your final reply.\n7. **Do not mark `done`.** The reviewer must approve first. Do not run `prjct status done` until the reviewer's reply is `APPROVED`.\n8. **Hand off.** Reply to the leader with a compact summary (≈one screen). The `FILES:` block is parsed by the leader to invoke `prjct crew record-run` — keep it strict: one path per line, no parens, no leading dash, no annotations:\n\n   ```\n   STATUS: ready-for-review\n\n   PLAN: <3-5 bullets from step 3>\n\n   FILES:\n   path/to/a.ts\n   path/to/a.test.ts\n\n   VERIFICATION: bun test path/to/a.test.ts  →  PASS (4 tests)\n\n   NOTES: <surprises, scope-creep captures by mem id, blockers>\n   ```\n\n   The leader will launch a `reviewer` next. Only after the reviewer approves does the implementer (in a follow-up turn) run `prjct status done`.\n\n## Hard rules\n\n- One task per session. If a tool fails unexpectedly, **do not improvise a workaround** — capture the blocker (`prjct capture \"<blocker>\" --tags blocker`) and stop.\n- Every code edit must be accompanied by its test before the next edit.\n- Never declare a task `done` without the reviewer's explicit `APPROVED`.\n- Never write debug `console.log` / `print` / scratch files into source. Clean up before handing off.\n- Never write report files into the working tree — no scratch `.md`, no subdirectory under `.prjct/`. Durable state goes through `prjct` CLI verbs only.\n\n## Keep your reply tight\n\nReply with the summary block above. Do not paste full diffs, do not paste full test output. If something is too long to summarize, capture it with `prjct remember <type> \"<text>\"` and cite the returned mem id in your NOTES line.\n","crew/agents/leader.md":"---\nname: leader\ndescription: \"Leader (Orchestrator, blue). Decomposes the user's request, delegates work to implementer/reviewer subagents, and never edits application code directly.\"\ntools: Read, Glob, Grep, Bash, Agent\nmodel: haiku\ncolor: blue\n---\n\n# Leader (Orchestrator)\n\nYou are the leader of this repository. Your only job is to **decompose and coordinate**, never to implement.\n\n## Boot protocol (run on first request of the session)\n\n1. Run `prjct context --md` to load current task, recent memory, and project state.\n2. Run `prjct status --md` to confirm whether there is an active task.\n3. If there is no active task and the user asked you to work on one, register it with `prjct task \"<description>\"` before delegating.\n4. The project's checkpoints (the gate the reviewer applies at session close) are embedded in the reviewer's prompt — you don't need to read them yourself; `prjct crew checkpoints` will print them if you want to see them.\n\n## How to break work down\n\nFor each request:\n\n1. Identify whether the work fits in **one** task or needs to be split.\n   - If split, register each part with `prjct task` (subtasks) so every implementer owns exactly one.\n2. Trivial change (1 file, no design surface) → 1 `implementer` subagent.\n3. Standard change (2-3 files) → 1 `implementer` then 1 `reviewer`.\n4. Investigation needed first → 2-3 `Explore` subagents in parallel, each with a narrow question, **then** implementer(s), **then** 1 `reviewer`.\n5. Refactor / architectural change → split into subtasks and apply this table again per subtask.\n6. **Independent subtasks → fan out implementers in parallel.** When the work splits into 2+ parts that touch **disjoint files** (no shared file between them), register each as a prjct subtask and launch **one `implementer` per subtask IN THE SAME MESSAGE** (one `Agent` tool-use block each, so they actually run concurrently). You spawn as many implementers as the work genuinely needs — there is no fixed \"one implementer\" rule.\n\n### Partition rule for parallel implementers (MUST)\n\nYou assign the work; the implementers never negotiate scope between themselves. Before fanning out:\n\n- Carve a **non-overlapping file scope** for each implementer and name it in that implementer's dispatch prompt (\"you own `src/auth/*` and its tests; do not touch anything else\").\n- If you **cannot** cleanly partition — two parts would edit the same file — **do NOT parallelize them**. Run those parts sequentially (or merge them into one subtask). Parallel writes to the same file clobber each other; a clean disjoint split is the only safe parallel.\n- One shared concern that several subtasks depend on (a type, a shared util) → do that part FIRST in its own implementer, let it return, THEN fan out the dependents.\n\n### Reviewing a fan-out\n\nAfter all parallel implementers return, launch **one** `reviewer` over the **combined** diff (`git diff --stat` shows every file touched across the fan-out). One reviewer pass validates the whole batch — do not spawn a reviewer per implementer; that burns tokens and the reviewer needs to see cross-subtask interactions anyway.\n\n## Keep subagent replies tight\n\nWhen you launch a subagent, instruct it to reply with a **one-screen summary** — files touched, verification command + outcome, blockers. Not a full diff, not a transcript, not a \"see attached\" file reference. You consume the reply directly.\n\nSubagents must not write reports to disk. Persistence on this project goes through `prjct` CLI verbs only — SQLite + the regenerated vault are the only allowed surfaces.\n\n## Model policy when dispatching (perf — non-negotiable)\n\nYou run on a small model on purpose: you orchestrate, you do not implement. Apply the same discipline to what you dispatch — a subagent inherits your model unless its definition or your Agent call sets one:\n\n- `implementer` → `model: \"opus\"` (it writes code; the only role that gets max).\n- `reviewer` → `model: \"sonnet\"` (judgment, not implementation).\n- `Explore` / any read-only investigation subagent you spawn → set `model: \"haiku\"` in the Agent call — they route information, they don't write code.\n\n`implementer` and `reviewer` already pin their model in their own definitions; you must set it explicitly for `Explore` and any ad-hoc subagent. Never let a non-implementer subagent run on the max model — that is what made tasks crawl.\n\n## Point, don't carry — nothing leaves prjct (MUST)\n\nThe plan, the task, and the memory live in prjct (SQLite + regenerated vault) — never in your dispatch prompt, never in a scratch file. When you delegate, your prompt NAMES where the work lives and the subagent reads it itself in its own window: `prjct context --md` (task + recent decisions), `prjct status --md` (active task), `prjct spec show <id> --md` (the plan), `prjct context memory <topic>` (memory). Do not paste task/plan/memory content into the subagent prompt — pass the command. Subagents persist back only through `prjct` verbs. No plan, memory, or task may exist outside prjct.\n\nExample correct prompt to a subagent:\n\n> \"Investigate how `notes.py` serializes IDs. Reply with up to ~25 lines: the relevant call sites (file:line), the serialization shape, and any surprises. If the answer is bigger, capture details with `prjct remember learning '<summary>'` and reply with the mem id + headline.\"\n\n### Why this is also a prompt-cache + token win (not just hygiene)\n\nPointing instead of carrying is what keeps you cheap:\n\n- Your own window stays lean — you never absorb the files/diffs the subagents read, so the cacheable prefix of YOUR context (system + this leader prompt + prjct state) stays stable across every dispatch and gets reused turn after turn.\n- Each subagent reads project state in ITS OWN fresh window via the `prjct` commands you name — that read is local to it and thrown away when it returns its one-screen summary. Nothing flows back into your context except the summary.\n- Keep dispatch prompts **structurally identical** across implementers (same skeleton: role line → the `prjct` commands to run → the disjoint scope → the output format). Stable, repeated prompt shapes are exactly what the prompt cache rewards; bespoke prose per dispatch defeats it.\n\nBurning tokens looks like: pasting file contents or task/plan/memory bodies into a dispatch, echoing a subagent's full transcript back to the user, or re-reading the same files in your own window that a subagent already read. Don't do any of those.\n\n## Session close protocol\n\nWhen the reviewer replies `VERDICT: APPROVED`:\n\n1. Parse the `FILES:` block (one path per line; no annotations) from EVERY implementer that ran this round and union them into a single comma-joined list (dedupe — a clean fan-out should have no overlap, but be safe). Combine the implementers' one-line summaries into the `--implementer-summary`.\n2. Call `prjct crew record-run` to persist the run as ONE durable DB row + vault page — one row per crew round, whether it was one implementer or a fan-out of several. Idempotent on `--run-id` (so a retry with the same id is safe):\n\n   ```\n   prjct crew record-run \\\n     --spec <spec-id-if-any> \\\n     --task <task-id-if-any> \\\n     --implementer-summary \"<the implementer's summary>\" \\\n     --files \"path/to/a.ts,path/to/a.test.ts\" \\\n     --reviewer-verdict APPROVED \\\n     --reviewer-notes \"<reviewer notes if any>\" \\\n     --md\n   ```\n\n3. Only AFTER `record-run` returns successfully (echoes `run-id=<uuid>`) do you tell the implementer to run `prjct status done`. The order is a gate — never advance the task before recording the run.\n\nIf the reviewer replies `VERDICT: CHANGES_REQUESTED`, do not call `record-run` for that round — pass the reviewer's notes back to the implementer for revision.\n\n## Effort scaling\n\n| Complexity                              | Subagents                                                  |\n|-----------------------------------------|------------------------------------------------------------|\n| Trivial (1 file)                        | 1 implementer                                              |\n| Standard (2-3 files)                    | 1 implementer + 1 reviewer                                 |\n| Independent subtasks (disjoint files)   | N implementers IN PARALLEL → 1 reviewer over combined diff |\n| Refactor / cross-cutting                | 2-3 explorers → implementer(s) → 1 reviewer                |\n| Very complex                            | Split into prjct subtasks; recurse per subtask             |\n\nMatch the implementer count to the work. One subtask → one implementer. Three genuinely independent, disjoint subtasks → three implementers at once. Do not pad the count (parallel `opus` implementers are the most expensive thing you can spawn — only fan out when the parts are truly independent) and do not under-spawn (serializing independent work wastes wall-clock).\n\n## What you do NOT do\n\n- Do not edit files in the application's source/test directories directly.\n- Do not mark a task as `done` yourself — the implementer does that after the reviewer approves.\n- Do not paste full subagent transcripts or diffs back to the user — summarize.\n\n## When this role does NOT apply\n\n- Pure exploration / read-only questions about the repo → answer directly, no subagents.\n- Edits to docs, configuration files (e.g. `.prjct/prjct.config.json`), or this file itself → you may edit directly.\n\n## Hard persistence rule\n\nNever write audit, checklist, review, deploy, or report markdown into any new file or subdirectory under the prjct state folder. The ONLY hand-editable file in that folder is `.prjct/prjct.config.json`. Durable state — checkpoints, audits, reviews, decisions, learnings — goes through `prjct` CLI verbs (`prjct crew checkpoints set`, `prjct remember`, `prjct capture`, `prjct spec record-review`). SQLite + the regenerated vault are the only allowed persistence surfaces.\n","crew/agents/reviewer.md":"---\nname: reviewer\ndescription: \"Reviewer (Strict auditor, pink). Approves or rejects an implementer's work against the project checkpoints and conventions. Never edits code.\"\ntools: Read, Glob, Grep, Bash\nmodel: sonnet\ncolor: pink\n---\n\n# Reviewer\n\nYou are a strict reviewer. Your only function is to **approve or reject** changes. You never edit code.\n\nThe project's checkpoints are inlined below (spliced in by `prjct crew install` from the kv_store row `crew:checkpoints`; manage them via `prjct crew checkpoints set|reset|export`). Walk every checkbox — `[x]` for met, `[ ]` for missed.\n\n## Checkpoints\n\n<!-- prjct:checkpoints:start - DO NOT EDIT (managed by `prjct crew checkpoints set|reset`) -->\n<!-- prjct:checkpoints:end -->\n\n## Protocol\n\n1. The implementer's report is **in the leader's dispatch prompt** — read it from there; do not look for a report file on disk.\n2. Identify the modified files (use `git status --porcelain` and `git diff --stat`). Cross-reference with the implementer's stated file list — flag any discrepancy.\n3. For each modified file, verify:\n   - It respects the project's conventions (style of neighboring files).\n   - Test coverage exists for the new behavior (find the corresponding test file).\n   - No debug noise was left behind (`console.log`, `print`, `TODO` without a captured note).\n4. Run the project's test command. Tests must pass — if any test is red, that is an automatic rejection.\n5. Walk every checkbox in the **Checkpoints** section above. Mark `[x]` for met, `[ ]` for missed.\n6. Reply to the leader with the verdict block (inline, no files).\n\n## Verdict format\n\nReply to the leader inline with this exact shape:\n\n```markdown\nVERDICT: APPROVED | CHANGES_REQUESTED\n\nCHECKPOINTS:\n- C1: [x]\n- C2: [x]\n- C3: [ ]  ← Reason: src/foo.ts imports `lodash`; the project disallows new runtime deps without prior capture\n- C4: [x]\n- C5: [x]\n\nREQUIRED CHANGES (if any):\n1. Remove `import lodash from 'lodash'` from src/foo.ts.\n2. ...\n```\n\nFirst line of the reply must be `VERDICT: APPROVED` or `VERDICT: CHANGES_REQUESTED`. The leader keys off that first token.\n\n## Hard rules\n\n- Never approve with red tests.\n- Never approve with empty checkboxes in C1-C5.\n- Never edit the implementer's code. Your job is to say what fails — not to fix it.\n- Be concrete: cite file paths and line numbers. No generic feedback.\n- Never write your verdict to a file. The reply itself IS the verdict.\n","crew/registry.json":"{\n  \"$schema\": \"./registry.schema.json\",\n  \"version\": 1,\n  \"crew\": [\n    {\n      \"id\": \"leader\",\n      \"name\": \"Leader\",\n      \"role\": \"Orchestrator\",\n      \"color\": \"blue\",\n      \"summary\": \"Decomposes the user's request and delegates to implementer/reviewer subagents. Never edits application code.\"\n    },\n    {\n      \"id\": \"implementer\",\n      \"name\": \"Implementer\",\n      \"role\": \"Worker\",\n      \"color\": \"purple\",\n      \"summary\": \"Takes one prjct task from active to ready-for-review. Writes code, writes tests, self-verifies. Never approves its own work.\"\n    },\n    {\n      \"id\": \"reviewer\",\n      \"name\": \"Reviewer\",\n      \"role\": \"Strict auditor\",\n      \"color\": \"pink\",\n      \"summary\": \"Approves or rejects work against project checkpoints and conventions. Never edits code.\"\n    }\n  ]\n}\n","cursor/commands/ship.md":"# /ship - Ship feature\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct ship {{args}} --md`\nFollow CLI output.\n","cursor/commands/task.md":"# /task - Start a task\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct task {{args}} --md`\nFollow CLI output.\n","cursor/p.md":"# p. Command Router for Cursor IDE\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct {{first_word_of_args}} {{rest_of_args}} --md`\nFollow CLI output.\n","cursor/router.mdc":"---\ndescription: \"prjct - Context layer for AI coding agents\"\nalwaysApply: true\n---\n\n# prjct\n\nCore: /sync, /task, /done, /ship, /pause, /resume, /next, /bug, /workflow\nOther: run `prjct <command> --md` and follow CLI output\n","global/ANTIGRAVITY.md":"<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Antigravity, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","global/CURSOR.mdc":"---\ndescription: \"prjct - Context layer for AI coding agents\"\nalwaysApply: true\n---\n\n<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Cursor, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","global/GEMINI.md":"<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- Persist everything (memories, captures, specs) in ENGLISH, whatever language the user speaks\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Gemini, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","global/STORAGE-SPEC.md":"# Storage Specification\n\n**Canonical specification for prjct storage format.**\n\nAll storage is managed by the `prjct` CLI which uses SQLite (`prjct.db`) internally. **NEVER read or write JSON storage files directly. Use `prjct` CLI commands for all storage operations.**\n\n---\n\n## Current Storage: SQLite (prjct.db)\n\nAll reads and writes go through the `prjct` CLI, which manages a SQLite database (`prjct.db`) with WAL mode for safe concurrent access.\n\n```\n~/.prjct-cli/projects/{projectId}/\n├── prjct.db            # SQLite database (SOURCE OF TRUTH for all storage)\n├── context/\n│   ├── now.md          # Current task (generated from prjct.db)\n│   └── next.md         # Queue (generated from prjct.db)\n├── config/\n│   └── skills.json     # Agent-to-skill mappings\n├── agents/             # Domain specialists (auto-generated)\n└── sync/\n    └── pending.json    # Events for backend sync\n```\n\n### How to interact with storage\n\n- **Read state**: Use `prjct status`, `prjct dash`, `prjct next` CLI commands\n- **Write state**: Use `prjct` CLI commands (task, done, pause, resume, etc.)\n- **Issue tracker setup**: Use `prjct linear setup` or `prjct jira setup` (MCP/OAuth)\n- **Never** read/write JSON files in `storage/` or `memory/` directories\n\n---\n\n## LEGACY JSON Schemas (for reference only)\n\n> **WARNING**: These JSON schemas are LEGACY documentation only. The `storage/` and `memory/` directories are no longer used. All data lives in `prjct.db` (SQLite). Do NOT read or write these files.\n\n### state.json (LEGACY)\n\n```json\n{\n  \"task\": {\n    \"id\": \"uuid-v4\",\n    \"title\": \"string\",\n    \"type\": \"feature|bug|improvement|refactor|chore\",\n    \"status\": \"active|paused|done\",\n    \"branch\": \"string|null\",\n    \"subtasks\": [\n      {\n        \"id\": \"uuid-v4\",\n        \"title\": \"string\",\n        \"status\": \"pending|done\"\n      }\n    ],\n    \"currentSubtask\": 0,\n    \"createdAt\": \"2024-01-15T10:30:00.000Z\",\n    \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n  }\n}\n```\n\n**Empty state (no active task):**\n```json\n{\n  \"task\": null\n}\n```\n\n### queue.json (LEGACY)\n\n```json\n{\n  \"tasks\": [\n    {\n      \"id\": \"uuid-v4\",\n      \"title\": \"string\",\n      \"type\": \"feature|bug|improvement|refactor|chore\",\n      \"priority\": 1,\n      \"createdAt\": \"2024-01-15T10:30:00.000Z\"\n    }\n  ],\n  \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### shipped.json (LEGACY)\n\n```json\n{\n  \"features\": [\n    {\n      \"id\": \"uuid-v4\",\n      \"name\": \"string\",\n      \"version\": \"1.0.0\",\n      \"type\": \"feature|bug|improvement|refactor|chore\",\n      \"shippedAt\": \"2024-01-15T10:30:00.000Z\"\n    }\n  ],\n  \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### events.jsonl (LEGACY - now stored in SQLite `events` table)\n\nPreviously append-only JSONL. Now stored in SQLite.\n\n```jsonl\n{\"type\":\"task.created\",\"timestamp\":\"2024-01-15T10:30:00.000Z\",\"data\":{\"taskId\":\"uuid\",\"title\":\"string\"}}\n{\"type\":\"task.started\",\"timestamp\":\"2024-01-15T10:30:00.000Z\",\"data\":{\"taskId\":\"uuid\"}}\n{\"type\":\"subtask.completed\",\"timestamp\":\"2024-01-15T10:35:00.000Z\",\"data\":{\"taskId\":\"uuid\",\"subtaskIndex\":0}}\n{\"type\":\"task.completed\",\"timestamp\":\"2024-01-15T10:40:00.000Z\",\"data\":{\"taskId\":\"uuid\"}}\n{\"type\":\"feature.shipped\",\"timestamp\":\"2024-01-15T10:45:00.000Z\",\"data\":{\"featureId\":\"uuid\",\"name\":\"string\",\"version\":\"1.0.0\"}}\n```\n\n**Event Types:**\n- `task.created` - New task created\n- `task.started` - Task activated\n- `task.paused` - Task paused\n- `task.resumed` - Task resumed\n- `task.completed` - Task completed\n- `subtask.completed` - Subtask completed\n- `feature.shipped` - Feature shipped\n\n### learnings.jsonl (LEGACY - now stored in SQLite)\n\nPreviously used for LLM-to-LLM knowledge transfer. Now stored in SQLite.\n\n```jsonl\n{\"taskId\":\"uuid\",\"linearId\":\"PRJ-123\",\"timestamp\":\"2024-01-15T10:40:00.000Z\",\"learnings\":{\"patterns\":[\"Use NestedContextResolver for hierarchical discovery\"],\"approaches\":[\"Mirror existing method structure when extending\"],\"decisions\":[\"Extended class rather than wrapper for consistency\"],\"gotchas\":[\"Must handle null parent case\"]},\"value\":{\"type\":\"feature\",\"impact\":\"high\",\"description\":\"Hierarchical AGENTS.md support for monorepos\"},\"filesChanged\":[\"core/resolver.ts\",\"core/types.ts\"],\"tags\":[\"agents\",\"hierarchy\",\"monorepo\"]}\n```\n\n**Schema:**\n```json\n{\n  \"taskId\": \"uuid-v4\",\n  \"linearId\": \"string|null\",\n  \"timestamp\": \"2024-01-15T10:40:00.000Z\",\n  \"learnings\": {\n    \"patterns\": [\"string\"],\n    \"approaches\": [\"string\"],\n    \"decisions\": [\"string\"],\n    \"gotchas\": [\"string\"]\n  },\n  \"value\": {\n    \"type\": \"feature|bugfix|performance|dx|refactor|infrastructure\",\n    \"impact\": \"high|medium|low\",\n    \"description\": \"string\"\n  },\n  \"filesChanged\": [\"string\"],\n  \"tags\": [\"string\"]\n}\n```\n\n**Why Local Cache**: Enables future semantic retrieval without API latency. Will feed into vector DB for cross-session knowledge transfer.\n\n### skills.json\n\n```json\n{\n  \"mappings\": {\n    \"frontend.md\": [\"frontend-design\"],\n    \"backend.md\": [\"javascript-typescript\"],\n    \"testing.md\": [\"developer-kit\"]\n  },\n  \"updatedAt\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n### pending.json (sync queue)\n\n```json\n{\n  \"events\": [\n    {\n      \"id\": \"uuid-v4\",\n      \"type\": \"task.created\",\n      \"timestamp\": \"2024-01-15T10:30:00.000Z\",\n      \"data\": {},\n      \"synced\": false\n    }\n  ],\n  \"lastSync\": \"2024-01-15T10:30:00.000Z\"\n}\n```\n\n---\n\n## Formatting Rules (MANDATORY)\n\nAll agents MUST follow these rules for cross-agent compatibility:\n\n| Rule | Value |\n|------|-------|\n| JSON indentation | 2 spaces |\n| Trailing commas | NEVER |\n| Key ordering | Logical (as shown in schemas above) |\n| Timestamps | ISO-8601 with milliseconds (`.000Z`) |\n| UUIDs | v4 format (lowercase) |\n| Line endings | LF (not CRLF) |\n| File encoding | UTF-8 without BOM |\n| Empty objects | `{}` |\n| Empty arrays | `[]` |\n| Null values | `null` (lowercase) |\n\n### Timestamp Generation\n\n```bash\n# ALWAYS use dynamic timestamps, NEVER hardcode\nbun -e \"console.log(new Date().toISOString())\" 2>/dev/null || node -e \"console.log(new Date().toISOString())\"\n```\n\n### UUID Generation\n\n```bash\n# ALWAYS generate fresh UUIDs\nbun -e \"console.log(crypto.randomUUID())\" 2>/dev/null || node -e \"console.log(require('crypto').randomUUID())\"\n```\n\n---\n\n## Write Rules (CRITICAL)\n\n### Direct Writes Only\n\n**NEVER use temporary files** - Write directly to final destination:\n\n```\nWRONG: Create `.tmp/file.json`, then `mv` to final path\nCORRECT: Use prjctDb.setDoc() or StorageManager.write() to write to SQLite\n```\n\n### Atomic Updates\n\nAll writes go through SQLite which handles atomicity via WAL mode:\n```typescript\n// StorageManager pattern (preferred):\nawait stateStorage.update(projectId, (state) => {\n  state.field = newValue\n  return state\n})\n\n// Direct kv_store pattern:\nprjctDb.setDoc(projectId, 'key', data)\n```\n\n### NEVER Do These\n\n- Read or write JSON files in `storage/` or `memory/` directories\n- Use `.tmp/` directories\n- Use `mv` or `rename` operations for storage files\n- Create backup files like `*.bak` or `*.old`\n- Bypass `prjct` CLI to write directly to `prjct.db`\n\n---\n\n## Cross-Agent Compatibility\n\n### Why This Matters\n\n1. **User freedom**: Switch between Claude and Gemini freely\n2. **Remote sync**: Storage will sync to prjct.app backend\n3. **Single truth**: Both agents produce identical output\n\n### Verification Test\n\n```bash\n# Start task with Claude\np. task \"add feature X\"\n\n# Switch to Gemini, continue\np. done  # Should work seamlessly\n\n# Switch back to Claude\np. ship  # Should read Gemini's changes correctly\n\n# All agents read from the same prjct.db via CLI commands\nprjct status  # Works from any agent\n```\n\n### Remote Sync Flow\n\n```\nLocal Storage: prjct.db (Claude/Gemini)\n        ↓\n    sync/pending.json (events queue)\n        ↓\n    prjct.app API\n        ↓\n    Global Remote Storage\n        ↓\n    Any device, any agent\n```\n\n---\n\n## MCP Issue Tracker Strategy\n\nIssue tracker integrations are MCP-only.\n\n### Rules\n\n- `prjct` CLI does not call Linear/Jira SDKs or REST APIs directly.\n- Issue operations (`sync`, `list`, `get`, `start`, `done`, `update`, etc.) are delegated to MCP tools in the AI client.\n- `p. sync` refreshes project context and agent artifacts, not issue tracker payloads.\n- Local storage keeps task linkage metadata (for example `linearId`) and project workflow state in SQLite.\n\n### Setup\n\n- `prjct linear setup`\n- `prjct jira setup`\n\n### Operational Model\n\n```\nAI client MCP tools <-> Linear/Jira\n          |\n          v\n       prjct workflow state (prjct.db)\n```\n\nThe CLI remains the source of truth for local project/task state.\nIssue-system mutations happen through MCP operations in the active AI session.\n\n---\n\n**Version**: 2.0.0\n**Last Updated**: 2026-02-10\n","global/WINDSURF.md":"---\ntrigger: always_on\ndescription: \"prjct - Context layer for AI coding agents\"\n---\n\n<!-- prjct:start - DO NOT REMOVE THIS MARKER -->\n# p/ — Context layer for AI agents\n\nSkills auto-activate for: task, done, pause, resume, ship, next, sync, bug, workflow, enrich, linear, jira, plan, velocity, tokens\nOther commands: run `prjct <command> --md` and follow CLI output\n\nFlow: idea → roadmap → next → task → done → ship → next (cycle until plan complete)\n\nData:\n- prjct runs → LLM generates relevant data → prjct stores it → LLM requests it from prjct → LLM uses it\n- prjct remembers and shows the path; the agent decides how to execute with its own native tools\n- Treat prjct output as signals, not a prescriptive harness\n- Commit footer: `Generated with [p/](https://www.prjct.app/)`\n- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`\n- Storage: `prjct` CLI (SQLite internally)\n- Worktree hygiene: if working in a git worktree, remove it AFTER its PR merges — `git worktree remove` from the main worktree; never with uncommitted/unpushed work, never `--force`\n\nCrew (opt-in via `prjct crew install`): Leader (blue) · Implementer (purple) · Reviewer (pink). Subagent dispatch is Claude-Code-only; in Windsurf, identify the role you are playing explicitly.\n\n**Auto-managed by prjct-cli** | https://prjct.app\n<!-- prjct:end - DO NOT REMOVE THIS MARKER -->\n","mcp-config.json":"{\n  \"mcpServers\": {\n    \"context7\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@upstash/context7-mcp@latest\"],\n      \"description\": \"Library documentation lookup\"\n    },\n    \"linear\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mcp-remote\", \"https://mcp.linear.app/mcp\"],\n      \"description\": \"Linear MCP server (OAuth)\"\n    },\n    \"jira\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mcp-remote\", \"https://mcp.atlassian.com/v1/mcp\"],\n      \"description\": \"Atlassian MCP server for Jira (OAuth)\"\n    }\n  },\n  \"usage\": {\n    \"context7\": {\n      \"when\": [\"Looking up library/framework documentation\", \"Need current API docs\"],\n      \"tools\": [\"resolve-library-id\", \"get-library-docs\"]\n    }\n  },\n  \"integrations\": {\n    \"linear\": \"MCP - Run `prjct linear setup`\",\n    \"jira\": \"MCP - Run `prjct jira setup`\"\n  }\n}\n","permissions/default.jsonc":"{\n  // Default permissions preset for prjct-cli\n  // Safe defaults with protection against destructive operations\n\n  \"bash\": {\n    // Safe read-only commands - always allowed\n    \"git status*\": \"allow\",\n    \"git log*\": \"allow\",\n    \"git diff*\": \"allow\",\n    \"git branch*\": \"allow\",\n    \"ls*\": \"allow\",\n    \"pwd\": \"allow\",\n    \"cat*\": \"allow\",\n    \"head*\": \"allow\",\n    \"tail*\": \"allow\",\n    \"grep*\": \"allow\",\n    \"find*\": \"allow\",\n    \"which*\": \"allow\",\n    \"node -e*\": \"allow\",\n    \"bun -e*\": \"allow\",\n    \"npm list*\": \"allow\",\n    \"npx tsc --noEmit*\": \"allow\",\n\n    // Potentially destructive - ask first\n    \"rm -rf*\": \"ask\",\n    \"rm -r*\": \"ask\",\n    \"git push*\": \"ask\",\n    \"git reset --hard*\": \"ask\",\n    \"npm publish*\": \"ask\",\n    \"chmod*\": \"ask\",\n\n    // Always denied - too dangerous\n    \"rm -rf /*\": \"deny\",\n    \"rm -rf ~/*\": \"deny\",\n    \"sudo*\": \"deny\"\n  },\n\n  \"files\": {\n    \"read\": {\n      \"**/*\": \"allow\"\n    },\n    \"write\": {\n      \"**/*\": \"allow\"\n    },\n    \"delete\": {\n      \"**/*\": \"ask\"\n    }\n  },\n\n  \"web\": {\n    \"enabled\": true\n  },\n\n  \"doomLoop\": {\n    \"enabled\": true,\n    \"maxRetries\": 3\n  },\n\n  \"externalDirectories\": \"ask\"\n}\n","permissions/permissive.jsonc":"{\n  // Permissive preset for prjct-cli\n  // For trusted environments - minimal restrictions\n\n  \"bash\": {\n    // Most commands allowed\n    \"git*\": \"allow\",\n    \"npm*\": \"allow\",\n    \"bun*\": \"allow\",\n    \"node*\": \"allow\",\n    \"ls*\": \"allow\",\n    \"cat*\": \"allow\",\n    \"mkdir*\": \"allow\",\n    \"cp*\": \"allow\",\n    \"mv*\": \"allow\",\n    \"rm*\": \"allow\",\n    \"chmod*\": \"allow\",\n\n    // Still protect against catastrophic mistakes\n    \"rm -rf /*\": \"deny\",\n    \"rm -rf ~/*\": \"deny\",\n    \"sudo rm -rf*\": \"deny\",\n    \":(){ :|:& };:*\": \"deny\"\n  },\n\n  \"files\": {\n    \"read\": {\n      \"**/*\": \"allow\"\n    },\n    \"write\": {\n      \"**/*\": \"allow\"\n    },\n    \"delete\": {\n      \"**/*\": \"allow\",\n      \"**/node_modules/**\": \"deny\" // Protect dependencies\n    }\n  },\n\n  \"web\": {\n    \"enabled\": true\n  },\n\n  \"doomLoop\": {\n    \"enabled\": true,\n    \"maxRetries\": 5\n  },\n\n  \"externalDirectories\": \"allow\"\n}\n","permissions/strict.jsonc":"{\n  // Strict permissions preset for prjct-cli\n  // Maximum safety - requires approval for most operations\n\n  \"bash\": {\n    // Only read-only commands allowed\n    \"git status\": \"allow\",\n    \"git log*\": \"allow\",\n    \"git diff*\": \"allow\",\n    \"ls*\": \"allow\",\n    \"pwd\": \"allow\",\n    \"cat*\": \"allow\",\n    \"head*\": \"allow\",\n    \"tail*\": \"allow\",\n    \"which*\": \"allow\",\n\n    // Everything else requires approval\n    \"git*\": \"ask\",\n    \"npm*\": \"ask\",\n    \"bun*\": \"ask\",\n    \"node*\": \"ask\",\n    \"rm*\": \"ask\",\n    \"mv*\": \"ask\",\n    \"cp*\": \"ask\",\n    \"mkdir*\": \"ask\",\n\n    // Always denied\n    \"rm -rf*\": \"deny\",\n    \"sudo*\": \"deny\",\n    \"chmod 777*\": \"deny\"\n  },\n\n  \"files\": {\n    \"read\": {\n      \"**/*\": \"allow\",\n      \"**/.*\": \"ask\", // Hidden files need approval\n      \"**/.env*\": \"deny\" // Never read env files\n    },\n    \"write\": {\n      \"**/*\": \"ask\" // All writes need approval\n    },\n    \"delete\": {\n      \"**/*\": \"deny\" // No deletions without explicit override\n    }\n  },\n\n  \"web\": {\n    \"enabled\": true,\n    \"blockedDomains\": [\"localhost\", \"127.0.0.1\", \"internal\"]\n  },\n\n  \"doomLoop\": {\n    \"enabled\": true,\n    \"maxRetries\": 2\n  },\n\n  \"externalDirectories\": \"deny\"\n}\n","planning-methodology-deep.md":"# Software Planning Methodology for prjct\n\nThis methodology guides the AI through developing ideas into complete technical specifications.\n\n## Phase 1: Discovery & Problem Definition\n\n### Questions to Ask\n- What specific problem does this solve?\n- Who is the target user?\n- What's the budget and timeline?\n- What happens if this problem isn't solved?\n\n### Output\n- Problem statement\n- User personas\n- Business constraints\n- Success metrics\n\n## Phase 2: User Flows & Journeys\n\n### Process\n1. Map primary user journey\n2. Identify entry points\n3. Define success states\n4. Document error states\n5. Note edge cases\n\n### Jobs-to-be-Done\nWhen [situation], I want to [motivation], so I can [expected outcome]\n\n## Phase 3: Domain Modeling\n\n### Entity Definition\nFor each entity, define:\n- Description\n- Attributes (name, type, constraints)\n- Relationships\n- Business rules\n- Lifecycle states\n\n### Bounded Contexts\nGroup entities into logical boundaries with:\n- Owned entities\n- External dependencies\n- Events published/consumed\n\n## Phase 4: API Contract Design\n\n### Style Selection\n| Style    | Best For |\n|----------|----------|\n| REST     | Simple CRUD, broad compatibility |\n| GraphQL  | Complex data requirements |\n| tRPC     | Full-stack TypeScript |\n| gRPC     | Microservices |\n\n### Endpoint Specification\n- Method/Type\n- Path/Name\n- Authentication\n- Input/Output schemas\n- Error responses\n\n## Phase 5: System Architecture\n\n### Pattern Selection\n| Pattern | Best For |\n|---------|----------|\n| Modular Monolith | Small team, fast iteration |\n| Serverless-First | Variable load, event-driven |\n| Microservices | Large team, complex domain |\n\n### C4 Model\n1. Context - System and external actors\n2. Container - Major components\n3. Component - Internal structure\n\n## Phase 6: Data Architecture\n\n### Database Selection\n| Type | Options | Best For |\n|------|---------|----------|\n| Relational | PostgreSQL | ACID, structured data |\n| Document | MongoDB | Flexible schema |\n| Key-Value | Redis | Caching, sessions |\n\n### Schema Design\n- Tables and columns\n- Indexes\n- Constraints\n- Relationships\n\n## Phase 7: Tech Stack Decision\n\n### Frontend Stack\n- Framework (Next.js, Remix, SvelteKit)\n- Styling (Tailwind, CSS Modules)\n- State management (Zustand, Jotai)\n- Data fetching (TanStack Query, SWR)\n\n### Backend Stack\n- Runtime (Node.js, Bun)\n- Framework (Next.js API, Hono)\n- ORM (Drizzle, Prisma)\n- Validation (Zod, Valibot)\n\n### Infrastructure\n- Hosting (Vercel, Railway, Fly.io)\n- Database (Neon, PlanetScale)\n- Cache (Upstash, Redis)\n- Monitoring (Sentry, Axiom)\n\n## Phase 8: Implementation Roadmap\n\n### MVP Scope Definition\n- Must-have features (P0)\n- Should-have features (P1)\n- Nice-to-have features (P2)\n- Future considerations (P3)\n\n### Development Phases\n1. Foundation - Setup, core infrastructure\n2. Core Features - Primary functionality\n3. Polish & Launch - Optimization, deployment\n\n### Risk Assessment\n- Technical risks and mitigation\n- Business risks and mitigation\n- Dependencies and assumptions\n\n## Output Structure\n\nWhen complete, generate:\n\n1. **Executive Summary** - Problem, solution, key decisions\n2. **Architecture Documents** - All phases detailed\n3. **Implementation Plan** - Prioritized tasks with estimates\n4. **Decision Log** - Key choices and reasoning\n\n## Interactive Development Process\n\n1. **Classification**: Determine if idea needs full architecture\n2. **Discovery**: Ask clarifying questions\n3. **Generation**: Create architecture phase by phase\n4. **Validation**: Review with user at key points\n5. **Refinement**: Iterate based on feedback\n6. **Output**: Save complete specification\n\n## Success Criteria\n\nA complete architecture includes:\n- Clear problem definition\n- User flows mapped\n- Domain model defined\n- API contracts specified\n- Tech stack chosen\n- Database schema designed\n- Implementation roadmap created\n- Risk assessment completed\n\n## Templates\n\n### Entity Template\n```\nEntity: [Name]\n├── Description: [What it represents]\n├── Attributes:\n│   ├── id: uuid (primary key)\n│   └── [field]: [type] ([constraints])\n├── Relationships: [connections]\n├── Rules: [invariants]\n└── States: [lifecycle]\n```\n\n### API Endpoint Template\n```\nOperation: [Name]\n├── Method: [GET/POST/PUT/DELETE]\n├── Path: [/api/resource]\n├── Auth: [Required/Optional]\n├── Input: {schema}\n├── Output: {schema}\n└── Errors: [codes and descriptions]\n```\n\n### Phase Template\n```\nPhase: [Name]\n├── Duration: [timeframe]\n├── Tasks:\n│   ├── [Task 1]\n│   └── [Task 2]\n├── Deliverable: [outcome]\n└── Dependencies: [prerequisites]\n```","sdd-canonical-sequence.md":"# SDD canonical sequence — prjct\n\nSpec-Driven Development is prjct's default flow for substantive work. The six stations:\n\n```\nspec ─→ audit-spec ─→ task (--spec <id>) ─→ implement ─→ ship (acceptance gate)\n                                                                  └─→ remember learning\n```\n\n## Stations\n\n### 1. `spec`\n\nThe user describes a feature, fix, or initiative WITH goals or stakes. You don't run `task` yet. You run `prjct spec \"<title>\"` and walk the forcing questions:\n\n- goal (1–3 sentences)\n- eli10 (2–4 sentences)\n- stakes if we ship the wrong thing\n- acceptance criteria (testable, observable list)\n- scope (what's IN)\n- out_of_scope (what's OUT)\n- risks (each with mitigation)\n- test plan\n\nThe CLI persists this in the `specs` table; the vault renders to `_generated/specs/<slug>.md`.\n\n### 2. `audit-spec`\n\nBefore writing any code: harden the spec. Run `prjct audit-spec <id>` — it emits a dispatch prompt for THREE review subagents that you run IN PARALLEL (one tool-use block per reviewer in the SAME message):\n\n- **strategic** — scope sanity. Worth doing? Right size?\n- **architecture** — feasibility. Data flow, failure modes, dependencies.\n- **design** — UX/DX quality. Four dimensions rated 0–10.\n\nEach returns a verdict (pass | fail) + notes. You write each back via `prjct spec record-review`. When all three pass, the spec auto-promotes from `draft` → `reviewed`.\n\nIf any reviewer fails: revise the spec via `prjct spec update`, re-audit. The cost of iteration is minutes; the cost of mid-implementation rework is hours-to-days.\n\n### 3. `task --spec <id>`\n\nNow create the task. The `--spec` flag wires the task to its spec via `linked_spec_id`. Without it, `ship` later has nothing to gate against.\n\n```\nprjct task \"implement rate-limit middleware\" --spec <id>\n```\n\n### 4. implement\n\nNormal coding loop. Mid-flight workflows (`review`, `qa`, `investigate`) still apply. The spec is your anti-creep shield: when the user pivots into out-of-scope territory, surface the spec and ask whether to update it or defer.\n\n### 5. `ship` (with the spec gate)\n\n`prjct ship` reads the linked spec's `acceptance_criteria` and surfaces them as a checklist in the PR description. Walk each one — pass / fail / N/A. If any criterion is unmet → STOP and surface to the user.\n\nOverride path: `prjct ship --no-spec-gate` (use only when the user explicitly accepts).\n\n### 6. `remember learning`\n\nAfter ship, capture what the spec got right and wrong:\n\n```\nprjct remember learning \"spec missed the clock-skew edge case; future rate-limit specs should call out time-source\"\n```\n\nThe next spec is sharper. Compounding effect: the vault accumulates spec-shaped lessons.\n\n## When to bypass SDD\n\nNot every keystroke goes through six stations. Routine work skips `spec`:\n\n- single-file fix with known scope\n- doc tweak / typo\n- inbox capture / GTD dump\n- conversational Q&A\n- re-running a failing test\n- bug fix where root cause is already known\n\nRule of thumb: if the work touches >1 file, ships to users, or takes >30 minutes, default to `spec` first.\n\n## Anti-patterns\n\n- **Skipping straight to `task` because the user said \"let's build X\".** If they said it WITH stakes, the spec is what protects them from scope creep mid-implementation.\n- **Auditing AFTER implementing.** Pre-implementation review is the whole point. Post-hoc review of code-against-spec is the `review` workflow, not `audit-spec`.\n- **Treating the spec as immutable.** Specs evolve. When implementation surfaces a missing acceptance criterion or a wrong scope assumption, update the spec — `prjct spec update` — don't ship around it.\n- **Marking `acceptance_criteria` met without proof.** The criterion exists to be tested. If the test wasn't run, the criterion isn't met.\n","skills/code-review.md":"---\nname: Code Review\ndescription: Review code changes for quality, security, and best practices\nagent: general\ntags: [review, quality, security]\nversion: 1.0.0\n---\n\n# Code Review Skill\n\nReview the provided code changes with focus on:\n\n## Quality Checks\n- Code readability and clarity\n- Naming conventions\n- Function/method length\n- Code duplication\n- Error handling\n\n## Security Checks\n- Input validation\n- SQL injection risks\n- XSS vulnerabilities\n- Sensitive data exposure\n- Authentication/authorization issues\n\n## Best Practices\n- SOLID principles\n- DRY (Don't Repeat Yourself)\n- Single responsibility\n- Proper typing (TypeScript)\n- Documentation where needed\n\n## Output Format\n\nProvide feedback in this structure:\n\n### Summary\nBrief overview of the changes\n\n### Issues Found\n- 🔴 **Critical**: Must fix before merge\n- 🟡 **Warning**: Should fix, but not blocking\n- 🔵 **Suggestion**: Nice to have improvements\n\n### Recommendations\nSpecific actionable items to improve the code\n","skills/debug.md":"---\nname: Debug\ndescription: Systematic debugging to find and fix issues\nagent: general\ntags: [debug, fix, troubleshoot]\nversion: 1.0.0\n---\n\n# Debug Skill\n\nSystematically debug the reported issue.\n\n## Process\n\n### Step 1: Understand the Problem\n- What is the expected behavior?\n- What is the actual behavior?\n- When did it start happening?\n- Can it be reproduced consistently?\n\n### Step 2: Gather Information\n- Read relevant error messages\n- Check logs\n- Review recent changes\n- Identify affected code paths\n\n### Step 3: Form Hypothesis\n- What could cause this behavior?\n- List possible causes in order of likelihood\n- Identify the most likely root cause\n\n### Step 4: Test Hypothesis\n- Add logging if needed\n- Isolate the problematic code\n- Verify the root cause\n\n### Step 5: Fix\n- Implement the minimal fix\n- Ensure no side effects\n- Add tests if applicable\n\n### Step 6: Verify\n- Confirm the issue is resolved\n- Check for regressions\n- Document the fix\n\n## Output Format\n\n```\n## Issue\n[Description of the problem]\n\n## Root Cause\n[What was causing the issue]\n\n## Fix\n[What was changed to fix it]\n\n## Prevention\n[How to prevent similar issues]\n```\n","skills/prjct/SKILL.md":"---\ndescription: \"Project memory + spec-driven runtime: recall and capture decisions/learnings/gotchas, run registered workflows, frame and ship work. Recognize intent in any language and run the verb yourself — never make the user type commands. Triage every turn: most work is SIMPLE → go direct (`prjct task` → ship); reserve the spec pipeline for genuinely complex or high-stakes work. Over-routing simple work through spec + reviewers is the main failure mode.\"\nallowed-tools: [\"Bash\", \"Read\", \"Write\", \"Edit\", \"Glob\", \"Grep\", \"Task\"]\nuser-invocable: true\n---\n\n# prjct\n\n## Use when\n\nYou want to:\n- recall prior project decisions, learnings, or shipped features\n- capture a thought, todo, or insight without a commitment\n- run a workflow the project already registered\n- understand your role and the MCPs available in this project\n\n## What's here\n\nThis is the baseline `prjct` skill installed by the CLI on every invocation.\n\nNo project has been initialized in this cwd yet (`.prjct/` missing). When the user\nshows intent (start a task, capture a thought, ship), suggest `prjct init` ONCE\nin one line, then run the verb. Don't gate routine captures on init.\n\nAfter `prjct sync` runs in an initialized project, this file is regenerated with\nproject-specific context (name, stack, velocity, active task, recent shipped,\nknown gotchas). The verb intent map below applies in both states.\n\n\n\n### Agent contract\n\n- prjct remembers project state and shows the path; it does not own the execution.\n- Treat prjct output as durable signals: active task, memories, workflows, specs, risks, and recent learnings.\n- Claude, GPT, and other agents decide the concrete HOW with their own native tools and judgment. Persist meaningful outcomes back through `prjct remember`, `prjct capture`, `prjct task`, and `prjct ship` so the next interaction starts smarter.\n\n### Primitives\n\n- `prjct spec \"<title>\"` — frame work BEFORE coding (Goal/Acceptance/Scope/Risks)\n- `prjct audit-spec <id>` — dispatch parallel strategic/architecture/design review\n- `prjct capture \"<anything>\"` — inbox dump (zero ceremony)\n- `prjct remember <type> \"<content>\" [--tags]` — typed memory entry\n- `prjct search \"<query>\"` — recall project memory (BM25 + semantic + recall); the verb to reach for when you need prior knowledge\n- `prjct context memory [topic]` — same blended retrieval as `search`, plus `learnings`/`wiki` subtools\n- `prjct guard <file>` — preventive memory recorded against a file, before you edit it\n- `prjct workflow list` / `prjct workflow run <name>` — registered workflows\n- `prjct seed list` — active packs (memory types + workflow slots)\n\nBase memory types: `fact · decision · learning · gotcha · pattern · anti-pattern · shipped · inbox · todo · idea · insight · question · source · person · spec`. Any lowercase string works (e.g. `recipe`, `okr`, `stakeholder`).\n\n### Data paths\n\n- `.prjct/wiki/_generated/` — agent-crawlable markdown (regenerated on ship/remember)\n- `.prjct/wiki/captured/` — drop notes with frontmatter, run `prjct context wiki sync` to ingest\n- `.prjct/prjct.config.json` — persona + active packs\n\n## Act: default DIRECT — escalation is the rare exception\n\n**The first move on almost every turn is to just do the work DIRECTLY.** A fix, a one-file change, a capture, a question, anything the user frames as quick/direct work (in any language): `prjct task` → implement it yourself → `ship`. **NO spec, NO audit-spec, NO subagents, NO fan-out.** This is the common case and the safe default — when unsure, this is what you pick. Ask at most ONE line; never escalate just to be safe.\n\nEscalate to the spec pipeline ONLY when the test is unambiguous: multi-file + new behavior AND ambiguous scope AND real/irreversible stakes (or the user explicitly frames goals/acceptance/risks). Then, and only then: `spec ─→ audit-spec ─→ task --spec <id> ─→ implement ─→ ship ─→ remember learning`. Forcing simple work through this pipeline is the #1 perf-killer — it burns tokens for zero protection.\n\n**If you ever dispatch a subagent (Agent tool), set `model:` explicitly — never let it inherit yours.** Only the agent that WRITES code gets `model: \"opus\"`. Reviewing/judging (`review`, `security`, `investigate`, audit-spec reviewers) → `model: \"sonnet\"`. Pure routing/orchestration → `model: \"haiku\"`. A non-implementer left on the parent's max model is exactly why a task crawls and burns tokens. Not optional.\n\nHeavy quality workflows (`review`, `qa`, `security`, `investigate`, `audit`, `audit-spec`), the parallel-implementer fan-out rules, decision-briefs, the `prjct prefs` protocol, the spec stations and builder ethos all live in `workflows.md` — **read it on demand when (and only when) you actually run one.** Do not preload it; do not reach for the menu on simple work.\n\n**CONTENT LANGUAGE — author every stored memory in ENGLISH**, no matter what language the user speaks (Spanish, Japanese, German — any). When you `capture`/`remember`, translate the intent into a clean English entry; the persisted knowledge is always English. LLMs comprehend English better and embeddings stay high-quality in one canonical language — mixed-language content produces cross-language retrieval noise and extra token cost on every later recall.\n\n## Verb intent map — you run the verb, the user never types it\n\nOn every turn ask: \"what is the user trying to accomplish?\" and match to a verb below. The user may phrase intent in ANY language — the verbs are language-agnostic. These are *signals*, not phrase templates. The **Tier** column governs whether you auto-run or confirm first (see Routing).\n\n| Intent / signal | Verb | Tier |\n|---|---|---|\n| starting a unit of work — \"do X for me\", a fix, a change, picking up a queue item (THE DEFAULT, most turns) | `prjct task \"<desc>\"` (add `--spec <id>` if a spec exists) | 2 |\n| framing genuinely complex work WITH goals/stakes/acceptance criteria (the exception) | `prjct spec \"<title>\"` | 2 |\n| harden / pressure-test an existing spec before any code | `prjct audit-spec <id>` | 2 |\n| need prior project knowledge — \"what did we decide about X\", \"find what we had on Y\", recall before re-reading source | `prjct search \"<query>\"` | 1 |\n| an interesting thought to keep, no commitment yet | `prjct capture \"<text>\" --tags topic:<x>` | 1 |\n| a non-trivial choice just got resolved (+ its why) | `prjct remember decision \"<choice + one-line why>\"` | 1 |\n| an insight / \"aha\" / new mental model | `prjct remember learning \"<insight>\"` | 1 |\n| a non-obvious trap surfaced (+ how to avoid) | `prjct remember gotcha \"<trap + how to avoid>\"` | 1 |\n| categorize the active task (type/domain/priority) | `prjct tag type:bug domain:auth …` | 1 |\n| about to edit a file — check for known traps | `prjct guard <file>` | 1 |\n| work is done, push it | `prjct ship` | 2 |\n| lifecycle change on the active task | `prjct status done\\|paused\\|active` | 2 |\n| \"is the codebase healthy?\" | `prjct health --md` | 1 |\n| \"what did we accomplish?\" | `prjct retro 7d --md` | 1 |\n| pause / resume the working context | `prjct context-save` / `prjct context-restore --md` | 1 |\n\nDisambiguators: the \"why\" separates a `decision` from an `inbox` dump — if you can't state it in one line, capture as inbox. A bare \"fix X\" is `task`, never `spec`. `audit-spec` requires an existing spec. For `ship`, if the active task has a `linked_spec_id`, ship surfaces the spec's acceptance_criteria as a PR checklist — STOP on any unmet criterion (override: `prjct ship --no-spec-gate`).\n\n## Routing — Tier governs auto-run vs confirm (by blast radius)\n\n- **Tier 1 — auto-execute, one-line confirm.** `search`, `capture`, `tag`, `remember`, `guard`, `context-save`, `health`, `retro`, `prefs check/list`. Additive/read-only: run IMMEDIATELY, emit one line (`✓ saved as decision: …`). Do not ask \"want me to save that?\" — just save it; the user corrects afterward. Pausing for permission on routine captures is what makes prjct useless.\n- **Tier 2 — suggest-and-confirm, ONE line.** `task`, `spec`, `audit-spec`, `ship`, `status done|paused`, `prefs set`. State intent + blast radius in one line and wait for a green light (an affirmative in any language, or silence). Never run `ship` without surfacing the plan first — it is un-doable without a force-push.\n- **Tier 3 — decision-brief** (hard forks costing >5 min to undo): `prjct prefs check <id>` first, then the decision-brief format. Both detailed in `workflows.md`.\n\n## Gotchas\n\n- Memory recall is best-effort — an empty result means no match, not \"nothing exists\".\n- Tags are freeform strings — reuse existing vocabulary before inventing new keys.\n- Secret-like content is refused by `remember` and `capture` unless `--force`.\n- Bare `prjct \"<text>\"` routes to `capture` (inbox), not `task`. Use `prjct task` explicitly for work that needs a branch/worktree.\n- Hooks in `~/.claude/settings.json` already inject persona + topical memory on SessionStart / UserPromptSubmit — you rarely need to call prjct by hand at session start.\n- **Worktree hygiene.** If you are working inside a git worktree, clean it up so they don't pile up on the local machine: AFTER the branch's PR is *merged* (not at session end — an open PR keeps its worktree), `git worktree remove <path>` + `git worktree prune`, run from the MAIN worktree (git won't remove the worktree you're standing in). NEVER remove a worktree with uncommitted or unpushed work, and never `--force` over a dirty tree (it silently discards work).\n\n","skills/refactor.md":"---\nname: Refactor\ndescription: Refactor code for better structure, readability, and maintainability\nagent: general\ntags: [refactor, cleanup, improvement]\nversion: 1.0.0\n---\n\n# Refactor Skill\n\nRefactor the specified code with these goals:\n\n## Objectives\n1. **Improve Readability** - Clear naming, logical structure\n2. **Reduce Complexity** - Simplify nested logic, extract functions\n3. **Enhance Maintainability** - Make future changes easier\n4. **Preserve Behavior** - No functional changes unless requested\n\n## Approach\n\n### Step 1: Analyze Current Code\n- Identify pain points\n- Note code smells\n- Understand dependencies\n\n### Step 2: Plan Changes\n- List specific refactoring operations\n- Prioritize by impact\n- Consider breaking changes\n\n### Step 3: Execute\n- Make incremental changes\n- Test after each change\n- Document decisions\n\n## Common Refactorings\n- Extract function/method\n- Rename for clarity\n- Remove duplication\n- Simplify conditionals\n- Replace magic numbers with constants\n- Add type annotations\n\n## Output\n- Modified code\n- Brief explanation of changes\n- Any trade-offs made\n","spec-reviewer-rubrics/architecture.md":"# Architecture reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for engineering feasibility. You receive the spec body verbatim. Apply the questions below; return a structured verdict.\n\n## Questions to ask\n\n1. **Can this be built?** With the team's stack and skill set, in the implied timeframe. If \"no\" or \"yes but only by replacing the database\", fail.\n2. **Is the data flow coherent?** Trace input → state → output. Where does data live? Who writes it? Who reads it? Failure modes at each hop.\n3. **Is the state machine implicit or explicit?** Explicit > implicit. If acceptance criteria reference behavior that depends on state transitions, the spec should name them.\n4. **What edge cases / failure modes are missing?** Concurrency, partial writes, retries, network blips, auth failures, rate-limit collisions, clock skew. Name the top 1–2 that the spec doesn't address.\n5. **What dependencies does this introduce?** New runtime dep? New infra (Redis, queue, cron)? Document it. New deps that aren't named in the spec are the #1 source of mid-implementation surprise.\n6. **Test plan adequate?** A test plan that says \"tests added\" is not a plan. Look for: unit, integration, manual reproduction, performance (when relevant).\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: 2–4 sentences + (when applicable) a short ASCII data flow / state diagram.\n       If pass, name the most load-bearing architectural choice.\n       If fail, name the SINGLE biggest gap and how to close it.\n```\n\n## Examples\n\n**Pass with diagram:**\n\n```\nverdict: pass\nnotes: Token-bucket per IP with 5-minute Redis TTL is the right call — survives restarts, no GC pressure, easy to extend to user-id keys later. The spec correctly limits scope to /auth (no /api yet). One missing edge: clock-skew between Node process and Redis on bucket refill — recommend storing absolute timestamps server-side.\n\n   request → middleware → Redis GETSET (token, ts)\n                            ├── allowed → next()\n                            └── refused → 429 + Retry-After\n```\n\n**Fail:**\n\n```\nverdict: fail\nnotes: Spec references \"real-time updates\" in acceptance_criteria but is silent on transport (WebSocket? SSE? polling?). Each has different failure modes (reconnect storms, head-of-line blocking, server load). Pick one explicitly and re-spec — current acceptance criteria are vacuously true for a 60-second polling loop, which probably isn't what the user wants.\n```\n\n## Anti-patterns to refuse\n\n- Architectural cosplay: \"consider using DDD/hexagonal/CQRS\" without showing why this spec demands it.\n- Failing because \"the spec doesn't say which framework\" when framework is obvious from the project's stack (skill body's project context tells you).\n- Skipping the data flow trace — the most useful thing this rubric produces.\n","spec-reviewer-rubrics/design.md":"# Design reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for design quality (UX for user-facing surfaces, DX for developer-facing surfaces — same rubric, different surface).\n\n## Questions to ask\n\nRate each dimension 0–10 against the spec's described surface (UI, API, CLI, library):\n\n1. **Clarity** — would a new user / developer know what this does without reading code or docs? 0 = inscrutable; 10 = self-documenting.\n2. **Ergonomics** — is the common case fast and the rare case possible? 0 = forces the rare case into every flow; 10 = invisible until needed.\n3. **Consistency** — does it match the surrounding system's conventions? 0 = a foreign body; 10 = indistinguishable from neighboring features.\n4. **Accessibility** — for UI: keyboard / screen-reader / contrast / motion. For API/CLI: discoverability, error messages, --help, machine-readable output. 0 = unusable for entire categories of users; 10 = enables everyone.\n\n## Verdict rule\n\n- All four dimensions ≥ 6 → `pass`.\n- Any dimension < 6 → `fail`.\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: clarity=N ergonomics=N consistency=N accessibility=N\n       Lowest-scoring dimension first, with the SINGLE concrete change that would raise it.\n```\n\n## Examples\n\n**Pass:** \"clarity=8 ergonomics=7 consistency=9 accessibility=6. Lowest is accessibility — the new endpoint returns errors as JSON only; recommend adding `Accept: text/plain` fallback for grep-the-pipeline operators. Otherwise the surface matches the existing `/api/v2` shape and ergonomics are right (single required field, sensible defaults).\"\n\n**Fail:** \"clarity=4 ergonomics=6 consistency=7 accessibility=7. Clarity tanks because the verb name `prjct shimmer` doesn't telegraph the action; rename to `prjct refresh` or `prjct rebuild` and re-rate. Other dimensions are healthy.\"\n\n## Anti-patterns to refuse\n\n- Vague \"looks good\" — every dimension needs a number.\n- Ignoring accessibility for \"internal tools\" — internal users include the colorblind and the blind.\n- Failing on aesthetic taste alone (color, typography). Design rubric is about USE, not opinion.\n- Over-indexing on novelty. Surfaces that surprise users score LOW on consistency, not high.\n","spec-reviewer-rubrics/strategic.md":"# Strategic reviewer rubric — `audit-spec`\n\nYou are reviewing a `prjct` spec for strategic soundness. You receive the spec body verbatim. Apply the questions below; return a single structured verdict.\n\n## Questions to ask\n\n1. **Is the goal real?** Does this solve a problem the user (or org) actually has? Or is it a tools-team-flavored solution looking for a problem?\n2. **Is the goal worth the cost?** Crude estimate of build cost vs. impact. If goal is small but cost is large, fail.\n3. **Is `out_of_scope` coherent with `goal`?** Goal that says \"fix onboarding\" with `out_of_scope: [\"welcome email\", \"first-login flow\"]` — what's left? Fail if scope evaporates the goal.\n4. **Is the spec OVER-scoped?** Trying to ship a quarter's work in one PR. Boil-the-lake principle says completeness is cheap when it costs minutes — fail when it costs months.\n5. **Is the spec UNDER-scoped?** Acceptance criteria so narrow that shipping doesn't move the needle. Fail when meeting all criteria still leaves the user's problem unsolved.\n6. **Are stakes honest?** \"Users will be frustrated\" is too vague. \"Auth fails for 3% of sessions during peak load\" is testable.\n\n## Output format\n\n```\nverdict: pass | fail\nnotes: 2–4 sentences. If pass, name the strongest framing element. If fail, name the SINGLE\n       biggest gap and how to close it.\n```\n\n## Examples\n\n**Pass:** \"Goal is concrete (sub-200ms p95 on dashboard) and the stakes are measurable (lost engagement on slow widgets). Scope and out_of_scope draw a clean line. The strongest element is the explicit 'no caching layer in this PR' — that's the right anti-creep.\"\n\n**Fail:** \"Goal says 'improve auth UX' but acceptance_criteria all measure backend latency. Either rewrite the goal (this is a perf spec, not UX) or rewrite the criteria (add a usability metric). Currently the spec would pass review on a perf change that didn't move UX at all.\"\n\n## Anti-patterns to refuse\n\n- Praising the spec without naming a strength (`pass: looks good!` — useless).\n- Failing without proposing a fix (the next iteration of the spec needs a path forward).\n- Auto-failing because the spec is \"ambitious\" — strategic review measures soundness, not size.\n","spec-template.md":"# Spec template — `prjct spec`\n\nA spec frames a piece of work BEFORE implementation. Cheap to write, cheap to revise; un-doing implementation isn't.\n\nThe fields below match `core/types/spec.ts`. Validation is enforced by Zod at write time.\n\n---\n\n## Title (one line)\n\nWhat you'd say to a coworker walking by your desk.\n\n## Goal (1–3 sentences)\n\nWhat success looks like. Concrete. Observable.\n\n## ELI10 (2–4 sentences)\n\nPlain English a 16-year-old could follow. Forces you to articulate why this matters without jargon.\n\n## Stakes if we ship the wrong thing (1 sentence)\n\nWhat breaks. Who notices. How fast.\n\n## Acceptance criteria (testable, observable list)\n\nEach line is a sentence ending in a verifiable claim:\n\n- the new endpoint returns 429 after the 11th request in a minute from the same IP\n- the dashboard widget renders within 200ms p95 on a synthetic 4G profile\n- `prjct spec audit <id>` blocks if any reviewer returns `fail`\n\nAnti-patterns:\n\n- \"the system should be fast\" — what threshold, measured how?\n- \"users will love it\" — not testable\n- \"follow industry best practices\" — what specifically?\n\n## Scope (what's IN)\n\nThe pieces this spec commits to. Be specific about file paths, surfaces, modules.\n\n## Out of scope (what's OUT)\n\nThe pieces this spec explicitly DOES NOT cover. This is your anti-creep shield mid-implementation.\n\n## Risks\n\nEach risk has a mitigation. A risk without a mitigation is just a complaint.\n\n- **risk:** legacy endpoints rely on the same rate-limit middleware → **mitigation:** scope key separates `/auth` from `/api`\n- **risk:** Redis dependency raises ops cost → **mitigation:** start with in-memory token bucket; swap to Redis only above 5 RPS\n\n## Test plan\n\nHow you'll prove the acceptance criteria. Includes the unhappy path.\n\n- unit tests for the token bucket math\n- integration test: 11 requests, 11th returns 429\n- load test: 100 RPS sustained for 60s, no memory growth\n- manual: trigger via `curl` and inspect response headers\n\n## Notes (optional)\n\nThings that don't fit anywhere else but matter for context.\n\n---\n\n## Lifecycle\n\n```\ndraft  →  reviewed  →  in_progress  →  shipped\n                                    →  archived\n```\n\n- `draft` — created, not yet audited.\n- `reviewed` — `prjct audit-spec` returned pass on all three reviewers.\n- `in_progress` — at least one task with `linked_spec_id` exists.\n- `shipped` — code merged, criteria met (or override accepted).\n- `archived` — superseded or abandoned.\n\n## Verb cheatsheet\n\n```\nprjct spec \"<title>\"                       # draft — NO `draft` subverb, pass title directly\nprjct spec list [--status <s>]\nprjct spec show <id>\nprjct spec update <id> --json '{...}'      # PATCH content (shallow merge)\nprjct spec audit <id>                      # emit subagent dispatch\nprjct spec record-review <id> --reviewer <name> --verdict <pass|fail> --notes \"...\"\nprjct spec link-task <id> --task-id <task>\nprjct spec ship <id> [--pr <n>]\nprjct spec set-status <id> --status archived\nprjct spec inventory [--md|--json]         # coverage map per module\n```\n\n> **No `draft` subverb.** `prjct spec \"<title>\"` already creates a draft. The CLI tolerates `prjct spec draft|new|create \"<title>\"` as friendly aliases (the leading word is stripped) so `prjct spec draft \"rate limiting\"` and `prjct spec \"rate limiting\"` produce the same spec — but the canonical form has no leading verb.\n","tools/bash.txt":"Execute shell commands in a persistent bash session.\n\nUse this tool for terminal operations like git, npm, docker, build commands, and system utilities. NOT for file operations (use Read, Write, Edit instead).\n\nCapabilities:\n- Run any shell command\n- Persistent session (environment persists between calls)\n- Support for background execution\n- Configurable timeout (up to 10 minutes)\n\nBest practices:\n- Quote paths with spaces using double quotes\n- Use absolute paths to avoid cd\n- Chain dependent commands with &&\n- Run independent commands in parallel (multiple tool calls)\n- Never use for file reading (use Read tool)\n- Never use echo/printf to communicate (output text directly)\n\nGit operations:\n- Never update git config\n- Never use destructive commands without explicit request\n- Always use HEREDOC for commit messages\n","tools/edit.txt":"Edit files using exact string replacement.\n\nUse this tool to make precise changes to existing files. Requires reading the file first to ensure accurate matching.\n\nCapabilities:\n- Replace exact string matches in files\n- Support for replace_all to change all occurrences\n- Preserves file formatting and indentation\n\nRequirements:\n- Must read the file first (tool will error otherwise)\n- old_string must be unique in the file (or use replace_all)\n- Preserve exact indentation from the original\n\nBest practices:\n- Include enough context to make old_string unique\n- Use replace_all for renaming variables/functions\n- Never include line numbers in old_string or new_string\n","tools/glob.txt":"Find files by pattern matching.\n\nUse this tool to locate files using glob patterns. Fast and efficient for any codebase size.\n\nCapabilities:\n- Match files using glob patterns (e.g., \"**/*.ts\", \"src/**/*.tsx\")\n- Returns paths sorted by modification time\n- Works with any codebase size\n\nPattern examples:\n- \"**/*.ts\" - all TypeScript files\n- \"src/**/*.tsx\" - React components in src\n- \"**/test*.ts\" - test files anywhere\n- \"core/**/*\" - all files in core directory\n\nBest practices:\n- Use specific patterns to narrow results\n- Prefer glob over bash find command\n- Run multiple patterns in parallel if needed\n","tools/grep.txt":"Search file contents using regex patterns.\n\nUse this tool to search for code patterns, function definitions, imports, and text across the codebase. Built on ripgrep for speed.\n\nCapabilities:\n- Full regex syntax support\n- Filter by file type or glob pattern\n- Multiple output modes: files_with_matches, content, count\n- Context lines before/after matches (-A, -B, -C)\n- Multiline matching support\n\nOutput modes:\n- files_with_matches (default): just file paths\n- content: matching lines with context\n- count: match counts per file\n\nBest practices:\n- Use specific patterns to reduce noise\n- Filter by file type when possible (type: \"ts\")\n- Use content mode with context for understanding matches\n- Never use bash grep/rg directly (use this tool)\n","tools/read.txt":"Read files from the filesystem.\n\nUse this tool to read file contents before making edits. Always read a file before attempting to modify it to understand the current state and structure.\n\nCapabilities:\n- Read any text file by absolute path\n- Supports line offset and limit for large files\n- Returns content with line numbers for easy reference\n- Can read images, PDFs, and Jupyter notebooks\n\nBest practices:\n- Always read before editing\n- Use offset/limit for files > 2000 lines\n- Read multiple related files in parallel when exploring\n","tools/task.txt":"Launch specialized agents for complex tasks.\n\nUse this tool to delegate multi-step tasks to autonomous agents. Each agent type has specific capabilities and tools.\n\nAgent types:\n- Explore: Fast codebase exploration, file search, pattern finding\n- Plan: Software architecture, implementation planning\n- general-purpose: Research, code search, multi-step tasks\n\nWhen to use:\n- Complex multi-step tasks\n- Open-ended exploration\n- When multiple search rounds may be needed\n- Tasks matching agent descriptions\n\nBest practices:\n- Provide clear, detailed prompts\n- Launch multiple agents in parallel when independent\n- Prefer direct Glob/Grep for simple exploration. Subagents inherit all MCP tool schemas from the parent session and can start heavy — only delegate to Explore when the search is genuinely open-ended and benefits from parallel rounds\n- Use Plan for implementation design\n","tools/webfetch.txt":"Fetch and analyze web content.\n\nUse this tool to retrieve content from URLs and process it with AI. Useful for documentation, API references, and external resources.\n\nCapabilities:\n- Fetch any URL content\n- Automatic HTML to markdown conversion\n- AI-powered content extraction based on prompt\n- 15-minute cache for repeated requests\n- Automatic HTTP to HTTPS upgrade\n\nBest practices:\n- Provide specific prompts for extraction\n- Handle redirects by following the provided URL\n- Use for documentation and reference lookup\n- Results may be summarized for large content\n","tools/websearch.txt":"Search the web for current information.\n\nUse this tool to find up-to-date information beyond the knowledge cutoff. Returns search results with links.\n\nCapabilities:\n- Real-time web search\n- Domain filtering (allow/block specific sites)\n- Returns formatted results with URLs\n\nRequirements:\n- MUST include Sources section with URLs after answering\n- Use current year in queries for recent info\n\nBest practices:\n- Be specific in search queries\n- Include year for time-sensitive searches\n- Always cite sources in response\n- Filter domains when targeting specific sites\n","tools/write.txt":"Write or create files on the filesystem.\n\nUse this tool to create new files or completely overwrite existing ones. For modifications to existing files, prefer the Edit tool instead.\n\nCapabilities:\n- Create new files with specified content\n- Overwrite existing files completely\n- Create parent directories automatically\n\nRequirements:\n- Must read existing file first before overwriting\n- Use absolute paths only\n\nBest practices:\n- Prefer Edit for modifications to existing files\n- Only create new files when truly necessary\n- Never create documentation files unless explicitly requested\n","windsurf/router.md":"---\ntrigger: always_on\ndescription: \"prjct - Context layer for AI coding agents\"\n---\n\n# prjct\n\nCore: /sync, /task, /done, /ship, /pause, /resume, /next, /bug, /workflow\nOther: run `prjct <command> --md` and follow CLI output\n","windsurf/workflows/ship.md":"# /ship - Ship feature\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct ship {{args}} --md`\nFollow CLI output.\n","windsurf/workflows/task.md":"# /task - Start a task\n\n**ARGUMENTS**: {{args}}\n\nRun: `prjct task {{args}} --md`\nFollow CLI output.\n"}