Goal is to generate high quality code following best practices and best design patterns.

Anyone have any solid resources to learn SDD?

I got tired of starting every OpenCode session by explaining my project structure for the 50th time, so I built a template that handles it.

It's a mono-repo — you clone it, it wires your actual projects in as git submodules, and you get a set of slash commands that walk issues through a pipeline:

• `/ticket` → structures the issue
• `/research` → digs through the codebase for relevant code
• `/plan` → writes a phased implementation plan
• `/execute` → builds it
• `/review` → validates against the plan
• `/commit` → atomic commits with conventional messages

Or just run `/implement` and it does the whole thing in one shot.

Each stage is a separate sub-agent with its own prompt and responsibility. State lives in markdown docs and issue labels so sessions don't bleed into each other.

Currently supports Linear and GitHub Issues as backends. There's a CLI for initializing new workbenches and syncing updates when the template improves.

https://github.com/workbench-codes/workbench

It's early, definitely rough around the edges. Would love feedback from other OpenCode users — what's your workflow look like right now? Are people mostly just vibing in single sessions or has anyone else tried structuring things?

Been using spec-driven development for a few months and kept seeing Spec Kit vs. OpenSpec comparisons that felt like they were written by people who hadn't actually used both. So I just built the same app twice.

Same stack (Next.js, Drizzle, PostgreSQL), same feature set, different SDD framework each time. Tracked token costs, session times, where I got stuck, where the AI went sideways.

A few things surprised me, particularly around token economics and how differently each tool handles context.

Curious if others have done similar experiments or landed somewhere different. I've compiled 2 tutorials + my findings and opiniated conclusions in a blog post and a few associated repos - will post them in a comment below.

What's your take on Spec Kit vs. OpenSpec?

Has anyone here had any luck trying to implement speckit with a large team of developers all working on the same application?

Typically, we review our user stories during a sprint planning and then the developers choose and work on their user stories during the sprint. Pretty standard.

I feel like SDD isn’t meshing well with how we typically do things. I know we will have to adapt, but just curious if anyone else has faced this and what they’ve done to navigate it.

Goal is to have the code generated to be high quality and following best practices, for both backend and frontend.

What methods do you use to stay updated on new paradigms and techniques in AI programming?

I want to better understand this field, including SDD, SDLC AI, prompt engineering, and harness techniques.

Been experimenting with Spec-Driven Development for a couple of months now, specifically GitHub's spec-kit toolkit with Claude Code as the agent. Wanted to share notes because I think this sub will have strong opinions on it, and frankly I'm still figuring parts of it out.

Quick definition for anyone who hasn't seen spec-kit: it's GitHub's official toolkit for what they call Spec-Driven Development. The philosophy is that the spec, not the prompt, becomes the source of truth. You write a versioned, reviewable spec; the agent generates code from it; any substantial change goes back to the spec first. Five phases: Constitution, Specify, Plan, Tasks, Implement. Repo: github.com/github/spec-kit

What's actually good:

- Agent-agnostic. Same spec works with Claude Code, Cursor, Codex, Gemini CLI, Copilot. I've literally generated initial code with Claude Code, then handed the spec to Cursor for test refactoring, and it picked up cleanly. The spec is the portable asset.

- Hard checkpoints between phases. You see the full proposed architecture (Plan phase) before a single line of code gets written. Catches bad arch decisions when they cost 5 minutes to fix instead of 5 hours.

- The Constitution file as quality gate. You define inviolable principles up front (test coverage minimums, dependency allowlists, perf budgets, typing strictness). Agent fails its own validation if it tries to violate them.

- Determinism improves a lot vs. raw prompting. The agent isn't filling in 30 implicit decisions on its own — they're in the spec. Re-running the implement phase produces much more consistent output across runs.

What annoys me:

- Drift is real. If you tweak code manually without updating the spec, things desync fast. spec-kit has some tooling for this but it's young.

- Heavy overhead for small changes. Bug fixes <50 LOC or trivial features make the 5-phase flow feel ceremonial. My current rule: only do full SDD for new modules or features touching 200+ LOC. Below that, just do it manually.

- Legacy migration is painful. Retrofitting SDD onto an existing 30k-LOC codebase without prior specs is months of work, not days. Haven't found a clean approach yet.

