# The Agentic Startup: a spec-driven command set for Claude Code

> The Agentic Startup is a collection of Claude Code plugins that turn a coding session into a spec-first pipeline, with ten slash commands across three phases, three decomposition tiers that decide how much ceremony a task gets, and optional project governance rules. It is MIT licensed and installed from a marketplace or a one line shell script.

**rsmdt/the-startup** — The Agentic Startup - A collection of Claude Code commands, skills, and agents.

- Repository: https://github.com/rsmdt/the-startup
- Website: https://www.r16t.com/agentic-startup
- Stars: 570 · Forks: 69
- Language: Shell
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rsmdt-the-startup

## What the plugin set actually is

The Agentic Startup is a collection of Claude Code commands, skills and agents, distributed as a Claude Code plugin with a marketplace entry.

The framing in the project documentation is a multi-agent AI framework that makes Claude Code work like a startup team: create detailed specifications before coding, then execute with parallel specialist agents, with expert developers, architects and engineers working together to turn ideas into shipped code. The headline is ten slash commands across three phases, and the order is specify first, then build with confidence.

The features list makes the mechanism concrete. Spec-driven development runs PRD, then SDD, then tier-appropriate decomposition, then code. Three decomposition tiers exist, Direct, Incremental and Factory, with /specify classifying the complexity and /implement auto-dispatching on the result. Multiple specialists work simultaneously. Validation is built in at every stage. And installation is zero configuration through marketplace plugins with a one line install.

Version 3 added Agent Teams, marked experimental, which enable multi-agent collaboration where specialised agents coordinate on complex tasks, and the installer now offers to configure this automatically.

The users are Claude Code users who want structure around the model rather than a better prompt, and the repository is registered as a Claude Code plugin and Claude plugin marketplace project, with the homepage at r16t.com/agentic-startup and the project mentioned in the Awesome Claude Code list.

## Installing the plugins and choosing an output style

The requirement is Claude Code v2.0 or newer with marketplace support, and the install is one shell command:

```bash
curl -fsSL https://raw.githubusercontent.com/rsmdt/the-startup/main/install.sh | sh
```

That installs the core plugins, configures the default output style, and sets up the statusline with a customizable config file.

The manual route is documented as well, and it starts by opening claude and running the marketplace and install commands:

```bash
# Add The Agentic Startup marketplace
/plugin marketplace add rsmdt/the-startup

/plugin install start@the-startup  # Install the Start plugin (core workflows)
/plugin install team@the-startup   # (Optional) Install the Team plugin (specialized agents)
```

Two plugins, and the split is meaningful. The Start plugin carries the core workflows, the slash commands that drive the pipeline, and the Team plugin is optional and holds the specialised agents that do the parallel work.

After installation there are two things to set up. The first is optional governance:

```bash
# (Optional) Create project governance rules
/constitution                      # Auto-enforced during specify, implement, review
```

The second is the output style, which can be switched at any time:

```bash
# Switch output styles anytime
/output-style "start:The Startup"   # High-energy, fast execution (default)
/output-style "start:The ScaleUp"   # Calm confidence, educational
```

The two styles are a real behavioural difference rather than a colour scheme. The Startup style is described as high-energy and fast, and it is the default, while The ScaleUp is calmer and educational.

The statusline is the third piece, and it is set up by the installer with a config file you can customise, which is how the plugin surfaces progress without you asking for it.

## The command flow from specify to document

The quick start is two commands, and the documentation says that is all it takes:

```bash
# Create a specification
/specify Add user authentication with OAuth support

# Execute the implementation
/implement 001
```

The full workflow has a primary build path and a maintenance path. The build path runs /specify to create the specification, with requirements and the technical solution, and it classifies the complexity as Direct, Incremental or Factory, with the constitution checked on the SDD. Then /validate checks quality using a 3 Cs framework, with constitution mode available. Then /implement auto-dispatches by tier and executes, with the constitution and drift enforced. Then /test runs the tests and enforces ownership, with the note that there are no pre-existing excuses. Then /review does a multi-agent code review with constitution compliance checked. And /document generates or syncs the documentation.

