npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@nhalm/pi-specd

v1.1.1

Published

Spec-driven development workflow for pi

Readme

pi-specd

Automates specd workflow iterations in pi. Each iteration runs in a fresh context to avoid context window bloat.

Overview

specd is a spec-driven development framework. You describe what to build, agents implement autonomously, and audits verify against specs. This extension automates the implementation loop in pi.

Quick Start

Install from npm:

pi install npm:@nhalm/pi-specd

Or install from GitHub:

pi install git:github.com/nhalm/pi-specd

Initialize specd in your project:

# In pi, in your project directory
/specd:setup

Existing nhalm/specd projects can migrate instead:

/specd:migrate

Then plan and run the loop:

# Plan (interactive — happens in the parent pi chat)
/specd:plan

# Run the loop (automated)
/specd:loop

# Check status
/specd:status

Concepts

| Concept | File | Purpose | Committed? | | ---------------- | ---------------------- | -------------------------------------- | -------------- | | Specs | specs/*.md | What to build (behavior + contracts) | Yes | | Agent guidelines | AGENTS.md | How agents should approach the project | Yes | | Project facts | PROJECT.md | Build/test commands, conventions | Yes | | Work queue | specd_work_list.yaml | Concrete tasks for agents | No (ephemeral) | | Review queue | specd_review.yaml | Ambiguous findings awaiting decision | No (ephemeral) |

/specd:setup creates all of the above and adds the ephemeral files to .gitignore.

How a run looks

Each command runs work in a separate sub-agent session — a brand-new pi agent with its own conversation and context. That sub-agent runs to completion and disposes itself; nothing it sees or says leaks back into the parent pi chat unless the extension chooses to surface it.

How that sub-agent's progress is shown depends on whether you're running pi inside tmux.

Inside tmux: live side pane

When pi detects $TMUX, every sub-agent run opens a horizontal side pane (tmux split-window -h) running a small viewer process. That viewer uses pi's own UI components — the same ones pi's interactive mode renders — so the side pane looks exactly like a regular pi chat: tool-call cards, syntax-highlighted code, streaming markdown, the works.

The pane is not just a log. It's interactive:

  • Sub-agent activity (every tool call, every assistant message, every thinking block) renders into the pane in real time.
  • The pane has its own input box pinned to the bottom. Type into it and press Enter to talk to the sub-agent mid-run — your message gets steered into the running session (interrupting the current turn) or queued as the next prompt if it's between turns. Useful for nudging the agent: "actually skip the changelog removal", "delete that file too", "answer in JSON instead", etc.
  • For /specd:loop, the same pane is reused across all phases — review intake, every implement cycle, audit. Activity history scrolls; you can scroll back through completed cycles.
  • The parent pi chat stays usable, but typing there talks to the parent agent, not the sub-agent. Cross-pane discipline matters: type into the child pane to steer the child; type into the parent pane for parent-level concerns.

Outside tmux: rolling-log widget

If you're not running pi inside tmux, the side pane isn't available. Instead, the sub-agent's recent activity appears as a multi-line widget above the editor in the parent pi pane: tool calls with their args, file paths, streaming response snippets. The last six entries are kept; older activity scrolls off. You can't steer the sub-agent in this mode — that requires the side pane's input box.

Ctrl+C and abort

While a sub-agent is running, Ctrl+C in the parent pi pane aborts the in-flight sub-agent. The side pane has its own input box, but it isn't wired to abort — Ctrl+C typed inside the side pane is just keyboard input destined for that input box. (Escape used to be an abort key as well; it was removed.)

  • For /specd:migrate, an abort tears the side pane down immediately and cancels the migration.
  • For /specd:loop, an abort stops the current phase and pi shows a confirm dialog: Continue with the loop? Choosing yes moves on to the next phase (next cycle, audit, etc.); choosing no ends the loop entirely. This lets you skip a stuck implement cycle without scrapping the whole loop.

When a sub-agent finishes

/specd:migrate:

  • Side pane closes.
  • The sub-agent's structured summary (files modified / created / deleted / caveats / technical notes) is handed to the parent pi agent via a hidden trigger message. The parent agent then relays the summary to you in its own voice in the main pi chat. The trigger itself is not displayed; you only see the parent's response.

/specd:loop:

  • Pane stays open after the loop completes (audit included), so you can scroll back through everything that happened. When a run finishes cleanly, the parent sends a specd:done control event and the pane renders a "complete — close pane to dismiss" banner; the pane stays open until you close it. A 5-minute fallback fires if the parent crashes without sending specd:done.
  • Final status appears in the main pi chat.

Sub-agent tool surface

Sub-agents are restricted to the standard built-in tools: read, bash, edit, write. Extension tools that pi may have loaded for the parent (e.g. @mjakl/pi-subagent's subagent) are intentionally hidden from the sub-agent so it doesn't try to delegate to agents that aren't configured in its context.

Commands

/specd:setup

Initialize specd in a new project. Detects build/test commands and conventions.

/specd:migrate

Migrate an existing nhalm/specd project to specd-loop format (removes spec versions, status lifecycle, and changelogs). Runs in a sub-agent. After it finishes, the parent pi agent delivers a summary in chat. Tmux side pane is interactive while it runs.

/specd:plan

Interactive planning. Runs in the parent pi session itself, not in a sub-agent — the planning brief is injected as a user message and pi takes a turn, asking clarifying questions, writing specs, and updating specd_work_list.yaml. There's no side pane for plan.

/specd:loop [options]

Run the full automated loop: review intake → implement (looped) → audit. Each phase runs as its own sub-agent (fresh context per phase / per cycle). One side pane is reused for all phases.

| Option | Description | | ---------------- | ---------------------------------------------- | | --skip-audit | Skip the audit phase | | --max-cycles=N | Override max implement iterations (default: 5) |

  • Halt on no-commit: if an implement cycle finishes but the agent didn't land a new commit (verified via git rev-list HEAD ^${headBefore} --count ≥ 1, which also rejects an --amend of the previous commit), the loop halts entirely — it does not skip the item. The work item stays incomplete and the loop surfaces a recovery message pointing at git status, blocked hooks, and the per-phase transcript path. Re-run /specd:loop to retry.

/specd:status

Show the work list: ready items, blocked items, pending reviews, and the next action to take.

Review items

Any of the three loop phases — review intake, implement, or audit — can produce a finding when it hits an ambiguous situation. When that happens the loop pauses and surfaces the finding. Edit specd_review.yaml and add a decision: field to each finding. The path to the file is printed when the loop pauses.

Common decisions:

  • Fix the code → adds a work item to fix the code
  • Update the spec → updates the spec, then adds a work item
  • Ignore → deletes the finding, no action
  • Keep as is → deletes the finding, code is correct

When you run /specd:loop again, the review intake interprets your decisions and updates accordingly.

Requirements

  • pi (@mariozechner/pi-coding-agent) installed and configured.
  • The working directory must contain AGENTS.md, PROJECT.md, and specs/README.md. /specd:setup creates all three.
  • For the side-pane viewer experience, pi must be running inside a tmux session. Otherwise the rolling-log widget fallback is used (no in-flight steering).

Troubleshooting

  • "Cannot verify commits: this directory is not a git repository" — the loop verifies progress via git rev-list, so the project must be a git repo. Run git init (and make at least one commit) before re-running /specd:loop.
  • Cycle ended without a commit — the loop halts and surfaces a recovery hint. Check git status for leftover staged or unstaged changes; check whether a pre-commit / commit-msg hook blocked the commit; and read the full transcript at the path printed in the recovery message. Fix the underlying issue, then re-run /specd:loop to pick up the same item.
  • Spec file missing — a work item references specs/<name>.md but the file doesn't exist. Run /specd:plan to (re)create the spec, or remove the work item from specd_work_list.yaml.
  • Version-mismatch warning at preflight — the project's .pi-specd file records a different extension version than the installed extension. Re-run /specd:setup to refresh the marker (and pick up any new template behavior).
  • Per-phase log files — every phase (review intake, each implement cycle, audit) writes its full transcript to ${TMPDIR}/specd-loop/<phase>-<timestamp>.log (on macOS, TMPDIR is something like /var/folders/.../T; on Linux it's typically /tmp). The loop prints the exact path when it surfaces an error, but they're useful for any post-hoc investigation.
  • Sub-agent crash diagnostics — set SPECD_DEBUG=1 (e.g. SPECD_DEBUG=1 pi) to also write any sub-agent unhandled rejection or uncaught exception to ${TMPDIR}/specd-debug.log. Off by default so normal runs don't leave files in /tmp.
  • Pinning a sub-agent model — set SPECD_MODEL=<model-id> before launching pi to override the inherited model. Example: SPECD_MODEL=claude-sonnet-4-6 pi. Useful for deterministic loops. Accepts a bare model id or canonical provider/modelId. If the reference is empty or doesn't unambiguously match a configured model, sub-agents fall back to pi's currently-configured model.
  • Loop crashed mid-cycle — when /specd:loop next runs, it'll detect the crash and ask whether to resume. Saying yes finishes the cycle (marks the in-flight item complete and continues with the next); saying no discards the checkpoint and starts fresh. The checkpoint lives at .specd-loop-checkpoint.json (gitignored).

License

MIT