BDD lightweight Feature Highlighter extension

Sometimes You Just Need the Highlighter

The extension: Feature Highlighter on VS Marketplace

The repo: GitHub - Feature-Highlighter

I’ve ridden the SpecFlow rollercoaster that lead to Reqnroll. Before that it was Cucumber. The BDD dream was always the same: write human-readable specs, generate tests, keep everyone on the same page. The reality was also always the same: developers hate writing Gherkin, and eventually the feature files become artifacts that nobody maintains.

But here’s the thing. In 2026, those feature files have become valuable again, just not for the reason we originally wrote them.

The GenAI Context Problem

I’ve written about my ICECAP workflow before. Interview stakeholders, transcribe, generate Gherkin features, generate code and tests in parallel. The feature files are the backbone of the whole operation. They’re the contract. The checklist. The pause point where you can verify the LLM understood what you need.

The features live in a Specs project alongside the code. They’re versioned. They’re human-readable. And critically, they give the LLM context about what the software is supposed to do.

When you’re working with Claude or any other LLM on a codebase, those Gherkin files are gold. They explain intent in plain English. They describe expected behaviors. They’re basically a requirements document that doesn’t lie, because it’s been verified against the actual code through tests.

Or at least, that’s the theory.

The Two-Sided Problem

I’m a longtime Reqnroll fan (née SpecFlow). The extension does exactly what BDD extensions should do: syntax highlighting, step definition navigation, automatic binding generation. All the automation you need to practice BDD without wanting to throw your keyboard through a window.

But my new team hasn’t embraced BDD. We’re not running automated tests. That’s their prerogative. Different teams, different tools, different comfort levels.

This creates a problem on both ends. When I have Reqnroll installed, it’s doing its job: generating backing code for automated tests. Step definition skeletons. Test scaffolding. All the machinery of BDD automation. But we’re not using that machinery. So I’ve got generated code cluttering my PRs, noise everywhere. The extension is working exactly as designed, for a workflow we’re not following.

Meanwhile, my teammates who don’t have any extension installed? They open a feature file and see a wall of plain text. No color. No structure. The Given/When/Then keywords don’t stand out. The scenarios blur together. Reading unformatted Gherkin is like reading poetry as a paragraph. You lose the rhythm that makes it useful.

I still want the feature files. They’re too valuable as context documents for GenAI workflows. But I need a middle path.

The Goldilocks Problem

So I needed something in between. Not the full SpecFlow/Reqnroll extension with all its code generation. But not plain text files either, because reading unformatted Gherkin is like reading poetry as a wall of prose. You lose the structure.

The syntax highlighting matters. When you’re scanning a feature file, you need to see the Given/When/Then structure at a glance. You need the scenarios to stand out. You need to parse intent quickly. That’s true for humans reviewing the specs, and it’s true when you’re deciding which files to include in LLM context.

What I wanted was just the highlighter. No generation. No bindings. No build integration. Just pretty colors on .feature files so my team can read them without squinting.

Vibes and Attribution

So I did what any reasonable developer does in 2026: I vibe-coded it.

The Reqnroll extension is open source, which meant I could look at exactly how they do their syntax highlighting. Solid work. Well-structured. The kind of code that makes you appreciate that someone else solved this problem thoroughly.

I extracted the highlighting logic, wrapped it in a minimal VS extension, and published it. The whole thing took an afternoon. Most of that was fighting with the VSIX packaging, because of course it was.

The attribution matters. This isn’t my clever invention. This is standing on the shoulders of the Reqnroll team and extracting just the piece I needed. The extension readme says so explicitly. If you want the full BDD experience with test generation and binding navigation, go install Reqnroll. If you just want to read your feature files without a wall of monochrome text, this is the lighter option.

The Actual Extension

It’s called Feature Highlighter. You can find it on the Visual Studio Marketplace and the source is on GitHub. It does exactly one thing: syntax highlighting for .feature files.

I uninstall Reqnroll, install this instead, and the code generation stops. My teammates install it, and suddenly the feature files are readable. Everyone sees the same colored Gherkin. Nobody gets unwanted build artifacts.

The Broader Point

This is what strategic doing looks like in practice. I’m not trying to sell my team on adopting BDD and convince them of the value of feature files. My need was: readable feature files without extra generated code boating my PRs. My solution was: extract just the highlighting.

Sometimes the best engineering decision is the one that removes friction without requiring everyone else to change. The feature files stay in the repo. The LLM context stays intact. The team doesn’t have to learn new tooling. Everyone gets what they need.

That’s not revolutionary. That’s just pragmatism. But pragmatism is underrated, especially when you’re trying to ship software for civic organizations that can’t afford six months of tooling debates.

* * *

The extension: Feature Highlighter on VS Marketplace

The repo: GitHub - Feature-Highlighter

The Reqnroll project (for the full BDD experience): reqnroll.net