72 lines
2.1 KiB
Markdown
72 lines
2.1 KiB
Markdown
# Mode Evaluation
|
|
|
|
Use these checks after the global evaluator.
|
|
|
|
## technical-review
|
|
|
|
- Does it name the actual failure mode?
|
|
- Does it preserve severity words like wrong, unacceptable, broken, dodgy, shitty when present?
|
|
- Does it avoid praise before criticism?
|
|
- Does it keep concrete implementation nouns?
|
|
- Does it distinguish blocker from preference?
|
|
|
|
Reject if it says:
|
|
|
|
- "There may be some architectural concerns"
|
|
- "This is a solid start"
|
|
- "It would be worth considering"
|
|
|
|
## spec-direction
|
|
|
|
- Does it preserve commands as commands?
|
|
- Does it keep tool names, file names, PR instructions, and output constraints?
|
|
- Does it avoid narrating what the assistant will do?
|
|
- Does it stop once the instruction is complete?
|
|
|
|
Reject if it turns:
|
|
|
|
- "commit and push" into "consider committing and pushing"
|
|
- "use the github skill" into "use relevant tooling"
|
|
- "do not edit" into an implied preference
|
|
|
|
## casual-opinion
|
|
|
|
- Does it keep the thinking-out-loud rhythm?
|
|
- Does it preserve mild uncertainty when the source has it?
|
|
- Does it avoid UX/product jargon?
|
|
- Does it keep blunt visual/product judgements blunt?
|
|
|
|
Reject if it turns:
|
|
|
|
- "looks rough" into "requires refinement"
|
|
- "weird shit" into "unconventional setup"
|
|
- "cluttering up the ui" into "adding visual noise" unless the user asked for polish
|
|
|
|
## debugging-help
|
|
|
|
- Does it keep exact commands, errors, stack fragments, and observed state?
|
|
- Does it ask for root cause rather than generic steps?
|
|
- Does it avoid support-agent reassurance?
|
|
- Does it preserve severity when the user is clearly frustrated?
|
|
|
|
Reject if it says:
|
|
|
|
- "Let's work through this step by step"
|
|
- "It sounds like the issue is persisting"
|
|
- "Could you provide more details" when the needed detail is already present
|
|
|
|
## formal-public
|
|
|
|
- Does it explain what changed and why it mattered?
|
|
- Does it avoid release-note phrasing?
|
|
- Does it keep the hook conversational or blunt?
|
|
- Does it use uncertainty honestly for WIP/not deployed items?
|
|
- Does it avoid inspirational endings?
|
|
|
|
Reject if it says:
|
|
|
|
- "improved operational resilience"
|
|
- "enhanced user experience"
|
|
- "this journey shows"
|
|
- "key takeaway"
|