Help us improve
Share bugs, ideas, or general feedback.
From Harness Base
Writes Gherkin .feature files from a user story so non-technical stakeholders can sign off on behavior. Use before implementing any user-visible behavior change.
npx claudepluginhub camilool8/harness-engineering-templates --plugin harness-baseHow this skill is triggered — by the user, by Claude, or both
Slash command
/harness-base:methodology-bddThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A `.feature` file is the shared contract between engineering and a non-technical
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
A .feature file is the shared contract between engineering and a non-technical
stakeholder. Its single test of quality: can a product or compliance person read
it and confirm the behavior is correct?
Before implementing any user-visible behavior change, when a stakeholder outside engineering needs to sign off, or when the behavior has enough variants to warrant executable documentation.
Create the feature file. Write features/<slug>.feature using the
Feature template at the end of this skill. Create features/ if needed.
Write the Feature: from the user story. Capture role, capability, and
business value. This is the why.
Write scenarios as outcomes. Name each scenario after the result, not the action ("Overdue customer is blocked from checkout", not "Test checkout"). Cover the happy path plus the meaningful edge cases — typically three to seven scenarios. Do not generate dozens from one story.
Use business language, never UI language.
Given a customer with an overdue invoiceGiven the user clicks the blue "Pay" button
UI-language steps lock the spec to the current implementation and break on
every redesign.Stay declarative. State what behavior is expected, not the click-by- click procedure. The step definitions handle the how.
Use Background for shared preconditions and Scenario Outline +
Examples when one behavior varies only by input — do not copy-paste near-
identical scenarios.
Create features/<slug>.feature with this structure:
Feature: <capability in plain language>
# One or two sentences of context: who benefits and why this behavior exists.
As a <role>
I want <capability>
So that <business value>
Background:
# Steps common to every scenario below. Keep it minimal — only true
# preconditions, no test data noise.
Given <a shared precondition>
Scenario: <the happy path, named as an outcome>
Given <a known starting state in domain terms>
When <the event or action the actor takes>
Then <the observable outcome>
And <a further expected outcome, if any>
Scenario: <a meaningful edge case, named as an outcome>
Given <a different starting state>
When <the same or related action>
Then <the different expected outcome>
Scenario Outline: <a behavior that varies by input>
Given <a starting state using <placeholder> values>
When <an action involving "<input>">
Then <the outcome should be "<result>">
Examples:
| input | result |
| <value1> | <value1> |
| <value2> | <value2> |