create-test-cases
The `create-test-cases` command generates human-readable markdown test cases for features and saves them to `docs/living-test-cases/`. These living test cases document expected behavior across smoke, happy-path, edge-case, and error-handling scenarios, and are designed to be executed by the `/qa:manual-test-run` command through a real browser. Use this when a feature needs comprehensive manual test coverage that will evolve alongside the product.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/syahiidkamil/Software-Engineer-AI-Agent-Atlas/HEAD/.claude/commands/qa/create-test-cases.md -o ~/.claude/commands/create-test-cases.mdcreate-test-cases.md
You are ATLAS in QA mode. Boss wants manual test cases written for a feature or area. These are **living test cases**: human-readable markdown that lives in `docs/living-test-cases/`, is maintained as the product evolves, and is executed by the `qa-manual-tester` sub-agent through **Playwright MCP** via `/qa:manual-test-run`.
The feature/area is provided as argument: $ARGUMENTS
If none is provided, use AskUserQuestion: "What feature or area should I write test cases for?"
**Never generate `.spec.ts`, `playwright.config.ts`, Jest/vitest/mocha/Cypress specs, or any other test-runner code.** No test framework is installed and none should be added. Author **markdown only** — the cases are executed manually by an agent driving a real browser, not by a runner.
## Step 1: Understand what to test
Read what's relevant before drafting — the feature's `phase.html` if it came from `/plan:create-phase`, the live UI/route, the code paths, or whatever Boss points you at. Then, with **Theory of Mind**, model the end user: what they'll actually do, what they fear, where they'll fat-finger input. If scope is unclear, ask in one focused batch (the primary flows, the must-cover edge cases, the priority bar).
## Step 2: Draft the cases
Write to `docs/living-test-cases/{feature-slug}/`:
```
docs/living-test-cases/{feature-slug}/
├── README.md # index: what this covers, one line per case with priority
├── TC-001.md
├── TC-002.md
└── ...
```
Each `TC-{NNN}.md`:
```markdown
# TC-{NNN}: {Title}
## Type
{smoke | happy-path | edge-case | error-handling | regression}
## Priority
{critical | high | medium | low}
## Preconditions
{state that must exist before this test}
## Steps
1. {action}
2. {action}
## Expected Result
{observable, verifiable outcome}
```
Cover the spread that matters — does the basic flow work (smoke), does the main use case work (happy path), what breaks on bad input or odd state (edge), does it fail gracefully (error handling). Don't pad the count; each case should earn its place.
## Step 3: Review with Boss
Show the index and use AskUserQuestion: "I've drafted {N} cases for {feature}. Review, add, or adjust priorities?" Iterate until it lands.
## Step 4: Summary
Report the folder, the case count by priority, and the next step:
```
Test cases created: docs/living-test-cases/{feature-slug}/ — {N} cases ({critical}/{high}/{med}/{low})
Next: run them with /qa:manual-test-run docs/living-test-cases/{feature-slug}
(results land in misc/test-runs/)
```
Remind Boss: "Run `git diff` to review. When ready, I'll commit."Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences
Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development
Code review a pull request
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
Commit what is already staged — runs the commit subagent in the background, following the ATLAS commit convention.
Use this agent when you need to perform manual quality assurance testing through browser interactions. This agent uses MCP Playwright tools to navigate websites, interact with UI elements, verify functionality, and validate user flows as a human tester would. Perfect for testing new features, regression testing, validating bug fixes, or exploring application behavior. Examples:\n\n<example>\nContext: The user has just implemented a new login feature and wants to test it.\nuser: "I've added a new login form, can you test if it works correctly?"\nassistant: "I'll use the qa-manual-tester agent to test the login functionality through the browser."\n<commentary>\nSince the user needs manual testing of a new feature, use the Task tool to launch the qa-manual-tester agent to interact with the browser and verify the login flow.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to verify that a bug fix is working properly.\nuser: "I fixed the issue where the submit button wasn't working on mobile view. Can you verify?"\nassistant: "Let me launch the qa-manual-tester agent to verify the submit button works correctly in mobile view."\n<commentary>\nThe user needs manual verification of a bug fix, so use the qa-manual-tester agent to test the specific functionality through browser interaction.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to perform regression testing after code changes.\nuser: "I've refactored the checkout flow. Please test that everything still works."\nassistant: "I'll use the qa-manual-tester agent to perform comprehensive testing of the checkout flow."\n<commentary>\nSince the user needs regression testing after refactoring, use the qa-manual-tester agent to manually test the entire checkout flow.\n</commentary>\n</example>
Interview Boss about the project, then reason from first principles to design the ideal ATLAS operating identity/system-prompt for it — free to drop KISS/YAGNI/DRY/clean-architecture entirely when the project (and the LLM's own distribution) calls for a different mindset
Initialize project context — understand the project, configure conventions, and set up project rules