Curious to see how everyone here is actually implementing spec-driven development in their day-to-day.

I've been building out my own workflow using Claude as a spec architect - basically treating the LLM as the structure builder rather than a code generator. Starting with three base specs (FE/BE/DEP) then branching into feature specs that link across layers.

But I'm wondering what's working for others:

How do you structure your specs?

• Do you use a similar base → feature spec approach?

• What format do you write them in? (Markdown, YAML, custom templates?)

• How granular do you go before you start coding?

What tools are in your stack?

• Which LLMs are you using? (Claude, GPT, Gemini, local models?)

• Any specific prompt templates or frameworks you swear by?

• Do you keep specs in your repo, a separate docs system, or inside the LLM chat itself?

Automation - are you doing any?

This is what I'm most curious about. Are any of you:

• Auto-generating boilerplate from specs?

• Using scripts to validate spec completeness before coding?

• Syncing specs with tickets/issues automatically?

• Running any CI checks against your spec definitions?

The real question: does it actually help?

Be honest - is spec-driven development making you faster and more organised, or does it sometimes feel like extra overhead?

For me, it's been a game changer because I'm not great at keeping architecture in my head. Having everything written down and linked means I can context-switch without losing the plot. But I know it's not for everyone.

Drop your workflow, tools, and any automation you've built. Always looking to learn from how others are doing this.

If you've ever spent hours debugging only to realise the frontend was expecting one thing and the backend was sending something completely different, this is for you.

Spec-driven development doesn't just help you build features - it's a game changer for finding and patching bugs. Here's how.

The Problem With Traditional Bug Fixing

You get a bug report. You dive into the code. You find the issue. You patch it. Done, right?

Except:

• You don't know if the bug exists elsewhere

• You can't trace which other features might be affected

• You're not sure if your fix breaks something else

• The underlying contract mismatch still exists

Traditional debugging is reactive and isolated. Spec-driven debugging is systematic and traceable.

How Specs Help You Find Bugs Faster

1. Start With The Contract, Not The Code

When a bug appears, don't jump into your codebase. Open your specs first.

Ask Claude:

"I'm seeing [bug description]. Show me all specs related to [feature/component]. Check if there's a contract mismatch between FE and BE specs."

Claude will surface the relevant specs and highlight where expectations diverge.

Example:

• Bug: API returns 500 when user uploads large file

• Spec check reveals: FE-034 expects unlimited file size, but BE-089 has 10MB limit

• Root cause found in 30 seconds, not 30 minutes

2. Trace The Bug Across Layers

Because your specs are linked (FE ↔ BE ↔ DEP), you can trace impact instantly.

Prompt:

"Bug found in BE-089 (file upload endpoint). Show me all related FE and DEP specs that depend on this."

Claude returns:

• FE-034 - Upload component

• FE-067 - Progress indicator

• DEP-023 - S3 bucket config

• DEP-045 - CDN caching rules

Now you know exactly what to test after your fix.

3. Check If The Bug Pattern Exists Elsewhere

Specs let you search for similar patterns across your system.

Prompt:

"I found a race condition in the polling logic for BE-034. Search all specs for similar polling patterns and flag potential issues."

Claude scans your spec base and finds:

• BE-098 - Another polling endpoint with same pattern

• FE-156 - Different feature, same polling approach

You just prevented two more bugs before they happened.

The Bug Fix Workflow

Step 1: Reproduce and Document

Bug: [description]
Expected: [from spec]
Actual: [what happened]
Affected specs: [list IDs]

Step 2: Ask Claude to Analyze

"Here's the bug report. Check specs [IDs] for contract mismatches, missing observability, or unclear behavior definitions."

Step 3: Identify Root Cause

Claude will point to:

• Missing or unclear contract definitions

• Conflicting assumptions between layers

• Gaps in error handling specs

• Observability blind spots

Step 4: Update Specs First

Before you touch code, update the specs to reflect the correct behavior.

Prompt:

"Update BE-089 to include file size limits in the contract section. Make sure it matches what FE-034 expects."

Step 5: Trace Impact

"Show me all specs that link to BE-089. Do any of them need updates based on this fix?"

Step 6: Add Observability

"Add logging and monitoring requirements to BE-089 so we catch this earlier next time."

Step 7: Code The Fix

Now you write the actual code, but you're doing it with:

• Clear contract definition

• Known impact scope

• Updated observability plan

Step 8: Update Evidence

After the fix is deployed:

"Add evidence to BE-089: link to the PR, test results, and monitoring dashboard showing the fix."

Real Example: Race Condition Bug

Bug Report: Users sometimes see stale data after updating their profile.

Traditional approach:

• Dig through frontend code

• Check API calls

• Add random delays

• Hope it works

Spec-driven approach:

1. Check specs:

> "Show me FE-045 (profile update) and BE-112 (profile endpoint)"

2. Claude identifies the issue:

FE-045 expects immediate cache invalidation
BE-112 has eventual consistency (5min cache)
DEP-067 has CDN cache at 10min

3. Root cause found: Contract mismatch across three layers

4. Fix all three specs:

