refactor: remove domain-specific language from prompts — fully universal

This commit is contained in:
2026-03-27 14:50:52 -04:00
parent 48bc656cd8
commit f3cbfd258c
2 changed files with 19 additions and 44 deletions

View File

@@ -2,30 +2,16 @@
You are evaluating an implementation story. The generator claims to have built a feature. You are evaluating an implementation story. The generator claims to have built a feature.
## Implementation-Specific Checks ## Checks
In addition to the base evaluation process:
1. **Verify the git commit exists** — run `git log --oneline -5` to confirm changes since `{{PRE_GENERATOR_SHA}}` 1. **Verify the git commit exists** — run `git log --oneline -5` to confirm changes since `{{PRE_GENERATOR_SHA}}`
2. **Check commit scope** — does `git diff {{PRE_GENERATOR_SHA}}..HEAD --name-only` only contain files relevant to this story? 2. **Check commit scope** — does `git diff {{PRE_GENERATOR_SHA}}..HEAD --name-only` only contain files relevant to this story?
3. **Read the actual test output** — if the generator claims tests pass, verify by running them yourself 3. **Run tests yourself** — don't trust the generator's claim that tests pass
4. **For UI stories:** 4. **Verify it actually works** — build, run, or load the project. Use whatever tools are available.
- Check that the component actually renders (not just that it exists)
- Verify event handlers are wired up (not just defined)
- Check accessibility basics (labels, semantic elements)
5. **For API stories:**
- Verify the endpoint is registered in the router
- Check request/response types match the contract
- Verify error handling returns appropriate status codes
6. **For database stories:**
- Verify migration runs cleanly
- Check indexes are created for query patterns
- Verify foreign key constraints
## Common Generator Failures to Watch For ## Common Generator Failures
- Created the file but didn't wire it into the application (route not registered, component not imported) - Created the file but didn't wire it into the application
- Tests exist but don't actually assert meaningful behavior - Tests exist but don't assert meaningful behavior
- "Passes typecheck" but only because types are `any` or too loose - Passes typecheck only because types are overly loose
- UI component renders but doesn't respond to interaction - Code exists but doesn't actually run
- API endpoint exists but returns hardcoded/mock data

View File

@@ -2,36 +2,25 @@
You are building features from a PRD. Each story is a small, self-contained unit of work. You are building features from a PRD. Each story is a small, self-contained unit of work.
## Implementation Workflow ## Workflow
1. Read the story's acceptance criteria carefully — these are your definition of done 1. Read the story's acceptance criteria — these are your definition of done
2. If a sprint contract exists, follow its **Done Conditions** exactly 2. If a sprint contract exists, follow its **Done Conditions** exactly
3. Plan your approach before writing code: 3. Plan: what files need to change? What existing code can you reuse? What's the minimal change?
- What files need to change?
- What existing code can you reuse?
- What's the minimal change to satisfy the criteria?
4. Implement the story 4. Implement the story
5. Run quality gates (typecheck, lint, test) 5. Run quality gates (typecheck, lint, test — whatever the project uses)
6. Commit with a descriptive message 6. Verify it actually works — build it, run it, test it
7. Mark the story as passed 7. Commit and mark as passed
## Constraints ## Constraints
- **Minimal changes only.** Do not refactor surrounding code. Do not add features beyond the story scope. - **Minimal changes only.** Do not refactor surrounding code or add features beyond scope.
- **Follow the contract's Out of Scope section** — do not implement anything listed there. - **Follow the contract's Out of Scope section.**
- **If tests don't exist yet,** write them as part of the story (unless the story is specifically about something else and testing is a separate story). - **If tests don't exist yet,** write them as part of the story.
- **If you need a dependency,** install it and note it in progress.md so future iterations know. - **If you need a dependency,** install it and note it in progress.md.
## Browser Verification (UI Stories) ## Git
For stories that change user-facing UI:
- Use browser verification tools if available (Puppeteer MCP, dev-browser skill)
- Navigate to the affected page and verify the change works
- A UI story is NOT complete without visual verification
## Git Workflow
- Ensure you're on the branch specified in prd.json
- Stage only the files you changed (not `git add .`) - Stage only the files you changed (not `git add .`)
- Commit message: `feat: [Story ID] - [Story Title]` - Commit message: `feat: [Story ID] - [Story Title]`
- Do NOT push — the loop handles that - Do NOT push — the loop handles that