Settings

Everything the plugin adds lives under Settings → Tools → SpecBinder. The defaults are chosen to be sensible on a fresh project, so nothing here is required — but two of them, both on the General page, are worth a look on day one.

General

The two options worth a look on day one both sit on Settings → Tools → SpecBinder → General: which files the plugin handles, and what happens when you save one.

Recognized file extensions has two choices:

• .feature and .specb: SpecBinder handles both. Use it when SpecBinder is your only Gherkin plugin.
• .specb only: SpecBinder handles .specb files and leaves .feature to the Cucumber/Gherkin plugin. Use it when both plugins are installed, so that each works on its own files.

One page, three controls: which files the plugin handles, what a save does, and spell checking.

When a spec file is saved has three choices:

• Recompile marker class: build that class immediately. Thus you can edit a step, save, and run the test. The generated code is already current.
• Touch marker class: mark the class for a rebuild, but do not build it now. The next build that you start regenerates the test class.
• Off: do nothing when you save.

The marker class is the class annotated with @Gherkin2JUnit, from which SpecBinder generates the test class at build time.

The recompile covers every kind of change to a spec file. Add a Rule, add a Scenario, write a new step, change the wording of an existing one, extend an Examples table or edit a doc string — then save the file. The plugin regenerates the test class immediately, so the generated code is current before you run anything.

Editor

How a spec file looks while you edit it.

• Fold on open: three checkboxes — Rules, Scenarios, Doc strings. Each ticked kind of element starts folded whenever a spec file opens, so a long spec, or one carrying large payloads, opens as an outline rather than a wall of text — see Editing spec files.
• Show doc-string previews inline: an image, svg or html type doc-string parameter gets an eye icon in the gutter, beside the parameter's opening """. A click renders the content under the step, so an image or a page can be checked visually without leaving the spec. The bar colour only sets the previews apart from the surrounding text — see Inline previews.

Fold on open takes a tick per kind of element — Rules, Scenarios, Doc strings — and inline previews sit below it with their bar colour.

Split view

What can open beside a spec file. A row of buttons in the editor's top-right corner switches between the views:

• three layout buttons — the spec file alone, the spec file and a tab side by side, or the tab alone;
• past a divider, one document button per enabled tab — Execution Report (a page with a tick) first, then Test Code (</>) — picking which document the other side shows.

The options below decide which tabs are offered.

• Test Code and Execution Report decide which documents can open beside a spec file. Execution Report is worth turning on once tests run with the SpecBinder reporter, so the last run sits next to the spec that produced it — see Execution report as Gherkin.
• Show JUnit TestReporter entries: shows the values a step published during the run — URLs, ids, payloads — under that step in the report, the first place to look when a run needs explaining — see Execution results.
• Linked-ranges colour: the highlight that pairs a line in the spec with the matching line on the other side.

Each ticked tab gets a document button in the editor's top-right corner, beside the three shared layout buttons — an unticked tab is never offered.

Execution results

How a run's results are drawn — see Execution results.

• Icon style: JUnit-style circles match the badges IntelliJ puts on ordinary tests; SpecBinder chevrons match the spec file's own icon.
• Project-code frames: picks out the stack-trace lines in the project's own classes, so the frame that matters stands out among the framework frames.
• Show Expected / Actual previews: renders the expected and actual values of an HTML, image or SVG assertion in the error panel, for a visual comparison instead of a text diff.

The two icon styles are shown side by side with every status, so you can pick one without running a test first.

Project view

How spec files appear in the Project tool window.

• Show file members in Project view: lists each spec's Rules and Scenarios under the spec file in the tree, so a scenario is one click away in the Project window — see Editing spec files.
• Reflect execution status in spec file icons and Mark folders that contain spec files with a status chevron, optionally with Use heavier chevrons: colour spec files, and the folders containing spec files, by the last result, so a failure deep in the tree shows from the top — see Spec file and folder status.

File members start switched off, while both status markers — on spec file icons and on folders — start switched on.

Agent integration

The AI agent button on the editor toolbar — see Agent integration.

• Show a "Launch AI agent" button on the toolbar: puts a button on the editor toolbar that opens a Claude Code session already pointed at this spec.
• Badge spec file icons with the linked agent's working state: then marks spec files whose agent is working or waiting for input, so the spec that needs attention stands out. Claude Code only.

The badge option sits under the launch button because it depends on it, and it starts switched off.

Elsewhere in Settings

Two things sit outside the SpecBinder page, alongside IntelliJ's own equivalents.

Colours for Gherkin tokens — Settings → Editor → Color Scheme → Gherkin (SpecBinder). The colour page lists every element of a spec file as its own entry: each keyword, title and description, tags, step parameters, doc strings, tables, outline placeholders and comments. Each entry takes its own colour, weight and effects, so the whole of a spec file's highlighting can be set to taste, and the sample below the list shows each change as it is made — see Editing spec files.

One entry per element of a spec file, each with its own colour, weight and effects, and a sample that shows every change at once.

Formatting — Settings → Editor → Code Style → Gherkin (SpecBinder). The code-style page sets what Reformat Code produces for a spec file:

• Tabs and Indents: the indent per nesting level and the tab size, and whether to indent with tab characters or spaces.
• Commenting: whether a line commented out with the comment shortcut keeps the # at the first column or at the line's own indent.
• Blank Lines: whether Reformat Code ensures at least one blank line between the elements of a spec file.

See Editing spec files for Reformat Code itself.

Three tabs, and a sample beside them that reformats as each setting changes.