reproduce-first

Reproduce user-visible bugs with a failing E2E spec before fixing code.

43|2|Updated Jan 25, 2024
One-click install
npx skills add https://github.com/glowingkitty/OpenMates --skill reproduce-first
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reproduce-first
Source: https://github.com/glowingkitty/OpenMates/tree/main/.agents/skills/reproduce-first
Command: npx skills add https://github.com/glowingkitty/OpenMates --skill reproduce-first

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents accidental, unverified fixes by ensuring every bug-fix session starts by reproducing the user-visible failure with a failing end-to-end specification.

Core Features & Use Cases

  • Step-1 Bug Understanding (Context Gathering): Parses an issue id (e.g., Linear OPE-123) and pulls full context via MCP functions, or asks targeted clarifying questions when given free-text.
  • Step-2 Spec Selection or Proposal: Checks for an existing E2E spec in the correct test suite, proposes a minimal new spec when none exists, or asks before extending an adjacent spec when one seems incomplete.
  • Step-3 Red Confirmation Workflow: Requires that the selected or newly added spec fails (RED) via the project’s test runner before any fix code is written.
  • Step-4 Minimal Fix & Step-5 Green Verification: Applies the smallest possible code change to make the spec pass (GREEN), reruns the same spec to confirm, and optionally checks adjacent tests to reduce regressions.
  • Use Case: When a user reports a wrong UI behavior or regression in an application flow, start this skill to produce a reliable failing E2E test that proves the bug exists before changing implementation code.

Quick Start

Run reproduce-first with the issue id or a brief description of the bug so the workflow can produce (or locate) a spec that reproduces the failure.

Frequently Asked Questions about reproduce-first

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why should I reproduce a bug with an E2E test before fixing it?

Reproducing a bug with an E2E test before fixing it prevents accidental, unverified fixes by proving the user-visible failure exists with a failing spec, ensuring your code change directly targets the regression.

How do I create a failing E2E spec from a Linear issue?

To create a failing E2E spec from a Linear issue, provide the issue id like OPE-123. The workflow parses the issue context via MCP, checks for an existing .spec.ts file, or proposes a new one before enforcing a RED run.

What is the test-first workflow for fixing UI regressions?

The test-first workflow for fixing UI regressions involves reproducing the failure with an end-to-end spec, confirming the test fails RED via run_tests.py, applying a minimal code change, and verifying the same spec passes GREEN.

Can I use a free-text bug description instead of a Linear issue id?

Yes, you can use a free-text bug description instead of a Linear issue id. When provided, the workflow asks targeted clarifying questions to gather enough context to propose an appropriate failing test specification.

Does this bug reproduction workflow work with existing Playwright tests?

Yes, this bug reproduction workflow works with existing Playwright tests by checking the correct test suite for an appropriate .spec.ts file. It proposes a minimal new spec only when none exists or asks before extending an incomplete adjacent spec.

What happens after the minimal code change is applied to fix the bug?

After the minimal code change is applied to fix the bug, the workflow reruns the same E2E spec to confirm it passes GREEN, and optionally checks adjacent tests to reduce the risk of introducing new regressions in the application flow.