What problem does it solve? End-to-end tests are the slowest and most expensive tests in a project, so writing unnecessary ones — or ones that assert nothing meaningful — wastes CI time while giving false confidence. This Skill guides you through deciding when an e2e scenario is actually owed, and how to write one that genuinely guards behavior rather than just confirming a message arrived. ## Core Features & Use Cases - Necessity gate: Decides whether a change earns an e2e scenario at all — only callback-keyboard dispatch, bugs that escaped unit tests, or extreme real-input cases qualify. - Scenario authoring rules: Enforces the describeScenario structure, chat-driving verbs (say, tap, replyToPrompt, tapRaw, restartBot), and assertion discipline (assert text before captions, capture button data from the hardest state, never import from src/). - Clean-ending enforcement: Ensures every scenario closes all keyboards the way a real evening ends, since leftover tappable screens corrupt later runs. - Use Case: After adding a new inline-keyboard feature to the bot, use this Skill to write a *.e2e.spec.ts that plays a full game against a real bot process and asserts what the scenario can actually see. ## Quick Start Write an e2e scenario for the new seating-order keyboard feature following the rules in this skill.
