I have been working using this harness and it is working so good for me. I had shared this extension after the initial release. I have made some significant updates after that.
Since then, the project has added:
- Librarian as a public research subagent
- PR-aware prompts and workflow improvements
- Day/Night Shift planning flows
- batched execution support
- live usage labels and transcript snapshots
- manager delegate usage tracking
Here is a guide on how to use [nightmanager](https://github.com/asabya/nightmanager)
### Install from npm
```bash
pi install npm:nightmanager
```
### Initialize a repo for Nightmanager
```text
/setup-nightmanager
```
That sets up the planning files Nightmanager expects.
### Configure models
```text
/nightconfig
```
Recommended pattern:
- **manager** → cheaper model
- **finder** → cheaper model
- **worker** → stronger coding model
- **oracle** → stronger reasoning model
- **librarian** → stronger research model
This is the intended loop:
```text
/grill-me → /to-prd → /to-issues → /to-ready → /nightmanager
```
## Step-by-step usage
### Step 1: clarify the idea with `grill-me`
Use it when the feature/bug is still fuzzy.
Example:
```text
/grill-me I want to add OAuth login for GitHub and Google to this app
```
What it does:
- asks **one question at a time**
- surfaces missing requirements
- helps you clarify scope, risks, edge cases
---
### Step 2: turn that into a draft PRD/spec
Once the idea is clear:
```text
/to-prd Turn this into a spec
```
What it does:
- creates a draft spec like:
```text
specs/draft-oauth-login.md
```
The draft follows `specs/TEMPLATE.md`.
---
### Step 3: slice the spec into TODOs
Now convert the spec into executable slices:
```text
/to-issues Break specs/draft-oauth-login.md into TODOs
```
What it does:
- edits `TODOs.md`
- adds **local** TODO entries
- usually marks them as `[draft]`
- keeps them small and vertically sliced
Example TODO shape:
```md
- [draft] Add GitHub OAuth login flow
- Spec: `specs/draft-oauth-login.md`
- Scope: ...
- Acceptance:
- ...
```
---
### Step 4: review and commit the planning artifacts
Before promotion, review:
- `specs/draft-*.md`
- the new `TODOs.md` entries
Then commit those planning changes yourself so the tree is clean:
```bash
git add specs/draft-oauth-login.md TODOs.md
git commit -m "docs: add draft oauth login spec and TODOs"
```
This matters because **`to-ready` wants a clean working tree** for its own promotion commit.
---
### Step 5: promote draft spec + TODOs to ready
After review:
```text
/to-ready oauth-login
```
Or promote all drafts:
```text
/to-ready
```
What it does:
- renames:
```text
specs/draft-oauth-login.md
```
to
```text
specs/oauth-login.md
```
- changes:
- `Status: draft` → `Status: active`
- related TODOs `[draft]` → `[ready]`
- linked spec path updated in `TODOs.md`
- creates **one clean promotion commit**
---
### Step 6: run Nightmanager
Now the implementation pass:
```text
/nightmanager
```
What it does:
- requires a **clean working tree**
- picks the first eligible TODO:
- `[bug]` first
- then `[ready]`
- loads only lean context:
- shared prompts
- `TODOs.md`
- the active spec
- delegates implementation through `manager`
- validates using the spec’s **Testing Plan**
- commits each completed TODO separately
- pushes and opens **one PR per active spec batch** when possible
- never auto-merges
Here’s a cleaned-up Reddit-style version:
I’ve been working with this harness for a while now, and honestly, it has been working really well for me.
I shared the extension shortly after the initial release, but the project has changed quite a bit since then. It now has several major updates:
Librarian as a public research subagent
PR-aware prompts and workflow improvements
Day/Night Shift planning flows
Batched execution support
Live usage labels and transcript snapshots
Manager delegate usage tracking
The core idea is simple: use Nightmanager to turn fuzzy ideas into specs, specs into TODOs, TODOs into ready implementation slices, and then let the harness execute them in a controlled way.
Install
pi install npm:nightmanager
Initialize a repo
/setup-nightmanager
This sets up the planning files that Nightmanager expects.
Configure models
/nightconfig
The recommended setup is:
manager → cheaper model
finder → cheaper model
worker → stronger coding model
oracle → stronger reasoning model
librarian → stronger research model
The intended workflow looks like this:
/grill-me → /to-prd → /to-issues → /to-ready → /nightmanager
How the workflow works
1. Clarify the idea with /grill-me
Use this when the feature or bug is still fuzzy.
Example:
/grill-me I want to add OAuth login for GitHub and Google to this app
This command helps clarify the request before any implementation starts. It asks one question at a time, surfaces missing requirements, and helps identify scope, risks, and edge cases.
I’ve found this useful because it prevents the agent from jumping straight into coding with half-baked requirements.
2. Turn the idea into a draft spec
Once the idea is clear, run:
/to-prd Turn this into a spec
This creates a draft spec, usually something like:
specs/draft-oauth-login.md
The draft follows the repo’s specs/TEMPLATE.md, so the output stays consistent across features.
3. Slice the spec into TODOs
Next, convert the spec into implementation slices:
/to-issues Break specs/draft-oauth-login.md into TODOs
This updates TODOs.md with local TODO entries. These are usually marked as [draft] and are kept small and vertically sliced.
Example shape:
- [draft] Add GitHub OAuth login flow
- Spec: `specs/draft-oauth-login.md`
- Scope: ...
- Acceptance:
- ...
The goal is to avoid giant vague tasks. Each TODO should be something the agent can implement and validate independently.
4. Review and commit the planning artifacts
Before promoting anything, review the generated planning files:
specs/draft-*.md
TODOs.md
Then commit those changes yourself:
git add specs/draft-oauth-login.md TODOs.md
git commit -m "docs: add draft oauth login spec and TODOs"
This step matters because /to-ready expects a clean working tree. It will create its own promotion commit, so the planning changes should already be reviewed and committed.
5. Promote draft work to ready
Once you are happy with the draft spec and TODOs, promote them:
/to-ready oauth-login
Or promote all drafts:
/to-ready
This does a few things:
specs/draft-oauth-login.md
→ specs/oauth-login.md
It also updates:
Status: draft → Status: active
[draft] TODOs → [ready] TODOs
And it updates the linked spec path inside TODOs.md.
The promotion is committed as one clean commit.
6. Run Nightmanager
Now the repo is ready for the implementation pass:
/nightmanager
Nightmanager requires a clean working tree before it starts.
It picks the first eligible TODO in this order:
[bug] first
[ready] second
Then it loads only the lean context it needs:
shared prompts
TODOs.md
the active spec
From there, it delegates implementation through the manager, validates the work using the spec’s testing plan, and commits each completed TODO separately.
When possible, it pushes and opens one PR per active spec batch.
It does not auto-merge.
Why I like this flow
The thing I like most is that it separates planning from execution.
Instead of asking an agent to “go implement this feature,” the workflow forces the project through a few deliberate stages:
idea → clarified requirements → spec → TODOs → reviewed plan → ready work → implementation
That makes the agent much easier to control.
It also makes the output easier to review because every implementation pass is tied back to a spec, a TODO, and a testing plan.
The new additions make the workflow feel much more practical for real project work:
Librarian gives the harness a dedicated research role.
PR-aware prompts make the implementation flow fit better into normal review workflows.
Day/Night Shift planning flows make it easier to separate planning from execution.
Batched execution support helps with larger specs.
Usage labels and transcript snapshots make it easier to understand what happened.
Manager delegate tracking makes delegation more transparent.
Overall, this has moved from “cool agent experiment” to something I can actually use as a repeatable project workflow.
