Initial commit

commands/bupkis.md

@@ -0,0 +1,111 @@
+---
+description: Get guidance on writing idiomatic bupkis assertions
+argument-hint: '[what-to-assert]'
+---
+
+# Bupkis Assertion Guidance
+
+Provide guidance on writing idiomatic assertions using the bupkis testing library.
+
+## Usage
+
+```bash
+/bupkis [optional: what you're trying to assert]
+```
+
+**Arguments:**
+
+- `what-to-assert` (optional): Describe what you're trying to test or assert
+
+## Instructions
+
+When this command is invoked:
+
+1. **Load the bupkis assertion patterns skill** from `skills/bupkis-assertion-patterns/SKILL.md`
+
+2. **If the user provided context**, analyze their needs and:
+   - Identify which patterns from the skill apply to their situation
+   - Provide specific code examples using those patterns
+   - Explain why the recommended approach is better
+   - Show before/after comparisons from the skill when helpful
+
+3. **If no context was provided**, offer to help by:
+   - Asking what they're trying to test or assert
+   - Listing common scenarios:
+     - Checking if properties exist on objects
+     - Verifying object structure and types
+     - Testing arrays or collections
+     - Validating promise behavior
+     - Type checking values
+   - Offering to show examples of specific patterns
+
+4. **Always emphasize key principles**:
+   - Using semantic assertions over indirect checks
+   - Combining related checks with `to satisfy`
+   - Choosing positive assertions when possible (e.g., `to be defined` vs `not to be undefined`)
+   - Letting assertions imply related checks (e.g., `to be an object` implies non-null)
+   - Using `expectAsync` for promise-based assertions
+
+## Example Interactions
+
+**With context:**
+
+```text
+User: /bupkis checking if an object has multiple numeric properties
+
+Agent: For checking multiple properties with specific types, use `to satisfy`
+with nested `expect.it()` assertions:
+
+✅ DO - concise, shows structure at a glance:
+expect(state, 'to satisfy', {
+  filesCompleted: expect.it('to be a number'),
+  suitesCompleted: expect.it('to be a number'),
+  tasksCompleted: expect.it('to be a number'),
+});
+
+This is better than separate assertions because:
+- Shows the expected structure clearly
+- Better error messages show exactly which properties failed
+- More maintainable - all related checks in one place
+```
+
+**With specific code:**
+
+```text
+User: /bupkis
+How can I improve this?
+expect('filesCompleted' in state, 'to be truthy');
+
+Agent: Instead of checking property existence with the `in` operator,
+use the semantic `to have property` assertion:
+
+✅ DO - clear, semantic assertion:
+expect(state, 'to have property', 'filesCompleted');
+
+This is clearer because it directly expresses your intent and provides
+better error messages when the property is missing.
+```
+
+**Without context:**
+
+```text
+User: /bupkis
+
+Agent: I can help you write idiomatic bupkis assertions! What are you trying to test?
+
+Common scenarios:
+- Checking if properties exist on objects
+- Verifying object structure and types
+- Testing arrays or collections
+- Validating promise behavior
+- Type checking values
+
+You can also paste your current test code and I'll suggest improvements,
+or ask about a specific assertion pattern!
+```
+
+## Related Files
+
+- [Bupkis Assertion Patterns Skill](../skills/bupkis-assertion-patterns/SKILL.md)
+- [API Reference](../skills/bupkis-assertion-patterns/references/api_reference.md)
+- [Common Patterns](../skills/bupkis-assertion-patterns/references/common_patterns.md)