prjct-cli 1.47.0 → 1.47.4

package/templates/commands/serve.md

@@ -1,11 +0,0 @@
----
-allowed-tools: [Bash]
----
-
-# p. serve $ARGUMENTS
-
-```bash
-prjct serve ${ARGUMENTS || "3478"} --md
-```
-
-Follow the instructions in the CLI output.

package/templates/commands/sessions.md

@@ -1,13 +0,0 @@
----
-allowed-tools: [Bash, Read, AskUserQuestion]
----
-
-# p. sessions
-
-## Step 1: Show recent sessions
-```bash
-prjct sessions --md
-```
-
-## Step 2: Offer to resume
-If sessions exist, ask the user which one to resume. Then switch to that project directory and run `prjct resume --md`.

package/templates/commands/setup.md

@@ -1,11 +0,0 @@
----
-allowed-tools: [Bash]
----
-
-# p. setup $ARGUMENTS
-
-```bash
-prjct setup $ARGUMENTS --md
-```
-
-Follow the instructions in the CLI output.

package/templates/commands/ship.md

@@ -1,46 +0,0 @@
----
-allowed-tools: [Bash, Read, AskUserQuestion]
----
-
-# p. ship $ARGUMENTS
-
-## Step 0: Complete task (implicit)
-The ship workflow automatically completes the current task before shipping.
-This means `p. done` is implicit — you do NOT need to run it separately before shipping.
-
-## Pre-flight (BLOCKING)
-```bash
-git branch --show-current
-```
-IF on main/master: STOP. Create a feature branch first.
-
-```bash
-gh auth status
-```
-IF not authenticated: STOP. Run `gh auth login`.
-
-## Step 1: Quality checks
-```bash
-prjct ship "$ARGUMENTS" --md
-```
-
-## Step 2: Review changes
-Show the user what will be committed, versioned, and PR'd.
-
-## Step 3: Get approval (BLOCKING)
-ASK: "Ready to ship?" Yes / No / Show diff
-
-## Step 4: Ship
-- Commit with prjct footer: `Generated with [p/](https://www.prjct.app/)`
-- Push and create PR
-- Update issue tracker if linked
-- Every commit MUST include the prjct footer. No exceptions.
-
-
-## Presentation
-Format the ship flow as:
-
-1. `**Shipping**: {feature name}`
-2. Quality checks as a table: | Check | Status |
-3. Show the PR summary
-4. Ask for approval with clear formatting

package/templates/commands/skill.md

@@ -1,13 +0,0 @@
----
-allowed-tools: [Bash, Read, Glob]
----
-
-# p. skill $ARGUMENTS
-
-Supports: `list` (default), `search <query>`, `show <id>`, `invoke <id>`, `add <source>`, `remove <name>`, `init <name>`, `check`.
-
-```bash
-prjct skill $ARGUMENTS --md
-```
-
-Follow the instructions in the CLI output.

package/templates/commands/spec.md

@@ -1,20 +0,0 @@
----
-allowed-tools: [Bash, Read, Write, AskUserQuestion, Task]
----
-
-# p. spec $ARGUMENTS
-
-## Step 1: Validate
-If $ARGUMENTS is empty, ASK the user for a feature name.
-
-## Step 2: Create spec via CLI
-```bash
-prjct spec "$ARGUMENTS" --md
-```
-
-## Step 3: Follow CLI instructions
-The CLI will guide through requirements, design decisions, and task breakdown.
-Search the codebase for relevant patterns.
-
-## Step 4: Get approval
-Show the spec to the user and get explicit approval before adding tasks to queue.

package/templates/commands/status.md

@@ -1,11 +0,0 @@
----
-allowed-tools: [Bash]
----
-
-# p. status $ARGUMENTS
-
-```bash
-prjct status $ARGUMENTS --md
-```
-
-Follow the instructions in the CLI output.

package/templates/commands/sync.md

@@ -1,23 +0,0 @@
----
-allowed-tools: [Bash, AskUserQuestion]
----
-
-# p. sync $ARGUMENTS
-
-## Step 1: Run CLI sync
-```bash
-prjct sync $ARGUMENTS --md
-```
-If CLI output is JSON with `options`, present the options to the user and execute the chosen command.
-
-Follow ALL instructions in the CLI output (including LLM Analysis if present).
-
-## Step 2: Present results
-After all steps complete, present the output clearly:
-- Use the tables and sections as-is from CLI markdown
-- If LLM analysis was performed, summarize key findings:
-  - Architecture style and top insights
-  - Critical anti-patterns (high severity)
-  - Top tech debt items
-  - Key conventions discovered
-- Add a brief interpretation of what changed and why

package/templates/commands/task.md

