gherkin-feature-writer — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited gherkin-feature-writer (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use this skill when the user asks to write or normalize a .feature file, express behavior or acceptance criteria as Given/When/Then scenarios, or author BDD specs for Cucumber, Behave, SpecFlow, Reqnroll, or any Gherkin-compatible runner.
Use it to produce standard-compliant, declarative Gherkin that reads as living documentation and stays maintainable as the system evolves.
Do NOT use this skill to write step-definition / glue code, design the feature itself, or convert exhaustive boundary tables that belong in unit tests. This skill writes the specification, not the automation.
references/gherkin-reference.md for exact syntax before using Background, Scenario Outline, Data Tables, Doc Strings, or Rule.references/gherkin-best-practices.md.assets/feature-template.feature as the scaffold. One Feature per file; capitalize keywords.| Situation | Use | |
|---|---|---|
| High-level intent, business-readable spec | Declarative style (default) | |
| Precondition shared by ALL scenarios in the file | Background (keep it short; only true shared setup) | |
| Same behavior across several input/output sets | Scenario Outline + Examples with <placeholder> | |
| Grouping scenarios under one business rule | Rule (Gherkin v6+) with nested examples | |
| Structured input/output data for one step | Data Table (`\ | ) or Doc String ("""`) |
| Categorizing/filtering runs (smoke, wip, regression) | Tags (@tag) above Feature/Scenario | |
| Step needs "and"/"but" continuation | And / But — never a conjunction inside one step | |
| Dozens of boundary rows or exhaustive edge cases | Push to unit tests; keep Gherkin to stakeholder-relevant behavior |
Given — preconditions / existing state. No actions, no assertions.When — the single action or event under test.Then — observable, verifiable outcome. No actions.And / But / * — continue the previous step type.Produce a valid .feature file with this structure (see assets/feature-template.feature):
@optional-feature-tags
Feature: <concise capability name>
As a <role>
I want <capability>
So that <business value>
Background: # optional — shared preconditions only
Given <shared state>
@optional-scenario-tags
Scenario: <one concise behavior, stated as outcome>
Given <precondition>
When <single action>
Then <observable outcome>
And <additional outcome>Rules: one Feature per file; keep scenarios to a single-digit step count (<10); each scenario independent (no scenario depends on another's side effects); third-person consistent voice; descriptive scenario titles that name the behavior, not the procedure.
Before returning the file, verify:
Feature with a value statement (role / capability / benefit).Given/When/Then used in their correct roles; no actions in Then, no assertions in Given.And/But.Scenario Outline used only for variations of the same behavior; Examples columns match <placeholders>.Background holds only setup shared by all scenarios; no assertions in it..feature.references/gherkin-reference.md — standard keyword/syntax reference with examples. Read before using advanced constructs.references/gherkin-best-practices.md — declarative style, anti-patterns, titling, step-count rules.assets/feature-template.feature — annotated scaffold and worked declarative example.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.