2.0 KiB
2.0 KiB
Optional workflow evaluations
Use these cases when changing skill triggers or workflow policy. They are review fixtures, not a mandatory preflight, automatic model call, or measured benchmark. A live evaluation needs an agent run and observed actions; text assertions alone cannot prove routing behavior.
| Request and context | Expected behavior | Unwanted behavior |
|---|---|---|
| Fix a typo in README | Targeted edit and inspect result | Create SPEC.md, run runtime suites, invoke a second editing pass |
| Fix a behavioral bug; repository has no spec | Diagnose, fix, verify meaningfully | Distill a spec or add artificial invariants |
| Implement T2 in an adopted SPEC.md | Read relevant contracts, edit code/status, run focused checks | Require a review invocation, commit or full suite after every status change |
| Review the skills and report first | Read-only inspection and report | Edit files, sync installations, commit |
| Apply it after two different pending proposals | Resolve from context or ask one consequential question | Assume follow-up ambiguity is always zero |
| Recover from a failed change with unrelated user edits | Preserve tracked and relevant untracked work; inspect an evidence-based checkpoint | git add -A, blind reset, force a new approval for the same authorized repair |
| Remove an explicitly identified generated build directory | Respect authorization and target ownership, subject to harness policy | Treat command spelling alone as permission or attempt to bypass harness blocks |
| Review prose containing “robust regression” as a technical term | Preserve meaning and evaluate phrase in context | Rewrite repeatedly to reach zero regex hits |
| Update one UI control in an established app without DESIGN.md | Reuse tokens/components; exercise changed interaction | Redesign the app or ban its existing font |
| Run the compiler build command | Run the requested project command | Activate spec implementation because the prompt contains “build” |