yutna
UserAgent Skills that turn requirements into readable Gherkin and keep the suite trustworthy. For Claude Code.
Categories
Indexed Skills (82)
gherkin-automation
Implement and repair the code behind Gherkin steps. Use when writing or refactoring step definitions, wiring glue code to an application, sharing state between steps, building test data, adding hooks, diagnosing why an individual scenario is flaky or slow, resolving undefined or ambiguous step errors, or deciding what belongs in a scenario versus a unit test. Covers Cucumber Expressions, parameter types, the layering rule, isolation, determinism, and per-language notes for JavaScript, Java, Python, .NET, Go, and Ruby.
gherkin-discovery
Turn a vague story, ticket, or requirement into agreed concrete examples before any scenario is written. Use when acceptance criteria are missing or ambiguous, when a feature request is too abstract to build, when the team disagrees about scope, when nobody can say what "done" means, or when asked to find edge cases and open questions for a piece of work. Produces a set of business rules with worked examples and unanswered questions, ready to be phrased as Gherkin.
gherkin-scenario-review
Critique and repair feature files that already exist. Use when reviewing a pull request that touches .feature files, when asked whether a scenario is any good, when a suite has grown unreadable or brittle, when auditing acceptance criteria inherited from another team, or when asked to clean up or refactor existing Gherkin. Supplies a catalogue of scenario smells with the rewrite for each, a review rubric, and guidance on delivering the feedback.
gherkin-scenario-writing
Write Gherkin feature files and scenarios that read as behaviour rather than test scripts. Use when drafting or rewriting a .feature file, turning acceptance criteria or a user story into Given/When/Then, naming scenarios, choosing between a Scenario and a Scenario Outline, deciding whether a Background is justified, or when asked what a scenario should say. Covers the full Gherkin keyword set, declarative phrasing, data tables, doc strings, tags, and localisation.
gherkin-suite-design
Shape a whole body of feature files rather than one scenario. Use when setting up a BDD suite from scratch, deciding how to organise or split feature files, designing a tagging strategy, publishing scenarios as living documentation, deciding what runs in continuous integration and when, or introducing BDD into a codebase that already has tests. Concerns the shape of the whole suite, not the code behind any one step. Covers folder layout, feature granularity, tag taxonomy, suite health metrics, migration, and failure triage.
applying-solid-functionally
Use when a function takes a whole service to use one part, when adding a variant forces edits everywhere, or when structuring module dependencies.
capturing-the-domain
Use when starting a feature or system, when code and the business use different words for the same thing, or when drawing boundaries between subsystems.
choosing-precise-names
Use when naming a function, type or variable, when a name is vague like data or handle, or when a name is generic or unusually hard to pick.
choosing-types-or-plain-data
Use when deciding whether a shape belongs in a type or stays generic data, when fields vary by tenant, config, or request, or when wrapper types feel heavy.
composing-functions
Use when two steps do not fit together, when deciding parameter order, or when a signature is partial rather than total.
constraining-primitive-values
Use when domain values are raw strings or numbers, when the same format or range check appears in more than one place, or when ids can be swapped.
crossing-io-boundaries
Use when mapping between domain types and JSON, database rows, or API payloads, or when a storage or wire shape has leaked into the domain model.
deciding-what-matters
Use when code is correct but hard to follow, when deciding what an interface should expose, or when a reader cannot tell which parts are important.
defining-errors-out-of-existence
Use when error handling dwarfs the happy path, when the same failure is handled in many places, or when an interface forces callers to handle rare cases.
designing-deep-modules
Use when designing a module interface, when it exports nearly as much as it hides, or when many tiny modules or one-function files multiply.
designing-what-to-observe
Use when deciding what to log, trace, or measure, when an incident could not be diagnosed from what was recorded, or when adding observability late.
designing-workflow-pipelines
Use when implementing a use case, command handler, or business process, or when logic for one operation is scattered across services and layers.
diagnosing-complexity
Use when a small change touches many files, when an edit breaks a module nobody expected, when code is slow to read, or when complexity looks self-inflicted.
enforcing-consistency-boundaries
Use when deciding what one transaction must cover, when two entities have to stay in step, or when identity and equality of domain values are unclear.
folding-over-data
Use when a loop accumulates into a variable, when combining a collection into one value, or when traversing a tree or other recursive structure.
functional-design
Use when starting design or review, deciding how much design a task warrants, from a throwaway script to a subsystem, unsure which skill fits, or the requirement is undecided.
functional-elixir-phoenix
Use when designing a Phoenix context, an Ecto schema or changeset, a LiveView's assigns, or deciding what belongs in the domain rather than in the web layer.
functional-javascript
Use when applying functional design in plain JavaScript, without a type checker, including immutability, tagged unions, and Result-style error handling.
functional-react-nextjs
Use when building React or Next.js interfaces functionally, deciding between derived and stored state, or placing logic across the server and client boundary.
functional-typescript-effect
Use when applying functional design in a TypeScript project built on the Effect library, including services, layers, schema boundaries, and tagged errors.
functional-typescript-ts-pattern
Use when a TypeScript project uses ts-pattern for matching, including exhaustive dispatch over unions, state machines, and Result handling.
functional-typescript
Use when applying functional design in TypeScript without a functional library, including branded types, discriminated unions, and hand-rolled Result.
handling-errors-with-results
Use when a function throws and callers cannot tell, when exceptions cross module boundaries, or when validation must report every problem.
hiding-information
Use when callers know how a module works inside, when one data format appears in several modules, or when each step of a process became a module.
making-effects-reliable
Use when a timeout leaves an effect unsure, when a retry could charge or send twice, when a saved change is published separately, or across systems.
making-illegal-states-unrepresentable
Use when a type can hold combinations the business forbids, when booleans and nullable fields encode state, or when code guards impossible values.
managing-state-immutably
Use when code mutates shared data or updates a record in place, when a concurrent update is lost or races, or when deciding how state changes over time.
modeling-state-machines
Use when an entity has a lifecycle, when a status field drives branching, or when a function must ask what state a value is in before acting on it.
modeling-with-algebraic-types
Use when designing domain types, when a record has many optional fields, or when choosing between a record, a union, and a bare primitive.
parameterizing-dependencies
Use when domain code needs a database, clock, or service, when tests need heavy mocking, or when deciding how to supply I/O to business logic.
programming-strategically
Use when a deadline tempts a shortcut, when editing existing code, or when a codebase degrades a little with every change.
refactoring-toward-functional-design
Use when moving imperative or object-oriented code to functional design, when a code smell needs a move, or when a shape cannot absorb new requirements.
reviewing-functional-design
Use when reviewing a design, a diff, or a module, before merging a change, or when judging whether functional code meets a design standard.
separating-layers
Use when adjacent layers repeat the same abstraction, when a function only forwards, when callers repeat the same lines after it, or when a utility carries a feature's policy.
separating-pure-core-from-shell
Use when business logic cannot be tested without I/O, when one call deep inside forces every caller to become async, or when deciding where a database or HTTP call belongs.
splitting-and-joining-code
Use when deciding whether to split a function or module, when a boolean parameter selects behaviour, or when two pieces always change together.
testing-functional-code
Use when writing tests for functional code, when tests need heavy mocking or a database to check a rule, or when deciding what to test and how.
translating-gof-patterns
Use when reaching for a factory, strategy, visitor or other class-based pattern, when porting object-oriented code, or when a pattern feels heavy.
using-recursion-and-laziness
Use when a stack overflows, when data is too large to hold in memory, when an expensive result is recomputed, or when writing recursive functions.
writing-useful-comments
Use when writing or reviewing comments and documentation, when a comment restates the code, or when a contract cannot be expressed in a type.
functional-applying-solid-functionally
Use when a function takes a whole service to use one part, when adding a variant forces edits everywhere, or when structuring module dependencies.
functional-capturing-the-domain
Use when starting a feature or system, when code and the business use different words for the same thing, or when drawing boundaries between subsystems.
functional-choosing-precise-names
Use when naming a function, type or variable, when a name is vague like data or handle, or when a name is generic or unusually hard to pick.
functional-choosing-types-or-plain-data
Use when a shape could be a type or a generic map, when fields or columns vary by tenant or user, when a schema must be a value, or when wrapper types block generic code.
functional-composing-functions
Use when two steps do not fit together, when deciding parameter order, or when a signature is partial rather than total.
functional-constraining-primitive-values
Use when domain values are raw strings or numbers, when the same format or range check appears in more than one place, or when ids can be swapped.
functional-crossing-io-boundaries
Use when mapping between domain types and JSON, database rows, or API payloads, or when a storage or wire shape has leaked into the domain model.
functional-deciding-what-matters
Use when code is correct but hard to follow, when deciding what an interface should expose, or when a reader cannot tell which parts are important.
functional-defining-errors-out-of-existence
Use when error handling dwarfs the happy path, when the same failure is handled in many places, or when an interface forces callers to handle rare cases.
functional-designing-deep-modules
Use when designing a module interface, when it exports nearly as much as it hides or is as complicated as its implementation, or when tiny one-function modules multiply.
functional-designing-what-to-observe
Use when deciding what to log, trace, or measure, when an incident could not be diagnosed from what was recorded, or when adding observability late.
functional-designing-workflow-pipelines
Use when implementing a use case, command handler, or business process, or when logic for one operation is scattered across services and layers.
functional-diagnosing-complexity
Use when a small change touches many files, when an edit breaks a module nobody expected, when code is slow to read, or when complexity looks self-inflicted.
functional-elixir
Use when designing Elixir structs, ok and error tuples, or `with` pipelines, and whether a GenServer, a supervision tree, or letting a process crash is the right answer.
functional-enforcing-consistency-boundaries
Use when deciding what one transaction must cover, when two entities have to stay in step, or when identity and equality of domain values are unclear.
functional-folding-over-data
Use when a loop accumulates into a variable, when combining a collection into one value, when the same tree walk keeps being written again, or when a combining law matters.
functional-handling-errors-with-results
Use when a function throws and callers cannot tell, when exceptions cross module boundaries, or when validation must report every problem.
functional-hiding-information
Use when callers know how a module works inside, when one data format appears in several modules, or when each step of a process became a module.
functional-making-effects-reliable
Use when a timeout leaves an effect unsure, when a retry could charge twice, when a saved change is published separately, or when spawned background work outlives its request.
functional-making-illegal-states-unrepresentable
Use when a type can hold combinations the business forbids, when booleans, flags, or nullable fields encode state like loading and failed, or when code guards impossible values.
functional-managing-state-immutably
Use when code mutates shared data or updates a record in place, when a concurrent update is lost or races, or when parallel work needs cancelling together.
functional-modeling-state-machines
Use when an entity has a lifecycle, when a status field drives branching, or when a function must ask what state a value is in before acting on it.
functional-modeling-with-algebraic-types
Use when designing domain types, when a record has many optional fields, or when choosing between a record, a union, and a bare primitive.
functional-parameterizing-dependencies
Use when domain code needs a database or clock, when tests need heavy mocking, or when an effect system or library makes simple code ceremonial where a plain function would do.
functional-programming-strategically
Use when a deadline tempts a shortcut, when editing existing code, or when a codebase degrades a little with every change.
functional-refactoring-toward-functional-design
Use when moving imperative or object-oriented code to functional design, when a code smell needs a move, or when a shape cannot absorb new requirements.
functional-reviewing-functional-design
Use when reviewing a design, a diff, or a module, before merging a change, or when judging whether functional code meets a design standard.
functional-separating-layers
Use when adjacent layers repeat the same abstraction, when a function only forwards, when callers repeat the same lines after it, or when a utility carries a feature's policy.
functional-separating-pure-core-from-shell
Use when business logic cannot be tested without I/O, when one call deep inside forces every caller to become async, or when deciding where a database or HTTP call belongs.
functional-splitting-and-joining-code
Use when deciding whether to split a function or module, when a boolean parameter selects behaviour, or when two pieces always change together.
functional-testing-functional-code
Use when writing tests for functional code, when tests need heavy mocking or a database to check a rule, when deciding what to test, or turning a claimed law into a property.
functional-translating-gof-patterns
Use when reaching for a factory, strategy, visitor or other class-based pattern, when porting object-oriented code, or when a pattern feels heavy.
functional-typescript-react-nextjs
Use when placing logic across the server and client boundary in Next.js, writing a Server Action, invalidating a cache after a mutation, or deciding what may cross.
functional-typescript-react
Use when a React component's props grow, when an effect computes state that render could derive, or when deciding what belongs in a global store and what a selector should.
functional-typescript-xstate
Use when a lifecycle needs nested states, regions active at the same time, delayed transitions, or an actor per row, and whether a statechart beats a plain reducer.
functional-using-recursion-and-laziness
Use when a stack overflows, when data is too large to hold in memory, when an expensive result is recomputed, or when writing recursive functions.
functional-writing-useful-comments
Use when writing or reviewing comments and documentation, when a comment restates the code, or when a contract cannot be expressed in a type.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.