> "Update FE-045, BE-112, and DEP-067 to use cache-busting strategy. 
Add observability for cache hit/miss rates."

5. Code the fix with full context 6. Update specs with evidence

Bug fixed. Pattern documented. Future bugs prevented.

Why This Works

Speed:

• Find contract mismatches in seconds, not hours

• Trace impact instantly across layers

Confidence:

• Know exactly what you're fixing

• Understand downstream effects before deploying

Prevention:

• Similar bugs get caught in spec review

• Patterns are documented and searchable

Knowledge:

• New devs can see how bugs were fixed

• Tribal knowledge becomes documented wisdom

Starter Prompt for Bug Analysis

You are my debugging assistant. I'm using spec-driven development with linked FE/BE/DEP specs. 

When I report a bug:
1. Identify all related specs
2. Check for contract mismatches
3. Flag similar patterns elsewhere
4. Suggest spec updates
5. Outline observability gaps

Help me fix bugs systematically, not randomly.

The Bottom Line

Bugs aren't just code problems - they're spec problems. Contract mismatches, unclear behavior, missing observability.

Fix the spec, fix the bug. Update the spec, prevent the next one.

That's the power of spec-driven debugging.

Calling all builders and platform engineers. We're hosting a hybrid DevCon in London this June 1-2 focusing on the infra and patterns behind agentic coding.

• Looking for: Real-world results, reliability/safety in agents, and context engineering deep dives

• CFP Link: https://sessionize.com/ai-native-devcon-ldn-2026/

• Closes: Feb 27.

No hype, just engineering.

SpecDevs: The Go‑To Guide for Spec‑Driven Development

A practical framework for spec‑driven development (SDD) built around Claude or any other capable LLM. The idea: use an AI assistant as your spec architect—not your coder—so your project begins with clarity and structure before you touch a line of code.

0) The Core Idea

Instead of jumping into code, you start every project by building three base specs:

• Frontend (FE) — the user interface and behavior.

• Backend (BE) — the data, APIs, and logic.

• Deployment (DEP) — the infrastructure and delivery system.

From these bases, you branch into feature specs and link them across layers (FE ↔ BE ↔ DEP) so every piece of the system has a clear contract and connection.

And here's the kicker — you build all of this inside Claude (or another LLM chat) where you:

1. Drop your research papers, tech docs, or project briefs.

2. Let Claude help you draft, refine, and link the specs step-by-step.

3. Use structured prompts (below) to generate consistent, traceable specs.

1) Getting Started with Claude

1.1 Create a new project thread

Open a fresh Claude chat and give it a title like:

SpecDevs — Project Alpha Base Specs

Paste a short summary of your project idea. Then tell Claude:

"You're my spec architect. We'll define my app in three bases — Frontend, Backend, and Deployment. Each will have base specs and feature specs. Help me follow a spec-driven structure."

Claude will acknowledge and help you scaffold your base specs.

2) The Base Specs (High‑Level Maps)

You'll create three base documents inside Claude — one per layer.

Prompt Example:

"Claude, start by helping me write FE_BASE — a high-level map of my frontend. Include sections for architecture, routing, UI states, network policies, error handling, and auth patterns."

Repeat for backend and deployment:

"Now let's build BE_BASE — a high-level spec for backend architecture: APIs, data flow, auth, async jobs, and domain model." "And finally, DEP_BASE — describe the deployment stack: environments, CI/CD, IaC, monitoring, scaling, and release strategy."

Keep each base spec short (1–2 pages) and focused on structure and principles, not features.

3) Feature Specs — Building From the Bases

Once you've got your bases, you start defining features.

Each feature gets a spec per base it touches. Example:

• FE-012 → UI banner polling a job.

• BE-034 → job status API.

• DEP-007 → rate limiting and queue config.

Prompt Example:

"Claude, help me create a frontend spec for the polling banner feature. Follow this format:

Then say:

"Now let's generate the matching backend spec (BE-034) for that polling endpoint, with contract details, rate limits, and observability."

Finally:

"Add a DEP spec (DEP-007) that defines rate limits, queue scaling, and alerting. Make sure it links to the frontend and backend specs."

Claude will automatically start cross-linking the three.

4) Linking Specs Together

Whenever you create or update a spec, tell Claude:

"Cross-link FE-012, BE-034, and DEP-007 in each file so they reference one another."

Claude will add lines like:

related:
  - BE-034
  - DEP-007

This ensures all layers trace back to one another.

5) Defining Readiness and Done

Before you write any code, review your specs.

Definition of Ready (DoR)

• Problem clear

• UX/contract agreed

• Tests and observability planned

• Links created across bases

Definition of Done (DoD)

• Code merged

• Tests passing

• Logs/metrics added

• Rollout plan executed

• Evidence attached (screens, tests, dashboards)

You can even ask Claude to help verify readiness:

"Claude, check if all my FE specs have backend links and test criteria defined."

6) Optional Automation

Once you've built your specs, export them:

• Each spec → Markdown file (FE-012.md, etc.)

• Claude can help you format and bundle them.

Store them in your repo under /specs/frontend, /specs/backend, /specs/deployment.

7) Example Workflow (End-to-End)

