mirror of
https://github.com/coleam00/Archon.git
synced 2025-12-24 02:39:17 -05:00
refactor: simplify workflow to user-selectable 6-command architecture
Simplifies the workflow orchestrator from hardcoded 11-step atomic operations to user-selectable 6-command workflow with context passing. Core changes: - WorkflowStep enum: 11 steps → 6 commands (create-branch, planning, execute, commit, create-pr, prp-review) - workflow_orchestrator.py: 367 lines → 200 lines with command stitching loop - Remove workflow_type field, add selected_commands parameter - Simplify agent names from 11 → 6 constants - Remove test/review phase config flags (now optional commands) Deletions: - Remove test_workflow.py, review_workflow.py, workflow_phase_tracker.py - Remove 32 old command files from .claude/commands - Remove PRPs/specs and PRD files from version control - Update .gitignore to exclude specs, features, and validation markdown files Breaking changes: - AgentWorkOrder no longer has workflow_type field - CreateAgentWorkOrderRequest now uses selected_commands instead of workflow_type - WorkflowStep enum values incompatible with old step history 56 files changed, 625 insertions(+), 15,007 deletions(-)
This commit is contained in:
Rasmus Widing
@@ -1,56 +0,0 @@
|
||||
# Agent Workflow: Plan
|
||||
|
||||
You are executing a planning workflow for a GitHub issue or project task.
|
||||
|
||||
## Your Task
|
||||
|
||||
1. Read the GitHub issue description (if provided via issue number)
|
||||
2. Analyze the requirements thoroughly
|
||||
3. Create a detailed implementation plan
|
||||
4. Save the plan to `PRPs/specs/plan-{work_order_id}.md`
|
||||
5. Create a git branch named `feat-wo-{work_order_id}`
|
||||
6. Commit all changes to git with clear commit messages
|
||||
|
||||
## Branch Naming
|
||||
|
||||
Use format: `feat-wo-{work_order_id}`
|
||||
|
||||
Example: `feat-wo-a3c2f1e4`
|
||||
|
||||
## Commit Message Format
|
||||
|
||||
```
|
||||
plan: Create implementation plan for work order
|
||||
|
||||
- Analyzed requirements
|
||||
- Created detailed plan
|
||||
- Documented approach
|
||||
|
||||
Work Order: {work_order_id}
|
||||
```
|
||||
|
||||
## Deliverables
|
||||
|
||||
- Git branch created following naming convention
|
||||
- `PRPs/specs/plan-{work_order_id}.md` file with detailed plan
|
||||
- All changes committed to git
|
||||
- Clear commit messages documenting the work
|
||||
|
||||
## Plan Structure
|
||||
|
||||
Your plan should include:
|
||||
|
||||
1. **Feature Description** - What is being built
|
||||
2. **Problem Statement** - What problem does this solve
|
||||
3. **Solution Statement** - How will we solve it
|
||||
4. **Architecture** - Technical design decisions
|
||||
5. **Implementation Plan** - Step-by-step tasks
|
||||
6. **Testing Strategy** - How to verify it works
|
||||
7. **Acceptance Criteria** - Definition of done
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Always create a new branch for your work
|
||||
- Commit frequently with descriptive messages
|
||||
- Include the work order ID in branch name and commits
|
||||
- Focus on creating a comprehensive, actionable plan
|
||||
@@ -1,97 +0,0 @@
|
||||
# Bug Planning
|
||||
|
||||
Create a new plan to resolve the `Bug` using the exact specified markdown `Plan Format`. Follow the `Instructions` to create the plan use the `Relevant Files` to focus on the right files.
|
||||
|
||||
## Variables
|
||||
issue_number: $1
|
||||
adw_id: $2
|
||||
issue_json: $3
|
||||
|
||||
## Instructions
|
||||
|
||||
- IMPORTANT: You're writing a plan to resolve a bug based on the `Bug` that will add value to the application.
|
||||
- IMPORTANT: The `Bug` describes the bug that will be resolved but remember we're not resolving the bug, we're creating the plan that will be used to resolve the bug based on the `Plan Format` below.
|
||||
- You're writing a plan to resolve a bug, it should be thorough and precise so we fix the root cause and prevent regressions.
|
||||
- Create the plan in the `specs/` directory with filename: `issue-{issue_number}-adw-{adw_id}-sdlc_planner-{descriptive-name}.md`
|
||||
- Replace `{descriptive-name}` with a short, descriptive name based on the bug (e.g., "fix-login-error", "resolve-timeout", "patch-memory-leak")
|
||||
- Use the plan format below to create the plan.
|
||||
- Research the codebase to understand the bug, reproduce it, and put together a plan to fix it.
|
||||
- IMPORTANT: Replace every <placeholder> in the `Plan Format` with the requested value. Add as much detail as needed to fix the bug.
|
||||
- Use your reasoning model: THINK HARD about the bug, its root cause, and the steps to fix it properly.
|
||||
- IMPORTANT: Be surgical with your bug fix, solve the bug at hand and don't fall off track.
|
||||
- IMPORTANT: We want the minimal number of changes that will fix and address the bug.
|
||||
- Don't use decorators. Keep it simple.
|
||||
- If you need a new library, use `uv add` and be sure to report it in the `Notes` section of the `Plan Format`.
|
||||
- IMPORTANT: If the bug affects the UI or user interactions:
|
||||
- Add a task in the `Step by Step Tasks` section to create a separate E2E test file in `.claude/commands/e2e/test_<descriptive_name>.md` based on examples in that directory
|
||||
- Add E2E test validation to your Validation Commands section
|
||||
- IMPORTANT: When you fill out the `Plan Format: Relevant Files` section, add an instruction to read `.claude/commands/test_e2e.md`, and `.claude/commands/e2e/test_basic_query.md` to understand how to create an E2E test file. List your new E2E test file to the `Plan Format: New Files` section.
|
||||
- To be clear, we're not creating a new E2E test file, we're creating a task to create a new E2E test file in the `Plan Format` below
|
||||
- Respect requested files in the `Relevant Files` section.
|
||||
- Start your research by reading the `README.md` file.
|
||||
|
||||
## Relevant Files
|
||||
|
||||
Focus on the following files:
|
||||
- `README.md` - Contains the project overview and instructions.
|
||||
- `app/**` - Contains the codebase client/server.
|
||||
- `scripts/**` - Contains the scripts to start and stop the server + client.
|
||||
- `adws/**` - Contains the AI Developer Workflow (ADW) scripts.
|
||||
|
||||
Ignore all other files in the codebase.
|
||||
|
||||
## Plan Format
|
||||
|
||||
```md
|
||||
# Bug: <bug name>
|
||||
|
||||
## Bug Description
|
||||
<describe the bug in detail, including symptoms and expected vs actual behavior>
|
||||
|
||||
## Problem Statement
|
||||
<clearly define the specific problem that needs to be solved>
|
||||
|
||||
## Solution Statement
|
||||
<describe the proposed solution approach to fix the bug>
|
||||
|
||||
## Steps to Reproduce
|
||||
<list exact steps to reproduce the bug>
|
||||
|
||||
## Root Cause Analysis
|
||||
<analyze and explain the root cause of the bug>
|
||||
|
||||
## Relevant Files
|
||||
Use these files to fix the bug:
|
||||
|
||||
<find and list the files that are relevant to the bug describe why they are relevant in bullet points. If there are new files that need to be created to fix the bug, list them in an h3 'New Files' section.>
|
||||
|
||||
## Step by Step Tasks
|
||||
IMPORTANT: Execute every step in order, top to bottom.
|
||||
|
||||
<list step by step tasks as h3 headers plus bullet points. use as many h3 headers as needed to fix the bug. Order matters, start with the foundational shared changes required to fix the bug then move on to the specific changes required to fix the bug. Include tests that will validate the bug is fixed with zero regressions.>
|
||||
|
||||
<If the bug affects UI, include a task to create a E2E test file. Your task should look like: "Read `.claude/commands/e2e/test_basic_query.md` and `.claude/commands/e2e/test_complex_query.md` and create a new E2E test file in `.claude/commands/e2e/test_<descriptive_name>.md` that validates the bug is fixed, be specific with the steps to prove the bug is fixed. We want the minimal set of steps to validate the bug is fixed and screen shots to prove it if possible.">
|
||||
|
||||
<Your last step should be running the `Validation Commands` to validate the bug is fixed with zero regressions.>
|
||||
|
||||
## Validation Commands
|
||||
Execute every command to validate the bug is fixed with zero regressions.
|
||||
|
||||
<list commands you'll use to validate with 100% confidence the bug is fixed with zero regressions. every command must execute without errors so be specific about what you want to run to validate the bug is fixed with zero regressions. Include commands to reproduce the bug before and after the fix.>
|
||||
|
||||
<If you created an E2E test, include the following validation step: "Read .claude/commands/test_e2e.md`, then read and execute your new E2E `.claude/commands/e2e/test_<descriptive_name>.md` test file to validate this functionality works.">
|
||||
|
||||
- `cd app/server && uv run pytest` - Run server tests to validate the bug is fixed with zero regressions
|
||||
- `cd app/client && bun tsc --noEmit` - Run frontend tests to validate the bug is fixed with zero regressions
|
||||
- `cd app/client && bun run build` - Run frontend build to validate the bug is fixed with zero regressions
|
||||
|
||||
## Notes
|
||||
<optionally list any additional notes or context that are relevant to the bug that will be helpful to the developer>
|
||||
```
|
||||
|
||||
## Bug
|
||||
Extract the bug details from the `issue_json` variable (parse the JSON and use the title and body fields).
|
||||
|
||||
## Report
|
||||
- Summarize the work you've just done in a concise bullet point list.
|
||||
- Include the full path to the plan file you created (e.g., `specs/issue-123-adw-abc123-sdlc_planner-fix-login-error.md`)
|
||||
@@ -1,69 +0,0 @@
|
||||
# Chore Planning
|
||||
|
||||
Create a new plan to resolve the `Chore` using the exact specified markdown `Plan Format`. Follow the `Instructions` to create the plan use the `Relevant Files` to focus on the right files. Follow the `Report` section to properly report the results of your work.
|
||||
|
||||
## Variables
|
||||
issue_number: $1
|
||||
adw_id: $2
|
||||
issue_json: $3
|
||||
|
||||
## Instructions
|
||||
|
||||
- IMPORTANT: You're writing a plan to resolve a chore based on the `Chore` that will add value to the application.
|
||||
- IMPORTANT: The `Chore` describes the chore that will be resolved but remember we're not resolving the chore, we're creating the plan that will be used to resolve the chore based on the `Plan Format` below.
|
||||
- You're writing a plan to resolve a chore, it should be simple but we need to be thorough and precise so we don't miss anything or waste time with any second round of changes.
|
||||
- Create the plan in the `specs/` directory with filename: `issue-{issue_number}-adw-{adw_id}-sdlc_planner-{descriptive-name}.md`
|
||||
- Replace `{descriptive-name}` with a short, descriptive name based on the chore (e.g., "update-readme", "fix-tests", "refactor-auth")
|
||||
- Use the plan format below to create the plan.
|
||||
- Research the codebase and put together a plan to accomplish the chore.
|
||||
- IMPORTANT: Replace every <placeholder> in the `Plan Format` with the requested value. Add as much detail as needed to accomplish the chore.
|
||||
- Use your reasoning model: THINK HARD about the plan and the steps to accomplish the chore.
|
||||
- Respect requested files in the `Relevant Files` section.
|
||||
- Start your research by reading the `README.md` file.
|
||||
- `adws/*.py` contain astral uv single file python scripts. So if you want to run them use `uv run <script_name>`.
|
||||
- When you finish creating the plan for the chore, follow the `Report` section to properly report the results of your work.
|
||||
|
||||
## Relevant Files
|
||||
|
||||
Focus on the following files:
|
||||
- `README.md` - Contains the project overview and instructions.
|
||||
- `app/**` - Contains the codebase client/server.
|
||||
- `scripts/**` - Contains the scripts to start and stop the server + client.
|
||||
- `adws/**` - Contains the AI Developer Workflow (ADW) scripts.
|
||||
|
||||
Ignore all other files in the codebase.
|
||||
|
||||
## Plan Format
|
||||
|
||||
```md
|
||||
# Chore: <chore name>
|
||||
|
||||
## Chore Description
|
||||
<describe the chore in detail>
|
||||
|
||||
## Relevant Files
|
||||
Use these files to resolve the chore:
|
||||
|
||||
<find and list the files that are relevant to the chore describe why they are relevant in bullet points. If there are new files that need to be created to accomplish the chore, list them in an h3 'New Files' section.>
|
||||
|
||||
## Step by Step Tasks
|
||||
IMPORTANT: Execute every step in order, top to bottom.
|
||||
|
||||
<list step by step tasks as h3 headers plus bullet points. use as many h3 headers as needed to accomplish the chore. Order matters, start with the foundational shared changes required to fix the chore then move on to the specific changes required to fix the chore. Your last step should be running the `Validation Commands` to validate the chore is complete with zero regressions.>
|
||||
|
||||
## Validation Commands
|
||||
Execute every command to validate the chore is complete with zero regressions.
|
||||
|
||||
<list commands you'll use to validate with 100% confidence the chore is complete with zero regressions. every command must execute without errors so be specific about what you want to run to validate the chore is complete with zero regressions. Don't validate with curl commands.>
|
||||
- `cd app/server && uv run pytest` - Run server tests to validate the chore is complete with zero regressions
|
||||
|
||||
## Notes
|
||||
<optionally list any additional notes or context that are relevant to the chore that will be helpful to the developer>
|
||||
```
|
||||
|
||||
## Chore
|
||||
Extract the chore details from the `issue_json` variable (parse the JSON and use the title and body fields).
|
||||
|
||||
## Report
|
||||
- Summarize the work you've just done in a concise bullet point list.
|
||||
- Include the full path to the plan file you created (e.g., `specs/issue-7-adw-abc123-sdlc_planner-update-readme.md`)
|
||||
@@ -1,39 +0,0 @@
|
||||
# ADW Workflow Extraction
|
||||
|
||||
Extract ADW workflow information from the text below and return a JSON response.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Look for ADW workflow commands in the text (e.g., `/adw_plan`, `/adw_test`, `/adw_build`, `/adw_plan_build`, `/adw_plan_build_test`)
|
||||
- Look for ADW IDs (8-character alphanumeric strings, often after "adw_id:" or "ADW ID:" or similar)
|
||||
- Return a JSON object with the extracted information
|
||||
- If no ADW workflow is found, return empty JSON: `{}`
|
||||
|
||||
## Valid ADW Commands
|
||||
|
||||
- `/adw_plan` - Planning only
|
||||
- `/adw_build` - Building only (requires adw_id)
|
||||
- `/adw_test` - Testing only
|
||||
- `/adw_plan_build` - Plan + Build
|
||||
- `/adw_plan_build_test` - Plan + Build + Test
|
||||
|
||||
## Response Format
|
||||
|
||||
Respond ONLY with a JSON object in this format:
|
||||
```json
|
||||
{
|
||||
"adw_slash_command": "/adw_plan",
|
||||
"adw_id": "abc12345"
|
||||
}
|
||||
```
|
||||
|
||||
Fields:
|
||||
- `adw_slash_command`: The ADW command found (include the slash)
|
||||
- `adw_id`: The 8-character ADW ID if found
|
||||
|
||||
If only one field is found, include only that field.
|
||||
If nothing is found, return: `{}`
|
||||
|
||||
## Text to Analyze
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,21 +0,0 @@
|
||||
# Github Issue Command Selection
|
||||
|
||||
Based on the `Github Issue` below, follow the `Instructions` to select the appropriate command to execute based on the `Command Mapping`.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Based on the details in the `Github Issue`, select the appropriate command to execute.
|
||||
- IMPORTANT: Respond exclusively with '/' followed by the command to execute based on the `Command Mapping` below.
|
||||
- Use the command mapping to help you decide which command to respond with.
|
||||
- Don't examine the codebase just focus on the `Github Issue` and the `Command Mapping` below to determine the appropriate command to execute.
|
||||
|
||||
## Command Mapping
|
||||
|
||||
- Respond with `/chore` if the issue is a chore.
|
||||
- Respond with `/bug` if the issue is a bug.
|
||||
- Respond with `/feature` if the issue is a feature.
|
||||
- Respond with `0` if the issue isn't any of the above.
|
||||
|
||||
## Github Issue
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,33 +1,55 @@
|
||||
# Generate Git Commit
|
||||
# Create Git Commit
|
||||
|
||||
Based on the `Instructions` below, take the `Variables` follow the `Run` section to create a git commit with a properly formatted message. Then follow the `Report` section to report the results of your work.
|
||||
Create an atomic git commit with a properly formatted commit message following best practices for the uncommited changes or these specific files if specified.
|
||||
|
||||
## Variables
|
||||
Specific files (skip if not specified):
|
||||
|
||||
agent_name: $1
|
||||
issue_class: $2
|
||||
issue: $3
|
||||
- File 1: $1
|
||||
- File 2: $2
|
||||
- File 3: $3
|
||||
- File 4: $4
|
||||
- File 5: $5
|
||||
|
||||
## Instructions
|
||||
|
||||
- Generate a concise commit message in the format: `<agent_name>: <issue_class>: <commit message>`
|
||||
- The `<commit message>` should be:
|
||||
- Present tense (e.g., "add", "fix", "update", not "added", "fixed", "updated")
|
||||
- 50 characters or less
|
||||
- Descriptive of the actual changes made
|
||||
- No period at the end
|
||||
- Examples:
|
||||
- `sdlc_planner: feat: add user authentication module`
|
||||
- `sdlc_implementor: bug: fix login validation error`
|
||||
- `sdlc_planner: chore: update dependencies to latest versions`
|
||||
- Extract context from the issue JSON to make the commit message relevant
|
||||
**Commit Message Format:**
|
||||
|
||||
- Use conventional commits: `<type>: <description>`
|
||||
- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`
|
||||
- Present tense (e.g., "add", "fix", "update", not "added", "fixed", "updated")
|
||||
- 50 characters or less for the subject line
|
||||
- Lowercase subject line
|
||||
- No period at the end
|
||||
- Be specific and descriptive
|
||||
|
||||
**Examples:**
|
||||
|
||||
- `feat: add web search tool with structured logging`
|
||||
- `fix: resolve type errors in middleware`
|
||||
- `test: add unit tests for config module`
|
||||
- `docs: update CLAUDE.md with testing guidelines`
|
||||
- `refactor: simplify logging configuration`
|
||||
- `chore: update dependencies`
|
||||
|
||||
**Atomic Commits:**
|
||||
|
||||
- One logical change per commit
|
||||
- If you've made multiple unrelated changes, consider splitting into separate commits
|
||||
- Commit should be self-contained and not break the build
|
||||
|
||||
**IMPORTANT**
|
||||
|
||||
- NEVER mention claude code, anthropic, co authored by or anything similar in the commit messages
|
||||
|
||||
## Run
|
||||
|
||||
1. Run `git diff HEAD` to understand what changes have been made
|
||||
2. Run `git add -A` to stage all changes
|
||||
3. Run `git commit -m "<generated_commit_message>"` to create the commit
|
||||
1. Review changes: `git diff HEAD`
|
||||
2. Check status: `git status`
|
||||
3. Stage changes: `git add -A`
|
||||
4. Create commit: `git commit -m "<type>: <description>"`
|
||||
|
||||
## Report
|
||||
|
||||
Return ONLY the commit message that was used (no other text)
|
||||
- Output the commit message used
|
||||
- Confirm commit was successful with commit hash
|
||||
- List files that were committed
|
||||
|
||||
@@ -1,38 +0,0 @@
|
||||
# E2E Test: Basic Query Execution
|
||||
|
||||
Test basic query functionality in the Natural Language SQL Interface application.
|
||||
|
||||
## User Story
|
||||
|
||||
As a user
|
||||
I want to query my data using natural language
|
||||
So that I can access information without writing SQL
|
||||
|
||||
## Test Steps
|
||||
|
||||
1. Navigate to the `Application URL`
|
||||
2. Take a screenshot of the initial state
|
||||
3. **Verify** the page title is "Natural Language SQL Interface"
|
||||
4. **Verify** core UI elements are present:
|
||||
- Query input textbox
|
||||
- Query button
|
||||
- Upload Data button
|
||||
- Available Tables section
|
||||
|
||||
5. Enter the query: "Show me all users from the users table"
|
||||
6. Take a screenshot of the query input
|
||||
7. Click the Query button
|
||||
8. **Verify** the query results appear
|
||||
9. **Verify** the SQL translation is displayed (should contain "SELECT * FROM users")
|
||||
10. Take a screenshot of the SQL translation
|
||||
11. **Verify** the results table contains data
|
||||
12. Take a screenshot of the results
|
||||
13. Click "Hide" button to close results
|
||||
|
||||
## Success Criteria
|
||||
- Query input accepts text
|
||||
- Query button triggers execution
|
||||
- Results display correctly
|
||||
- SQL translation is shown
|
||||
- Hide button works
|
||||
- 3 screenshots are taken
|
||||
@@ -1,33 +0,0 @@
|
||||
# E2E Test: Complex Query with Filtering
|
||||
|
||||
Test complex query capabilities with filtering conditions.
|
||||
|
||||
## User Story
|
||||
|
||||
As a user
|
||||
I want to query data using natural language with complex filtering conditions
|
||||
So that I can retrieve specific subsets of data without needing to write SQL
|
||||
|
||||
## Test Steps
|
||||
|
||||
1. Navigate to the `Application URL`
|
||||
2. Take a screenshot of the initial state
|
||||
3. Clear the query input
|
||||
4. Enter: "Show users older than 30 who live in cities starting with 'S'"
|
||||
5. Take a screenshot of the query input
|
||||
6. Click Query button
|
||||
7. **Verify** results appear with filtered data
|
||||
8. **Verify** the generated SQL contains WHERE clause
|
||||
9. Take a screenshot of the SQL translation
|
||||
10. Count the number of results returned
|
||||
11. Take a screenshot of the filtered results
|
||||
12. Click "Hide" button to close results
|
||||
13. Take a screenshot of the final state
|
||||
|
||||
## Success Criteria
|
||||
- Complex natural language is correctly interpreted
|
||||
- SQL contains appropriate WHERE conditions
|
||||
- Results are properly filtered
|
||||
- No errors occur during execution
|
||||
- Hide button works
|
||||
- 5 screenshots are taken
|
||||
@@ -1,30 +0,0 @@
|
||||
# E2E Test: SQL Injection Protection
|
||||
|
||||
Test the application's protection against SQL injection attacks.
|
||||
|
||||
## User Story
|
||||
|
||||
As a user
|
||||
I want to be protected from SQL injection attacks when using the query interface
|
||||
So that my data remains secure and the database integrity is maintained
|
||||
|
||||
## Test Steps
|
||||
|
||||
1. Navigate to the `Application URL`
|
||||
2. Take a screenshot of the initial state
|
||||
3. Clear the query input
|
||||
4. Enter: "DROP TABLE users;"
|
||||
5. Take a screenshot of the malicious query input
|
||||
6. Click Query button
|
||||
7. **Verify** an error message appears containing "Security error" or similar
|
||||
8. Take a screenshot of the security error
|
||||
9. **Verify** the users table still exists in Available Tables section
|
||||
10. Take a screenshot showing the tables are intact
|
||||
|
||||
## Success Criteria
|
||||
- SQL injection attempt is blocked
|
||||
- Appropriate security error message is displayed
|
||||
- No damage to the database
|
||||
- Tables remain intact
|
||||
- Query input accepts the malicious text
|
||||
- 4 screenshots are taken
|
||||
27
.claude/commands/agent-work-orders/execute.md
Normal file
27
.claude/commands/agent-work-orders/execute.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Execute PRP Plan
|
||||
|
||||
Implement a feature plan from the PRPs directory by following its Step by Step Tasks section.
|
||||
|
||||
## Variables
|
||||
|
||||
Plan file: $ARGUMENTS
|
||||
|
||||
## Instructions
|
||||
|
||||
- Read the entire plan file carefully
|
||||
- Execute **every step** in the "Step by Step Tasks" section in order, top to bottom
|
||||
- Follow the "Testing Strategy" to create proper unit and integration tests
|
||||
- Complete all "Validation Commands" at the end
|
||||
- Ensure all linters pass and all tests pass before finishing
|
||||
- Follow CLAUDE.md guidelines for type safety, logging, and docstrings
|
||||
|
||||
## When done
|
||||
|
||||
- Move the PRP file to the completed directory in PRPs/features/completed
|
||||
|
||||
## Report
|
||||
|
||||
- Summarize completed work in a concise bullet point list
|
||||
- Show files and lines changed: `git diff --stat`
|
||||
- Confirm all validation commands passed
|
||||
- Note any deviations from the plan (if any)
|
||||
@@ -1,120 +0,0 @@
|
||||
# Feature Planning
|
||||
|
||||
Create a new plan in PRPs/specs/\*.md to implement the `Feature` using the exact specified markdown `Plan Format`. Follow the `Instructions` to create the plan use the `Relevant Files` to focus on the right files.
|
||||
|
||||
## Instructions
|
||||
|
||||
- IMPORTANT: You're writing a plan to implement a net new feature based on the `Feature` that will add value to the application.
|
||||
- IMPORTANT: The `Feature` describes the feature that will be implemented but remember we're not implementing a new feature, we're creating the plan that will be used to implement the feature based on the `Plan Format` below.
|
||||
- Create the plan in the `PRPs/specs/*.md` file. Name it appropriately based on the `Feature`.
|
||||
- Use the `Plan Format` below to create the plan.
|
||||
- Research the codebase to understand existing patterns, architecture, and conventions before planning the feature.
|
||||
- IMPORTANT: Replace every <placeholder> in the `Plan Format` with the requested value. Add as much detail as needed to implement the feature successfully.
|
||||
- Use your reasoning model: THINK HARD about the feature requirements, design, and implementation approach.
|
||||
- Follow existing patterns and conventions in the codebase. Don't reinvent the wheel.
|
||||
- Design for extensibility and maintainability.
|
||||
- If you need a new library, use `uv add` and be sure to report it in the `Notes` section of the `Plan Format`.
|
||||
- Respect requested files in the `Relevant Files` section.
|
||||
- Start your research by reading the `README.md` file.
|
||||
- ultrathink about the research before you create the plan.
|
||||
|
||||
## Relevant Files
|
||||
|
||||
Focus on the following files:
|
||||
|
||||
- `README.md` - Contains the project overview and instructions.
|
||||
- `app/server/**` - Contains the codebase server.
|
||||
- `app/client/**` - Contains the codebase client.
|
||||
- `scripts/**` - Contains the scripts to start and stop the server + client.
|
||||
- `adws/**` - Contains the AI Developer Workflow (ADW) scripts.
|
||||
|
||||
Ignore all other files in the codebase.
|
||||
|
||||
## Plan Format
|
||||
|
||||
```md
|
||||
# Feature: <feature name>
|
||||
|
||||
## Feature Description
|
||||
|
||||
<describe the feature in detail, including its purpose and value to users>
|
||||
|
||||
## User Story
|
||||
|
||||
As a <type of user>
|
||||
I want to <action/goal>
|
||||
So that <benefit/value>
|
||||
|
||||
## Problem Statement
|
||||
|
||||
<clearly define the specific problem or opportunity this feature addresses>
|
||||
|
||||
## Solution Statement
|
||||
|
||||
<describe the proposed solution approach and how it solves the problem>
|
||||
|
||||
## Relevant Files
|
||||
|
||||
Use these files to implement the feature:
|
||||
|
||||
<find and list the files that are relevant to the feature describe why they are relevant in bullet points. If there are new files that need to be created to implement the feature, list them in an h3 'New Files' section.>
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Foundation
|
||||
|
||||
<describe the foundational work needed before implementing the main feature>
|
||||
|
||||
### Phase 2: Core Implementation
|
||||
|
||||
<describe the main implementation work for the feature>
|
||||
|
||||
### Phase 3: Integration
|
||||
|
||||
<describe how the feature will integrate with existing functionality>
|
||||
|
||||
## Step by Step Tasks
|
||||
|
||||
IMPORTANT: Execute every step in order, top to bottom.
|
||||
|
||||
<list step by step tasks as h3 headers plus bullet points. use as many h3 headers as needed to implement the feature. Order matters, start with the foundational shared changes required then move on to the specific implementation. Include creating tests throughout the implementation process. Your last step should be running the `Validation Commands` to validate the feature works correctly with zero regressions.>
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
|
||||
<describe unit tests needed for the feature>
|
||||
|
||||
### Integration Tests
|
||||
|
||||
<describe integration tests needed for the feature>
|
||||
|
||||
### Edge Cases
|
||||
|
||||
<list edge cases that need to be tested>
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
<list specific, measurable criteria that must be met for the feature to be considered complete>
|
||||
|
||||
## Validation Commands
|
||||
|
||||
Execute every command to validate the feature works correctly with zero regressions.
|
||||
|
||||
<list commands you'll use to validate with 100% confidence the feature is implemented correctly with zero regressions. every command must execute without errors so be specific about what you want to run to validate the feature works as expected. Include commands to test the feature end-to-end.>
|
||||
|
||||
- `cd app/server && uv run pytest` - Run server tests to validate the feature works with zero regressions
|
||||
|
||||
## Notes
|
||||
|
||||
<optionally list any additional notes, future considerations, or context that are relevant to the feature that will be helpful to the developer>
|
||||
```
|
||||
|
||||
## Feature
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Report
|
||||
|
||||
- Summarize the work you've just done in a concise bullet point list.
|
||||
- Include a path to the plan you created in the `PRPs/specs/*.md` file.
|
||||
@@ -1,24 +0,0 @@
|
||||
# Find Plan File
|
||||
|
||||
Based on the variables and `Previous Step Output` below, follow the `Instructions` to find the path to the plan file that was just created.
|
||||
|
||||
## Variables
|
||||
issue_number: $1
|
||||
adw_id: $2
|
||||
previous_output: $3
|
||||
|
||||
## Instructions
|
||||
|
||||
- The previous step created a plan file. Find the exact file path.
|
||||
- The plan filename follows the pattern: `issue-{issue_number}-adw-{adw_id}-sdlc_planner-{descriptive-name}.md`
|
||||
- You can use these approaches to find it:
|
||||
- First, try: `ls specs/issue-{issue_number}-adw-{adw_id}-sdlc_planner-*.md`
|
||||
- Check git status for new untracked files matching the pattern
|
||||
- Use `find specs -name "issue-{issue_number}-adw-{adw_id}-sdlc_planner-*.md" -type f`
|
||||
- Parse the previous output which should mention where the plan was saved
|
||||
- Return ONLY the file path (e.g., "specs/issue-7-adw-abc123-sdlc_planner-update-readme.md") or "0" if not found.
|
||||
- Do not include any explanation, just the path or "0" if not found.
|
||||
|
||||
## Previous Step Output
|
||||
|
||||
Use the `previous_output` variable content to help locate the file if it mentions the path.
|
||||
@@ -1,36 +0,0 @@
|
||||
# Generate Git Branch Name
|
||||
|
||||
Based on the `Instructions` below, take the `Variables` follow the `Run` section to generate a concise Git branch name following the specified format. Then follow the `Report` section to report the results of your work.
|
||||
|
||||
## Variables
|
||||
|
||||
issue_class: $1
|
||||
adw_id: $2
|
||||
issue: $3
|
||||
|
||||
## Instructions
|
||||
|
||||
- Generate a branch name in the format: `<issue_class>-issue-<issue_number>-adw-<adw_id>-<concise_name>`
|
||||
- The `<concise_name>` should be:
|
||||
- 3-6 words maximum
|
||||
- All lowercase
|
||||
- Words separated by hyphens
|
||||
- Descriptive of the main task/feature
|
||||
- No special characters except hyphens
|
||||
- Examples:
|
||||
- `feat-issue-123-adw-a1b2c3d4-add-user-auth`
|
||||
- `bug-issue-456-adw-e5f6g7h8-fix-login-error`
|
||||
- `chore-issue-789-adw-i9j0k1l2-update-dependencies`
|
||||
- `test-issue-323-adw-m3n4o5p6-fix-failing-tests`
|
||||
- Extract the issue number, title, and body from the issue JSON
|
||||
|
||||
## Run
|
||||
|
||||
Run `git checkout main` to switch to the main branch
|
||||
Run `git pull` to pull the latest changes from the main branch
|
||||
Run `git checkout -b <branch_name>` to create and switch to the new branch
|
||||
|
||||
## Report
|
||||
|
||||
After generating the branch name:
|
||||
Return ONLY the branch name that was created (no other text)
|
||||
@@ -1,16 +0,0 @@
|
||||
# Implement the following plan
|
||||
|
||||
Follow the `Instructions` to implement the `Plan` then `Report` the completed work.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Read the plan, ultrathink about the plan and implement the plan.
|
||||
|
||||
## Plan
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Report
|
||||
|
||||
- Summarize the work you've just done in a concise bullet point list.
|
||||
- Report the files and total lines changed with `git diff --stat`
|
||||
176
.claude/commands/agent-work-orders/noqa.md
Normal file
176
.claude/commands/agent-work-orders/noqa.md
Normal file
@@ -0,0 +1,176 @@
|
||||
# NOQA Analysis and Resolution
|
||||
|
||||
Find all noqa/type:ignore comments in the codebase, investigate why they exist, and provide recommendations for resolution or justification.
|
||||
|
||||
## Instructions
|
||||
|
||||
**Step 1: Find all NOQA comments**
|
||||
|
||||
- Use Grep tool to find all noqa comments: pattern `noqa|type:\s*ignore`
|
||||
- Use output_mode "content" with line numbers (-n flag)
|
||||
- Search across all Python files (type: "py")
|
||||
- Document total count of noqa comments found
|
||||
|
||||
**Step 2: For EACH noqa comment (repeat this process):**
|
||||
|
||||
- Read the file containing the noqa comment with sufficient context (at least 10 lines before and after)
|
||||
- Identify the specific linting rule or type error being suppressed
|
||||
- Understand the code's purpose and why the suppression was added
|
||||
- Investigate if the suppression is still necessary or can be resolved
|
||||
|
||||
**Step 3: Investigation checklist for each noqa:**
|
||||
|
||||
- What specific error/warning is being suppressed? (e.g., `type: ignore[arg-type]`, `noqa: F401`)
|
||||
- Why was the suppression necessary? (legacy code, false positive, legitimate limitation, technical debt)
|
||||
- Can the underlying issue be fixed? (refactor code, update types, improve imports)
|
||||
- What would it take to remove the suppression? (effort estimate, breaking changes, architectural changes)
|
||||
- Is the suppression justified long-term? (external library limitation, Python limitation, intentional design)
|
||||
|
||||
**Step 4: Research solutions:**
|
||||
|
||||
- Check if newer versions of tools (mypy, ruff) handle the case better
|
||||
- Look for alternative code patterns that avoid the suppression
|
||||
- Consider if type stubs or Protocol definitions could help
|
||||
- Evaluate if refactoring would be worthwhile
|
||||
|
||||
## Report Format
|
||||
|
||||
Create a markdown report file (create the reports directory if not created yet): `PRPs/reports/noqa-analysis-{YYYY-MM-DD}.md`
|
||||
|
||||
Use this structure for the report:
|
||||
|
||||
````markdown
|
||||
# NOQA Analysis Report
|
||||
|
||||
**Generated:** {date}
|
||||
**Total NOQA comments found:** {count}
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
- Total suppressions: {count}
|
||||
- Can be removed: {count}
|
||||
- Should remain: {count}
|
||||
- Requires investigation: {count}
|
||||
|
||||
---
|
||||
|
||||
## Detailed Analysis
|
||||
|
||||
### 1. {File path}:{line number}
|
||||
|
||||
**Location:** `{file_path}:{line_number}`
|
||||
|
||||
**Suppression:** `{noqa comment or type: ignore}`
|
||||
|
||||
**Code context:**
|
||||
|
||||
```python
|
||||
{relevant code snippet}
|
||||
```
|
||||
````
|
||||
|
||||
**Why it exists:**
|
||||
{explanation of why the suppression was added}
|
||||
|
||||
**Options to resolve:**
|
||||
|
||||
1. {Option 1: description}
|
||||
- Effort: {Low/Medium/High}
|
||||
- Breaking: {Yes/No}
|
||||
- Impact: {description}
|
||||
|
||||
2. {Option 2: description}
|
||||
- Effort: {Low/Medium/High}
|
||||
- Breaking: {Yes/No}
|
||||
- Impact: {description}
|
||||
|
||||
**Tradeoffs:**
|
||||
|
||||
- {Tradeoff 1}
|
||||
- {Tradeoff 2}
|
||||
|
||||
**Recommendation:** {Remove | Keep | Refactor}
|
||||
{Justification for recommendation}
|
||||
|
||||
---
|
||||
|
||||
{Repeat for each noqa comment}
|
||||
|
||||
````
|
||||
|
||||
## Example Analysis Entry
|
||||
|
||||
```markdown
|
||||
### 1. src/shared/config.py:45
|
||||
|
||||
**Location:** `src/shared/config.py:45`
|
||||
|
||||
**Suppression:** `# type: ignore[assignment]`
|
||||
|
||||
**Code context:**
|
||||
```python
|
||||
@property
|
||||
def openai_api_key(self) -> str:
|
||||
key = os.getenv("OPENAI_API_KEY")
|
||||
if not key:
|
||||
raise ValueError("OPENAI_API_KEY not set")
|
||||
return key # type: ignore[assignment]
|
||||
````
|
||||
|
||||
**Why it exists:**
|
||||
MyPy cannot infer that the ValueError prevents None from being returned, so it thinks the return type could be `str | None`.
|
||||
|
||||
**Options to resolve:**
|
||||
|
||||
1. Use assert to help mypy narrow the type
|
||||
- Effort: Low
|
||||
- Breaking: No
|
||||
- Impact: Cleaner code, removes suppression
|
||||
|
||||
2. Add explicit cast with typing.cast()
|
||||
- Effort: Low
|
||||
- Breaking: No
|
||||
- Impact: More verbose but type-safe
|
||||
|
||||
3. Refactor to use separate validation method
|
||||
- Effort: Medium
|
||||
- Breaking: No
|
||||
- Impact: Better separation of concerns
|
||||
|
||||
**Tradeoffs:**
|
||||
|
||||
- Option 1 (assert) is cleanest but asserts can be disabled with -O flag
|
||||
- Option 2 (cast) is most explicit but adds import and verbosity
|
||||
- Option 3 is most robust but requires more refactoring
|
||||
|
||||
**Recommendation:** Remove (use Option 1)
|
||||
Replace the type:ignore with an assert statement after the if check. This helps mypy understand the control flow while maintaining runtime safety. The assert will never fail in practice since the ValueError is raised first.
|
||||
|
||||
**Implementation:**
|
||||
|
||||
```python
|
||||
@property
|
||||
def openai_api_key(self) -> str:
|
||||
key = os.getenv("OPENAI_API_KEY")
|
||||
if not key:
|
||||
raise ValueError("OPENAI_API_KEY not set")
|
||||
assert key is not None # Help mypy understand control flow
|
||||
return key
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Report
|
||||
|
||||
After completing the analysis:
|
||||
|
||||
- Output the path to the generated report file
|
||||
- Summarize findings:
|
||||
- Total suppressions found
|
||||
- How many can be removed immediately (low effort)
|
||||
- How many should remain (justified)
|
||||
- How many need deeper investigation or refactoring
|
||||
- Highlight any quick wins (suppressions that can be removed with minimal effort)
|
||||
```
|
||||
176
.claude/commands/agent-work-orders/planning.md
Normal file
176
.claude/commands/agent-work-orders/planning.md
Normal file
@@ -0,0 +1,176 @@
|
||||
# Feature Planning
|
||||
|
||||
Create a new plan to implement the `PRP` using the exact specified markdown `PRP Format`. Follow the `Instructions` to create the plan use the `Relevant Files` to focus on the right files.
|
||||
|
||||
## Variables
|
||||
|
||||
FEATURE $1 $2
|
||||
|
||||
## Instructions
|
||||
|
||||
- IMPORTANT: You're writing a plan to implement a net new feature based on the `Feature` that will add value to the application.
|
||||
- IMPORTANT: The `Feature` describes the feature that will be implemented but remember we're not implementing a new feature, we're creating the plan that will be used to implement the feature based on the `PRP Format` below.
|
||||
- Create the plan in the `PRPs/features/` directory with filename: `{descriptive-name}.md`
|
||||
- Replace `{descriptive-name}` with a short, descriptive name based on the feature (e.g., "add-auth-system", "implement-search", "create-dashboard")
|
||||
- Use the `PRP Format` below to create the plan.
|
||||
- Deeply research the codebase to understand existing patterns, architecture, and conventions before planning the feature.
|
||||
- If no patterns are established or are unclear ask the user for clarifications while providing best recommendations and options
|
||||
- IMPORTANT: Replace every <placeholder> in the `PRP Format` with the requested value. Add as much detail as needed to implement the feature successfully.
|
||||
- Use your reasoning model: THINK HARD about the feature requirements, design, and implementation approach.
|
||||
- Follow existing patterns and conventions in the codebase. Don't reinvent the wheel.
|
||||
- Design for extensibility and maintainability.
|
||||
- Deeply do web research to understand the latest trends and technologies in the field.
|
||||
- Figure out latest best practices and library documentation.
|
||||
- Include links to relevant resources and documentation with anchor tags for easy navigation.
|
||||
- If you need a new library, use `uv add <package>` and report it in the `Notes` section.
|
||||
- Read `CLAUDE.md` for project principles, logging rules, testing requirements, and docstring style.
|
||||
- All code MUST have type annotations (strict mypy enforcement).
|
||||
- Use Google-style docstrings for all functions, classes, and modules.
|
||||
- Every new file in `src/` MUST have a corresponding test file in `tests/`.
|
||||
- Respect requested files in the `Relevant Files` section.
|
||||
|
||||
## Relevant Files
|
||||
|
||||
Focus on the following files and vertical slice structure:
|
||||
|
||||
**Core Files:**
|
||||
|
||||
- `CLAUDE.md` - Project instructions, logging rules, testing requirements, docstring style
|
||||
app/backend core files
|
||||
app/frontend core files
|
||||
|
||||
## PRP Format
|
||||
|
||||
```md
|
||||
# Feature: <feature name>
|
||||
|
||||
## Feature Description
|
||||
|
||||
<describe the feature in detail, including its purpose and value to users>
|
||||
|
||||
## User Story
|
||||
|
||||
As a <type of user>
|
||||
I want to <action/goal>
|
||||
So that <benefit/value>
|
||||
|
||||
## Problem Statement
|
||||
|
||||
<clearly define the specific problem or opportunity this feature addresses>
|
||||
|
||||
## Solution Statement
|
||||
|
||||
<describe the proposed solution approach and how it solves the problem>
|
||||
|
||||
## Relevant Files
|
||||
|
||||
Use these files to implement the feature:
|
||||
|
||||
<find and list the files that are relevant to the feature describe why they are relevant in bullet points. If there are new files that need to be created to implement the feature, list them in an h3 'New Files' section. inlcude line numbers for the relevant sections>
|
||||
|
||||
## Relevant research docstring
|
||||
|
||||
Use these documentation files and links to help with understanding the technology to use:
|
||||
|
||||
- [Documentation Link 1](https://example.com/doc1)
|
||||
- [Anchor tag]
|
||||
- [Short summary]
|
||||
- [Documentation Link 2](https://example.com/doc2)
|
||||
- [Anchor tag]
|
||||
- [Short summary]
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Foundation
|
||||
|
||||
<describe the foundational work needed before implementing the main feature>
|
||||
|
||||
### Phase 2: Core Implementation
|
||||
|
||||
<describe the main implementation work for the feature>
|
||||
|
||||
### Phase 3: Integration
|
||||
|
||||
<describe how the feature will integrate with existing functionality>
|
||||
|
||||
## Step by Step Tasks
|
||||
|
||||
IMPORTANT: Execute every step in order, top to bottom.
|
||||
|
||||
<list step by step tasks as h3 headers plus bullet points. use as many h3 headers as needed to implement the feature. Order matters:
|
||||
|
||||
1. Start with foundational shared changes (schemas, types)
|
||||
2. Implement core functionality with proper logging
|
||||
3. Create corresponding test files (unit tests mirror src/ structure)
|
||||
4. Add integration tests if feature interacts with multiple components
|
||||
5. Verify linters pass: `uv run ruff check src/ && uv run mypy src/`
|
||||
6. Ensure all tests pass: `uv run pytest tests/`
|
||||
7. Your last step should be running the `Validation Commands`>
|
||||
|
||||
<For tool implementations:
|
||||
|
||||
- Define Pydantic schemas in `schemas.py`
|
||||
- Implement tool with structured logging and type hints
|
||||
- Register tool with Pydantic AI agent
|
||||
- Create unit tests in `tests/tools/<name>/test_<module>.py`
|
||||
- Add integration test in `tests/integration/` if needed>
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
See `CLAUDE.md` for complete testing requirements. Every file in `src/` must have a corresponding test file in `tests/`.
|
||||
|
||||
### Unit Tests
|
||||
|
||||
<describe unit tests needed for the feature. Mark with @pytest.mark.unit. Test individual components in isolation.>
|
||||
|
||||
### Integration Tests
|
||||
|
||||
<if the feature interacts with multiple components, describe integration tests needed. Mark with @pytest.mark.integration. Place in tests/integration/ when testing full application stack.>
|
||||
|
||||
### Edge Cases
|
||||
|
||||
<list edge cases that need to be tested>
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
<list specific, measurable criteria that must be met for the feature to be considered complete>
|
||||
|
||||
## Validation Commands
|
||||
|
||||
Execute every command to validate the feature works correctly with zero regressions.
|
||||
|
||||
<list commands you'll use to validate with 100% confidence the feature is implemented correctly with zero regressions. Include (example for BE Biome and TS checks are used for FE):
|
||||
|
||||
- Linting: `uv run ruff check src/`
|
||||
- Type checking: `uv run mypy src/`
|
||||
- Unit tests: `uv run pytest tests/ -m unit -v`
|
||||
- Integration tests: `uv run pytest tests/ -m integration -v` (if applicable)
|
||||
- Full test suite: `uv run pytest tests/ -v`
|
||||
- Manual API testing if needed (curl commands, test requests)>
|
||||
|
||||
**Required validation commands:**
|
||||
|
||||
- `uv run ruff check src/` - Lint check must pass
|
||||
- `uv run mypy src/` - Type check must pass
|
||||
- `uv run pytest tests/ -v` - All tests must pass with zero regressions
|
||||
|
||||
**Run server and test core endpoints:**
|
||||
|
||||
- Start server: @.claude/start-server
|
||||
- Test endpoints with curl (at minimum: health check, main functionality)
|
||||
- Verify structured logs show proper correlation IDs and context
|
||||
- Stop server after validation
|
||||
|
||||
## Notes
|
||||
|
||||
<optionally list any additional notes, future considerations, or context that are relevant to the feature that will be helpful to the developer>
|
||||
```
|
||||
|
||||
## Feature
|
||||
|
||||
Extract the feature details from the `issue_json` variable (parse the JSON and use the title and body fields).
|
||||
|
||||
## Report
|
||||
|
||||
- Summarize the work you've just done in a concise bullet point list.
|
||||
- Include the full path to the plan file you created (e.g., `PRPs/features/add-auth-system.md`)
|
||||
@@ -1,12 +1,28 @@
|
||||
# Prime
|
||||
|
||||
> Execute the following sections to understand the codebase then summarize your understanding.
|
||||
Execute the following sections to understand the codebase before starting new work, then summarize your understanding.
|
||||
|
||||
## Run
|
||||
|
||||
git ls-files
|
||||
- List all tracked files: `git ls-files`
|
||||
- Show project structure: `tree -I '.venv|__pycache__|*.pyc|.pytest_cache|.mypy_cache|.ruff_cache' -L 3`
|
||||
|
||||
## Read
|
||||
|
||||
README.md
|
||||
please read PRPs/PRD.md and core files in PRPs/specs
|
||||
- `CLAUDE.md` - Core project instructions, principles, logging rules, testing requirements
|
||||
- `python/src/agent_work_orders` - Project overview and setup (if exists)
|
||||
|
||||
- Identify core files in the agent work orders directory to understand what we are woerking on and its intent
|
||||
|
||||
## Report
|
||||
|
||||
Provide a concise summary of:
|
||||
|
||||
1. **Project Purpose**: What this application does
|
||||
2. **Architecture**: Key patterns (vertical slice, FastAPI + Pydantic AI)
|
||||
3. **Core Principles**: TYPE SAFETY, KISS, YAGNI
|
||||
4. **Tech Stack**: Main dependencies and tools
|
||||
5. **Key Requirements**: Logging, testing, type annotations
|
||||
6. **Current State**: What's implemented
|
||||
|
||||
Keep the summary brief (5-10 bullet points) and focused on what you need to know to contribute effectively.
|
||||
|
||||
89
.claude/commands/agent-work-orders/prp-review.md
Normal file
89
.claude/commands/agent-work-orders/prp-review.md
Normal file
@@ -0,0 +1,89 @@
|
||||
# Code Review
|
||||
|
||||
Review implemented work against a PRP specification to ensure code quality, correctness, and adherence to project standards.
|
||||
|
||||
## Variables
|
||||
|
||||
Plan file: $ARGUMENTS (e.g., `PRPs/features/add-web-search.md`)
|
||||
|
||||
## Instructions
|
||||
|
||||
**Understand the Changes:**
|
||||
|
||||
- Check current branch: `git branch`
|
||||
- Review changes: `git diff origin/main` (or `git diff HEAD` if not on a branch)
|
||||
- Read the PRP plan file to understand requirements
|
||||
|
||||
**Code Quality Review:**
|
||||
|
||||
- **Type Safety**: Verify all functions have type annotations, mypy passes
|
||||
- **Logging**: Check structured logging is used correctly (event names, context, exception handling)
|
||||
- **Docstrings**: Ensure Google-style docstrings on all functions/classes
|
||||
- **Testing**: Verify unit tests exist for all new files, integration tests if needed
|
||||
- **Architecture**: Confirm vertical slice structure is followed
|
||||
- **CLAUDE.md Compliance**: Check adherence to core principles (KISS, YAGNI, TYPE SAFETY)
|
||||
|
||||
**Validation Ruff for BE and Biome for FE:**
|
||||
|
||||
- Run linters: `uv run ruff check src/ && uv run mypy src/`
|
||||
- Run tests: `uv run pytest tests/ -v`
|
||||
- Start server and test endpoints with curl (if applicable)
|
||||
- Verify structured logs show proper correlation IDs and context
|
||||
|
||||
**Issue Severity:**
|
||||
|
||||
- `blocker` - Must fix before merge (breaks build, missing tests, type errors, security issues)
|
||||
- `major` - Should fix (missing logging, incomplete docstrings, poor patterns)
|
||||
- `minor` - Nice to have (style improvements, optimization opportunities)
|
||||
|
||||
## Report
|
||||
|
||||
Return ONLY valid JSON (no markdown, no explanations) save to [report-#.json] in prps/reports directory create the directory if it doesn't exist. Output will be parsed with JSON.parse().
|
||||
|
||||
### Output Structure
|
||||
|
||||
```json
|
||||
{
|
||||
"success": "boolean - true if NO BLOCKER issues, false if BLOCKER issues exist",
|
||||
"review_summary": "string - 2-4 sentences: what was built, does it match spec, quality assessment",
|
||||
"review_issues": [
|
||||
{
|
||||
"issue_number": "number - issue index",
|
||||
"file_path": "string - file with the issue (if applicable)",
|
||||
"issue_description": "string - what's wrong",
|
||||
"issue_resolution": "string - how to fix it",
|
||||
"severity": "string - blocker|major|minor"
|
||||
}
|
||||
],
|
||||
"validation_results": {
|
||||
"linting_passed": "boolean",
|
||||
"type_checking_passed": "boolean",
|
||||
"tests_passed": "boolean",
|
||||
"api_endpoints_tested": "boolean - true if endpoints were tested with curl"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Example Success Review
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"review_summary": "The web search tool has been implemented with proper type annotations, structured logging, and comprehensive tests. The implementation follows the vertical slice architecture and matches all spec requirements. Code quality is high with proper error handling and documentation.",
|
||||
"review_issues": [
|
||||
{
|
||||
"issue_number": 1,
|
||||
"file_path": "src/tools/web_search/tool.py",
|
||||
"issue_description": "Missing debug log for API response",
|
||||
"issue_resolution": "Add logger.debug with response metadata",
|
||||
"severity": "minor"
|
||||
}
|
||||
],
|
||||
"validation_results": {
|
||||
"linting_passed": true,
|
||||
"type_checking_passed": true,
|
||||
"tests_passed": true,
|
||||
"api_endpoints_tested": true
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,41 +0,0 @@
|
||||
# Create Pull Request
|
||||
|
||||
Based on the `Instructions` below, take the `Variables` follow the `Run` section to create a pull request. Then follow the `Report` section to report the results of your work.
|
||||
|
||||
## Variables
|
||||
|
||||
branch_name: $1
|
||||
issue: $2
|
||||
plan_file: $3
|
||||
adw_id: $4
|
||||
|
||||
## Instructions
|
||||
|
||||
- Generate a pull request title in the format: `<issue_type>: #<issue_number> - <issue_title>`
|
||||
- The PR body should include:
|
||||
- A summary section with the issue context
|
||||
- Link to the implementation `plan_file` if it exists
|
||||
- Reference to the issue (Closes #<issue_number>)
|
||||
- ADW tracking ID
|
||||
- A checklist of what was done
|
||||
- A summary of key changes made
|
||||
- Extract issue number, type, and title from the issue JSON
|
||||
- Examples of PR titles:
|
||||
- `feat: #123 - Add user authentication`
|
||||
- `bug: #456 - Fix login validation error`
|
||||
- `chore: #789 - Update dependencies`
|
||||
- `test: #1011 - Test xyz`
|
||||
- Don't mention Claude Code in the PR body - let the author get credit for this.
|
||||
|
||||
## Run
|
||||
|
||||
1. Run `git diff origin/main...HEAD --stat` to see a summary of changed files
|
||||
2. Run `git log origin/main..HEAD --oneline` to see the commits that will be included
|
||||
3. Run `git diff origin/main...HEAD --name-only` to get a list of changed files
|
||||
4. Run `git push -u origin <branch_name>` to push the branch
|
||||
5. Set GH_TOKEN environment variable from GITHUB_PAT if available, then run `gh pr create --title "<pr_title>" --body "<pr_body>" --base main` to create the PR
|
||||
6. Capture the PR URL from the output
|
||||
|
||||
## Report
|
||||
|
||||
Return ONLY the PR URL that was created (no other text)
|
||||
@@ -1,51 +0,0 @@
|
||||
# Resolve Failed E2E Test
|
||||
|
||||
Fix a specific failing E2E test using the provided failure details.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Analyze the E2E Test Failure**
|
||||
- Review the JSON data in the `Test Failure Input`, paying attention to:
|
||||
- `test_name`: The name of the failing test
|
||||
- `test_path`: The path to the test file (you will need this for re-execution)
|
||||
- `error`: The specific error that occurred
|
||||
- `screenshots`: Any captured screenshots showing the failure state
|
||||
- Understand what the test is trying to validate from a user interaction perspective
|
||||
|
||||
2. **Understand Test Execution**
|
||||
- Read `.claude/commands/test_e2e.md` to understand how E2E tests are executed
|
||||
- Read the test file specified in the `test_path` field from the JSON
|
||||
- Note the test steps, user story, and success criteria
|
||||
|
||||
3. **Reproduce the Failure**
|
||||
- IMPORTANT: Use the `test_path` from the JSON to re-execute the specific E2E test
|
||||
- Follow the execution pattern from `.claude/commands/test_e2e.md`
|
||||
- Observe the browser behavior and confirm you can reproduce the exact failure
|
||||
- Compare the error you see with the error reported in the JSON
|
||||
|
||||
4. **Fix the Issue**
|
||||
- Based on your reproduction, identify the root cause
|
||||
- Make minimal, targeted changes to resolve only this E2E test failure
|
||||
- Consider common E2E issues:
|
||||
- Element selector changes
|
||||
- Timing issues (elements not ready)
|
||||
- UI layout changes
|
||||
- Application logic modifications
|
||||
- Ensure the fix aligns with the user story and test purpose
|
||||
|
||||
5. **Validate the Fix**
|
||||
- Re-run the same E2E test step by step using the `test_path` to confirm it now passes
|
||||
- IMPORTANT: The test must complete successfully before considering it resolved
|
||||
- Do NOT run other tests or the full test suite
|
||||
- Focus only on fixing this specific E2E test
|
||||
|
||||
## Test Failure Input
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Report
|
||||
|
||||
Provide a concise summary of:
|
||||
- Root cause identified (e.g., missing element, timing issue, incorrect selector)
|
||||
- Specific fix applied
|
||||
- Confirmation that the E2E test now passes after your fix
|
||||
@@ -1,46 +0,0 @@
|
||||
# Resolve Failed Review Issue
|
||||
|
||||
Fix a specific blocker issue identified during the review phase.
|
||||
|
||||
## Arguments
|
||||
|
||||
1. review_issue_json: JSON string containing the review issue to fix
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Parse Review Issue**
|
||||
- Extract issue_title, issue_description, issue_severity, and affected_files from the JSON
|
||||
- Ensure this is a "blocker" severity issue (tech_debt and skippable are not resolved here)
|
||||
|
||||
2. **Understand the Issue**
|
||||
- Read the issue description carefully
|
||||
- Review the affected files listed
|
||||
- If a spec file was referenced in the original review, re-read relevant sections
|
||||
|
||||
3. **Create Fix Plan**
|
||||
- Determine what changes are needed to resolve the issue
|
||||
- Identify all files that need to be modified
|
||||
- Plan minimal, targeted changes
|
||||
|
||||
4. **Implement the Fix**
|
||||
- Make only the changes necessary to resolve this specific issue
|
||||
- Ensure code quality and consistency
|
||||
- Follow project conventions and patterns
|
||||
- Do not make unrelated changes
|
||||
|
||||
5. **Verify the Fix**
|
||||
- Re-run relevant tests if applicable
|
||||
- Check that the issue is actually resolved
|
||||
- Ensure no new issues were introduced
|
||||
|
||||
## Review Issue Input
|
||||
|
||||
$ARGUMENT_1
|
||||
|
||||
## Report
|
||||
|
||||
Provide a concise summary of:
|
||||
- Root cause of the blocker issue
|
||||
- Specific changes made to resolve it
|
||||
- Files modified
|
||||
- Confirmation that the issue is resolved
|
||||
@@ -1,41 +0,0 @@
|
||||
# Resolve Failed Test
|
||||
|
||||
Fix a specific failing test using the provided failure details.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Analyze the Test Failure**
|
||||
- Review the test name, purpose, and error message from the `Test Failure Input`
|
||||
- Understand what the test is trying to validate
|
||||
- Identify the root cause from the error details
|
||||
|
||||
2. **Context Discovery**
|
||||
- Check recent changes: `git diff origin/main --stat --name-only`
|
||||
- If a relevant spec exists in `specs/*.md`, read it to understand requirements
|
||||
- Focus only on files that could impact this specific test
|
||||
|
||||
3. **Reproduce the Failure**
|
||||
- IMPORTANT: Use the `execution_command` provided in the test data
|
||||
- Run it to see the full error output and stack trace
|
||||
- Confirm you can reproduce the exact failure
|
||||
|
||||
4. **Fix the Issue**
|
||||
- Make minimal, targeted changes to resolve only this test failure
|
||||
- Ensure the fix aligns with the test purpose and any spec requirements
|
||||
- Do not modify unrelated code or tests
|
||||
|
||||
5. **Validate the Fix**
|
||||
- Re-run the same `execution_command` to confirm the test now passes
|
||||
- Do NOT run other tests or the full test suite
|
||||
- Focus only on fixing this specific test
|
||||
|
||||
## Test Failure Input
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Report
|
||||
|
||||
Provide a concise summary of:
|
||||
- Root cause identified
|
||||
- Specific fix applied
|
||||
- Confirmation that the test now passes
|
||||
@@ -1,101 +0,0 @@
|
||||
# Review Implementation Against Specification
|
||||
|
||||
Compare the current implementation against the specification file and identify any issues that need to be addressed before creating a pull request.
|
||||
|
||||
## Variables
|
||||
|
||||
REVIEW_TIMEOUT: 10 minutes
|
||||
|
||||
## Arguments
|
||||
|
||||
1. spec_file_path: Path to the specification file (e.g., "PRPs/specs/my-feature.md")
|
||||
2. work_order_id: The work order ID for context
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Read the Specification**
|
||||
- Read the specification file at `$ARGUMENT_1`
|
||||
- Understand all requirements, acceptance criteria, and deliverables
|
||||
- Note any specific constraints or implementation details
|
||||
|
||||
2. **Analyze Current Implementation**
|
||||
- Review the code changes made in the current branch
|
||||
- Check if all files mentioned in the spec have been created/modified
|
||||
- Verify implementation matches the spec requirements
|
||||
|
||||
3. **Capture Screenshots** (if applicable)
|
||||
- If the feature includes UI components:
|
||||
- Start the application if needed
|
||||
- Take screenshots of key UI flows
|
||||
- Save screenshots to `screenshots/wo-$ARGUMENT_2/` directory
|
||||
- If no UI: skip this step
|
||||
|
||||
4. **Compare Implementation vs Specification**
|
||||
- Identify any missing features or incomplete implementations
|
||||
- Check for deviations from the spec
|
||||
- Verify all acceptance criteria are met
|
||||
- Look for potential bugs or issues
|
||||
|
||||
5. **Categorize Issues by Severity**
|
||||
- **blocker**: Must be fixed before PR (breaks functionality, missing critical features)
|
||||
- **tech_debt**: Should be fixed but can be addressed later
|
||||
- **skippable**: Nice-to-have, documentation improvements, minor polish
|
||||
|
||||
6. **Generate Review Report**
|
||||
- Return ONLY the JSON object as specified below
|
||||
- Do not include any additional text, explanations, or markdown formatting
|
||||
- List all issues found, even if none are blockers
|
||||
|
||||
## Report
|
||||
|
||||
Return ONLY a valid JSON object with the following structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"review_passed": boolean,
|
||||
"review_issues": [
|
||||
{
|
||||
"issue_title": "string",
|
||||
"issue_description": "string",
|
||||
"issue_severity": "blocker|tech_debt|skippable",
|
||||
"affected_files": ["string"],
|
||||
"screenshots": ["string"]
|
||||
}
|
||||
],
|
||||
"screenshots": ["string"]
|
||||
}
|
||||
```
|
||||
|
||||
### Field Descriptions
|
||||
|
||||
- `review_passed`: true if no blocker issues found, false otherwise
|
||||
- `review_issues`: Array of all issues found (blockers, tech_debt, skippable)
|
||||
- `issue_severity`: Must be one of: "blocker", "tech_debt", "skippable"
|
||||
- `affected_files`: List of file paths that need changes to fix this issue
|
||||
- `screenshots`: List of screenshot file paths for this specific issue (if applicable)
|
||||
- `screenshots` (root level): List of all screenshot paths taken during review
|
||||
|
||||
### Example Output
|
||||
|
||||
```json
|
||||
{
|
||||
"review_passed": false,
|
||||
"review_issues": [
|
||||
{
|
||||
"issue_title": "Missing error handling in API endpoint",
|
||||
"issue_description": "The /api/work-orders endpoint doesn't handle invalid repository URLs. The spec requires validation with clear error messages.",
|
||||
"issue_severity": "blocker",
|
||||
"affected_files": ["python/src/agent_work_orders/api/routes.py"],
|
||||
"screenshots": []
|
||||
},
|
||||
{
|
||||
"issue_title": "Incomplete test coverage",
|
||||
"issue_description": "Only 60% test coverage achieved, spec requires >80%",
|
||||
"issue_severity": "tech_debt",
|
||||
"affected_files": ["python/tests/agent_work_orders/"],
|
||||
"screenshots": []
|
||||
}
|
||||
],
|
||||
"screenshots": []
|
||||
}
|
||||
```
|
||||
33
.claude/commands/agent-work-orders/start-server.md
Normal file
33
.claude/commands/agent-work-orders/start-server.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Start Servers
|
||||
|
||||
Start both the FastAPI backend and React frontend development servers with hot reload.
|
||||
|
||||
## Run
|
||||
|
||||
### Run in the background with bash tool
|
||||
|
||||
- Ensure you are in the right PWD
|
||||
- Use the Bash tool to run the servers in the background so you can read the shell outputs
|
||||
- IMPORTANT: run `git ls-files` first so you know where directories are located before you start
|
||||
|
||||
### Backend Server (FastAPI)
|
||||
|
||||
- Navigate to backend: `cd app/backend`
|
||||
- Start server in background: `uv sync && uv run python run_api.py`
|
||||
- Wait 2-3 seconds for startup
|
||||
- Test health endpoint: `curl http://localhost:8000/health`
|
||||
- Test products endpoint: `curl http://localhost:8000/api/products`
|
||||
|
||||
### Frontend Server (Bun + React)
|
||||
|
||||
- Navigate to frontend: `cd ../app/frontend`
|
||||
- Start server in background: `bun install && bun dev`
|
||||
- Wait 2-3 seconds for startup
|
||||
- Frontend should be accessible at `http://localhost:3000`
|
||||
|
||||
## Report
|
||||
|
||||
- Confirm backend is running on `http://localhost:8000`
|
||||
- Confirm frontend is running on `http://localhost:3000`
|
||||
- Show the health check response from backend
|
||||
- Mention: "Backend logs will show structured JSON logging for all requests"
|
||||
@@ -1,115 +0,0 @@
|
||||
# Application Validation Test Suite
|
||||
|
||||
Execute comprehensive validation tests for both frontend and backend components, returning results in a standardized JSON format for automated processing.
|
||||
|
||||
## Purpose
|
||||
|
||||
Proactively identify and fix issues in the application before they impact users or developers. By running this comprehensive test suite, you can:
|
||||
- Detect syntax errors, type mismatches, and import failures
|
||||
- Identify broken tests or security vulnerabilities
|
||||
- Verify build processes and dependencies
|
||||
- Ensure the application is in a healthy state
|
||||
|
||||
## Variables
|
||||
|
||||
TEST_COMMAND_TIMEOUT: 5 minutes
|
||||
|
||||
## Instructions
|
||||
|
||||
- Execute each test in the sequence provided below
|
||||
- Capture the result (passed/failed) and any error messages
|
||||
- IMPORTANT: Return ONLY the JSON array with test results
|
||||
- IMPORTANT: Do not include any additional text, explanations, or markdown formatting
|
||||
- We'll immediately run JSON.parse() on the output, so make sure it's valid JSON
|
||||
- If a test passes, omit the error field
|
||||
- If a test fails, include the error message in the error field
|
||||
- Execute all tests even if some fail
|
||||
- Error Handling:
|
||||
- If a command returns non-zero exit code, mark as failed and immediately stop processing tests
|
||||
- Capture stderr output for error field
|
||||
- Timeout commands after `TEST_COMMAND_TIMEOUT`
|
||||
- IMPORTANT: If a test fails, stop processing tests and return the results thus far
|
||||
- Some tests may have dependencies (e.g., server must be stopped for port availability)
|
||||
- API health check is required
|
||||
- Test execution order is important - dependencies should be validated first
|
||||
- All file paths are relative to the project root
|
||||
- Always run `pwd` and `cd` before each test to ensure you're operating in the correct directory for the given test
|
||||
|
||||
## Test Execution Sequence
|
||||
|
||||
### Backend Tests
|
||||
|
||||
1. **Python Syntax Check**
|
||||
- Preparation Command: None
|
||||
- Command: `cd app/server && uv run python -m py_compile server.py main.py core/*.py`
|
||||
- test_name: "python_syntax_check"
|
||||
- test_purpose: "Validates Python syntax by compiling source files to bytecode, catching syntax errors like missing colons, invalid indentation, or malformed statements"
|
||||
|
||||
2. **Backend Code Quality Check**
|
||||
- Preparation Command: None
|
||||
- Command: `cd app/server && uv run ruff check .`
|
||||
- test_name: "backend_linting"
|
||||
- test_purpose: "Validates Python code quality, identifies unused imports, style violations, and potential bugs"
|
||||
|
||||
3. **All Backend Tests**
|
||||
- Preparation Command: None
|
||||
- Command: `cd app/server && uv run pytest tests/ -v --tb=short`
|
||||
- test_name: "all_backend_tests"
|
||||
- test_purpose: "Validates all backend functionality including file processing, SQL security, LLM integration, and API endpoints"
|
||||
|
||||
### Frontend Tests
|
||||
|
||||
4. **TypeScript Type Check**
|
||||
- Preparation Command: None
|
||||
- Command: `cd app/client && bun tsc --noEmit`
|
||||
- test_name: "typescript_check"
|
||||
- test_purpose: "Validates TypeScript type correctness without generating output files, catching type errors, missing imports, and incorrect function signatures"
|
||||
|
||||
5. **Frontend Build**
|
||||
- Preparation Command: None
|
||||
- Command: `cd app/client && bun run build`
|
||||
- test_name: "frontend_build"
|
||||
- test_purpose: "Validates the complete frontend build process including bundling, asset optimization, and production compilation"
|
||||
|
||||
## Report
|
||||
|
||||
- IMPORTANT: Return results exclusively as a JSON array based on the `Output Structure` section below.
|
||||
- Sort the JSON array with failed tests (passed: false) at the top
|
||||
- Include all tests in the output, both passed and failed
|
||||
- The execution_command field should contain the exact command that can be run to reproduce the test
|
||||
- This allows subsequent agents to quickly identify and resolve errors
|
||||
|
||||
### Output Structure
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"test_name": "string",
|
||||
"passed": boolean,
|
||||
"execution_command": "string",
|
||||
"test_purpose": "string",
|
||||
"error": "optional string"
|
||||
},
|
||||
...
|
||||
]
|
||||
```
|
||||
|
||||
### Example Output
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"test_name": "frontend_build",
|
||||
"passed": false,
|
||||
"execution_command": "cd app/client && bun run build",
|
||||
"test_purpose": "Validates TypeScript compilation, module resolution, and production build process for the frontend application",
|
||||
"error": "TS2345: Argument of type 'string' is not assignable to parameter of type 'number'"
|
||||
},
|
||||
{
|
||||
"test_name": "all_backend_tests",
|
||||
"passed": true,
|
||||
"execution_command": "cd app/server && uv run pytest tests/ -v --tb=short",
|
||||
"test_purpose": "Validates all backend functionality including file processing, SQL security, LLM integration, and API endpoints"
|
||||
}
|
||||
]
|
||||
```
|
||||
@@ -1,64 +0,0 @@
|
||||
# E2E Test Runner
|
||||
|
||||
Execute end-to-end (E2E) tests using Playwright browser automation (MCP Server). If any errors occur and assertions fail mark the test as failed and explain exactly what went wrong.
|
||||
|
||||
## Variables
|
||||
|
||||
adw_id: $1 if provided, otherwise generate a random 8 character hex string
|
||||
agent_name: $2 if provided, otherwise use 'test_e2e'
|
||||
e2e_test_file: $3
|
||||
application_url: $4 if provided, otherwise use http://localhost:5173
|
||||
|
||||
## Instructions
|
||||
|
||||
- Read the `e2e_test_file`
|
||||
- Digest the `User Story` to first understand what we're validating
|
||||
- IMPORTANT: Execute the `Test Steps` detailed in the `e2e_test_file` using Playwright browser automation
|
||||
- Review the `Success Criteria` and if any of them fail, mark the test as failed and explain exactly what went wrong
|
||||
- Review the steps that say '**Verify**...' and if they fail, mark the test as failed and explain exactly what went wrong
|
||||
- Capture screenshots as specified
|
||||
- IMPORTANT: Return results in the format requested by the `Output Format`
|
||||
- Initialize Playwright browser in headed mode for visibility
|
||||
- Use the `application_url`
|
||||
- Allow time for async operations and element visibility
|
||||
- IMPORTANT: After taking each screenshot, save it to `Screenshot Directory` with descriptive names. Use absolute paths to move the files to the `Screenshot Directory` with the correct name.
|
||||
- Capture and report any errors encountered
|
||||
- Ultra think about the `Test Steps` and execute them in order
|
||||
- If you encounter an error, mark the test as failed immediately and explain exactly what went wrong and on what step it occurred. For example: '(Step 1 ❌) Failed to find element with selector "query-input" on page "http://localhost:5173"'
|
||||
- Use `pwd` or equivalent to get the absolute path to the codebase for writing and displaying the correct paths to the screenshots
|
||||
|
||||
## Setup
|
||||
|
||||
- IMPORTANT: Reset the database by running `scripts/reset_db.sh`
|
||||
- IMPORTANT: Make sure the server and client are running on a background process before executing the test steps. Read `scripts/` and `README.md` for more information on how to start, stop and reset the server and client
|
||||
|
||||
|
||||
## Screenshot Directory
|
||||
|
||||
<absolute path to codebase>/agents/<adw_id>/<agent_name>/img/<directory name based on test file name>/*.png
|
||||
|
||||
Each screenshot should be saved with a descriptive name that reflects what is being captured. The directory structure ensures that:
|
||||
- Screenshots are organized by ADW ID (workflow run)
|
||||
- They are stored under the specified agent name (e.g., e2e_test_runner_0, e2e_test_resolver_iter1_0)
|
||||
- Each test has its own subdirectory based on the test file name (e.g., test_basic_query → basic_query/)
|
||||
|
||||
## Report
|
||||
|
||||
- Exclusively return the JSON output as specified in the test file
|
||||
- Capture any unexpected errors
|
||||
- IMPORTANT: Ensure all screenshots are saved in the `Screenshot Directory`
|
||||
|
||||
### Output Format
|
||||
|
||||
```json
|
||||
{
|
||||
"test_name": "Test Name Here",
|
||||
"status": "passed|failed",
|
||||
"screenshots": [
|
||||
"<absolute path to codebase>/agents/<adw_id>/<agent_name>/img/<test name>/01_<descriptive name>.png",
|
||||
"<absolute path to codebase>/agents/<adw_id>/<agent_name>/img/<test name>/02_<descriptive name>.png",
|
||||
"<absolute path to codebase>/agents/<adw_id>/<agent_name>/img/<test name>/03_<descriptive name>.png"
|
||||
],
|
||||
"error": null
|
||||
}
|
||||
```
|
||||
@@ -1,3 +0,0 @@
|
||||
# List Built-in Tools
|
||||
|
||||
List all core, built-in non-mcp development tools available to you. Display in bullet format. Use typescript function syntax with parameters.
|
||||
Reference in New Issue
Block a user