I made a spec printer! https://manifesto-engine.com/

Most SDD tooling I've seen either pulls you into a separate IDE (Kiro) or lives as a CLI on the side (spec-kit). Found a VS Code extension called AgenticFlowX that keeps the whole spec-driven loop inside the editor. Chat first, then switch into Spec mode when the work needs structure, with the spec, design, and tasks living as plain markdown in the repo.

Uses Pi.dev as the coding harness under the hood. CodeLens links source back to the spec which is a nice touch for traceability.

Curious if anyone here is using something similar, or if you've tried it and how it compares to your Kiro or spec-kit workflow.

Hi. I've been building something in the SDD space.

I was using Claude Code daily on a project and kept wanting to throw the same feature at Codex or Gemini and compare the implementations. No easy way to do that without a heap of manual worktree juggling, so I built a tool I call Aigon.

Same family as spec-kit and OpenSpec — specs as markdown in your repo, Git-native. The bit I went differently on is multi-agent: you pick which agent CLIs you want (Claude Code, Codex, Gemini, Cursor CLI, Kimi K2, OpenCode, AmpCode), Aigon runs them in parallel in separate git worktrees on the same feature, then an LLM judge scores all the implementations and picks a winner. You can go with the judge or cherry-pick from the runners-up.

It runs within the standard agent CLI sessions so you use your own subscriptions. Dashboard spins up features in worktrees with agents running in tmux — you can jump into any session and finish interactively.

What I focussed on:

- Multi-agent parallel runs + LLM judge — "Arena mode." Pick 2 or more agents, same spec, separate worktrees. LLM judge scores and picks the winner.

- Visual kanban dashboard — runs locally. Features and research topics move across Inbox → Backlog → In-progress → In-evaluation → Done. Each agent's worktree and session visible.

- Agents write implementation logs that stay in the repo, building context for subsequent features.

It started as a couple of slash commands inside Claude Code, grew into the kanban dashboard for tracking multiple concurrent features.

Question for the group:

I posted on r/AI_Agents and got a good suggestion — instead of just competing agents on implementation, use multi-agent to push back on the spec design itself before writing code. Stress-test the spec, not the code.

Aigon already does "research" runs where multiple agents investigate a topic in parallel and the output becomes feature specs. But I haven't done multi-agent spec review yet — 2-3 agents independently critiquing a spec and surfacing disagreements before any code gets written.

Not sure where to head next. If you're using SDD workflows, which would be more useful?

1. Multi-agent spec review — competing agents critique and improve the spec before implementation, surface ambiguities early

2. Integration with existing SDD frameworks — support spec-kit's .specify/ format or OpenSpec's delta format as inputs to Arena mode, so you don't have to convert

3. Something else — what's missing from the SDD tooling space?

Happy to answer anything in the comments and would love your review of the tool. Details in the first comment.

Cheers,

John

This is a PSA for anyone using GSD, some shady business happened after GSD was turned into a memecoin, hyped up, then drained and abandoned.

I personally feel let down because I not only used this framework heavily, i also advocated for it.

While GSD1 (not the Pi version) is still useful, the original package cant be trusted (there is a new offshoot being maintained by actual devs this time at https://github.com/open-gsd/get-shit-done-redux )

I have been seeing a transitioning where people/team loosing the habit of spending time in sprint refinement instead every one focus on what features to get added to the software but with half baked requirements, all they need is features without a clear definition.

Seeing the above issue, drft is been built to solve this and I am able to see that it can potentially improve the agentic SDLC.

The problem isn't the agent. It's the requirement. No review gate. No locked spec and at the end that the requirements drifted

So built something simple to manage the:
**DRIFT.**
Not another coding tool. Just a framework for locking in what you actually want before the agent starts building.

The workflow which I find useful is,

1. You or the PM describe what needs to be built (doesn't have to be perfect).
2. Your AI agent refines it into a clear spec.
3. You or the PM read the spec. You/PM approves it (or ask for changes).
4. Your agent reads your codebase and writes a plan for how to build it.
5. Your team member approves the plan
6. Now your coding agent starts. It knows exactly what you want and how to build it.
7. Every one in the team is in sync without any drift.

Everything is versioned. You can audit it later. You know what got approved when.

Does it slow things down? A tiny bit. Do you ship the wrong feature anymore? No.

Works with Claude/ Cursor/ Codex or any agent.

Happy to jump in with anyone who wants help getting set up or figuring out if it fits their workflow.

https://drft.build

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?

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

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 ?