@@ -1,69 +0,0 @@
----
-allowed-tools: [Bash, Read, Write, Edit, Glob, Grep, Task, AskUserQuestion]
----
-
-# p. task $ARGUMENTS
-
-## Step 1: Validate
-If $ARGUMENTS is empty, ASK the user what task to start.
-
-## Step 2: Get task context
-```bash
-prjct task "$ARGUMENTS" --md
-```
-If CLI output is JSON with `options`, present the options to the user and execute the chosen command.
-
-## Step 3: Understand before acting (USE YOUR INTELLIGENCE)
-- Context7 is mandatory: for framework/library APIs, consult Context7 docs before implementation/refactor
-- Read the relevant files from the CLI output
-- If the task is ambiguous, ASK the user to clarify
-- Explore beyond suggested files if needed
-
-## Step 4: Pattern commitment (MANDATORY — do not skip)
-
-Before writing ANY code, complete this checklist:
-
-1. Read **Locked Decisions (NON-NEGOTIABLE)** from the Context Contract output. These are hard constraints — do not deviate.
-2. Read **Pattern Briefing** — each pattern lists a VIOLATION line showing what NOT to do.
-3. Read **Task Patterns (MUST follow)** — for each one, state HOW you will apply it to this specific task.
-
-Output a commitment table:
-
-| Pattern | Implementation plan for this task |
-|---------|----------------------------------|
-| (name from Task Patterns) | (concrete: which files, which types, which components) |
-
-If no patterns were provided in the CLI output (e.g., project not yet synced), skip this step.
-If the user corrects a commitment, update the table before proceeding.
-
-## Step 5: Plan the approach
-- For non-trivial changes, propose 2-3 approaches
-- Consider existing patterns in the codebase
-- If CLI output mentions domain agents, read them for project patterns
-- Summarize anti-patterns from the CLI output before editing any file
-
-## Step 6: Execute
-- Create feature branch if on main: `git checkout -b {type}/{slug}`
-- Work through subtasks in order
-- When done with a subtask: `prjct done --md`
-- Every git commit MUST include footer: `Generated with [p/](https://www.prjct.app/)`
-- If a change may violate a high-severity anti-pattern, ask for confirmation and propose a safer alternative first
-
-## Step 7: Ship (MANDATORY)
-When all work is complete, you MUST execute the ship workflow:
-ASK: "Work complete. Ready to ship?" Ship now / Continue working / Pause
-- If Ship now: execute `p. ship` workflow (load and follow `~/.claude/commands/p/ship.md`)
-- If Continue working: stay in Step 6
-- If Pause: execute `p. pause`
-
-NEVER end a task without asking about shipping. This is non-negotiable.
-
-## Presentation
-When showing task context to the user, format your response as:
-
-1. Start with a brief status line: `**Task started**: {description}`
-2. Show the subtask table from CLI output
-3. List 2-3 key files you'll work on with `code formatting` for paths
-4. End with your approach (concise, 2-3 bullets)
-
-Keep responses scannable. Use tables for structured data. Use `code formatting` for file paths and commands.

package/templates/commands/test.md

@@ -1,22 +0,0 @@
----
-allowed-tools: [Bash, Read]
----
-
-# p. test $ARGUMENTS
-
-## Step 1: Run tests
-```bash
-prjct test $ARGUMENTS --md
-```
-
-If the CLI doesn't handle testing directly, detect and run:
-- Node: `npm test` or `bun test`
-- Python: `pytest`
-- Rust: `cargo test`
-- Go: `go test ./...`
-
-## Step 2: Report results
-Show pass/fail counts. If tests fail, show the relevant output.
-
-## Fix mode (`p. test fix`)
-Update test snapshots and re-run to verify.

package/templates/commands/update.md

@@ -1,11 +0,0 @@
----
-allowed-tools: [Bash, Read, Write, Glob]
----
-
-# p. update
-
-```bash
-prjct update --md
-```
-
-Follow the instructions in the CLI output.

package/templates/commands/verify.md

@@ -1,11 +0,0 @@
----
-allowed-tools: [Bash]
----
-
-# p. verify
-
-```bash
-prjct verify --md
-```
-
-Follow the instructions in the CLI output.

package/templates/commands/workflow.md

@@ -1,69 +0,0 @@
----
-allowed-tools: [Bash, AskUserQuestion]
----
-
-# p. workflow $ARGUMENTS
-
-## Step 1: Parse intent
-
-If $ARGUMENTS is empty, show current rules:
-```bash
-prjct workflow --md
-```
-
-**If $ARGUMENTS contains natural language, DO NOT pass it raw to the CLI.**
-The CLI only accepts structured args — you must parse the intent yourself first.
-
-Parse:
-- **Action**: add / remove / list / create / delete / reset
-- **Command**: the shell command to run (infer from description)
-- **Position**: `before` or `after` (from words like "after", "después de", "before", "antes de")
-- **Workflow**: `task` / `done` / `ship` / `sync` (infer from context)
-
-**Inference examples**:
-| Natural language | → | Structured |
-|---|---|---|
-| "después del merge revisa npm" | → | `add "npm view prjct-cli version" after ship` |
-| "after ship check npm version" | → | `add "npm view prjct-cli version" after ship` |
-| "before task run tests" | → | `add "npm test" before task` |
-| "check lint before ship" | → | `add "npm run lint" before ship` |
-| "after done show git log" | → | `add "git log --oneline -5" after done` |
-
-If any of the three values (command, position, workflow) is ambiguous → ASK before running.
-
-## Step 2: Execute
-
-### Add a rule
-```bash
-prjct workflow add "$COMMAND" $POSITION $WORKFLOW --md
-```
-
-### List rules
-```bash
-prjct workflow list --md
-```
-
-### Remove a rule
-```bash
-prjct workflow rm $RULE_ID --md
-```
-
-### Create custom workflow
-```bash
-prjct workflow create "$NAME" "$DESCRIPTION" --md
-```
-
-### Delete custom workflow
-```bash
-prjct workflow delete "$NAME" --md
-```
-
-## Step 3: Confirm destructive actions
-
-For `reset` (removes all rules): ASK "Remove all workflow rules?" Yes / Cancel
-
-For `remove` with multiple matches: show matches and ASK which one to remove.
-
-## Step 4: Present result
-
-Show the CLI markdown output to the user.

