One understanding, two readers
Dubstack keeps each decision in two forms: a page you read and answer, and a record the agent reads. Both carry the same ID.
When a decision needs you, the agent builds a page with the options side by side, what each one makes true, and its recommendation with the reason for it. You answer there, comment on anything already settled, and hand the round back. The agent writes each decision into its record with the source, the rationale, and a stable ID. The next stage, a new session, or another agent reads that record and continues from it. When a question's meaning changes, it gets a new ID, so an earlier answer is never applied to it.
Install
Dubstack is one plugin with 19 skills. Install it one way per agent, because the plugin and the standalone skills together give you every skill twice.
Claude Code
claude plugin marketplace add malhashemi/dubstack
claude plugin install dubstack@dubstack
Skills appear with the plugin's prefix, such as /dubstack:basecamp. Run claude plugin update dubstack@dubstack to update.
Codex
codex plugin marketplace add malhashemi/dubstack
codex plugin add dubstack@dubstack
GitHub Copilot (CLI and VS Code)
copilot plugin install malhashemi/dubstack
In VS Code, run Chat: Install Plugin From Source and enter https://github.com/malhashemi/dubstack.
Cursor, OpenCode, Gemini CLI, and other agents
npx skills add malhashemi/dubstack
The skills CLI asks which agents to install for. Add --skill <name> to install one skill, and run npx skills update to update.
What you need
- Dossier, where most skills publish their pages and records. You need a workspace you can publish in. Either someone with a deployment invites you to one, or you host your own by following Dossier's runbook. The maintainer's deployment,
dossier.agent964.com, is invite-only. The CLI needs Node.js 22.12 or newer, and thedubstackguide walks you through the setup. - The GitHub CLI, signed in, for issues and pull requests.
- Python 3 for the bundled scripts, and uv for the brand toolkit.
Some skills work without Dossier: orchestration-setup, stack-preferences, upstream-source, babysit-pr, brand-skill-generator, visualize-html, svg-design, and skill-writing.
Start here
- Tell your agents who does what. If you work with more than one model, run
orchestration-setuponce. It reads your current global instructions and your setup, then writes which model owns implementation, review, research, and the rest, and how a session reaches each one. - Ask the guide. Run
dubstackin any project and ask where it stands. It reads the repository, the project's pages, and its open pull requests, then names the next skill and why, starting with work already in progress. - Bring work to
basecamp. Whether it's a one-line fix or a loose set of ideas, basecamp records the goal and chooses its route.
How it works
Before the first project, orchestration-setup decides which model owns which work, and stack-preferences holds your preferred technologies, so every architecture starts from your choices rather than generic defaults.
Project context can come in any order. project-home builds the project's home, design-interview or a live conversational-interview gathers a customer's requirements, and brand-skill-generator develops a brand. design-interview also settles the project's vocabulary or runs a brainstorm.
A new project then gets its architecture through design-interview, the open-source references it needs through upstream-source, and a goal from project-scaffolding that sets up the whole stack, connected end to end, before the first feature. An existing codebase gets a goal that brings its checks and CI up to standard, with each check shown to fail on a deliberate violation. Then architecture-review finds where its structure makes change hard.
The goal loop
Every piece of work starts at basecamp. It chooses the route by what remains unresolved, not by the size of the work:
| The goal still lacks | Next stage |
|---|---|
| Nothing: the intent is clear and the work fits one session | Do it now, then the pull request |
| Facts too large to find along the way | research |
| Decisions only you can make | design-interview: a design discussion, or a PRD then a TDD |
| Only a plan for work in several phases | structure-outline |
| An approved outline | implement-outline, one continuous run |
| A committed change | describe-pr, then babysit-pr until reviewers clear it |
Every stage hands back to basecamp, which records it on the goal's page and writes the handoff that starts the next. Between features, architecture review, dependency updates, and incoming issues all become goals the same way. The guide's map covers the whole flow.
A goal, start to finish
- You tell
basecampthat teams need to invite people by link. It records the goal, opens an issue, and finds decisions only you can make. design-interviewpublishes a round: link expiry, who may invite, what an invitee sees on an expired link, each drawn with what it makes true and a recommendation. You answer in a few minutes and comment on one settled point.- The next round folds your answers in. When nothing is left open, the ledger freezes, and
structure-outlineturns it into phases with exact contracts and the checks that prove each one. implement-outlinebuilds the outline in one run, writing acceptance tests from the contracts first and recording demos as it verifies.describe-propens the pull request with those demos attached and a walkthrough of the change, andbabysit-prcarries it through CI and review. Basecamp marks the goal done when it merges.
What makes it different
Decisions go to you; facts go to the agent. Every interview looks up what can be looked up and asks only what you alone can settle: intent, trade-offs, and first-hand knowledge. Each question comes with its options, their consequences, and a recommendation you can take or overrule.
Goals keep their record across sessions. Each goal has a record, a page, and its stages, and they carry over between sessions, people, and agents. Stable IDs connect an answer to the question it settled, the outline entry it shaped, and the check that proves it.
Every stage proves its work. A safeguard counts only once it has failed on a deliberate violation and passed again. implement-outline records demos while it verifies the work, and describe-pr attaches them to the pull request. babysit-pr treats a pull request as ready only when its reviewers have cleared its current revision.
The skills improve as models do. They describe outcomes, evidence, and who decides. They leave out procedures a capable model already knows, so nothing in them goes stale when a better model arrives. skill-writing, the skill they were all written with, is included.
The project keeps its decisions. The glossary, the architecture review's register of candidates and decisions, and your stack preferences each have one skill that writes them, so later work starts from what was decided instead of working it out again.
The skills
Start
| Skill | What it does |
|---|---|
dubstack | Reads where a project stands and names the next skill, with the reason |
orchestration-setup | Decides which model owns each kind of work and how sessions reach it |
stack-preferences | Keeps your preferred technologies per category, as data you can query and refresh |
Project knowledge
| Skill | What it does |
|---|---|
project-home | Creates and maintains the project's home, goal list, and glossary page |
design-interview | Settles a PRD, TDD, design discussion, architecture, glossary, requirements, or brainstorm in rounds |
conversational-interview | Gathers requirements or brainstorms by voice or chat, and can move to and from pages |
brand-skill-generator | Develops a brand with you and packages it as a skill your agents apply |
architecture-review | Finds where the structure makes change hard, proposes deeper modules, and keeps a record of past decisions |
Foundations
| Skill | What it does |
|---|---|
upstream-source | Chooses and pins open-source repositories as local references for your agents |
project-scaffolding | Opens a goal for a project's whole stack, or for an existing codebase's safeguards |
The goal loop
| Skill | What it does |
|---|---|
basecamp | Takes in a goal, chooses its next stage, and keeps its record and page current |
research | Finds out how things are, with every finding sourced and dated |
structure-outline | Turns an approved design into phases of outcomes, contracts, and checks |
implement-outline | Builds an approved outline in one verified, reviewed run |
describe-pr | Opens the pull request with demos attached and a walkthrough for larger changes |
babysit-pr | Carries a pull request through CI and review until it is cleared to merge |
Craft
| Skill | What it does |
|---|---|
visualize-html | Builds visual explanations, comparisons, and feedback pages, locally or on Dossier |
svg-design | Designs logos, icons, and vector graphics as maintainable SVG code |
skill-writing | Writes and reviews agent skills that guide without over-prescribing |
For agents
If a user asked you to look at this repository, this section is for you.
- Setting it up. Install the plugin through the route for the user's agent under Install, or with
npx skills add malhashemi/dubstack. Most skills publish to Dossier, so checkdossier whoamianddossier lsbefore starting one of them. If either fails, walk the user through Dossier's setup. - Where to start.
dubstackreads where a project stands and names the next skill. If the user works with several models,orchestration-setupcomes first. New work goes tobasecamp. - Explaining it. Each skill's
SKILL.mdis the authority on what it does, so read it before describing the skill or saying a step can be skipped. When the user asks what sets Dubstack apart, the answer is in What makes it different. Each decision exists as a page for the user and a record for you, decisions go to the user and facts to you, goals keep their record across sessions, and every stage proves its work. Be plain about the cost. Most stages need Dossier, and the longer routes take more time than making a small change directly.
Built with T3 Code
Dubstack is developed and run in T3 Code, an agentic development environment that runs on top of the coding agents you already use. One thread can hand a task to any provider's model, which lets a Dubstack session give implementation to one model and review to another. The skills don't depend on it. orchestration-setup adapts to whatever your setup can reach, whether that's one coding agent with several models, a terminal multiplexer, or MCP servers.
Learned from
This set of skills wouldn't exist without what these people and projects taught:
- HumanLayer and its research, plan, implement loop, explained in Advanced Context Engineering for Coding Agents. Dubstack's goal loop builds on it.
- Theo, whose videos shaped the long-running, goal-based way of working, and whose T3 Code runs it.
- Matt Pocock's skills, for interviewing towards a shared understanding, a project's vocabulary, and deep modules.
- Superpowers, for showing that a whole development method can live in skills.
- Anthropic's Agent Skills and the Agent Skills format, which make skills portable across agents.
- pstack, for engineering principles and routing work to the right playbook.
- BMAD Method, Spec Kit, and GSD, for showing how far structured, spec-driven delivery with agents can go.
Contributing
AGENTS.md is the contributor guide: how skills are written, the full check (mise run check), and how releases work. Pull requests are squash-merged with a conventional title.