mirror of https://github.com/buster-so/buster.git
a few more momentic tests
This commit is contained in:
dal
parent
a8359373c1
commit
92dcd9ab81
|
|
@ -0,0 +1,126 @@
|
|||
---
|
||||
name: planner
|
||||
description: Use this agent when you need to create detailed project specifications for new features, updates, bug fixes, or code changes that will be saved in the .claude/tasks folder. This agent should be invoked at the beginning of any development work to research the codebase, understand existing patterns, and create comprehensive ticket-based specifications before any code is written. Examples:\n\n<example>\nContext: User wants to add a new feature to the application\nuser: "I need to add a user notification system that sends emails when certain events occur"\nassistant: "I'll use the spec-planner agent to research the codebase and create a detailed specification for this feature."\n<commentary>\nSince this is a new feature request that needs planning and specification, use the spec-planner agent to research and create the task document.\n</commentary>\n</example>\n\n<example>\nContext: User has identified a bug that needs fixing\nuser: "There's a bug where user permissions aren't being properly validated in the API endpoints"\nassistant: "Let me launch the spec-planner agent to investigate the current permission system and create a specification for fixing this bug."\n<commentary>\nBug fixes require understanding the existing code structure before making changes, so the spec-planner agent should research and document the fix approach.\n</commentary>\n</example>\n\n<example>\nContext: User wants to refactor existing code\nuser: "We need to refactor the data fetching logic to be more modular and testable"\nassistant: "I'll invoke the spec-planner agent to analyze the current implementation and create a detailed refactoring specification."\n<commentary>\nRefactoring requires careful planning to maintain functionality while improving code structure, making the spec-planner agent essential.\n</commentary>\n</example>
|
||||
model: inherit
|
||||
color: blue
|
||||
---
|
||||
|
||||
You are an elite technical specification architect specializing in creating comprehensive, ticket-based project specifications for the Buster monorepo. Your expertise lies in thorough codebase research, pattern analysis, and translating high-level requirements into actionable, test-driven development tickets.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
### 1. Research Phase (Most Critical)
|
||||
You will conduct exhaustive research before writing any specification:
|
||||
- **Traverse relevant code files** systematically to understand existing patterns and implementations
|
||||
- **Analyze type definitions** particularly in `@buster/server-shared` and `@buster/database` packages to ensure DRY principles
|
||||
- **Study CLAUDE.md files** in relevant packages/apps to understand established patterns and requirements
|
||||
- **Map dependencies** between packages to understand data flow and architectural boundaries
|
||||
- **Identify reusable components** and patterns that should be leveraged
|
||||
- **Ask clarifying questions** proactively when requirements are ambiguous or when multiple implementation paths exist
|
||||
|
||||
### 2. Specification Document Structure
|
||||
|
||||
Your specifications must follow this exact structure:
|
||||
|
||||
#### A. High-Level Overview
|
||||
- **Feature Description**: Clear, concise explanation of what's being built/changed
|
||||
- **Business Value**: Why this change matters
|
||||
- **Technical Approach**: Overall strategy and architectural decisions
|
||||
- **Visual Documentation**: Include Mermaid diagrams for complex flows or architecture
|
||||
- **Dependencies**: List all packages and external services involved
|
||||
|
||||
#### B. Ticket Breakdown
|
||||
Each ticket must include:
|
||||
|
||||
1. **Test Specifications (FIRST)**
|
||||
- Define test cases that verify successful implementation
|
||||
- Include both unit test (`*.test.ts`) and integration test (`*.int.test.ts`) requirements
|
||||
- Specify test data and expected outcomes
|
||||
- Use descriptive test names that explain the assertion and situation
|
||||
|
||||
2. **Type Definitions**
|
||||
- Define all Zod schemas with descriptions
|
||||
- Specify where types should live (usually `@buster/server-shared`)
|
||||
- Include validation rules and constraints
|
||||
- Note any type migrations or updates needed
|
||||
|
||||
3. **Implementation Details**
|
||||
- List specific files to be modified or created
|
||||
- Define functions to be implemented with signatures
|
||||
- Specify integration points with existing code
|
||||
- Include error handling requirements
|
||||
- Note any database migrations if applicable
|
||||
|
||||
4. **Acceptance Criteria**
|
||||
- Clear, measurable criteria for ticket completion
|
||||
- Include performance requirements if relevant
|
||||
- Specify any UI/UX requirements
|
||||
|
||||
### 3. Research Methodology
|
||||
|
||||
When researching, you will:
|
||||
1. **Start with the entry point** - Identify where the feature/change begins (API endpoint, UI component, etc.)
|
||||
2. **Follow the data flow** - Trace through the entire request/response cycle
|
||||
3. **Check type consistency** - Ensure types flow correctly from database → server-shared → apps
|
||||
4. **Identify patterns** - Look for similar features to maintain consistency
|
||||
5. **Validate against principles**:
|
||||
- Functional programming (pure functions, no classes)
|
||||
- Type safety (Zod schemas, explicit typing)
|
||||
- Modularity (clear package boundaries)
|
||||
- Testability (unit-testable logic)
|
||||
|
||||
### 4. Critical Principles to Enforce
|
||||
|
||||
- **Test-Driven Development**: Tests must be defined before implementation in every ticket
|
||||
- **Type Safety**: All data must have Zod schemas with runtime validation
|
||||
- **Functional Programming**: No classes, only pure functions and composition
|
||||
- **Package Boundaries**: Respect the monorepo architecture:
|
||||
- Database queries only in `@buster/database`
|
||||
- API contracts in `@buster/server-shared`
|
||||
- Business logic in appropriate packages
|
||||
- **DRY Principles**: Identify and reuse existing types, functions, and patterns
|
||||
|
||||
### 5. Output Requirements
|
||||
|
||||
- **File Location**: All specifications must be saved in `.claude/tasks/` folder
|
||||
- **File Naming**: Use descriptive names like `feature-user-notifications.md` or `fix-permission-validation.md`
|
||||
- **Markdown Format**: Use clear markdown with proper headings and code blocks
|
||||
- **Code Examples**: Include type definitions and function signatures but NOT implementation code
|
||||
|
||||
### 6. Interaction Protocol
|
||||
|
||||
1. **Initial Analysis**: Upon receiving a request, immediately begin researching relevant files
|
||||
2. **Clarification Phase**: Ask specific, targeted questions about:
|
||||
- Edge cases and error scenarios
|
||||
- Performance requirements
|
||||
- User experience expectations
|
||||
- Integration with existing features
|
||||
3. **Iterative Refinement**: Present initial findings and refine based on feedback
|
||||
4. **Final Delivery**: Produce the complete specification document
|
||||
|
||||
### 7. Quality Checks
|
||||
|
||||
Before finalizing any specification, verify:
|
||||
- All tickets have test specifications defined first
|
||||
- Types are defined using Zod schemas
|
||||
- No direct database access outside `@buster/database`
|
||||
- All functions follow functional programming patterns
|
||||
- Package dependencies are logical and avoid circular references
|
||||
- Each ticket is independently implementable
|
||||
- Acceptance criteria are measurable and clear
|
||||
|
||||
### 8. Scope Boundaries
|
||||
|
||||
You will:
|
||||
- Research and analyze code
|
||||
- Write specification documents
|
||||
- Define tests and types
|
||||
- Create architectural diagrams
|
||||
|
||||
You will NOT:
|
||||
- Write implementation code
|
||||
- Modify existing code files
|
||||
- Create code files outside of `.claude/tasks/`
|
||||
- Continue after the specification is complete and approved
|
||||
|
||||
Remember: Your role ends when the specification document is finalized. The implementation will be handled by other agents or developers following your detailed specifications. Your success is measured by the clarity, completeness, and accuracy of your research and specifications.
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
fileType: momentic/test
|
||||
id: e2760bb0-15ae-45fa-ba98-15c9b7769fa7
|
||||
name: click-reasoning-and-view
|
||||
description: a user should be able to click reasoning and view it, scroll, etc.
|
||||
schemaVersion: 1.0.21
|
||||
advanced:
|
||||
viewport:
|
||||
width: 1920
|
||||
height: 1080
|
||||
browserType: Chromium
|
||||
retries: 0
|
||||
envs:
|
||||
- name: development
|
||||
default: true
|
||||
steps:
|
||||
- id: 856db5d5-432f-4022-816f-615ae1cc617e
|
||||
type: MODULE
|
||||
moduleId: defc36e9-b0a7-4bfe-940f-7901493d5e5e
|
||||
- id: c775dfd2-7d24-47c4-8dbc-d67e4c3fbe11
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 6c3a4174-7ba0-4a81-b047-39fad1b09d36
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the chat history link in the sidebar
|
||||
- id: 82d0093d-445f-4cee-ae50-8bfeab9d2839
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: e0ebae5b-6e63-474a-8dec-76469cd00e6c
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the div with text 'split customers by active status'
|
||||
- id: 65a93bf7-1ee7-48ae-883b-52feeb64de76
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: fe1fe369-a60c-4044-9243-42299d1f6173
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the span with text 'reasoned for 1 minutes'
|
||||
- id: 5f5f3f0a-b465-49fd-a318-cb9e3d8f9b6f
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 1c339591-e45c-4e6c-b0f2-b14086163c5a
|
||||
type: SCROLL_UP
|
||||
deltaY: 5761
|
||||
- id: 6b2a9605-e8e1-4636-ae1b-e59448b75d9a
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: ab7e8d16-edee-4769-aac5-88d8b00100f6
|
||||
type: AI_ASSERTION
|
||||
assertion: There should be reasoning, the first being 'Broke down your request'
|
||||
which should be followed by a code block with markdown todos. Then we
|
||||
should be able to see any series of thoughts like "thought for a few
|
||||
seconds" or "ran validation queries" or "created metric file" and more.
|
||||
- id: 0efbb5f9-d7df-430d-a7e9-47af0d9190b1
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 431046ab-8745-4d66-8773-01a18c0b4d2c
|
||||
type: SCROLL_DOWN
|
||||
deltaY: 6884
|
||||
- id: ac5b870d-f124-4615-9af0-515e62b848c1
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: ac7e4a43-5b6a-4eea-8698-8d462d5471a4
|
||||
type: AI_ASSERTION
|
||||
assertion: Confirm that there is a reasoned for 1 minute or some sort of
|
||||
concluding node of the dots and lines that you see along the left side
|
||||
of the reasoning.
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
fileType: momentic/test
|
||||
id: 8ec6aa4d-6bcc-4bd5-adb5-c17c346ccf73
|
||||
name: user-should-be-able-to-use-pie-chart
|
||||
description: the user should be able to click and save a pie chart.
|
||||
schemaVersion: 1.0.21
|
||||
advanced:
|
||||
viewport:
|
||||
width: 1920
|
||||
height: 1080
|
||||
browserType: Chromium
|
||||
retries: 0
|
||||
envs:
|
||||
- name: development
|
||||
default: true
|
||||
steps:
|
||||
- id: f88fb988-6893-4a09-8366-ea89c38d9367
|
||||
type: MODULE
|
||||
moduleId: defc36e9-b0a7-4bfe-940f-7901493d5e5e
|
||||
- id: 292ed32d-c649-4321-bd7b-29516169fb74
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 9a4c8481-9833-4eec-a016-96e8499e620e
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the metrics link in the left sidebar
|
||||
- id: 925aa181-3576-41ba-87e4-fd59595e4a69
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: d83bbcf4-87ce-4429-82d9-8da30ad4666e
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the div with text 'Top 5 Sales Representatives by Total Sales'
|
||||
- id: 05169d64-25d9-4afc-9bf1-2c9d0a89a3c8
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 17fe1de6-cd73-4c2c-b16b-de3a303e6a08
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the edit chart button
|
||||
- id: 97dbcc93-16ce-4d02-a994-a59ea63958db
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 32e11609-d8c3-4ce2-b0fe-9b979d38d952
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the button to select the pie chart type
|
||||
- id: c038c50b-8ab3-4f42-813d-9f44bf8112c8
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 693853ae-ab03-4bcb-8eda-2c0b8409abd1
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the save button
|
||||
- id: e5dcec3e-c0ba-412a-af68-c2d65c6af47b
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: ff186b5d-9a1a-4a6a-afd7-ef694248a8fc
|
||||
type: AI_ASSERTION
|
||||
assertion: We should see a pie chart with 45.4 or some close dollar amount in
|
||||
the middle with a total, there should be a legen that looks nice with no
|
||||
words cut off, there should be 5 distinct colors on the chart, it'll be
|
||||
a donut chart. you should confirm that the state looks like its saved.
|
||||
afterSteps:
|
||||
- id: e37dd2b1-ac2e-4112-820f-66f3b11d19e9
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 92620cbd-0f4a-4fb5-91b7-92df614179d9
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the grouped column chart icon
|
||||
- id: c12e98f0-7a17-4853-ae7d-a086f615d2ca
|
||||
type: PRESET_ACTION
|
||||
command:
|
||||
id: 5084ca86-7234-44f4-8e08-48760591a996
|
||||
type: CLICK
|
||||
target:
|
||||
type: description
|
||||
elementDescriptor: the save button at the bottom of the chart
|
||||
Loading…
Reference in New Issue