doperpowers

A methodology your coding agent actually follows — not a pile of prompts, but a set of skills that trigger themselves at the right moment and keep the agent honest from first idea to merged branch.

                     d o p e r p o w e r s

   idea ─▶ grill ─▶ design you sign off ─▶ spec ─┬─▶ ONE MILESTONE · runs in order from the spec itself
                                                 └─▶ SEVERAL       · a fresh subagent per milestone, reviewed at each frontier
   board · the backlog: you name a ticket, the session takes it through the same method

Most agent scaffolding is a single linear pipeline: you talk, it plans, it codes. doperpowers sizes the work first. Every change starts with a grill that closes the design questions while you are present, then a design you approve. From there the shape follows the reader: a change one agent builds in the session goes straight from the approved design to code; anything else gets one spec that carries its design with its reasoning, its acceptance, and its plan of work told as milestones. One milestone runs in order from the spec; several run a fresh subagent per milestone, reviewed at every boundary. How much independent review the work gets is a separate call, made from its stakes rather than its size. Either way the agent runs without stopping until it meets a decision the design did not cover, and that comes back to you.

Because every skill declares when it applies, you don't invoke any of this by hand. The agent checks for a relevant skill before it starts a task, and the right workflow just happens.

---

One method, sized by the work

Every change enforces the same non-negotiables — design before code, tests before implementation, evidence before "done." What varies is the shape, and the shape follows the size.

One unit — work one agent can reliably own. The agent refuses to jump straight to code. It interviews you (brainstorming) and turns the conversation into a design you approve; when the work is complex and sizable enough that reliable execution needs a spec, it writes the design up as a living spec that carries its own plan of work and progress (execspec), then builds it in order without stopping for next steps. You approve the design; an independent spec review and a whole-branch review gate the rest.

Several units, or taste mid-flight — work that needs more than one agent-ownable milestone, or your judgment while it is built. The same grill and the same spec: its plan of work is told as milestones an executor can own from the document and the code — files, interfaces, the decisions already settled, proof; no line numbers, no steps — and each one runs through a fresh subagent, reviewed at dependency frontiers — spec compliance, then code quality (subagent-driven-execution) — with the whole branch reviewed at the end.

Later — the backlog. Work deferred out of a session lands as a ticket on the board (issue-tracker, GitHub issues or an Arkho board service), and waits there until a session takes it — one you name it to, or one that picks up a ticket ready to build on its own — through the same method. Sessions working in one project see each other, message each other and you, and hand work between them (sminos). Product feedback can feed the board directly (triaging-feedback). The board once dispatched its own Architect, Executor and review workers onto tickets with nobody watching; that pipeline is dormant (docs/doperpowers/specs/2026-10-18-board-dispatch-dormant.md): unattended work proved slower and less reliable than a session working with you.

---

Install

Claude Code

doperpowers ships as a Claude Code plugin from a self-hosted marketplace in this repo. It installs side by side with anything else you have. The marketplace carries four plugins: doperpowers (the skills and agents), sminos (the project family: sessions that see and message each other and you, across machines; its CLI, the bridge and the async question tool), to-human (the report view of a session under the to-human output style; it installs sminos with it) and devcloud (opt-in, the cloud dev host and its secrets guard).

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

