Stop babysitting agents. Give them shared understanding.
Nightmanager is a spec-driven loop for solo developers and small teams: clarify intent, turn it into local specs and vertical TODOs, then delegate one ready slice for AFK implementation. You come back to a validated commit and, when possible, a PR for human review. Nightmanager does not merge automatically.
Some skills here were shamelessly borrowed from, then lovingly remixed from, https://github.com/mattpocock/skills.
Public site: asabya.github.io/nightmanager — or see docs/index.html for the source.
grill-me → to-prd → to-issues → /nightmanager → PR for review
- Grill the intent — use
grill-meto interrogate a feature, bug, or plan one question at a time until hidden requirements, risks, and trade-offs are surfaced. - Generate/refine the spec — use
to-prdto turn the clarified conversation into a concrete local spec with goals, non-goals, acceptance criteria, edge cases, testing, and risks. - Slice the work — use
to-issuesto break the spec into small, vertical local TODOs that are safe for one focused implementation pass. This is local-file-first; it does not create GitHub issues by default. - Delegate AFK implementation — run
/nightmanagerto select one ready TODO and delegate through Manager, Finder, Oracle, and Worker to implement, validate, commit, and open a PR when possible for human review.
Specs are the shared understanding. Subagents are the execution machinery that preserves your main-session context while doing focused work inside the loop.
| Tool | Role | Best For |
|---|---|---|
finder |
Codebase search | Locating features, tracing module connections |
oracle |
Reasoning & debugging | Root-cause analysis, trade-off planning |
worker |
Implementation | Smallest viable fix, verified changes |
manager |
Orchestration | Coordinating finder/oracle/worker workflows |
Install Nightmanager with Pi:
pi install npm:nightmanagerFrom your project:
pi install -l ./path/to/nightmanagerOpen Pi and run:
/nightmanager
If you are developing from the repo instead:
pi -e ./src/index.tsSource package usage:
pi -e ./src/index.tsUse finder for codebase exploration tasks like:
- where a feature is implemented
- which files participate in a flow
- how modules connect
Configuration is shared across nightmanager in ~/.pi/agent/nightmanager.json; see Configuration.
Example prompt:
Use finder to find where authentication is handled
Use oracle for reasoning-heavy tasks like:
- debugging ambiguous failures
- root-cause analysis
- trade-off-aware planning
- deciding the best next probe
Configuration is shared across nightmanager in ~/.pi/agent/nightmanager.json; see Configuration.
Example prompt:
Use oracle to debug why auth middleware fails intermittently
Use worker for implementation work that needs:
- focused edits
- smallest viable diff
- concrete verification
When invoked with handoff context, worker persists a JSON handoff artifact to .pi/handoffs/ for auditability before execution. The artifact includes objective, findings, target files, decisions, constraints, risks, verification guidance, and evidence.
worker accepts optional handoff context from manager, finder, or oracle:
- target files and related files
- findings and decisions
- constraints, risks, and suggested verification
When handoff context is provided, worker uses it as the starting map and avoids repeating broad discovery unless the context is missing or contradictory.
It may still use finder once if blocked by codebase uncertainty. It does not call oracle and does not recursively delegate.
Configuration is shared across nightmanager in ~/.pi/agent/nightmanager.json; see Configuration.
Example prompt:
Use worker to make the smallest possible fix and verify it
Use manager when a task may need multiple specialist phases, such as discovery -> diagnosis -> implementation.
Default orchestration policy:
- simple search ->
finder - simple reasoning/debugging ->
oracle - clear implementation ->
worker - implementation in unfamiliar code ->
finder->worker - ambiguous failure plus requested fix ->
oracle->worker - broad feature/change ->
finder-> optionaloracle->worker - ambiguous intent -> clarifying question
manager does not inspect or edit files directly. It delegates to specialized tools, passes structured handoff context between phases, and synthesizes the final result. Implementation is hard-gated through an internal handoff_to_worker tool, which requires non-empty objective, findings, target files, and decisions before Worker can run.
Handoff artifacts: When Worker receives handoff context, a JSON artifact is written to
.pi/handoffs/for auditability. See Notes.
Configuration is shared across nightmanager in ~/.pi/agent/nightmanager.json; see Configuration.
Example prompt:
Use manager to investigate the failing auth flow, choose the safest fix, implement it, and verify the result
The Nightmanager use one optional config file:
~/.pi/agent/nightmanager.json
If the file is missing, malformed, or a configured model cannot be found, the subagent falls back to the current Pi session model. thinking defaults to medium; avoid low for nightmanager.
{
"agents": {
"manager": {
"model": "provider/cheap-or-small-model",
"thinking": "medium"
},
"finder": {
"model": "provider/cheap-or-small-model",
"thinking": "medium"
},
"worker": {
"model": "provider/strong-model",
"thinking": "medium"
},
"oracle": {
"model": "provider/best-reasoning-model",
"thinking": "high"
}
}
}Recommended split:
managerandfinder: cheaper/smaller models.worker: stronger code-editing model.oracle: strongest reasoning model.
Use the optional config file at ~/.pi/agent/nightmanager.json to set models per tool. Missing or malformed config falls back to the current Pi session model.
{
"agents": {
"manager": { "model": "provider/cheap-or-small-model", "thinking": "medium" },
"finder": { "model": "provider/cheap-or-small-model", "thinking": "medium" },
"worker": { "model": "provider/strong-model", "thinking": "medium" },
"oracle": { "model": "provider/best-reasoning-model", "thinking": "high" }
}
}Keep manager and finder cheaper than worker and oracle when possible.
Install dependencies:
npm installRun the test suite:
npm testRun specific test layers:
npm run test:unit
npm run test:integration
npm run test:e2eTypecheck:
npm run typecheckBuild/typecheck (no dist output):
npm run buildRun from source:
pi -e ./src/index.tsRun the package entrypoint:
pi -e ./src/index.tsnightmanager/
package.json
src/
index.ts
tools/
core/
types/
tests/
unit/
integration/
e2e/
- The package uses one combined Pi extension entrypoint.
- The internal code is modular for testability and maintenance.
- The test strategy is layered: unit + integration + selective CLI smoke tests.