prjct-cli 2.20.1 → 2.20.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prjct-cli",
-  "version": "2.20.1",
+  "version": "2.20.2",
   "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

@@ -48,7 +48,10 @@ Base memory types: `fact · decision · learning · gotcha · pattern · anti-pa
 
 ## SDD — the canonical sequence
 
-prjct is a Spec-Driven Development system. Substantive work flows through six stations:
+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?
+
+- **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:
 
 ```
 spec ─→ audit-spec ─→ task (--spec <id>) ─→ implement ─→ ship (acceptance gate)
@@ -64,7 +67,7 @@ Read the user's intent and route to the right STATION, not the first verb that f
 - **ship** — surfaces the linked spec's acceptance_criteria as a checklist in the PR description. Ship is OK iff every criterion is met (or the user explicitly overrides with `--no-spec-gate`).
 - **remember learning** — post-ship reflection. What did we learn vs. the spec? Was a criterion wrong? Capture it; the next spec is sharper.
 
-Bypass the SDD flow only for: routine captures, bug fixes whose root cause is already known, conversational Q&A, single-keystroke memory work. If the work is *substantive* (would touch >1 file, ship to users, or take >30 min), default to `spec` first.
+Spec is the EXCEPTION, reserved for genuinely complex / high-stakes framing — NOT the default. Over-routing simple changes through spec + audit-spec is the failure mode that slows ship: it burns time and tokens for zero protection on a one-file fix. When unsure, ask ONE line — do not default to spec. Routine captures / conversational Q&A / single-keystroke memory: no verb ceremony at all.
 
 ## Verb intent map — recognize the user's goal, then act
 
@@ -78,7 +81,7 @@ Signals: the user describes a feature, fix, or initiative WITH goals/stakes atta
 
 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.
 
-Anti-pattern: 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.
+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.
 
 ### `audit-spec` — "lock the spec before we ship code against it"
 
@@ -90,7 +93,7 @@ What to do: run `prjct audit-spec <id>` — it emits a dispatch prompt. Then dis
 
 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).*
 
-What to do: if a relevant spec exists in `prjct spec list`, run `prjct task "<concise description>" --spec <id>` so ship can gate. If no spec and the work is substantive (touches >1 file, ships to users, >30 min), pause and surface `prjct spec` as the better first step. For routine work (single-file fix, doc tweak, refactor with known scope), run `prjct task` directly without --spec. No confirmation gate; starting a task is reversible.
+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.
 
 ### `capture` — "save this thought, don't decide anything yet"