pitroom 0.6.4 → 0.6.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pitroom",
-  "version": "0.6.4",
+  "version": "0.6.5",
   "description": "A free pit crew for your expensive coding agent: the superpowers development workflow, run by cheap workers. Delegate research, fixes, tests, reviews and whole plans from Claude Code, Codex or any agent to OpenCode, Codex or Claude Code workers, with receipts that prove the savings.",
   "type": "module",
   "author": "TahaAtas",
@@ -26,6 +26,7 @@
     "README.md",
     "CHANGELOG.md",
     "PRIVACY.md",
+    "THIRD_PARTY_NOTICES.md",
     "LICENSE"
   ],
   "engines": {
@@ -35,7 +36,8 @@
     "build": "node scripts/build.mjs",
     "typecheck": "tsc --noEmit",
     "test": "npm run build && node --test test/*.test.mjs",
-    "prepublishOnly": "npm run typecheck && npm test"
+    "prepublishOnly": "npm run typecheck && npm test",
+    "bump": "node scripts/bump-version.mjs"
   },
   "keywords": [
     "agent",

package/skills/pitroom-crew/SKILL.md

@@ -17,7 +17,7 @@ Don't use it when the failures are related (fixing one might fix the others: inv
 
 ## 1. Split
 
-Parts must be **independent**: no part needs another's result, and no two parts edit the same file. Two to five parts is the sweet spot; at most `maxParallel` workers (default 4) run at a time, the rest queue. Keep dependent or judgment-heavy parts for yourself.
+Parts must be **independent**: no part needs another's result, and no two parts edit the same file. Start as many workers as there are independent parts: up to 20 run at a time by default (`maxParallel`, 30 at most), the rest queue. Keep dependent or judgment-heavy parts for yourself.
 
 ## 2. Write focused briefs
 
@@ -76,5 +76,5 @@ pitroom show <run>                  # the full report of the ones you need
 ## When things go wrong
 
 - A worker failed or timed out: retry that part once with a sharper brief, or do it yourself.
-- Rate limits: the fallback chain handles single failures; if many fail, lower `maxParallel` (config or `PITROOM_MAX_PARALLEL`).
+- Rate limits: the fallback chain handles single failures; if many fail at once, lower `maxParallel` (config or `PITROOM_MAX_PARALLEL`) or spread the parts over more than one worker.
 - Stop everything: `pitroom stop -g NAME` (running and queued).

package/skills/pitroom-writing-plans/SKILL.md

@@ -50,7 +50,7 @@ Every task names the worker tier that implements it, on its own line right under
 - **standard**: several files with integration concerns, or an implementer working from prose.
 - **capable**: design judgment or broad understanding of the codebase.
 
-Turn count beats token price: the cheapest models take 2-3× the turns on multi-step work. When unsure between two tiers, take the higher.
+Turn count beats token price: the cheapest models take 2-3× the turns on multi-step work. The user prefers the free tier, so start with `cheap` for everything a cheap worker can plausibly do and raise only the tasks that need more; a failed cheap task costs one retry on a higher tier. When you are truly unsure between two tiers for a task that is costly to redo, take the higher.
 
 ## Bite-Sized Task Granularity
 

package/skills/using-pitroom/SKILL.md

@@ -55,6 +55,8 @@ Once you or the user pick a skill, follow it: its checklists and gates are how i
 
 Call `pitroom` (on PATH after `pitroom install`; otherwise the command in your session context). `pitroom doctor` diagnoses setup problems. Workers and models come from the user's config (`worker`, `fallback`, `models`, `tiers`); pick others only when the user or a plan says so (`--tier capable`, `-W codex`).
 
+Model and effort: tiers already name the workers. Before you pick anything else, run `pitroom models`: it lists what each worker offers (Codex, Claude Code, OpenCode), the effort levels each model accepts, what the user says it costs (`costs` in the config) and what it used so far. Take the cheapest model that fits the task, never a dearer one by habit: start on the `cheap` tier (OpenCode's free model) and move up only when the task needs it or a cheaper worker already failed. Set `--effort` from the task: `low` for lookups and mechanical edits, `medium` for ordinary changes, `high` for reviews and non-obvious bugs, `xhigh` or above only when the user asks or a lower level failed. More effort costs more tokens and time.
+
 Workers can take minutes. Start long work with `--bg` and keep working; follow it with `pitroom watch --json` through your host's background or monitor facility, or call `pitroom wait --timeout 540` again while it exits 75. Never poll with `sleep`.
 
 ## When you do use it
@@ -63,6 +65,7 @@ Workers can take minutes. Start long work with `--bg` and keep working; follow i
 - Worker output is draft work and a worker's report is a claim: verify what you rely on (`pitroom-verification`).
 - You apply patches and commit; workers never commit or push. Push, merge and pull requests happen only after the user asks.
 - Keep the decisions: delegate the reading and typing, not the architecture.
+- Say what you delegated: one line per worker run naming the worker and model (the run report has both) and what it cost or saved. Not every host shows Pitroom's cards or status line, and the user should always know which model touched their code. `pitroom savings --models` lists them all.
 - You set a worker's permissions when you create it, from the task and from how much autonomy the user gave you in this session (for example auto mode): read-only by default, `-i` (an isolated copy) for changes, `-w` (edits in place) when the user wants that, `--web` only when the task needs the web. A worker never widens its own permissions.
 - Pitroom keeps a fixed floor that no flag lifts: no git history changes, no `sudo`, no publishing, no secrets, no killing processes. Everything above that floor is your call.
 - Deletions are your decision, made as the user's agent. `pitroom apply` refuses a patch that deletes files unless you pass `--allow-delete`. If removing files is what the user asked for or an obvious part of it, apply with the flag and tell them which files went; if the worker deleted something the user did not ask for, ask first, or discard the run.