spec_generator

Extract the problem, root cause, and context from the issue, then populate the Workable Spec JSON schema with verified files_to_modify, ordered implementation steps, and a testing_strategy. All file paths must be confirmed to exist in the repository first.

The schema requires issue_id in owner/repo#number format, a summary object with problem, root_cause, and context, an implementation_plan with files_to_modify and steps, and a testing_strategy with test_file, expected_behavior, verification_steps, and framework.

No. Test files such as *.test.ts or *.spec.ts must be excluded from files_to_modify and placed in testing_strategy.test_file instead. Mixing them breaks the downstream automated code generation pipeline.

Failures usually come from schema deviations such as nesting objects inside the steps array, escaping single quotes with backslashes, or listing nonexistent file paths. Every step must be a flat string and all paths must be verified against the repository.

The testing_strategy.framework field is an enum limited to Vitest or N/A. Use Vitest when a relevant test file exists and N/A when no automated test applies to the fix.