The setup step sits outside the main flow and is optional. /constitution creates the project governance rules, and those are auto-enforced in the build workflow.

The maintenance path is for when the work is already shipped. /analyze discovers patterns and rules, /refactor improves the code while preserving behaviour, and /debug fixes bugs with root cause analysis.

What to notice is where the gates sit. The constitution is checked at three points, specify, implement and review, and the review step is explicitly multi-agent, so the gate is not one more opinion from the same context.

## The three decomposition tiers and how /implement dispatches

The tier system is the part of the design that does the actual work of matching process to task, and it is the piece most worth understanding before you install anything.

The three tiers are Direct, Incremental and Factory. /specify classifies the complexity of the request, and /implement auto-dispatches on that classification. The documentation describes Direct as needing no plan, Incremental as a phase loop, and Factory as parallel units.

In practice the tiers trade ceremony against throughput. A Direct task goes straight to implementation with no decomposition step, which is what you want for a small change and what makes the framework usable on a trivial ticket. An Incremental task runs a phase loop, so the work is broken into sequential phases and each one is checked before the next. A Factory task runs parallel units, which is the multi-agent case where several specialists work on the pieces at once.

The classification is automatic, which is both the convenience and the risk. You do not have to tell the framework how big your change is, but you also do not have a documented way to override it in what the project documentation shows, and a task misclassified upward will generate decomposition artifacts and validation passes that a small change did not need.

That is why the first thing to try is a small feature. If the classifier picks Direct for something you know is small, the pipeline behaves as advertised. If it picks Factory for a one-file change, you will find out early that the overhead is not what you wanted, rather than discovering it on a real piece of work.

## What a specification produces on disk

The output of /specify is a directory of documents, and the layout is documented. A specification lives under .start/specs/ with a numbered slug, and it contains two foundational documents that always exist, requirements.md which is what to build and why, and solution.md which is how to build it technically.

After that, one tier-specific set of decomposition artifacts is added, chosen by the complexity classifier. The documentation shows the Direct tier case explicitly, and the pattern for the other two follows from the tier names.

So the artefact is a specification folder, not a chat transcript, and the numbering is what /implement consumes, which is why the quick start shows /implement 001 rather than a description of the feature. The 001 is a specification identifier, and the framework is tracking specifications as a queue you work through one at a time.

Two more details from the tree. There is a .claude-plugin/ directory at the repository root, which is the manifest for the plugin itself, and a plugins/ directory holding the actual plugin packages, one of which is the marketplace that the manual install refers to as rsmdt/the-startup.

The repository also carries a MIGRATION.md file and a CHANGELOG.md, plus an AGENTS.md and a CLAUDE.md, and the release workflow has a badge, so the versioning of the plugin set is tracked separately from the plugin format it targets.

## Where The Agentic Startup is the wrong choice

The first limit is that it assumes a spec-first culture already fits. If your team writes a ticket, a reviewer reads a diff and a test proves it works, then the specification phase is a second source of truth and the drift enforcement and constitution checks are overhead aimed at a problem you do not have. The documentation itself makes the trade explicit by saying the framework ensures clarity and reduces rework, which is a claim about a specific failure mode rather than a universal improvement.

The second is the experimental Agent Teams. Multi-agent collaboration is marked experimental, and the installer offering to configure it automatically means a new team can end up with a coordination model nobody has evaluated. That is a lot of moving parts introduced by an installer, in a project whose own release notes flag the feature as not yet stable.

The third is the coupling to one tool. Everything here is Claude Code commands, skills and agents, in a Claude plugin format, requiring Claude Code v2.0 or newer with marketplace support. Nothing in the design is portable to another coding agent, and a team standardising on something else has no path.

The fourth is that the routing decisions are made by the model. /specify classifies complexity and /implement dispatches on it, with no documented override in what the project documentation shows. A framework that decides how much process your task deserves is convenient until the classification is wrong, and then the failure mode is a lot of wasted work rather than an error message.

Compare that with a plain code review checklist plus a definition of done. The difference in approach is that the checklist is something a person applies at the end, while this framework tries to move the decision to the front and enforce it with gates and a constitution. That is the better answer for an agent that would otherwise write code first and rationalise afterwards, and the wrong answer for a team whose problem is slow reviews.