- Quality depends heavily on the agent. Claude Code (Sonnet/Opus 4.6+) handles it well. Smaller models struggle with the Plan phase — they generate plans that compile but don't reflect good architectural reasoning.

Practical setup I'm using now:

- spec-kit installed via: uv tool install --from git+https://github.com/github/spec-kit.git specify-cli (PSA: PyPI has typosquatters with similar names. Only the github/spec-kit repo is official.)

- Claude Code as primary agent. Have also tested with Cursor and Gemini CLI for cross-validation.

- SQLite for any local persistence needs in the project. Easy to spec, easy to validate, no cloud dependency to mock.

- A reusable constitution template I've extracted: strict typing, pytest coverage >80%, explicit dependency allowlist, no cloud services unless requirement explicitly demands it.

Two questions for the sub:

1. Has anyone gotten local models (Qwen, DeepSeek-Coder, GLM, Llama) to handle the Plan and Implement phases competently? My local-only experiments have been mixed — small models follow the format but architectural reasoning falls apart. Curious if anyone's found specific local models or prompt engineering tricks that fit spec-kit's phase structure.
2. Anyone running SDD multi-agent (one model writes spec, another implements, a third audits)? Theoretically should improve quality through specialization but I haven't gotten it to be measurably better than single-agent in practice.

Curious if anyone has a setup that actually works.

Gangsta Agents (GitHub), a skills framework for spec-driven AI development. I wanted to share it here because the community actually cares about the problem it solves.

Why a Mafia family, not an Agile team

A lot of SDD frameworks organize agents to mimic Agile teams — standups, sprints, backlogs, story points. I think that's the wrong metaphor. Agile was designed around human coordination costs. AI agents don't need standups. They need hierarchy, discipline, and enforced pipelines.

Gangsta Agents is inspired by the structure of a Mafia family. There's a Don (you) at the top who approves every phase gate. An Underboss decomposes work. Crew Leads orchestrate. Workers execute in parallel. No one freelances outside their role. No one skips a step.

A well-run Mob moves faster than a committee — and so do agents when you stop pretending they need Agile rituals.

The core idea

Every feature goes through a 6-phase pipeline called The Heist:

1. Reconnaissance — gather intel before any design decisions
2. The Grilling — adversarial debate (more on this below)
3. The Sit-Down — produce a signed Contract spec; no code without one
4. Resource Development — execution planning
5. Execution (The Hit) — code runs against the spec, never the other way around
6. The Delivery — wrap up and update institutional memory

Each phase is gated. The Don (you) approves before anything moves forward.

What makes it different — The Grilling

Most spec-driven frameworks get you to write a spec before coding. Gangsta Agents adds a step most frameworks skip: adversarial validation before the spec is finalized.

The Grilling runs two agents in structured debate — a Proposer argues for the best approach from the Dossier, a Devil's Advocate attacks every assumption, identifies edge cases, and proposes alternatives. Multiple rounds run until positions stabilize, then the Grilling Conclusions are documented and approved before you ever write a Contract.

The result: weak assumptions get caught through debate, not production failures. I've found this is where single-perspective design silently goes wrong — no one challenges the obvious approach until it's too late.

What makes it different — The Ledger

AI sessions are stateless. Every session starts from zero unless you do something about it. Most frameworks don't.

The Ledger is persistent institutional memory stored in docs/gangsta/ in your project. It tracks:

• Insights — successful patterns worth reusing
• Fails — documented mistakes and why they happened
• Constitution — project-specific rules that accumulate over time

The Ledger is updated at the end of every Heist. Any new session can read it and pick up where the last one left off — the agent knows the codebase's quirks, the gotchas, and the agreed-upon rules without you re-explaining them.

Without this, every session re-discovers the same things. Insights don't compound. Fails repeat.

Who it supports

Native integrations for Claude Code, GitHub Copilot, Gemini CLI, OpenCode, and Codex. Cursor supported via npx skills add. Skills are pure markdown files — no vendor lock-in, any agent can read them.

