prjct-cli 2.40.0 → 2.42.0

package/package.json

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

@@ -40,7 +40,8 @@ known gotchas). The verb intent map below applies in both states.
 - `prjct audit-spec <id>` — dispatch parallel strategic/architecture/design review
 - `prjct capture "<anything>"` — inbox dump (zero ceremony)
 - `prjct remember <type> "<content>" [--tags]` — typed memory entry
-- `prjct context memory [topic]` — recall with optional keyword filter
+- `prjct search "<query>"` — recall project memory (BM25 + semantic + recall); the verb to reach for when you need prior knowledge
+- `prjct context memory [topic]` — same blended retrieval as `search`, plus `learnings`/`wiki` subtools
 - `prjct guard <file>` — preventive memory recorded against a file, before you edit it
 - `prjct workflow list` / `prjct workflow run <name>` — registered workflows
 - `prjct seed list` — active packs (memory types + workflow slots)
@@ -53,18 +54,15 @@ 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
 
-## TRIAGE FIRST — the gate before ANY verb
+## Act: default DIRECT — escalation is the rare exception
 
-Before any verb, one beat: **is this simple or complex?** Runs EVERY turn. Skipping it (defaulting to spec) is the single worst failure mode — it burns time + tokens for ZERO protection on routine work. Most work is SIMPLE.
+**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.
 
-- **SIMPLE → go DIRECT (the default, the common case):** ≈1 file, known root cause, bug/config/copy/doc, reversible, OR the user says "fix"/"hoy"/"rápido"/"directo". → `prjct task` → implement → `qa`/`review` → `ship`. **NO spec. NO audit-spec. NO reviewer subagents.** If even slightly unsure, this is the safe default — ask ONE line, do not escalate.
-- **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 pipeline:
+Escalate 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.
 
-```
-spec ─→ audit-spec ─→ task (--spec <id>) ─→ implement ─→ ship (acceptance gate) ─→ remember learning
-```
+**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.
 
-Forcing SIMPLE work (a fix, a one-file change, anything "hoy"/"rápido") through spec + audit-spec + parallel reviewers is the perf-killer. Default to DIRECT; reach for spec only when the complexity test is unambiguously met. The spec pipeline stations are detailed in `workflows.md`.
+Heavy 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.
 
 **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.
 
@@ -77,6 +75,7 @@ On every turn ask: "what is the user trying to accomplish?" and match to a verb
 | 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 |
 | framing genuinely complex work WITH goals/stakes/acceptance criteria (the exception) | `prjct spec "<title>"` | 2 |
 | harden / pressure-test an existing spec before any code | `prjct audit-spec <id>` | 2 |
+| need prior project knowledge — "what did we decide about X", "buscá lo de Y", recall before re-reading source | `prjct search "<query>"` | 1 |
 | an interesting thought to keep, no commitment yet | `prjct capture "<text>" --tags topic:<x>` | 1 |
 | a non-trivial choice just got resolved (+ its why) | `prjct remember decision "<choice + one-line why>"` | 1 |
 | an insight / "aha" / new mental model | `prjct remember learning "<insight>"` | 1 |
@@ -85,22 +84,17 @@ On every turn ask: "what is the user trying to accomplish?" and match to a verb
 | about to edit a file — check for known traps | `prjct guard <file>` | 1 |
 | work is done, push it | `prjct ship` | 2 |
 | lifecycle change on the active task | `prjct status done\|paused\|active` | 2 |
-| "find bugs" / "is this safe?" / "why broken?" / "ship-ready?" | `audit` / `review` / `security` / `investigate` (subagents — see `workflows.md`) | 2 |
 | "is the codebase healthy?" | `prjct health --md` | 1 |
 | "what did we accomplish?" | `prjct retro 7d --md` | 1 |
 | pause / resume the working context | `prjct context-save` / `prjct context-restore --md` | 1 |
 
 Disambiguators: 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`).
 
-## Routing — auto-execute vs confirm (by blast radius)
+## Routing — Tier governs auto-run vs confirm (by blast radius)
 
-- **Tier 1 — auto-execute, one-line confirm.** `capture`, `tag`, `remember <type>`, `guard`, `context-save`, `health`, `retro`, `prefs check/list`. Additive or read-only: run IMMEDIATELY and emit one confirmation line (`✓ saved as decision: use Bun runtime (faster cold start)`). Do NOT ask "want me to save that?" — just save it; the user corrects afterward (cheap, reversible). Pausing for permission on routine captures is the failure mode that makes prjct useless.
-- **Tier 2 — suggest-and-confirm, ONE line.** `task`, `spec`, `audit-spec`, `ship`, `status done|paused`, `audit`/`review`/`security`/`investigate`, `prefs set`. State intent + blast radius in one line ("I'll run `prjct ship` — bumps version, commits the staged files, opens PR. Ok?") and wait for green light (yes/dale/confirma/silence-after-a-beat). Never run `ship` without surfacing the plan first — it is un-doable without a force-push.
-- **Tier 3 — decision-brief.** Hard forks where a wrong call costs >5 min to undo. Run `prjct prefs check <questionId>` first (the user may have said "stop asking me this"), then use the decision-brief format. Both are specified in `workflows.md`.
-
-## Deep methodology — pull on demand (do not preload)
-
-When you actually run a heavy workflow (`review`, `qa`, `security`, `investigate`, `audit`, `audit-spec`) — or need the subagent-dispatch model policy, the parallel implementer fan-out rules, the decision-brief format, the `prjct prefs` protocol, the spec-pipeline stations, or the builder ethos — **read `workflows.md` in this skill directory first.** It is kept out of this file on purpose so it does not sit in your context every turn; pull it only when the task calls for it. This is the same pull-not-push rule the whole runtime follows.
+- **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.
+- **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.
+- **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`.
 
 ## Gotchas