prjct-cli 1.6.12 → 1.6.13

package/CHANGELOG.md

@@ -1,12 +1,44 @@
 # Changelog
 
+## [1.6.13] - 2026-02-07
+
+### Refactoring
+
+- remove unused templates and dead code (PRJ-293) (#138)
+- remove unused templates and dead code (PRJ-293)
+
+
+## [1.6.15] - 2026-02-07
+
+### Refactor
+- **Remove unused templates and dead code (PRJ-293)**: Deleted 8 unused template files from `templates/analysis/` (5) and `templates/agentic/` (3) that were never referenced by any code or other templates. Also removed unused type imports flagged by biome's `noUnusedImports` rule from `diff-generator.ts`, `sync-service.ts`, and `citations.ts`. Total: -471 lines removed.
+
+### Implementation Details
+Audited all 135 templates by cross-referencing with code that loads them. Carefully distinguished between templates loaded dynamically via `readdir` (checklists, skills — kept) and templates with zero references (analysis prompts, agentic scaffolding — deleted). Unused imports were types imported for re-export where the `export type` statement imports independently from the source module, making the `import type` line redundant.
+
+### Learnings
+- Dynamic template loading via `readdir` (in `prompt-builder.ts` and `skill-service.ts`) means simple grep searches can't identify all references — must trace runtime loading patterns to distinguish truly unused templates from dynamically loaded ones
+- TypeScript `export type { X } from 'module'` is a standalone declaration that imports independently — a separate `import type { X }` is only needed if `X` is used in the file body
+
+### Test Plan
+
+#### For QA
+1. Run `bun run build` — verify build succeeds with no errors
+2. Run `bun run lint` — verify zero biome warnings (especially `noUnusedImports`)
+3. Run `prjct sync` — verify sync still works (deleted templates were unused by sync)
+4. Verify `templates/checklists/*.md` and `templates/skills/*.md` are untouched (dynamically loaded)
+
+#### For Users
+**What changed:** Removed 8 unused internal template files and cleaned up dead imports. No user-facing behavior changes.
+**How to use:** No action needed — this is an internal cleanup.
+**Breaking changes:** None.
+
 ## [1.6.12] - 2026-02-07
 
 ### Bug Fixes
 
 - replace sync I/O in imports-tool hot path (PRJ-290) (#137)
 
-
 ## [1.6.14] - 2026-02-07
 
 ### Bug Fixes

package/core/services/diff-generator.ts

@@ -9,13 +9,7 @@
  */
 
 import chalk from 'chalk'
-import type {
-  DiffOptions,
-  DiffSection,
-  ParsedMarkdownSection,
-  PreservedInfo,
-  SyncDiff,
-} from '../types'
+import type { DiffOptions, ParsedMarkdownSection, SyncDiff } from '../types'
 
 export type {
   DiffOptions,

package/core/services/sync-service.ts

@@ -33,7 +33,6 @@ import configManager from '../infrastructure/config-manager'
 import pathManager from '../infrastructure/path-manager'
 import { metricsStorage } from '../storage/metrics-storage'
 import type {
-  AIToolResult,
   GitData,
   ProjectCommands,
   ProjectStats,
@@ -48,7 +47,6 @@ import { type ContextSources, defaultSources, type SourceInfo } from '../utils/c
 import * as dateHelper from '../utils/date-helper'
 import log from '../utils/logger'
 import { ContextFileGenerator } from './context-generator'
-import type { SyncDiff } from './diff-generator'
 import { localStateGenerator } from './local-state-generator'
 import { skillInstaller } from './skill-installer'
 import { StackDetector } from './stack-detector'

package/core/utils/citations.ts

@@ -7,7 +7,7 @@
  * @see PRJ-113
  */
 
-import type { ContextSources, SourceInfo, SourceType } from '../types/citations'
+import type { ContextSources, SourceInfo } from '../types/citations'
 
 export type { ContextSources, SourceInfo, SourceType } from '../types/citations'
 

package/dist/bin/prjct.mjs

@@ -28706,7 +28706,7 @@ var require_package = __commonJS({
   "package.json"(exports, module) {
     module.exports = {
       name: "prjct-cli",
-      version: "1.6.12",
+      version: "1.6.13",
       description: "Context layer for AI agents. Project context for Claude Code, Gemini CLI, and more.",
       main: "core/index.ts",
       bin: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prjct-cli",
-  "version": "1.6.12",
+  "version": "1.6.13",
   "description": "Context layer for AI agents. Project context for Claude Code, Gemini CLI, and more.",
   "main": "core/index.ts",
   "bin": {

package/templates/agentic/context-filtering.md

@@ -1,35 +0,0 @@
----
-allowed-tools: [Glob, Read]
----
-
-# Context Filtering
-
-Determine relevant files for a task.
-
-## Process
-
-1. **Get real extensions**: Only include what EXISTS in project
-2. **Identify directories**: Based on task, not assumptions
-3. **Filter by task**: What files will be modified?
-4. **Exclude non-relevant**: node_modules, .git, dist, build
-
-## Output
-
-```json
-{
-  "include": {
-    "extensions": [".ts", ".tsx"],
-    "directories": ["src/", "lib/"]
-  },
-  "exclude": {
-    "directories": ["node_modules/", ".git/", "dist/"]
-  },
-  "reasoning": "why these patterns"
-}
-```
-
-## Rules
-
-- Use REAL extensions (not assumed)
-- Task-specific filtering
-- Efficient - focus on what matters

package/templates/agentic/skill-integration.md

@@ -1,59 +0,0 @@
-# Skill Integration
-
-Agents integrate with Claude Code skills from claude-plugins.dev.
-
-## Agent → Skill Mapping
-
-| Agent | Skill |
-|-------|-------|
-| frontend.md | frontend-design |
-| uxui.md | frontend-design |
-| backend.md | javascript-typescript |
-| testing.md | developer-kit |
-| devops.md | developer-kit |
-| prjct-planner.md | feature-dev |
-| prjct-shipper.md | code-review |
-
-## Installation (during `p. sync`)
-
-1. Check existing: `ls ~/.claude/skills/*.md`
-2. Search: `https://claude-plugins.dev/skills?q={term}`
-3. Prefer: @anthropics, high downloads
-4. Write to: `~/.claude/skills/{name}.md`
-5. Save mapping: `{globalPath}/config/skills.json`
-
-## Agent Frontmatter
-
-```yaml
----
-name: frontend
-description: "Frontend specialist. Use PROACTIVELY."
-tools: Read, Write, Glob, Grep
-skills: [frontend-design]
----
-```
-
-## Usage
-
-**During `p. task`**:
-- Load agent → invoke linked skills
-
-**During `p. ship`**:
-- Invoke code-review skill
-
-## Key Skills
-
-| Skill | Purpose |
-|-------|---------|
-| frontend-design | UI components, anti-AI-slop |
-| javascript-typescript | Node.js, React patterns |
-| python-development | Django, FastAPI patterns |
-| feature-dev | Architecture, planning |
-| code-review | PR review, security |
-| developer-kit | Testing, DevOps |
-
-## Troubleshooting
-
-- Skill not invoking? Check agent `skills:` frontmatter
-- Wrong skill? Re-run `p. sync`
-- Manual invoke: `/frontend-design`

package/templates/agentic/subagent-generation.md

@@ -1,54 +0,0 @@
-# Sub-Agent Generation
-
-Generate project-specific agents based on detected stack.
-
-## Output Location
-
-`{globalPath}/agents/` (NEVER local project)
-
-## Agent Format
-
-```markdown
----
-name: agent-name
-description: When to use. Include "Use PROACTIVELY" for auto-invoke.
-tools: Read, Write, Glob, Grep, Bash
-model: sonnet
-skills: [skill-name]
----
-Agent prompt...
-```
-
-## Required Workflow Agents
-
-| Agent | Purpose | Skill |
-|-------|---------|-------|
-| prjct-workflow.md | Task lifecycle | - |
-| prjct-planner.md | Feature planning | feature-dev |
-| prjct-shipper.md | Git, deploy | code-review |
-
-## Domain Agents (based on stack)
-
-| If Detected | Generate | Skill |
-|-------------|----------|-------|
-| React, Vue, CSS | frontend.md | frontend-design |
-| Node, Express, API | backend.md | javascript-typescript |
-| PostgreSQL, MongoDB | database.md | - |
-| Docker, CI/CD | devops.md | developer-kit |
-| Jest, Pytest | testing.md | developer-kit |
-| Any UI | uxui.md | frontend-design |
-
-## Execution
-
-1. Read `{globalPath}/analysis/repo-summary.md`
-2. Create `{globalPath}/agents/` directory
-3. Generate workflow agents (always)
-4. Generate domain agents (based on analysis)
-5. Add skills to frontmatter
-6. Report generated agents
-
-## Rules
-
-- **ALWAYS** write to `{globalPath}/agents/`
-- **NEVER** write to `.claude/` or `.prjct/`
-- Adapt templates to project context

package/templates/analysis/bug-severity.md

@@ -1,74 +0,0 @@
----
-name: bug-severity
-description: Assess bug severity from description
-allowed-tools: [Read]
----
-
-# Bug Severity Assessment
-
-Analyze the bug description to determine its severity and priority.
-
-## Input
-- Bug: {{description}}
-- Context (if available)
-
-## Severity Levels
-
-### CRITICAL
-- System crash or data loss
-- Security vulnerability
-- Blocks all users
-- Production is down
-
-### HIGH
-- Major feature broken
-- Significant user impact
-- Workaround difficult
-- Affects many users
-
-### MEDIUM
-- Feature partially broken
-- Workaround exists
-- Limited user impact
-- Non-essential functionality
-
-### LOW
-- Minor inconvenience
-- Cosmetic issue
-- Edge case only
-- Easy workaround
-
-## Analysis Steps
-
-1. **Assess Impact**
-   - Who is affected?
-   - How many users?
-   - Is there data loss risk?
-
-2. **Check Urgency**
-   - Is production affected?
-   - Is there a deadline?
-   - Are users blocked?
-
-3. **Evaluate Workaround**
-   - Can users continue working?
-   - How hard is the workaround?
-
-## Output Format
-
-Return JSON:
-```json
-{
-  "severity": "critical|high|medium|low",
-  "priority": 1-4,
-  "reasoning": "<brief explanation>",
-  "suggestedAction": "<what to do next>"
-}
-```
-
-## Guidelines
-
-- Err on the side of higher severity if unsure
-- Security issues are always CRITICAL
-- Data loss is always CRITICAL
-- User-reported = add weight

package/templates/analysis/complexity.md

@@ -1,54 +0,0 @@
----
-name: complexity-analysis
-description: Analyze task complexity semantically
-allowed-tools: [Read]
----
-
-# Task Complexity Analysis
-
-Analyze the given task description and determine its complexity level.
-
-## Input
-- Task: {{task}}
-- Project context (if available)
-
-## Analysis Steps
-
-1. **Understand the Task**
-   - What is being asked?
-   - What systems/files are affected?
-   - Are there dependencies?
-
-2. **Evaluate Scope**
-   - Single file change → LOW
-   - Multiple files, same module → MEDIUM
-   - Cross-module or architectural → HIGH
-
-3. **Assess Risk**
-   - Read-only or additive → LOW risk
-   - Modifying existing logic → MEDIUM risk
-   - Refactoring or migration → HIGH risk
-
-4. **Consider Dependencies**
-   - No external deps → LOW
-   - Some integration → MEDIUM
-   - Multiple systems → HIGH
-
-## Output Format
-
-Return JSON:
-```json
-{
-  "complexity": "low|medium|high",
-  "type": "feature|bugfix|refactor|testing|docs|chore",
-  "estimatedHours": <number>,
-  "reasoning": "<brief explanation>"
-}
-```
-
-## Guidelines
-
-- Be realistic, not optimistic
-- Consider testing time in estimates
-- If unsure, lean toward higher complexity
-- Don't use keyword matching - analyze semantically

package/templates/analysis/health.md

@@ -1,66 +0,0 @@
----
-name: health-score
-description: Calculate project health score
-allowed-tools: [Read]
----
-
-# Project Health Score
-
-Evaluate the project's health based on activity metrics.
-
-## Input
-- Active task: {{hasActiveTask}}
-- Queue size: {{queueSize}}
-- Recent ships: {{recentShips}}
-- Ideas count: {{ideasCount}}
-- Days since last ship: {{daysSinceShip}}
-
-## Health Factors
-
-### Momentum (40%)
-- Active task = good
-- Regular shipping = good
-- Long gaps = concerning
-
-### Focus (30%)
-- Queue < 10 = focused
-- Queue 10-20 = busy
-- Queue > 20 = overloaded
-
-### Progress (20%)
-- Ships this week > 0 = active
-- Ships this month > 2 = productive
-- No ships in 7+ days = stalled
-
-### Planning (10%)
-- Ideas captured = thinking ahead
-- Too many ideas = unfocused
-
-## Score Calculation
-
-Evaluate each factor and combine:
-
-| Score | Label | Meaning |
-|-------|-------|---------|
-| 80-100 | Excellent | High momentum, focused, shipping |
-| 60-79 | Good | Active, some room to improve |
-| 40-59 | Fair | Slowing down, needs attention |
-| 0-39 | Low | Stalled, intervention needed |
-
-## Output Format
-
-Return JSON:
-```json
-{
-  "score": <0-100>,
-  "label": "Excellent|Good|Fair|Low",
-  "momentum": "<assessment>",
-  "suggestions": ["<action 1>", "<action 2>"]
-}
-```
-
-## Guidelines
-
-- Be encouraging but honest
-- Suggest specific actions
-- Focus on momentum, not perfection

package/templates/analysis/intent.md

@@ -1,66 +0,0 @@
----
-name: intent-detection
-description: Detect user intent from natural language
-allowed-tools: []
----
-
-# Intent Detection
-
-Analyze user input to determine their intent and map to appropriate action.
-
-## Input
-- User message: {{message}}
-
-## Intent Categories
-
-### Work Intents
-- **start_task**: User wants to begin working on something
-- **complete_task**: User finished current work
-- **ship**: User wants to release/deploy
-- **pause**: User needs to pause current work
-
-### Planning Intents
-- **add_feature**: User has a new feature idea
-- **add_idea**: Quick thought to capture
-- **add_bug**: Report a problem
-- **view_queue**: See what's next
-
-### Status Intents
-- **check_progress**: View metrics/status
-- **get_recap**: Project overview
-- **get_help**: Need guidance
-
-### System Intents
-- **sync**: Update project state
-- **analyze**: Analyze codebase
-- **cleanup**: Clean up files
-
-## Analysis
-
-Look for semantic meaning, not keywords:
-- "I'm done" → complete_task
-- "Let's ship this" → ship
-- "Quick thought..." → add_idea
-- "What should I do?" → get_help OR view_queue
-
-## Output Format
-
-Return JSON:
-```json
-{
-  "intent": "<intent_name>",
-  "confidence": <0.0-1.0>,
-  "parameters": {
-    "task": "<extracted task if any>",
-    "feature": "<extracted feature if any>"
-  },
-  "suggestedCommand": "/p:<command>"
-}
-```
-
-## Guidelines
-
-- Use semantic understanding, not regex
-- Extract relevant parameters
-- High confidence (>0.8) for clear intents
-- Ask for clarification if < 0.5

package/templates/analysis/task-breakdown.md

@@ -1,53 +0,0 @@
----
-name: task-breakdown
-description: Break down a feature into actionable tasks
-allowed-tools: [Read, Glob, Grep]
----
-
-# Feature Task Breakdown
-
-Analyze the feature description and break it into concrete, actionable tasks.
-
-## Input
-- Feature: {{feature}}
-- Project path: {{projectPath}}
-
-## Analysis Steps
-
-1. **Understand the Feature**
-   - Read related code if paths are obvious
-   - Identify affected systems
-   - Note existing patterns to follow
-
-2. **Identify Components**
-   - What new files/modules are needed?
-   - What existing code needs modification?
-   - What tests are required?
-
-3. **Order by Dependencies**
-   - Foundation tasks first (models, types, interfaces)
-   - Core logic second
-   - Integration third
-   - Tests and polish last
-
-4. **Size Each Task**
-   - Each task should be 20-60 minutes
-   - If larger, break down further
-   - If smaller, combine with related task
-
-## Output Format
-
-Return a numbered task list:
-```
-1. [20m] Task description - specific action
-2. [30m] Another task - what exactly to do
-3. [45m] Final task - clear deliverable
-```
-
-## Guidelines
-
-- Tasks must be specific and actionable
-- Include time estimates in brackets
-- Order matters - dependencies first
-- Don't assume - if unsure, read code first
-- Match project patterns (read existing code)