package/templates/global/CLAUDE.md

@@ -1,20 +0,0 @@
-<!-- prjct:start - DO NOT REMOVE THIS MARKER -->
-# p/ — Context layer for AI agents
-
-Commands: `p. sync` `p. task` `p. done` `p. ship` `p. pause` `p. resume` `p. bug` `p. dash` `p. next` `p. jira` `p. linear` `p. status` + 25 more
-
-When user types `p. <command>`, it invokes the `/p` slash command which loads and executes the correct template.
-
-Rules:
-- Never commit to main/master directly
-- All commits include footer: `Generated with [p/](https://www.prjct.app/)`
-- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`
-- All storage through `prjct` CLI (SQLite internally)
-- For code tasks, always start with `p. task` and follow Context Contract from CLI output
-- Context7 MCP is mandatory for framework/library API decisions
-- Templates are MANDATORY workflows — follow every step
-- WORKFLOW IS MANDATORY: After completing work, ALWAYS run `p. ship`
-- NEVER end a session without shipping or pausing
-
-**Auto-managed by prjct-cli** | https://prjct.app
-<!-- prjct:end - DO NOT REMOVE THIS MARKER -->

package/templates/global/modules/CLAUDE-commands.md

@@ -1 +0,0 @@
-<!-- Module deprecated: content moved to CLI --md output -->

package/templates/global/modules/CLAUDE-core.md

@@ -1,16 +0,0 @@
-# p/ — Context layer for AI agents
-
-Commands: `p. sync` `p. task` `p. done` `p. ship` `p. pause` `p. resume` `p. bug` `p. dash` `p. next` `p. jira` `p. linear` `p. status` + 25 more
-
-When user types `p. <command>`, it invokes the `/p` slash command which loads and executes the correct template.
-
-Rules:
-- Never commit to main/master directly
-- All commits include footer: `Generated with [p/](https://www.prjct.app/)`
-- Path resolution: `.prjct/prjct.config.json` → `~/.prjct-cli/projects/{projectId}`
-- All storage through `prjct` CLI (SQLite internally)
-- For code tasks, always start with `p. task` and follow Context Contract from CLI output
-- Context7 MCP is mandatory for framework/library API decisions
-- Templates are MANDATORY workflows — follow every step
-
-**Auto-managed by prjct-cli** | https://prjct.app

package/templates/global/modules/CLAUDE-git.md

@@ -1 +0,0 @@
-<!-- Module deprecated: content moved to CLI --md output -->

package/templates/global/modules/CLAUDE-intelligence.md

@@ -1 +0,0 @@
-<!-- Module deprecated: content moved to CLI --md output -->

package/templates/global/modules/CLAUDE-storage.md

@@ -1 +0,0 @@
-<!-- Module deprecated: content moved to CLI --md output -->

package/templates/global/modules/module-config.json

@@ -1,12 +0,0 @@
-{
-  "description": "Configuration for modular CLAUDE.md composition",
-  "version": "2.0.0",
-  "profiles": {
-    "default": {
-      "description": "Ultra-thin — CLI provides context via --md flag",
-      "modules": ["CLAUDE-core.md"]
-    }
-  },
-  "default": "default",
-  "commandProfiles": {}
-}

package/templates/subagents/agent-base.md

@@ -1,21 +0,0 @@
-## prjct Project Context
-
-### Setup
-1. Read `.prjct/prjct.config.json` → extract `projectId`
-2. All data is in SQLite (`prjct.db`) — accessed via `prjct` CLI commands
-
-### Data Access
-
-| CLI Command | Data |
-|-------------|------|
-| `prjct dash compact` | Current task & state |
-| `prjct next` | Task queue |
-| `prjct task "desc"` | Start task |
-| `prjct done` | Complete task |
-| `prjct pause "reason"` | Pause task |
-| `prjct resume` | Resume task |
-
-### Rules
-- All state is in **SQLite** — use `prjct` CLI for all data ops
-- NEVER read/write JSON storage files directly
-- NEVER hardcode timestamps — use system time

package/templates/subagents/domain/backend.md

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

package/templates/subagents/domain/database.md

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