## Licence, project state and what to set up first

The project is released under the MIT licence, with the text in the LICENSE file at the repository root. The MIT terms are permissive and the artefact is configuration rather than software, so the licensing question is a light one. Read the LICENSE file yourself for the exact wording.

The release history shows a rapid version line. v3.6.1 came on 2026-04-22, v3.7.0 and v3.8.0 both on 2026-05-07, and the last push was on 2026-08-03, so the tree is about two and a half months old relative to today. The repository is not archived. Three releases inside a fortnight suggests a fast moving configuration set, which is what you would expect from something that has to track the plugin format and the CLI behaviour of the host tool.

The primary language of the repository is Shell, and that matches the tree. There is an install.sh at the root as the one line installer, a scripts/ directory alongside it, a plugins/ directory holding the plugin packages, a .claude-plugin/ directory for the plugin manifest, and docs/ for the documentation.

What to set up first is a short list. Read the documentation for the /constitution command before anything else, because that file is what the specify, implement and review gates are checked against, and a constitution that states your actual rules beats one written for the demonstration. Then pick an output style deliberately rather than accepting the default, since The Startup and The ScaleUp differ in how much the agent talks and how fast it moves, and that choice changes how the rest of the pipeline feels.

Then run a small feature end to end and look at what lands in .start/specs/. If the documents are useful to you as a human, the framework is earning its keep. If they are noise you will never read, the tier classification is sending you to the wrong path.

## Conclusion

The Agentic Startup fits a team that wants the specification written before the code and wants the review gates to be enforced rather than suggested, and it fits a solo developer who has found that agents drift without written constraints. It does not fit a team whose workflow already has a spec process, since the governance rules and the phase structure would then be a second opinion rather than a contribution. Before you adopt it, read the /constitution step first, because it is what the later gates actually check against, and start with a small feature so you can see the tier classifier pick Direct rather than Factory.

## FAQ

### What is The Agentic Startup?

It is a multi-agent AI framework for Claude Code, distributed as a marketplace plugin with commands, skills and agents. It provides ten slash commands across three phases that follow spec-driven development, creating detailed specifications before code and then executing with parallel specialist agents.

### How do I install The Agentic Startup?

With Claude Code v2.0 or newer and marketplace support, run curl -fsSL https://raw.githubusercontent.com/rsmdt/the-startup/main/install.sh | sh, which installs the core plugins, configures the default output style and sets up the statusline. Manually you can add the marketplace with /plugin marketplace add rsmdt/the-startup and install the start and team plugins.

### What are the three decomposition tiers in The Agentic Startup?

They are Direct, Incremental and Factory. The /specify command classifies the complexity of a request and /implement auto-dispatches on that classification, with Direct needing no plan, Incremental running a phase loop, and Factory running parallel units.

### What do the slash commands in the build workflow do?

The build flow runs /specify to create the specification with requirements and solution documents, /validate to check quality with a 3 Cs framework, /implement to auto-dispatch by tier, /test to run tests and enforce ownership, /review for a multi-agent code review that checks constitution compliance, and /document to generate or sync documentation. The optional /constitution command creates governance rules that are auto-enforced during specify, implement and review.

### Where does The Agentic Startup store its specifications?

Under .start/specs/, in a numbered directory such as .start/specs/001-notification-system/. Each one holds requirements.md for what to build and why and solution.md for how to build it technically, plus one set of tier-specific decomposition artifacts chosen by the complexity classifier.

### What licence does The Agentic Startup use?

It is released under the MIT licence, with the terms in the LICENSE file at the repository root. The repository is not archived, the last push was on 2026-08-03, and the recent releases are v3.6.1, v3.7.0 and v3.8.0.

## Sources

- [License: MIT](https://github.com/rsmdt/the-startup/blob/main/LICENSE)
- [Project website](https://www.r16t.com/agentic-startup)
- [README](https://github.com/rsmdt/the-startup/blob/main/README.md)
- [Releases](https://github.com/rsmdt/the-startup/releases)
- [rsmdt/the-startup on GitHub](https://github.com/rsmdt/the-startup)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rsmdt-the-startup