Test-Only Workflow
When this applies
Section titled “When this applies”Use this workflow when production behavior is already implemented and the real problem is missing or weak automated coverage. The workflow consists of running 202 to generate Gherkin scenarios from the existing code, followed by 302 to implement those scenarios.
If the immediate problem is a red automated test and you do not yet know whether the defect is in the test, in source, or in intended behavior, use 402-test-correction first instead of starting with 302.
Example prompt sequence
Section titled “Example prompt sequence”First, generate the test scenarios based on the existing implementation:
Run 202 to analyze the existing code to determine what the end-to-end user test scenarios should be for this implemented feature. Identify any potential gaps or inconsistencies in the implementation that we need to make sure we're testing.Review the generated feature file output. Once you are satisfied with the scenarios, proceed to implement the tests. You can target specific scenarios or run them all at once:
Run 302 for test number 2 within the billing retry feature.Run 302 for all tests in @.specflow/features/[fid]-[feature-slug]Why not 301?
Section titled “Why not 301?”301 is for substantial implementation work. 302 exists to keep test-only work from silently turning into broader production changes.
If the current implementation disagrees with the requested scenarios, fix the mismatch first instead of normalizing it inside 302.
If you are not confident that the implementation is actually correct, route through 402-test-correction before deciding whether the next step is 302 or 301.