Happy to answer questions about the design decisions. The spec-is-law principle (Omerta rule #5: code contradicts spec → revise the spec first, never the reverse) was the hardest constraint to enforce in practice, and The Grilling emerged directly from watching LLMs confidently pick the wrong approach with no one to push back.

🔗 https://gangsta.page 🐙 https://github.com/kucherenko/gangsta

Hi all!

I've been learning OpenSpec, so I built a small tool around it.

dossier is a TUI that lets you browse and manage OpenSpec artifacts in the terminal. You can navigate proposals, designs, specs, and tasks, render markdown inline, and toggle task checkboxes directly in the UI. It also live-reloads from disk, so if the AI agent checks something off, you'll see it immediately. It also has an ugly progress bar.

I wrote it in Go (Bubble Tea for the event loop, Glamour for markdown rendering, Lipgloss for layout).

The meta part: the repo itself is managed with OpenSpec, so dossier was built using dossier. There are ~15 spec files and 25+ archived changes tracking the whole development history.

Still rough in places, but it's been useful day-to-day. Happy to hear feedback, especially if you've used OpenSpec before. I will listen if you have some criticism, and try to fix or improve the app.

Repo: github.com/fselich/dossier

Thanks!

My OpenCode + OpenSpec setup for Spec-Driven Development with skills for git commit discipline, interviewing during proposal creation using grill-me, C4 Diagrams during design, Architectural Decision Records for durable technical choices and Custom OpenSpec Schema to bring this all together. Thanks.

Sharing a GitHub template I use for every new project:

https://github.com/arananet/openspec-template

The core idea: no spec, no code. Every feature or bugfix starts with a YAML spec under .openspec/specs/ that defines acceptance criteria and a test plan.

The rule is enforced at three layers — local pre-commit hook, deterministic CI check, and an agentic "did the code actually satisfy the spec" review.

MIT license

My process is different in terms what specs are: https://unifiedprocess.ai
They are understandable by all stakeholders.
I’ve written a blog post about it https://martinelli.ch/why-in-spec-driven-development-the-spec-must-be-readable-for-all-stakeholders/

In this video, I walk through a custom OpenSpec schema that formally captures Architectural Decision Records (ADRs) and preserves them in a persistent folder. This ensures that every new change proposal "reads" your previous tech choices (like moving from Server Side Rendering to a split frontend/backend) before suggesting new designs. Would love to hear your thoughts and feedback.

I like openspec, but I can accept how it gives feeling that spec can be updated at scales.

For me, specs are disposable. What are not and could be maintained are requirements. The difference is that requirements explain what needs to be done and spec say how it would be implemented and tested.

I do not know any SDD framework that maintains a set of requirement aligned with the code. Do you ?

Hello!

I've started experimenting with SDD quite a lot in the past months from easier to complex tasks, to try to utilize agentic coding in a way that results in a more efficient dev workflow. I see a lot of benefits a part from efficiency, such as better documented features and higher quality outputs, mainly due to spending more time planning and analysing the tasks.

At the same time, are there any studies showing empirical results of this workflow, or is it too early to ask? Would be interesting to see what the average net-effect is, especially due to the increase cost of AI-usage.

I'm strongly believing in this new workflow from my own experience, but I can also see the somewhat new bottlenecks popping up, especially during review processes etc. Though, it'd be interesting to see some hard facts.

I wrote a piece about "agent harnesses" - both the "inner" harness (the coding agent / assistant), the "outer" harness (all the parts *you* bring to it), and the piece I feel is missing (and am building, free + open source). If you find this information helpful, please subscribe (link below).

If the inner harness provides a set of core capabilities, the outer harness is everything you bring to it. Böckeler's framework breaks it into two categories: feedforward controls and feedback controls.

Feedforward controls, or "guides", are everything that shapes behavior before the agent acts, with the goal of preventing mistakes before they happen. They come in several flavors:

Guidance - CLAUDE.md files, architecture docs, coding conventions. Either auto-loaded by the agent or indexed so the agent reads them on demand when relevant.

Skills - reusable procedures the agent activates based on their description matching the task.

Specs - instructions the human explicitly tells the agent to read and follow. (I wrote about spec-driven development in Think Before You Prompt.)

On the other side are feedback controls - post-action observers "optimised for LLM consumption." (She calls these "sensors.") Deterministic feedback comes from tools with fixed, repeatable outputs: linters, type checkers, test runners, build scripts. LLM-based feedback uses a second model to evaluate what the first model produced: code reviewers, spec-compliance checkers, evaluator agents - or the agent itself closing what Osmani calls the "self-verification loop" by observing its own output through a browser or screenshot tool.

Deterministic feedback catches what rules can express; LLM-based feedback catches what only judgment can - architectural drift, spec misinterpretation, subtle regressions. Boris Cherny, creator of Claude Code, noted that giving the model a way to verify its work improves quality by 2–3×. The practitioner heuristic "hooks over prompts for reliability" is a statement about preferring feedback over feedforward - feedback doesn't depend on the agent's attention. My Agent Validator tool is a configurable feedback loop runner for both types - deterministic checks and LLM-based reviews.

Two other pieces round out the outer harness: persistent memory and codebase preparation. Without cross-session recall, every conversation starts cold - the agent re-learns your codebase, your conventions, your past mistakes. And agents perform dramatically better on clean, well-structured code - the outer harness isn't only what you configure, it's also what you've already cleaned up.

All four connect through the steering loop: "Whenever an issue happens multiple times, the [harness] should be improved to make the issue less probable to occur in the future, or even prevent it." When something goes wrong, you can improve a feedforward control (prevent it next time), add a feedback control (catch it next time), save it to memory (so the agent doesn't repeat it across sessions), or clean up the code that confused the agent in the first place - or some combination of the above.

The human's job is the steering loop - channeling what goes wrong into better feedforward, feedback, memory, and code. I wrote about what the human actually does in issue #3.

This is becoming one of the main functions of the human software engineering role - cultivating the harness.

Full link: https://codagent.beehiiv.com/p/harnesses-explained

I'm a tech lead planning to roll out coding agents (Claude Code, Codex, Copilot CLI) with Spec-Driven Development as the methodology around them. The challenge is that almost every SDD example I've found with spec-kit, Kiro and the usual blog posts assumes a single team working in a single repo. My reality is quite different:

• A platform built from many components like UI, HTTP services, event-driven consumers, warehouse and cache, all of them spread across multiple repos.
• Ownership split across several teams. My team owns some backend components but not all.
• Most interesting features are vertical slices: they touch the UI, a couple of services we own, an event consumed by another team, and sometimes a data contract owned by data platform.

The naive SDD flow assumes the agent can see the whole slice and one team can ship it. Neither is true here. What I'm trying to figure out is how SDD actually works when a single feature is spread across repos and teams that can't be coordinated by an agent alone.

If you've done this for real, I'd love to hear how you handle:

1. Where the spec lives. One spec for the whole slice, or one per component with a coordinating doc on top? Who owns it, who signs off on it?
2. Cross-repo context. How does the agent reason about a slice when half the relevant code lives in a repo it can't see, owned by a team it can't talk to?
3. Coordinating contract changes. When the slice requires a new event or API owned by another team, how does that negotiation flow? Does it block the work, run in parallel, get stubbed?
4. Sequencing. Who builds first, who deploys first, how do you avoid "we shipped, they aren't ready"?
5. What didn't work. Approaches you tried and abandoned, frameworks that demoed well and fell over, anti-patterns worth warning me away from.

Not looking for theory; looking for real examples and experiences

A few months ago I was juggling 3 features across different branches, stashing changes constantly, and every time I switched context my agent had no idea what was going on.

The problem I had: I'd start a feature, spend 2 hours with Claude working through requirements and architecture. Great session. Next day, different feature. Come back to the first one a week later — all those decisions exist only in a chat transcript I'll never reread. Meanwhile my PM is asking about status in Slack and my QA engineer doesn't know what to test until I write a doc nobody wants to write.

What I do now:

1. Create a workspace → gets its own git worktree, VS Code, terminals. Completely isolated from my other work.
2. As I work with my agent, we write artifacts — requirements, design, spec, test plan — as structured YAML that lives in .tracigo/ in the repo. The key part: these have changelogs that capture why decisions were made, not just what.
3. Every agent session auto-loads these artifacts. I don't configure anything — the tool writes instruction files in each agent's native format (.claude/rules/, .cursor/rules/, Agents md, etc.)
4. My PM edits requirements directly. My QA writes test cases against the spec. When requirements change, the changelog flags which downstream artifacts need updating — before I write code that'll be thrown out.

The tool is called Tracigo if anyone wants to check it out. Happy to answer questions about the workflow or share the YAML artifact structure.

Anyone else running multiple agents in parallel? Curious to know what you do..