Sno Station
Sno Station is your agents' workstation: open-source software that turns the AI agents you already run into one squad on your own machine. Two heads are better than one, and they get better with every
brings agentic superpowers to the pane-driven.
Translation pending
PluginsShell · JavaScriptGitHub @transparent-pegasusSelf-installOwner unconfirmed
Paste into Claude or ChatGPT for installation instructions suited to your environment.
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Installable projects can be verified without a deployment domain. Use GitHub sign-in for a personal repository, or the repository verification file above for an organization repository.
Ask about other verification options
Loading the full README. The saved excerpt is shown below.
herdrpowers is a development framework for AI coding agents running inside herdr. It layers structured skills and multi-phase workflows on top of any repository, and delegates the work — implementation, test authoring, code review — to idle sibling agent panes, not to in-process subagents (the single exception: a review whose configured mode is orchestrator, which the orchestrator spawns a fresh subagent for).Read the full README ↗herdrpowers is a development framework for AI coding agents running inside herdr. It layers structured skills and multi-phase workflows on top of any repository, and delegates the work — implementation, test authoring, code review — to idle sibling agent panes, not to in-process subagents (the single exception: a review whose configured mode is orchestrator, which the orchestrator spawns a fresh subagent for).
The development cycle derives from obra/superpowers — brainstorming, plan writing, TDD, systematic debugging, worktrees, review — restructured so every dispatch goes through a pane, and wrapped in a command-driven workflow layer. See What Changed from Superpowers.
agent: / agents:); there is no prefer-different-type heuristic. There are no named test-engineer / code-reviewer personas — the property comes from the reset, not from the label.test-authoring assignment decides: delegate puts a task's tests in a pane that works from the same brief in a worktree at the pre-implementation commit and never sees the code — RED is structural there; implementer gives RED-GREEN-REFACTOR to the implementing pane, and the reviewers audit that test code as the only independent check. fix-round-test-authoring answers the same for a fix round. Assertions come from the requirements, never from the code, the RED run is quoted in the report, and the report names which pane wrote the tests.composer-submit.sh, completion is detected with a unique marker, and results are handed over as files — never reconstructed from pane scrollback.<BASE_BRANCH>, one implementation pane per worktree.Herdr must be installed and support herdr --skill. The pack reads its operating guide from the installed binary, so no Herdr repository clone or separate skill installation is needed.
HERDR_ENV=1 — the delegation skills verify this and stop if it is missing. The planning, TDD, debugging, and verification skills work anywhere; only delegation needs herdr.
Before an agent CLI is used as a delegation target for the first time (and after every upgrade), verify it can be driven at all:
bash skills/using-herdr-sibling-panes/scripts/probe-composer.sh "$PANE"
Composer key bindings differ per CLI and change across releases: ctrl+c quits Codex from an idle composer, and ctrl+enter does not submit there at all.
Claude Code
/plugin marketplace add transparent-pegasus/herdrpowers
/plugin install herdrpowers@herdrpowers
Codex
codex plugin marketplace add https://github.com/transparent-pegasus/herdrpowers
codex plugin add herdrpowers@herdrpowers
Cursor
cursor-agent plugin marketplace add https://github.com/transparent-pegasus/herdrpowers
Or install from this repository via the Cursor Marketplace ("Import from Repo").
OpenCode 2
opencode plugin add git+https://github.com/transparent-pegasus/herdrpowers.git
Use opencode2 in place of opencode if that is the name of your v2 binary.
The same package also supports OpenCode 1.18.29+, using its v1 installer:
opencode plugin -g herdrpowers@git+https://github.com/transparent-pegasus/herdrpowers.git
Both versions expose all 16 skills and the seven /herdrpowers:* workflows.
See OpenCode setup for local checkout configuration and verification.
Any other tool — check the pack in or vendor it as a submodule, and point the tool at the directories:
git clone https://github.com/transparent-pegasus/herdrpowers
cp -r herdrpowers/skills herdrpowers/commands .claude/ # or .agents/, or wherever your tool looks
Then ask the agent to "follow the workflow in commands/full_cycle.md" or "use the skill at skills/<name>/SKILL.md". docs/instruction_snippet.md has a paste-ready block for the repo's instruction files.
/init once per repository/herdrpowers:init
Plugin files are read-only, so repo-specific values are never written into the pack. /init detects the repo's tooling, confirms the values with you, and writes two things into the target repo:
Herdrpowers Configuration section in CLAUDE.md / AGENTS.md — every skill and command resolves its <KEY> placeholders (<BASE_BRANCH>, <REPORT_DIRECTORY>, <TARGETED_TEST_COMMAND>, <PLAN_PATH_PATTERN>, …) from there;.herdrpowers/config.yaml — a role list, the delegation defaults, plus the role assigned to every delegation task. Nothing is hard-coded: implementation, tests, chores, verification, and each of the five reviews are all reassignable, overriding the pack's shipped defaults key by key.roles: # role -> agent type(s)
coder: { agent: codex }
generalist: { agent: orchestrator } # the pane the user typed into
reviewer: { agents: [codex, cursor] } # a list role: one delegation per entry
# reviewer: { agents: [codex, cursor@Grok 4.7, cursor@Muse Spark 1.3] } # agent@model pins a model
delegation:
pane_scope: tab # never delegate outside the orchestrator's tab
execution: parallel # /full_cycle runs the plan's tracks concurrently
assignments: # task -> role + where it runs
complex-coding: { role: coder, mode: delegate }
chores: { role: generalist, mode: orchestrator }
test-authoring: { role: coder, mode: delegate } # a pane that never sees the code
verification: { role: generalist, mode: orchestrator }
task-review: { role: reviewer, mode: delegate, enabled: true } # two reviews, one per agent type
fix-round-re-review: { role: reviewer, mode: delegate, enabled: false } # off: named in the report
mode is delegate (a fresh pane of that role), orchestrator (this pane — a work task inline, a review in a fresh subagent the orchestrator spawns), or implementer (the pane that already owns the task). Reviews also take enabled; work tasks are never disabled — mode: orchestrator is how one stops being delegated.
Re-run /init any time to change them. Two things stay fixed regardless: review independence is the reset session (not pane identity), and every non-default assignment or disabled review is named in the final report.
Then start a feature with /herdrpowers:full_cycle, or break it up with plan → execute / execute_parallel. For small changes use quick. To run the same cycle with every review gate forced on regardless of the enabled values above, use strict_full_cycle.
Plugin installs update through the marketplace (/plugin marketplace update in Claude Code, codex plugin marketplace upgrade for Codex). The repo-local Herdrpowers Configuration section and .herdrpowers/config.yaml survive updates untouched, because the pack never stores repo-specific values in its own files. Checked-in copies update by diffing the new skills/ / commands/ against the copy — see changelogs/.
The payload is a single tree at the repository root, discovered by each platform's plugin convention:
| Platform | Skills | Workflow commands |
|---|---|---|
| Claude Code | skills/ (auto) | commands/ as namespaced slash commands |
| Codex | skills/ | commands/ (surfaced as skills) |
| Cursor | skills/ (auto) | commands/ as slash commands (auto) |
| OpenCode 1.18.29+ / 2 | skills/ (registered by the plugin) | commands/ as namespaced slash commands, registered by the plugin |
| Aider / Gemini CLI / others | read skills/<name>/SKILL.md directly | read commands/<name>.md directly |
Roles bind to agent types, not to platforms: the orchestrator can be any agent CLI, and Coder / Generalist / Reviewer resolve to whatever the repo's .herdrpowers/config.yaml says, falling back to skills/orchestration/roles.yaml. Reassign any delegation task, change where it runs, or turn a review off in the repo file — the pack's defaults stay untouched. An agent type can also be pinned to a model as agent@model (cursor@Muse Spark 1.3): herdr reports a pane's agent type but not its model, so the pack reads the model from the footer the CLI draws, and two panes of one CLI on different models count as different reviewers.
skills/ # 16 skills (single tree, platform-neutral wording)
herdr/ bootstrap for the installed binary's herdr --skill guide
orchestration/ routing, roles.yaml defaults, delegation assignments, fallbacks
using-herdr-sibling-panes/ the delegation transport + composer scripts
pane-driven-development/ the per-task loop over panes + brief templates
… planning, TDD, debugging, review, worktrees, docs
commands/ # Workflows: init, plan, execute, execute_parallel, full_cycle,
# strict_full_cycle, quick
docs/ # Human-facing framework docs + instruction-file snippet
changelogs/ # obra/superpowers refresh history + pack-native release notes
.claude-plugin/ # Claude Code plugin + marketplace manifests
.codex-plugin/ # Codex plugin manifest
.cursor-plugin/ # Cursor plugin manifest
.opencode-plugin/ # OpenCode plugin: v1 config hook and v2 setup/transforms
package.json # OpenCode package manifest (main → .opencode-plugin/index.mjs)
.agents/plugins/ # Codex marketplace manifest (fixed location per Codex convention)
NOTICE # Third-party attribution and retained MIT notices
roles.yaml and fallbacks./init, /full_cycle, /strict_full_cycle, /plan, /execute, /execute_parallel, /quick.Superpowers is skill-triggered and subagent-driven: skills fire on their own as the conversation goes, and subagent-driven-development dispatches each task to an in-process subagent that implements, tests, commits, and self-reviews before a reviewer subagent sees it. herdrpowers keeps that methodology and changes who runs it and how it is started.
Dispatch: panes, not in-process subagents. Every dispatch goes to an idle sibling agent pane over the composer, so the worker is a separate agent CLI process — its own context, its own model, its own vendor. That is the whole reason the rest of this list exists: a subagent is a call inside one session, a pane is another agent you have to talk to over a terminal, and it can be a different product than the orchestrator.
| Superpowers | herdrpowers | |
|---|---|---|
| worker | in-process subagent | idle sibling herdr pane (any agent CLI) |
| task loop | subagent-driven-development | pane-driven-development |
| parallel work | dispatching-parallel-agents | panes, bounded by idle panes and worktrees |
| entry point | skills trigger themselves | commands/ workflows, plus the same skills |
| routing | fixed in the skill | .herdrpowers/config.yaml over roles.yaml |
| who writes tests | the implementer, always | the test-authoring assignment |
| review | one reviewer subagent | a role bound to a list of agent types: one review per entry |
A command-driven workflow layer. Superpowers has no commands/. herdrpowers adds seven: init, plan, execute, execute_parallel, full_cycle, strict_full_cycle, quick — so a cycle is something you start and can stop mid-way, rather than something that unfolds from skill triggers. /init is what makes the pack repo-agnostic: plugin files are read-only, so every repo-specific value lives in the target repo instead of in the pack.
Test authorship became a setting. Superpowers has the implementer write its own tests. herdrpowers makes that the test-authoring assignment: delegate puts a task's tests in a different pane working from the same brief in a worktree at the pre-implementation commit, which never sees the implementation — RED is structural rather than disciplined. implementer keeps the Superpowers behaviour, and then the reviewers auditing that test code are the only independent check. fix-round-test-authoring answers the same question for a fix round. Either way the report names which pane wrote the tests.
Review independence comes from the session reset, not from a persona. Superpowers dispatches a named reviewer subagent per review. herdrpowers has no reviewer persona at all: composer-submit.sh resets the target session before every delegation, so the reviewer is a fresh context by construction, and the same physical pane may later review work it once wrote. Roles bind to agent types, so a reviewer role listing two CLIs gives a genuine cross-vendor double review. The same goes for brainstorming's builder check, where Superpowers has a fresh subagent read a project's full design as the person who will build it: here it is the plan-review gate, so those readers are panes too.
Everything degrades honestly. Outside herdr, or with no idle pane, the work runs inline — and the final report says which steps were not delegated, which independence was lost, and which assignments the repo changed.
Skills dropped from upstream: dispatching-parallel-agents and subagent-driven-development (replaced by pane delegation and pane-driven-development), and using-superpowers (the pack's own meta-skill). Not carried yet: diagnosing-superpowers (upstream v6.4.1), which needs its own pane-native design — the decisions a port must make first are in its port policy. Added: herdr, orchestration, using-herdr-sibling-panes, pane-driven-development, update-docs. Upstream's hooks/, scripts/, tests/, and package.json are not carried — the payload is skills and commands only.
This repository includes GitHub issue and pull-request templates under .github/ that require disclosure of the authoring environment: model, harness, harness version, installed plugins, and human review status. If an agent produced a contribution, say so plainly. If a human wrote it by hand without agent assistance, say that instead.
Every refresh from obra/superpowers is recorded in changelogs/, alongside pack-native release notes; the tracked upstream commit is in changelogs/UPSTREAM_SHA.
MIT License. This pack retains material derived from MIT-licensed packs, chiefly obra/superpowers; see NOTICE for the full attribution chain. Herdr is installed separately, and its official guide is read from herdr --skill. Earlier versions that bundled Herdr files retain their Apache-2.0 license.