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."Activate ATLAS pattern recognition mode. Identify repeated patterns, extract essential characteristics, and create reusable abstractions from concrete examples.
Adversarially review something just built — presume it is broken and find where. Use after implementing a feature, finishing a build, or before shipping, or whenever ATLAS or Boss wants a hostile second opinion on a diff, a running app, or a whole codebase. Spawns clean-context reviewers with opposing lenses (correctness, security, empty-world) and reproduces every finding by running the target before believing it. Distinct from /code-review, which statically reads a diff and never runs the app.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Stop and consult this skill whenever your response would include specific facts about Anthropic's products. Covers: Claude Code (how to install, Node.js requirements, platform/OS support, MCP server integration, configuration), Claude API (function calling/tool use, batch processing, SDK usage, rate limits, pricing, models, streaming), and Claude.ai (Pro vs Team vs Enterprise plans, feature limits). Trigger this even for coding tasks that use the Anthropic SDK, content creation mentioning Claude capabilities or pricing, or LLM provider comparisons. Any time you would otherwise rely on memory for Anthropic product details, verify here instead — your training data may be outdated or wrong.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.
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
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