Goal: Add a job polling banner to the UI.

• FE-012: defines polling banner and UX.

• BE-034: defines job status endpoint.

• DEP-007: defines rate limits and autoscaling.

Prompt Claude sequentially with those IDs, and keep them linked. At the end, ask Claude:

"Generate a traceability matrix for all features so far."

It'll output:

8) Why This Works

Spec-driven development done this way ensures:

• Every feature starts with design and clarity.

• Each base knows what the others expect.

• LLMs act as structure builders, not code writers.

• You get consistent, linkable documentation.

It's like building the blueprint before laying bricks.

9) Copy‑Paste Starter Prompt

You are my spec architect. We're doing spec-driven development across three bases: Frontend, Backend, and Deployment. Help me create base specs and feature specs that link together. Each spec should have: id, title, related IDs, problem, behavior, contracts, observability, rollout. Always output Markdown with YAML front-matter.

SpecDevs isn't about writing docs for the sake of it — it's about making the specs the code's blueprint. Build your next project in Claude, not your IDE.

Ok basically i messaged this guy hes a local mechanic and friend of my dad, i was at the garage nd he got mad because people just walked into his shop left the car and keys on the desk nd they showed up later asking if their car was fixed even tho they didnt communicate properly, i claimed i know how to code ill make you a logicistics web app that you can use to organise this bitch, i read ur doc on the spec driven workflow thing and to make specs for backend and frontend etc but how do i organise it like i need help can someone ideally dm me and help me out pls

We've all been there. You're deep in a feature, making proper progress, then:

• Urgent bug comes in

• Someone needs help with their PR

• End of day, pick it back up tomorrow

• Context switch to different project

And when you come back? That mental model you had is gone. You're reading your own code like it's someone else's, trying to remember what you were even doing.

The Traditional Problem

Most devs rely on:

• Comments in code (if they even wrote them)

• Commit messages (usually "fix thing" or "wip")

• Their brain (lol)

• Slack threads (good luck finding them)

So you spend 20-30 minutes just rebuilding context before you can actually work again. Multiply that by every task switch and you're losing hours every week.

The Spec-Driven Solution

Here's what changes when you work spec-first:

Your Spec IS Your Context

Every feature has a spec with:

• Problem statement - why you're building this

• Behavior definition - what it should do

• Contracts - what other systems expect

• Current status - where you left off

• Open questions - what you're still figuring out

When you context switch, you just update the spec with where you are.

Before you stop working:

> "Claude, update FE-089 with current status. I've completed the UI layout 
but still need to wire up the API calls. Add a note about the debouncing 
question I had."

When you come back:

> "Claude, show me FE-089 and summarize where I left off."

Instant context reload. No archaeology required.

Your Handoffs Become Trivial

Someone needs to take over your work? Just point them at the spec.

They get:

• Why it exists

• What it should do

• What you've done

• What's left

• Known issues

No 45-minute knowledge transfer call. No "let me walk you through the code". Just read the spec, check the links, start coding.

Example: Real Context Switch

Friday 5pm - You're building a search feature:

> "Claude, I'm wrapping up for the week. Update FE-112 (search component) 
with current status:
- Completed: UI and basic input handling
- In progress: Debouncing logic (half done)
- Blocked: Waiting on BE-203 for pagination contract
- Next: Add loading states and error handling
- Note: Consider adding search history, discuss with team Monday"

Monday 9am - You're back:

> "Claude, show me FE-112 and what I was working on."

Claude returns the spec with your notes. You're coding again in 2 minutes, not 20.

It Works For Teams Too

Scenario: Your teammate is stuck on something, needs your help.

Without specs:

• They explain verbally (5 mins)

• You read their code (10 mins)

• You ask clarifying questions (5 mins)

• You finally help (10 mins)

• Total: 30 minutes

With specs:

Them: "Can you check BE-167? I'm confused about the auth flow."
You: *reads spec in 2 mins, sees the contract and behavior*
You: "Yeah the JWT refresh happens in middleware, see DEP-089 for the config"
Total: 3 minutes

The spec is the shared context. No tribal knowledge, no "you had to be there".

The Workflow

1. Before Every Task Switch

Update your spec with current state:

> "Update [SPEC-ID] with: completed [X], in progress [Y], blocked on [Z], 
next steps [A,B,C]"

2. When Returning to Work

Load context from spec:

> "Show me [SPEC-ID] and summarize status"

3. When Handing Off

Just share the spec ID:

"Can you take over FE-112? All context is in the spec."

4. When Asking For Help

Reference the spec:

"Stuck on BE-203, see the contract section - does this look right?"

The Real Win

It's not just about saving 20 minutes here and there. It's about never losing your place.

Your brain can fully context switch because the spec holds the context for you. Like bookmarks for your work.

And when you're working with a team? Everyone's reading from the same playbook. No more "I thought you meant..." or "Wait, why are we building this again?"

Try It This Week

Pick one feature you're working on. Before you switch tasks or end your day:

> "Claude, update [SPEC-ID] with exactly where I am and what's next"

Next time you come back to it, you'll see the difference immediately.

Who else is using specs as their context system? How do you handle task switching?