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

pi-runline

v0.6.0

Published

Code mode for pi

Downloads

1,600

Readme

pi-runline

Code mode for pi.

An extension that plugs runline into coding agents. The agent gets one native tool, in-sandbox action discovery, a fuzzy picker for choosing which of the 188 built-in plugins to expose, and a guided credential prompt for the ones it hasn't seen before.

Install

pi install pi-runline

How the agent uses it

On session start, if the current working directory has a .runline/ (or one is configured globally — see below), the extension registers a single tool and injects a short primer naming the enabled plugins:

  • execute_runline — run JavaScript in runline's QuickJS sandbox. Every enabled plugin is a top-level global; return surfaces the result; logs are captured.

Discovery happens inside the sandbox, not as a separate tool. The agent uses an actions object to explore the catalog without paying for a full schema dump in its system prompt:

actions.list()                  // every "plugin.action" path
actions.list("github")          // filter to one plugin
actions.find("create issue")    // ranked fuzzy search (MiniSearch)
actions.describe("github.issue.create")
// → { path, plugin, action, description, signature, inputs }
actions.check("github.issue.create", { owner: "a" })
// → { ok, missing, unknown, typeErrors, signature }   (does NOT call the action)

Unknown paths throw with did-you-mean suggestions, so typos are self-correcting. Recommended flow: finddescribecheck → call.

Calling actions is unchanged — plugin globals and actions.<plugin>.<action>(...) are the same call:

return await github.issue.create({ owner: "acme", repo: "api", title: "Bug" });

/runline-plugins — the picker

Typing /runline-plugins in a pi session opens a fuzzy multi-select over all 188 built-in plugins.

╭─────────────────────────────────────────────╮
│ runline plugins · 5/188 enabled             │
│ type to filter · space toggle · ^A toggle   │
│                                             │
│ filter ❯ gith                               │
│                                             │
│ ❯ ◉ github       34 actions                 │
│   ◯ gitlab       17 actions                 │
│   ...                                       │
╰─────────────────────────────────────────────╯

Keys: type to filter · ↑/↓ to move · space to toggle · Ctrl-A to toggle all visible · enter to save · esc to cancel.

After saving, any newly-enabled plugin with a connectionConfigSchema that doesn't already have a connection (and can't be fully resolved from env vars) will prompt you field-by-field for credentials. Values are written to .runline/config.json under connections[].

Configuration

Per-project — .runline/config.json

{
  "showStatus": true,
  "piPlugins": ["github", "slack", "linear"],
  "connections": [
    { "name": "github", "plugin": "github", "config": { "token": "ghp_..." } }
  ]
}
  • piPlugins — the allowlist the extension uses. If missing or empty, nothing is exposed to the agent and the status bar says runline: /runline-plugins to enable.
  • showStatus — set to false to silence the status bar entry for this project.
  • connections — standard runline connections (shared with the CLI and SDK).

Global — ~/.pi/agent/runline.json

{ "project": "~/Projects/my-runline-project" }

Fallback used when the current cwd has no .runline/ anywhere up the tree. Useful when you want the runline tools available in every pi session without scattering .runline/ folders.

How plugin allow-listing works

The extension deliberately exposes nothing by default. That's on purpose — 2,410 actions is a lot of context budget. You pick the plugins that matter for a given project, commit the allowlist to .runline/config.json, and the agent only ever sees the ones you enabled in its primer.

Note that the QuickJS sandbox itself still registers every runline plugin as a global (and actions.list() will surface them all), so in principle an agent could guess and call a disabled plugin. In practice the primer only advertises the allowlisted ones, and unconfigured plugins error out at first action call anyway. Plumbing the allowlist into the sandbox registry is on the roadmap.