Their hooks run in the order your settings give them. Put this in ~/.claude/settings.json so the report view sees every row first and sminos's bridge sits outside every other plugin's hooks (a secrets guard's among them):

"prependPlugins": ["to-human@doperpowers", "sminos@doperpowers", "doperpowers@doperpowers"]

Add it with the owner/repo form above, not a raw URL to marketplace.json. The plugin's source is the repo root, so Claude clones the whole repository for that path to resolve.

Update later:

/plugin marketplace update doperpowers
/plugin install doperpowers@doperpowers

Full details, including how it coexists with other marketplaces: docs/INSTALL-doperpowers.md.

Codex

A Codex plugin manifest ships in .codex-plugin/ for local installs. (The external sync to the Codex plugins repository was retired in v7.23.0; the script lives in git history if ever needed again.)

For native subagents, install the Codex agent definitions. These port the Claude agent contracts to Codex and replace the companion runtime inside Codex; Claude's registered agents and companion remain available.

---

The skills

Seventeen skills, grouped by what they're for. Each one auto-triggers from its description; you rarely name them yourself.

Shape the work

• brainstorming — Socratic design refinement before any code is written
• execspec — after the approved design: write the living spec, review it, and run it — one milestone in order, several through a fresh subagent each
• architecture-mapping — author and maintain ARCHITECTURE.md, the repo's spine map with citable invariants
• decomposing — carve a large goal into a tree of well-scoped tickets
• organizing-sprints — turn a pile of raw observations into the next sprint
• transcribing-meeting-recordings — diarized, visually grounded transcripts from meeting recordings

Build it

• test-driven-development — RED → GREEN → REFACTOR, no code before a failing test
• subagent-driven-execution — one fresh subagent per milestone, reviews at dependency frontiers

Keep it honest

• review-code — the Claude-native code-review path: effort-routed to registered reviewer agents on GPT through the local gateway (low/medium/high) or a multi-lens panel workflow (xhigh/max)
• codex-companion — drive OpenAI Codex models for independent reviews and delegated work (manual /codex-companion)
• present — an HTML explainer article that leaves your human partner understanding a subject end to end: work an agent shipped, a design you discussed, a spec, someone else's code, or any idea (manual /present)

Track it and coordinate

• issue-tracker — the board as a backlog, in GitHub issues or on an Arkho board service: register, search, take a named ticket, close it out (its automatic dispatch is dormant)
• sminos — the project family, shipped as the sminos plugin: every session in a project is a member that can message the others and its human, spawn and retire background sessions, and span machines

Deployed alongside, not a skill

• application-agents/triaging-feedback/ — the feedback→triage poller: turns product feedback into grounded board tickets

Extend it

• writing-skills — create and test new skills that shape agent behavior

Output style

• to-human — for a session whose human reads a report stream rather than the transcript: the agent sends messages in <message> at the end of a turn and through mcp__to-human__message (the to-human plugin's tool, offered under this style) before a tool call, where text comes back from the API as a paraphrase (each message carrying a ★ Insight block on its implementation choices when it implemented something, opening with a ⚠ Critical block when work was lost, degraded, blocked, or significantly slowed, which ends on how far that is handled and whether it needs the human, and for what, and naming every bottleneck or friction on quality or throughput with how it would resolve or mitigate it) and asks for input through mcp__sminos__AskUserQuestion (the sminos plugin's: the native AskUserQuestion plus async, which the style names over the native tool) — async by default, with async: false when the work waits on the answer; a reader shows only those messages, in both forms, and the questions, with old <to-human>, <essential>, <need-input> and <insight> marks read as aliases of <message> (that reader is the to-human plugin). Select per launch with "outputStyle": "doperpowers:to-human" (the plugin-qualified name; the message tool registers only under it).

---

How a change flows

1. brainstorming — Activates before writing code. Refines rough ideas through questions, explores alternatives, presents the design in sections short enough to actually read, and routes: a well-scoped task is built right there; an initiative complex and sizable enough that reliable execution needs a spec goes to execspec.
2. execspec — Writes the spec from the approved design: the design with its reasoning, acceptance as observable behavior, and a plan of work told as milestones — files, interfaces, the decisions already settled, proof; code only where the code is a decision. Reviews it, then runs it: one milestone in order from the spec; several go to a fresh subagent each.
3. subagent-driven-execution — Sets up an isolated checkout, dispatches a fresh subagent per milestone, reviews at dependency frontiers, and fixes by resuming the executor. After the final review it writes the spec's retrospective and integrates the branch.
4. test-driven-development — Enforces the RED-GREEN-REFACTOR cycle throughout and deletes any code written before its test.

These are mandatory workflows, not suggestions. The agent checks for a relevant skill before any task.

---

Philosophy

• Design before code — understand the problem before proposing a solution.
• Test-driven — write the failing test first, always.
• Systematic over ad-hoc — a repeatable process beats guessing.
• Simplicity as a goal — the minimum that solves the problem, captured with all its real complexity.
• Evidence over claims — verify before declaring anything done.

---

Contributing

This is a personal fork, tuned to how its maintainer actually works. Skills are behavior-shaping code, not prose — changing one changes what the agent does, so use the writing-skills skill and test the change before relying on it. Issues and ideas: github.com/SSFSKIM/doperpowers/issues.

License

MIT — see LICENSE. Attribution for the upstream work this derives from is recorded in NOTICE and LICENSE-FORK.