prjct-cli 2.22.1 → 2.23.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prjct-cli",
-  "version": "2.22.1",
+  "version": "2.23.1",
   "description": "Context layer for AI agents. Project context for Claude Code, Gemini CLI, and more.",
   "main": "dist/bin/prjct.mjs",
   "bin": {

package/templates/skills/prjct/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: "Spec-Driven Development runtime + project memory. When the user describes a feature, fix, or initiative WITH goals or stakes attached (think rate-limiting an endpoint, fixing onboarding, building feature X that solves Y) draft a spec FIRST via `prjct spec` (Goal/Acceptance/Scope/Risks) then `audit-spec` (three parallel reviewers) then `task --spec <id>` then `ship` (acceptance gate). For routine work (single-file fix, doc tweak, GTD capture) skip the spec and use the matching verb directly. Recognize the intent in any language (es/en) and run the verb yourself — never make the user type commands. Routine captures (capture, remember, tag) auto-execute and confirm in one line; destructive verbs (ship, status done) suggest-and-confirm. Heavy reviews (audit, review, security, investigate, audit-spec) dispatch as parallel subagents. Lookup-first: check the vault before re-reading source."
+description: "Project-memory + spec-driven runtime. TRIAGE FIRST, every turn — is this simple or complex? MOST work is SIMPLE (≈1 file, known cause, bug/config/copy/doc, reversible, or the user says fix/hoy/rápido/directo): go DIRECT — `prjct task` → implement → `qa`/`review` → `ship`. NO spec, NO audit-spec, NO reviewer subagents. Spec is the EXCEPTION, ONLY for genuinely complex / high-stakes work (multi-file + new behavior, ambiguous scope, irreversible, or the user frames goals/acceptance/risks): then `spec` → `audit-spec` → `task --spec` → `ship`. Over-routing simple work through spec+reviewers is THE failure mode (burns time/tokens, zero protection on a one-file fix) — when unsure prefer DIRECT and ask one line; never default to spec. Recognize intent in any language (es/en) and run the verb yourself — never make the user type commands. Routine captures (capture/remember/tag) auto-execute, one-line confirm; destructive verbs (ship, status done) suggest-and-confirm; heavy reviews (audit/review/security/investigate) dispatch parallel subagents ONLY when the diff/scope warrants. Lookup-first: vault before re-reading source."
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Glob", "Grep", "Task"]
 user-invocable: true
 ---
@@ -46,19 +46,19 @@ Base memory types: `fact · decision · learning · gotcha · pattern · anti-pa
 - `.prjct/wiki/captured/` — drop notes with frontmatter, run `prjct context wiki sync` to ingest
 - `.prjct/prjct.config.json` — persona + active packs
 
-## SDD — the canonical sequence
+## TRIAGE FIRST — the gate before ANY verb
 
-prjct is Spec-Driven for *complex* work — and most changes are NOT complex. **Triage first** (one beat, before any verb): is this simple or complex?
+STOP. Before any verb, one beat: **is this simple or complex?** This gate runs on EVERY turn and is non-negotiable — skipping it (defaulting to spec) is the single worst failure mode: it burns time + tokens + drowns subagents in context for ZERO protection on routine work. Most work is SIMPLE.
 
-- **Simple** — ≈1 file, known root cause, bug/config/copy/doc, reversible, clear scope, or the user says "fix"/"hoy"/"rápido"/"directo". → Go DIRECT: `prjct task` → implement → `qa`/`review` workflow → `ship`. NO spec, NO audit-spec, NO reviewer subagents.
-- **Complex** — multi-file + new behavior, ambiguous scope, real stakes, irreversible, or the user frames goals/acceptance/risks. → Full SDD, the six stations:
+- **SIMPLE → go DIRECT (the default, the common case):** ≈1 file, known root cause, bug/config/copy/doc, reversible, clear scope, OR the user says "fix"/"hoy"/"rápido"/"directo". → `prjct task` → implement → `qa`/`review` → `ship`. **NO spec. NO audit-spec. NO reviewer subagents. No ceremony.** If you are even slightly unsure, this path is the safe default — ask ONE line, do not escalate to spec.
+- **COMPLEX → the EXCEPTION (rare):** ONLY multi-file + new behavior AND ambiguous scope AND real/irreversible stakes, OR the user explicitly frames goals/acceptance/risks. Then — and only then — the six stations:
 
 ```
 spec ─→ audit-spec ─→ task (--spec <id>) ─→ implement ─→ ship (acceptance gate)
                                                                   └─→ remember learning
 ```
 
-Read the user's intent and route to the right STATION, not the first verb that fits. The trap to avoid: jumping straight to `task` when the user is describing a feature without scope. Specs are cheap; un-doing implementation isn't.
+The trap that actually keeps happening: forcing SIMPLE work (a fix, a one-file change, anything the user said "hoy"/"rápido") through spec + audit-spec + parallel reviewers. That is the perf-killer — every action ballooning into multiple specs and subagent dispatches with bloated context. Default to DIRECT; reach for a spec only when the complexity test above is unambiguously met.
 
 - **spec** — user describes a feature, fix, initiative *with goals or stakes*. Anything that would be wasted as inbox AND wasted as a free-running task. Forcing questions: goal? eli10? stakes if wrong? acceptance criteria (testable, observable)? what's in scope? what's OUT? risks?
 - **audit-spec** — spec exists, before any code. Dispatch three review subagents in PARALLEL (strategic / architecture / design). Each returns pass|fail + notes. All three pass → spec auto-promotes draft → reviewed → safe to start `task`.
@@ -75,25 +75,25 @@ The user does NOT type prjct commands. You do. On every turn, ask: "what is the
 
 These are *signals*, not phrase templates. Read them as descriptions of moments in the user's flow.
 
-### `spec` — "we're framing work BEFORE we start coding"
+### `task` — "I'm starting a piece of work" (THE DEFAULT — try this first)
 
-Signals: the user describes a feature, fix, or initiative WITH goals/stakes attached — "we need to add rate limiting", "the onboarding is broken", "let's build SDD into prjct". Distinguishing tells vs `task`: the user mentions WHAT SUCCESS LOOKS LIKE or WHY IT MATTERS or ACCEPTANCE CRITERIA. They're not just naming a unit of work — they're framing one.
+Signals: the user is describing a unit of work to execute — a fix, a change, picking up a queue item, "haceme X", "arreglá Y". This is where the VAST MAJORITY of turns land.
 
-What to do: SUGGEST `prjct spec "<title>"` in one line ("I'll draft a spec — Goal/Acceptance/Scope/Risks. ~30 sec, then we audit and start the task. Ok?"). On green light, create the spec and walk the forcing questions: goal, eli10, stakes, acceptance criteria, scope, out_of_scope, risks, test_plan. Persist via `prjct spec update <id> --json '{...}'`. Then suggest `prjct audit-spec <id>` to harden it before any code.
+What to do: this is the DEFAULT path. Triage said simple (the common case) → run `prjct task "<concise description>"` and go straight to implement → `qa`/`review` → `ship`. NO confirmation gate; starting a task is reversible. Escalate to `spec` ONLY if the complexity test is unambiguously met (multi-file + new behavior + real/irreversible stakes, or the user explicitly framed goals/acceptance/risks). If a relevant spec already exists, link it: `prjct task "<desc>" --spec <id>`.
 
-Anti-pattern (both directions): skipping `spec` for genuinely complex / high-stakes work — AND its mirror, the more common failure: forcing a one-file "fix"/"hoy" change through `spec` + `audit-spec`. If it is simple, `task` direct + `qa` is correct; spec there is pure ceremony tax.
+### `spec` — "we're framing genuinely complex work BEFORE coding" (the EXCEPTION)
 
-### `audit-spec` — "lock the spec before we ship code against it"
+Signals: the user describes a feature/initiative WITH goals/stakes attached AND it is genuinely complex (multi-file, new behavior, ambiguous scope, irreversible) — "we need to add rate limiting", "the onboarding is broken", "let's build SDD into prjct". Distinguishing tell vs `task`: the user frames WHAT SUCCESS LOOKS LIKE / WHY IT MATTERS / ACCEPTANCE CRITERIA, not just naming a unit of work. A bare "fix X" / "hoy" is NOT this — that is `task`.
 
-Signals: spec exists, no implementation yet, user wants to harden / pressure-test. Phrases: "is this spec good?" / "can we start building?" / "what's missing?". Also fires automatically when the user says ship-soonish words while the linked spec is still `draft`.
+What to do: SUGGEST `prjct spec "<title>"` in one line ("I'll draft a spec — Goal/Acceptance/Scope/Risks. ~30 sec, then we audit and start the task. Ok?"). On green light, create the spec and walk the forcing questions: goal, eli10, stakes, acceptance criteria, scope, out_of_scope, risks, test_plan. Persist via `prjct spec update <id> --json '{...}'`. Then suggest `prjct audit-spec <id>`.
 
-What to do: run `prjct audit-spec <id>` — it emits a dispatch prompt. Then dispatch three Agent subagents IN PARALLEL (one tool-use block per reviewer in the SAME message — strategic / architecture / design — see Quality workflows below for the dispatch shape). Each returns a structured verdict. Persist each via `prjct spec record-review <id> --reviewer <name> --verdict <pass|fail> --notes "..."`. When all three pass the spec auto-promotes to `reviewed`.
+Anti-pattern (the common one): forcing a one-file "fix"/"hoy" change through `spec` + `audit-spec`. If it is simple, `task` direct + `qa` is correct; spec there is pure ceremony tax that degrades performance.
 
-### `task` — "I'm starting a new piece of work"
+### `audit-spec` — "lock the spec before we ship code against it" (only after a spec exists)
 
-Signals: the user is describing a unit of work to execute — switching context, picking up an item from the queue, asking you to plan / start something not yet started. *Distinguishes from `spec`: the framing is already done (spec linked, or work is small/clear enough to skip a spec).*
+Signals: a spec ALREADY exists, no implementation yet, user wants to harden / pressure-test. Phrases: "is this spec good?" / "can we start building?" / "what's missing?". Never run this without an existing spec.
 
-What to do: this is the DEFAULT path. After triage says simple, run `prjct task "<concise description>"` and go straight to implement → `qa`/`review` → `ship`. Only when the work is genuinely complex (multi-file + new behavior, ambiguous scope, real stakes) pause and surface `prjct spec` instead. If a relevant spec already exists, link it: `prjct task "<desc>" --spec <id>` so ship can gate. No confirmation gate; starting a task is reversible.
+What to do: run `prjct audit-spec <id>` — it emits a dispatch prompt. Then dispatch three Agent subagents IN PARALLEL (one tool-use block per reviewer in the SAME message — strategic / architecture / design — see Quality workflows below for the dispatch shape). Each returns a structured verdict. Persist each via `prjct spec record-review <id> --reviewer <name> --verdict <pass|fail> --notes "..."`. When all three pass the spec auto-promotes to `reviewed`.
 
 ### `capture` — "save this thought, don't decide anything yet"