From core
Collects test requirements from TestRail and Confluence, then creates an initial test plan document with cross-referenced feature context.
How this command is triggered — by the user, by Claude, or both
Slash command
/core:aqa-flow-data-collectionThe summary Claude sees in its command listing — used to decide when to auto-load this command
# Phase 1: Data Collection ## Objective Gather all required information from external sources (TestRail and Confluence) to understand test requirements and expected behavior. ## Prerequisites - TestRail MCP configured and accessible - Atlassian (Confluence) MCP configured and accessible - Test case ID or requirement provided by user ## Phase Tasks ### Task 1: Read TestRail Test Case **Actions**: 1. Ask user for TestRail test case ID if not provided 2. Use TestRail MCP to retrieve test case details: 3. Extract key information: - Test case ID and title - Test description -...
Gather all required information from external sources (TestRail and Confluence) to understand test requirements and expected behavior.
Actions:
Use: user-testrail-get_case with case_id
Expected Output: Complete understanding of what needs to be tested according to TestRail.
Actions:
Use: user-mcp-atlassian-confluence_search with query
Or: user-mcp-atlassian-confluence_get_page with page_id
Expected Output: Business and technical context for the feature being tested.
Actions:
agents/plans/aqa-<test-name>.md file with:
Template:
# AQA Test Plan - <Test Name>
**Created**: [DateTime]
**TestRail Case**: [ID/URL]
**Feature**: [Feature Name]
**Status**: Phase 1 Complete
## Test Case Information
### Source
- TestRail Case: [ID]
- Confluence: [Page URLs]
### Test Goal
[What is being tested and why]
### Preconditions
[List preconditions from TestRail]
### Test Steps
1. [Step 1]
- Expected: [Result]
2. [Step 2]
- Expected: [Result]
...
### Expected Overall Result
[Final expected outcome]
## Feature Context
### Business Purpose
[From Confluence - why this feature exists]
### Technical Details
[From Confluence - how it works]
### User Flow
[From Confluence - user journey]
## Notes
- [Any observations or questions]
---
## Phase 2: Requirements Clarification
[To be filled in Phase 2]
## Phase 3: Code Analysis
[To be filled in Phase 3]
## Phase 4: Selector Identification
[To be filled in Phase 4]
## Phase 5: Selector Implementation
[To be filled in Phase 5]
## Phase 6: Test Implementation
[To be filled in Phase 6]
agents/aqa-state.md updated with Phase 1 completionAfter completing Phase 1, update agents/aqa-state.md:
### Phase 1: Data Collection
- Completed: [DateTime]
- TestRail Case: [ID/URL]
- Confluence Pages: [URLs]
- Test Goal: [Brief description]
- Expected Result: [Brief description]
- Test Plan File: agents/plans/aqa-<test-name>.md
Mark Phase 1 as completed and Phase 2 as current.
Proceed to Phase 2: Requirements Clarification by executing:
ACQUIRE aqa-flow-requirements-clarification.md FROM KB
npx claudepluginhub p/griddynamics-core-instructions-r2-core/test-planCreates a structured test plan from feature artifacts — queries test types, environment, and credentials, auto-detects the test framework, generates test cases mapped to user stories, and saves them under features/<name>/testing/.
/hatch3r-test-planProduces a comprehensive test plan with coverage targets, priority ordering, test case outlines, and structured todo.md entries using parallel researchers for feature or module-level auditing.
/qaCreates test plans and executes comprehensive QA testing including auth flows, edge cases, regressions, and bug reports.
/tdd-testcasesGenerates test cases for TDD development by reading requirements and task context, producing categorized tests with reliability levels, evaluating quality, and suggesting next TDD phase.
/plan-qaGenerates a QA test plan YAML from a ticket ID. Fetches ticket details from Linear, Jira, or GitHub, then produces a YAML test plan for execution with /start-qa.
/speckit-checklistGenerates a domain-specific checklist to validate the quality, clarity, and completeness of requirements, treating specs as code and the checklist as their unit tests.