In 2026, several excellent proposals for kits emerged to standardize work with AI agents and modern development: Spec Kit from GitHub, Development Kit from Anthropic, internal kits from other large companies. These are serious, public efforts, with community behind them. Even so, at Steply, we chose to build our own kit and styleguide. This post explains why, at what point this decision makes sense for a company, and at what point adopting an off-the-shelf kit is clearly the better path.
The goal is not to sell the Steply Kit, it is to share the reasoning. If you are thinking "I am going to adopt Spec Kit / Development Kit / another" or "I am going to build my own", the arguments here will help you decide with clarity.
What a "kit" actually is
A kit, in this context, is a package of conventions, templates, prompts, commands, workflows, and tools that standardizes how a team works with AI agents and software development. It includes things like: spec format, commit standard, reusable system prompts, slash commands (/review, /test, /docs), PR playbooks, project structure standards, automated review rules.
The value of a kit lies in predictability: anyone on the team delivers to the same standard; every agent receives the same briefing; every client sees the same quality. Without a kit, each project is an improvisation and the company does not scale quality.
The off-the-shelf kits we evaluated
Spec Kit (GitHub): focused on Spec-Driven Development with a standardized spec format consumed by copilots and agents. Strong for alignment between product and engineering. Development Kit and tooling from Anthropic: focused on the workflow with Claude Code, agent standards, evals. Other kits, open or semi-open, from large companies with reusable pieces.
They all have real qualities. They are public efforts, maintained by serious teams, with community. In many cases, adopting them wholesale would be the right decision.
Why we built our own anyway
Five reasons weighed in, in order of impact.
1. Delivery culture is a competitive differentiator, not a commodity. The way Steply delivers, from briefing to final review, is part of what hires us. Adopting an off-the-shelf kit wholesale means our delivery becomes indistinguishable from any other company that adopts the same kit. Building our own kit anchors our way of working in our identity and lets us fine-tune what makes a difference for our audience.
2. Off-the-shelf standards optimize for the community's "average case". Open kits have to serve everything from the hackathon to the multinational bank. That is a virtue for adoption, but it forces concessions. Our kit can optimize for our client profile, our predominant stack, our processes. Every large convenience has a cost in generality.
3. Speed of evolution depends on ownership. When something needs to change, a new standard, a new prompt, a new rule, in an in-house kit it takes minutes. In an open kit, it is a PR, a debate, a wait, maybe a rejection, maybe ending up in a divergent fork. For a company that adjusts its process continuously, owning the tool is non-negotiable.
4. Deep integration with the internal ecosystem. Our kit talks to our agent harness, our evals pipeline, our observability, our client templates. Each piece of the kit is designed to fit into this stack. An external kit would demand continuous adaptation and a loss of cohesion.
5. Knowledge that stays at home. Building the kit forces the team to articulate every decision, record every standard, justify every convention. That process, in itself, is training. The people who build the kit understand the why of each piece, and the knowledge stays internalized, not delegated to an external README.
Where we adopt off-the-shelf pieces
Building an in-house kit is not about rejecting everything. In layers where the community standard is clearly superior and stable, we adopt it. MCP for agent tools, without hesitation. OpenAPI for REST API description. JSON Schema for validation. Conventional Commits for commit messages. Open SDD standards for the initial spec, with our extensions. Official SDKs from LLM providers. Where there is a useful and neutral standard, we use it; where the decision is cultural or about identity, we build.
What goes into the Steply Kit
The kit covers five axes. 1. Spec templates: a standardized briefing format, with mandatory and optional sections, ready to be consumed by coding agents. 2. System prompts: for agents in each role (reviewer, writer, test generator, legacy specialist), with standardized tone, principles, and output format. 3. Slash commands: reusable commands within our work environment (/review, /spec, /eval, /deploy, /audit), each triggering a predefined workflow. 4. Styleguide: voice, vocabulary, formatting, visual and textual communication rules, from code to internal Slack to the client deck. 5. Operational playbooks: how to run a kickoff, how to do a code review, how to deliver a release, how to manage an incident. Each playbook is versioned and reviewed at regular intervals.
Styleguide: voice and identity
The styleguide is the most underrated part. Without a styleguide, each PR, each email, each conversation with a client has a different tone. With a styleguide, there is coherence across channels. Our styleguide defines: grammatical person (third, plural, or first by channel), use of technical slang, expected level of detail in each format, adjective rules ("do not exaggerate", "avoid superlatives"), preferred markdown formatting, emoji standard (conscious restraint), and annotated examples of "how Steply sounds".
This is treated like code: it has a repository, it has PRs, it has a reviewer, it has a version. Every change is discussed and documented. Without a clear owner, a styleguide becomes fiction that no one follows.
When building your own does NOT make sense
Be honest. Building an in-house kit is not worth it when: (a) the team is small and does not yet have a standard to extract; (b) the stack varies a lot between projects with no consistency; (c) there is no one to maintain the kit over time (an orphan kit rots); (d) the open kit covers 95% of what you would need and the remaining 5% is cosmetic.
For most small companies starting now, adopting Spec Kit or similar wholesale is the right decision in the short term. Building comes later, when the identity of your delivery is already clear enough for the kit to reflect a mature way of working.
The real cost of maintaining your own kit
Honesty: an in-house kit has a recurring cost. It needs an owner, it needs time to evolve, it needs internal onboarding, it needs to be reviewed. In exchange, it compounds: every process improvement becomes a kit improvement, which becomes an automatic improvement in every future project. That compound effect, over years, justifies the investment for a company serious about quality.
What we learned
Three lessons we would do differently if we started today. 1. Start smaller. Our first kit tried to cover everything; it became heavy. Today, the kit is minimally viable, and it grows with internal traction. 2. Version aggressively. Without a clear version, a change becomes a silent regression. 3. Document the "why", not just the "how". A standard without justification falls apart. A standard with a story survives a team change.
Practical summary
For a small company or one starting now: adopt an open kit, gain speed, focus on delivering. For a company where the way it delivers has become a competitive differentiator, where the improvement cycle is constant, and where there is clear ownership: build your own kit, keep it versioned, integrate it with your ecosystem, and watch compound quality grow project after project. There is no universal answer. There is the right answer for the company's stage.