Two ways to get unstuck

Your teams are already using harnesses, and they’re using them in ways that make sense to them. Claude Code in one squad, Copilot in another, Cursor for the person who got there first. A CLAUDE.md someone wrote on a Friday afternoon. A handful of skills that work for the people who made them.

Mostly, that’s fine. Teams want to use things a certain way, and forcing one process on all of them is a good way to make sure none of them follow it.

But sometimes you’re stuck. Every team does it differently and nobody can agree on a shared way. The process lives in one person’s head. The agent keeps getting the same thing wrong because nobody has written down what right looks like. Ask what the workflow is and you get a diagram from a wiki nobody has opened since it was drawn, or a shrug.

That matters more than it used to, because the workflow is moving into the harness. Whatever you write into CLAUDE.md, a skill, a hook or a spec template is the process. The agent reads it every session, and the hooks run every time. Encode a muddle and the agent will run the muddle, a thousand times a day. Let every team encode its own and you’ve built it in secret all over again, just with better file formats.

Your harness config is your operating model. You might as well decide what’s in it.

So if you’re stuck, where do you start? I’ve seen five or six different ways teams work, even when they’re sitting right next to each other. But two keep coming up, and I love both of them.

They’re both ways of building your own harness. The difference is where you start: from a kit you customise, or from a path you build up.

Start from a kit

GitHub’s Spec Kit gives you something to work with on day one. Its own README says it best: “Start with a ready-made process, customize it, or bring your own.”

There is a default. Spec-driven development runs from constitution through specify, clarify, plan, checklist, tasks, analyze and implement to converge, which checks the code against the spec, plan and tasks, adds tasks for anything missed, and sends you round again until it reports converged. Several of those steps are optional quality gates, and the quickstart offers a shorter route.

The bit that sold me is that the flow itself is just a file. Spec Kit ships its core cycle as a workflow definition: agent commands in order, with review gates where the run waits for someone to approve or reject before it carries on. Trimmed down, it reads like this:

workflow:
  id: "speckit"
  name: "Full SDD Cycle"
  description: "Runs specify → plan → tasks → implement with review gates"

steps:
  - id: specify
    command: speckit.specify

  - id: review-spec
    type: gate
    message: "Review the generated spec before planning."
    options: [approve, reject]
    on_reject: abort

  - id: plan
    command: speckit.plan

  - id: review-plan
    type: gate
    message: "Review the plan before generating tasks."
    options: [approve, reject]
    on_reject: abort

  - id: tasks
    command: speckit.tasks

  - id: implement
    command: speckit.implement

That’s a team’s workflow, readable by anyone, with the same steps and the same gates every run. And you don’t fork it to make it yours. You write an overlay that inserts, replaces or removes steps, and Spec Kit layers it on top of the installed workflow, so your changes survive upgrades. Say your team wants its own checks after implementation:

id: "our-checks"
extends: "speckit"
edits:
  - insert_after: implement
    step:
      id: preflight
      type: shell
      run: "npm run lint && npm test"

A handful of lines, and the team’s rule is part of the flow.

But the default isn’t the product. The customisation docs call the bundled processes “starting points, not limits”. Presets swap the templates and commands so the method can lean Agile, Kanban or domain-driven design. Extensions add whole phases. Bundles package a team’s setup so another team can install it. It works across dozens of agents, Claude Code among them, so it fits around most of the harnesses your teams are likely to be using.

And at the root sits the constitution. Run that step with the principles you care about, or let it ask you, and you’ve got a file of principles that every later step gets checked against: testing standards, architecture rules, security posture. It might be wrong on day one, but it’s there, and the team has something to argue with.

What I love about it: you’re customising from the first hour, not starting from a blank page.

Start from a path

Anthropic’s AI-native SDLC playbook comes at it the other way. It gives you worked examples and sample config, but not a kit you install. It describes a path, and you build the harness for it yourself, mostly in Claude Code, with claude.ai or Cowork for the people who aren’t engineers. I’ve said before it’s one of the best-documented simple approaches out there, and I stand by that.

The path is six stages: plan, design, build, test, deploy, maintain. Each one leaves a file in version control for the next to pick up. An intent.md becomes a spec.md, which becomes a plan.md, which becomes a diff with tests, a reviewed pull request and, when something breaks in production, a fresh intent.md. It’s a loop, and humans make the calls at the gates. The agent can do the work right up to production, but a named person signs off the release.

None of that comes installed. Running /init drafts you a starting CLAUDE.md, and the playbook tells you to cut it down, but there’s no constitution step. You have to work for it for a while. The CLAUDE.md grows as the agent gets things wrong: the playbook’s rule is that a mistake made twice goes into it. Then a few skills for the things people keep doing differently. Then hooks for the things that can’t be left to chance. Eventually a plugin, so the next team gets it all in one go.

Where it ends up looks less like a document and more like a preflight. This site has one, installed as a plugin. Before I push from Claude Code, it summarises the change for a reviewer, runs a style review, and only stamps the commit if both pass. Nobody has to remember the rules, because the check runs before the push.

This is actual work. You have to sit down and think about your process: what you do, why you do it, and which bits you’d defend if someone asked. I think that’s the point. In my experience, Spec Kit takes some of that thinking away. Not all of it, but enough that you can end up with a workflow you’ve adopted rather than one you understand.

What I love about the path: everything in it was earned. Each rule is there because real work needed it, and you know why it’s there because you put it there. Building out your own harness is something I think everyone should experience at least once.

