pitroom

Use when you or the user want a feature, component or behaviour change designed before it is built - explores intent, requirements and design with the user and gets approval before implementation.

Use when facing two or more independent tasks - questions about different areas, unrelated bugs or failing test files, the same mechanical change in separate modules - to run Pitroom workers in parallel, watch them live and merge their results.

Use when a bug, test failure or unexpected behaviour has no obvious cause and you want a root-cause process before proposing fixes - with Pitroom workers gathering the evidence.

Use when executing a written implementation plan - each task goes to a Pitroom worker in an isolated copy, a worker on another model reviews it, and you rule, apply and commit between tasks.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - verifies, presents merge / pull request / keep options, and executes the one your human partner chooses.

Use for well-defined code changes a cheaper worker can make - small bug fixes, simple features, mechanical refactors, renames, writing tests, fixing lint or type errors, docs - where you can state the goal and check the result with a diff or tests.

Use when receiving code review feedback - from a Pitroom reviewer, a colleague or a pull request - before implementing suggestions, especially if feedback seems unclear or technically questionable; requires technical rigor and verification, not performative agreement or blind implementation.

Use when you need to find, map or explain code - where something is defined or called, how a flow works end to end, which files a change would touch, what a large module does - and the answer is much smaller than what must be read. Runs a read-only Pitroom worker and returns its answer with verified file references.

Use when completing a task, implementing a major feature, before merging, or whenever you want a second opinion on a diff, branch or pull request - a read-only Pitroom worker on another model reviews it against its requirements.

Use when you want to drive a feature or bugfix test-first - red, green, refactor, for you and for the workers you brief.

Use when you want evidence before claiming work is complete, fixed or passing, or before committing or opening a PR - run the checks and read their output first, including for claims a worker made.

Use when starting feature work that needs isolation from the current workspace, or before executing an implementation plan - sets up an isolated branch for your own work (workers get isolated copies from Pitroom itself).

Use when you have a spec or requirements for a multi-step task, before touching code - writes a task-by-task implementation plan that Pitroom workers can execute.

Use when you want cheap Pitroom workers or its workflow skills for a task, or when the user asks for Pitroom - a menu of the pitroom-* skills (brainstorm, plan, worker-driven development, review, debugging, TDD, verification, finishing), when each pays off, and how to run workers. Optional; skip it for work you would rather do yourself.