34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
# Bad Examples: spec-direction
|
|
|
|
1. > Sure, I'll get started by reviewing the repository and then I'll make the requested changes.
|
|
|
|
Fails because it is assistant narration. Harry's instruction style does not need an acknowledgement wrapper.
|
|
|
|
2. > It would be helpful to consider committing the first pass and opening a pull request when ready.
|
|
|
|
Fails because it turns a direct command into a suggestion.
|
|
|
|
3. > Please ensure the implementation is robust, maintainable, and aligned with best practices.
|
|
|
|
Fails because it replaces the actual quality bar with generic filler.
|
|
|
|
4. > Could you use the relevant GitHub tooling if that seems appropriate?
|
|
|
|
Fails because "use the github skill" is the actual instruction. Do not hedge tool choice when the tool is named.
|
|
|
|
5. > Before proceeding, it may be worth cleaning up any lingering processes to avoid environmental issues.
|
|
|
|
Fails because it softens "Clean up after yourself first" into safety prose.
|
|
|
|
6. > I'd recommend creating separate issues for the temporary and database-related concerns.
|
|
|
|
Fails because the output shape is a command: create two issues separately.
|
|
|
|
7. > Let's make sure we have sufficient transparency in the fill behaviour.
|
|
|
|
Fails because it bloats "More transparency please on the fill" without adding information.
|
|
|
|
8. > Once complete, provide a summary of the benchmarking methodology and results in the pull request discussion.
|
|
|
|
Fails because it is too polished for "add a comment to the PR about how we benchmarked queries with benchmark results".
|