And that seems to be where the people making these tools are heading. Over the last couple of months the theme I keep seeing is this: build as you go, one slice at a time. Don’t start from something pre-baked, and don’t copy someone else’s homework. The playbook says it outright. Start with “one piece of knowledge that is enforced inconsistently today”, and treat its sample settings as “a starting point to tailor, rather than a recommendation to copy.”

Start from a kit

Solves a workflow on day one

• Spec Kit's default process
• A constitution in the first hour
• Presets, extensions and bundles
• Dozens of agents, no lock-in

Start from a path

Solves a harness that grows with you

• The playbook's six stages
• A CLAUDE.md that grows
• Skills, then hooks, then a plugin
• Every rule earned by real work

vs

Same principle

The two feel different, but the principle is the same. Either way, you’re building what constitutes your harness: what the agent reads, what it’s made to do, and what it won’t let through.

What the agent reads

Principles

A constitution, or a CLAUDE.md grown over time.

Know-how

Skills for the things people keep doing differently.

---

Your harness

What the agent can't skip

Checks

Hooks, managed settings and review gates.

A preflight

Installed once, run before anything leaves the machine.

Whichever you pick, a constitution only counts if something checks the work against it.

Native or third party

There’s one more difference, and it’s a matter of taste as much as anything.

Building inside the vendor’s own harness, whether that’s Anthropic’s, OpenAI’s or whoever’s model you’ve bet on, gets you first-class support and a first-class feel. The CLAUDE.md, the skills, the hooks and the plugins are the harness’s own parts, built by the people who build the harness. That’s what I mean by the AI-native feeling. Nothing sits in between.

Third-party harnesses like Spec Kit are good. Genuinely good. But they sit on top. Spec Kit generates its commands and skills into each agent’s own format, and its docs tell you not to edit those generated files by hand. That’s the right call for a tool that supports dozens of agents, and it’s also the tell: there’s a translation layer between you and the harness, and you lose some of that native feel.

Whether that matters is a personal opinion. Some teams won’t notice. Some will feel it every day.

What isn’t opinion is the speed. These harnesses change every few weeks. When the vendor ships something new, the native route gets it the day it lands. A third-party layer has to notice, adapt and release before you can use it through the kit. Most of the time that gap is small. But at the pace things are moving, there’s a real chance you’ll spend some of your time a step behind.

The flip side is the reason Spec Kit exists: no lock-in. If your teams are split across agents, or you expect to switch, that translation layer is exactly what you’re paying for.

Which one, when

Start from the kit if you need something on the table this week. Your teams are spread across different agents, there’s no shared process, or the same arguments keep coming back in pull request comments. Write the constitution first. What does a good change look like here? What can never ship? Who signs off what? Then customise the workflow until it enforces those answers.

Start from the path if your teams already live in Claude Code, you want the native feel and the new features the day they ship, and you can afford to grow it. Run the playbook’s stages on one piece of real work. Don’t debate it up front. Let the work show you where it doesn’t fit, add a rule every time the same mistake happens twice, and package it once it holds.

Or build the whole thing yourself. Ignore both. Skip Claude Code’s first-party pieces and Spec Kit, and write your own harness on top of the models or an agent SDK. I’ve seen that done too, and done well. It’s the same principle taken all the way down. Honestly, it just comes down to how much work you want to sign up for.

You don’t have to pick one forever, either. You can borrow the playbook’s stages and write them down with Spec Kit, or start with a constitution and grow the rest in Claude Code. Spec Kit doesn’t ask you to throw away the harness your teams already understand, and if they’re already in Claude Code, neither does the path.

From stuck to agreed

Whichever way in, the journey looks roughly the same.

1. Write down what actually happens

   Who: The whole team

   Not the wiki diagram. Take the last three things you shipped and trace them: where the idea came from, who touched it, where it waited. That’s your real workflow, and it’s the baseline.

2. Agree one handoff

   Who: ProductEngineering

   Don’t fix the whole process. Pick the seam that hurts most, usually idea to spec, and agree the artifact that crosses it. An intent file, a spec template, one page. That’s your first agreement.

3. Pick a starting point

   Who: Tech lead

   Spec Kit’s default or the playbook’s stages, on real work, as written. You’ll learn more from where it chafes than from a month of workshops.

4. Write it where the harness reads it

   Who: EngineeringPlatform

   CLAUDE.md, skills, a constitution, a preset. Advice goes in skills. Anything that must never happen goes in a hook, because a skill is a suggestion and a hook is a rule.

5. Let the work argue back

   Who: Everyone

   When the agent gets the same thing wrong twice, the fix goes into the config, not into someone’s memory. The workflow should change because of real work, not because someone read a blog post.

6. Package it for the next team

   Who: PlatformOther teams

   Once it holds, bundle it: a plugin, a preset, a shared constitution. The next team starts from what works and tailors it. That’s how a team workflow becomes a domain capability.

The last step is where this meets the road. A workflow that’s packaged, versioned and shared is a paved road for process. Teams follow it because it’s the easiest way to get their work done, not because a committee said so.

Final thought

If your teams are getting on fine with the harnesses they’ve got, leave them to it. If they’re stuck, you don’t have to invent a workflow from nothing. Spec Kit gives you a kit to customise on day one. The playbook gives you a path to build up in Claude Code, one earned rule at a time.

And you don’t have to crown a winner. I actually encourage teams to run four or five approaches side by side, done extremely carefully. That isn’t every squad doing its own thing in secret. It’s agreed handoffs between them, the same checks at the gates, everything visible, and someone paying attention to which approach is actually working.

No kit or path can agree any of it for you. That part is still people. Get them in a room with the last three things they shipped, agree one handoff, and write it down where the agent can read it. Everything after that is iteration.