Claude Code plugins for building software with agents.
doperpowers takes a change from a rough idea to a reviewed, merged branch.
sminos makes your sessions, on one machine or many, work as a team.

Install · What's inside · What to expect

---

doperpowers: one method for every change

flowchart LR
    grill["<b>brainstorming</b><br/>a design you approve"]
    grill -- "well scoped" --> here["built in<br/>the session"]
    grill -- "needs a spec" --> spec["<b>execspec</b><br/>one living spec"]
    spec -- "one milestone" --> inorder["run in order"]
    spec -- "several" --> fresh["a fresh subagent<br/>per milestone"]
    here --> review["<b>review-code</b><br/>another model family"]
    inorder --> review
    fresh --> review
    review --> merged([merged])

Loading

• It asks before it builds. brainstorming explores what the work should be and grills you in batched rounds while you are there, then presents the design. Nothing that commits a product or design decision is built before you approve it.
• One living spec, when the work needs one. execspec writes a single document that carries the design with its reasoning, acceptance as observable behavior, and the plan of work as milestones. It is reviewed before it runs and kept current while it runs: progress, decisions, surprises, and a retrospective at the end.
• The shape follows the size. A well-scoped change is built in the session. A one-milestone spec runs in order. Several milestones each go to a fresh subagent (subagent-driven-execution), built test-first and reviewed at every dependency boundary, so your session stays the design session.
• Review by a different model. review-code sends the finished branch to an independent reviewer from another model family, sized by the stakes: one reviewer for a focused diff, a multi-lens panel with a binding verifier for a large one.
• It keeps going. Between your approval and the merge the agent doesn't stop to ask what's next. It comes back when it meets a decision the design didn't cover.

You don't call any of this by hand: every skill says when it applies, and the agent checks before it starts.

sminos: your sessions, as a team

Run more than a couple of Claude Code sessions and they start stepping on each other: two of them edit the same file, one waits on a fact another already found, and you become the message bus. sminos makes every session in a project a member that knows the others.

$ sminos list
api
  parser  [7a11ce01]  interactive  busy  @macbook  api@parser  in charge: the new parser
  ci      [a45b97a3]  interactive  idle  @mini     api@main    in charge: CI and releases
  e2e     [2b52e44a]  seat         busy  @macbook  api@e2e     in charge: the flaky e2e suite
you: parser [7a11ce01]

$ sminos say "@ci the parser rewrite renames the tokens table; hold the release"

flowchart LR
    you((you))
    subgraph macbook
        parser["parser"]
        e2e["e2e (a spawned seat)"]
    end
    subgraph mini
        ci["ci"]
    end
    parser <-- "say @ci" --> ci
    parser -- "spawn, watch, steer" --> e2e
    parser -. "a report, and questions<br/>that don't block" .-> you

Loading

• Who's here, and what they own. sminos list shows every session in the project: its machine, branch, state and the line it is in charge of. A project is every clone and worktree of one repository, on every enrolled machine.
• Messages instead of copy-paste. sminos say "@parser …" reaches that session wherever it runs; @all, a machine, or the whole org work too.
• Spawn and drive. sminos spawn starts a background session (a seat) on a task; watch, steer, interrupt, answer and decide reach into one that is running on the same machine. Messages cross machines; these controls don't.
• Every commit names its author session. Commits and PRs end with a Sminos-Session: line, and sminos who <commit|PR> finds that session and how to reach it.
• Questions that don't block. A session asks you through an async question tool and keeps working until you answer.
• Catch up in one read. The manager skill follows the sessions you name and tells you what they need from you and what you missed.

to-human comes with it: a session writes you a report, message by message, and the terminal folds its working record (tool calls, scratch notes) behind a button, so you read what the session says to you instead of its transcript.

Install

In Claude Code:

/plugin marketplace add SSFSKIM/doperpowers
/plugin install doperpowers@doperpowers
/plugin install sminos@doperpowers
/plugin install to-human@doperpowers

Then, in ~/.claude/settings.json, turn on function hooks (sminos's bridge and question tool, and the to-human view, are built on them) and put the plugins' hooks in order:

{
  "env": { "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1" },
  "prependPlugins": ["to-human@doperpowers", "sminos@doperpowers", "doperpowers@doperpowers"],
  "outputStyle": "doperpowers:to-human"
}

outputStyle is optional: leave it out to keep reading the transcript. Spanning machines takes one more step, a git mirror or a desk hub: see sminos's setup guide. Updating, and how this coexists with other marketplaces: docs/INSTALL-doperpowers.md.

What to expect

This is one person's daily setup, published as it runs. It moves fast (the plugin version is past 7.200) and is shaped by how its maintainer works, so a few things are worth knowing up front:

• Some agents are pinned to models served through a local gateway. The review-code reviewers and a few others run on another model family (sol, astra). Without that gateway, point the model: lines in agents/ at models you have, and do the same for the LADDER in the review-code panel workflow (code-review.js), which pins them itself; its deriverModel, finderModel and verifierModel arguments override a lane per call.
• Built for Claude Code. sminos, to-human and the hooks are Claude Code plugins. The skills also ship as a local Codex plugin, with ports of the agent definitions; upstream's other harness adapters were dropped.
• The board is a backlog. issue-tracker keeps deferred work as GitHub issues that a session takes when you name one. The unattended pipeline that once dispatched agents onto tickets is dormant: a session working with you proved faster and more reliable.

Every skill, agent and hook is listed in What's inside.

Credits

doperpowers started as a fork of obra/superpowers by Jesse Vincent and has since been rebuilt around the living spec, cross-model review and multi-session work. The brainstorming skill's grill comes from Matt Pocock's grill-me. This repository carries no license of its own; NOTICE reproduces the MIT notices of both projects.

Skills here are behavior-shaping code, not prose: changing one changes what the agent does, so changes go through the writing-skills skill and get tested. Issues and ideas: github.com/SSFSKIM/doperpowers/issues.