Template
refactor: rebuild template — Tailwind v4, Docker self-hosting, passkey auth
Toolchain fixes (all previously broken): - npm run lint: next lint was removed in Next 16 -> eslint with flat config - .eslintrc.json was ignored by ESLint 9 -> eslint.config.mjs - npm test / test:e2e exited 1 with no tests -> passWithNoTests - Vitest scanned tests/ and would have run Playwright specs -> scoped to src/ - Playwright targeted Mobile Safari while docs installed only chromium - reuseExistingServer silently tested a foreign server on :3000 -> E2E_PORT - 11 high-severity vulns -> npm audit fix - deny rule Read(**/.env*) also blocked .env.example -> precise patterns Stack changes: - Tailwind v3 -> v4 (CSS-first, no tailwind.config.ts, tw-animate-css) - shadcn regenerated for v4; 33 components -> 6 core, bundled radix-ui - Supabase removed entirely; data layer is now chosen per project - Vercel removed; Docker Compose self-hosting with scripts/update.sh - Better Auth + passkey plugin as the binding auth standard - ThemeProvider and Sonner mounted; dark mode and toasts now actually work Workflow system: - Sub-agents wired: /frontend, /backend, /qa delegate to .claude/agents - Checklists folded into their SKILL.md; one file per skill - Rules rewritten: DB-agnostic backend, passkey security, v4 frontend - Spec language settled as German, skill instructions English
This commit is contained in:
Florian Wilde
+75
-131
@@ -1,159 +1,103 @@
|
||||
---
|
||||
name: qa
|
||||
description: Test features against acceptance criteria, find bugs, and perform security audit. Use after implementation is done.
|
||||
argument-hint: "feature-spec-path"
|
||||
description: Test a feature against acceptance criteria, find bugs, audit security. Use after implementation is done.
|
||||
argument-hint: "PROJ-X or feature-spec-path"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
# QA Engineer
|
||||
# QA
|
||||
|
||||
## Role
|
||||
You are an experienced QA Engineer AND Red-Team Pen-Tester. You test features against acceptance criteria, identify bugs, and audit for security vulnerabilities.
|
||||
You own the test phase for one feature. The **QA Engineer** sub-agent does the
|
||||
testing; you set up its context, then present and prioritize the results with the
|
||||
user.
|
||||
|
||||
## Before Starting
|
||||
1. Read `features/INDEX.md` for project context
|
||||
2. Read the feature spec referenced by the user
|
||||
3. Check recently implemented features for regression testing: `git log --oneline --grep="PROJ-" -10`
|
||||
4. Check recent bug fixes: `git log --oneline --grep="fix" -10`
|
||||
5. Check recently changed files: `git log --name-only -5 --format=""`
|
||||
## 1. Load context
|
||||
|
||||
### Check Playwright Browser Installation
|
||||
Run: `npx playwright install --dry-run 2>&1 | head -5`
|
||||
1. Read `features/INDEX.md` — note which features are already **Deployed**
|
||||
(those are the regression surface)
|
||||
2. Read the feature spec
|
||||
3. `git log --oneline -10` — what changed recently
|
||||
|
||||
If browsers are not installed, tell the user:
|
||||
> "Playwright browsers need to be installed once. I'll do this now — it downloads ~300MB of browser binaries."
|
||||
> Then run: `npx playwright install chromium`
|
||||
> This is a one-time setup per machine. After cloning the repo, always run this once before E2E tests.
|
||||
## 2. Set status
|
||||
|
||||
## Workflow
|
||||
Update `features/INDEX.md` and the spec header to **In Review**. Verify by
|
||||
re-reading.
|
||||
|
||||
### 1. Read Feature Spec
|
||||
- Understand ALL acceptance criteria
|
||||
- Understand ALL documented edge cases
|
||||
- Understand the tech design decisions
|
||||
- Note any dependencies on other features
|
||||
## 3. Delegate testing
|
||||
|
||||
### 2. Manual Testing
|
||||
Test the feature systematically in the browser:
|
||||
- Test EVERY acceptance criterion (mark pass/fail)
|
||||
- Test ALL documented edge cases
|
||||
- Test undocumented edge cases you identify
|
||||
- Cross-browser: Chrome, Firefox, Safari
|
||||
- Responsive: Mobile (375px), Tablet (768px), Desktop (1440px)
|
||||
Invoke the **QA Engineer** sub-agent with:
|
||||
- the spec path
|
||||
- the list of deployed features to regression-check
|
||||
- any areas the developer flagged as risky
|
||||
|
||||
### 3. Security Audit (Red Team)
|
||||
Think like an attacker:
|
||||
- Test authentication bypass attempts
|
||||
- Test authorization (can user X access user Y's data?)
|
||||
- Test input injection (XSS, SQL injection via UI inputs)
|
||||
- Test rate limiting (rapid repeated requests)
|
||||
- Check for exposed secrets in browser console/network tab
|
||||
- Check for sensitive data in API responses
|
||||
Wait for its report.
|
||||
|
||||
### 4. Regression Testing
|
||||
Verify existing features still work:
|
||||
- Check features listed in `features/INDEX.md` with status "Deployed"
|
||||
- Test core flows of related features
|
||||
- Verify no visual regressions on shared components
|
||||
## 4. Write results into the spec
|
||||
|
||||
### 5. Run Automated Tests
|
||||
Run existing test suites before manual testing:
|
||||
```bash
|
||||
npm test # Vitest: integration tests for API routes
|
||||
npm run test:e2e # Playwright: E2E tests from previous QA runs
|
||||
Append this to the feature spec — not to a separate file:
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## QA Test Results
|
||||
|
||||
**Getestet:** YYYY-MM-DD
|
||||
**Tester:** QA Engineer (AI)
|
||||
|
||||
### Acceptance Criteria
|
||||
- [x] AC-1: [Kriterium]
|
||||
- [ ] AC-2: [Kriterium] — BUG-1
|
||||
|
||||
### Edge Cases
|
||||
- [x] EC-1: [Randfall] — korrekt behandelt
|
||||
|
||||
### Security-Audit
|
||||
- [x] Ohne Session kein Zugriff
|
||||
- [x] Kein Zugriff auf fremde Datensätze
|
||||
- [x] Passkey ist der primäre Anmeldeweg
|
||||
- [x] Eingaben validiert, keine Injection
|
||||
|
||||
### Gefundene Bugs
|
||||
|
||||
#### BUG-1: [Titel]
|
||||
- **Severity:** Critical | High | Medium | Low
|
||||
- **Reproduktion:** 1. … 2. … 3. …
|
||||
- **Erwartet:** …
|
||||
- **Tatsächlich:** …
|
||||
|
||||
### Zusammenfassung
|
||||
- **Acceptance Criteria:** X von Y bestanden
|
||||
- **Bugs:** N gesamt (C critical, H high, M medium, L low)
|
||||
- **Produktionsreif:** JA / NEIN
|
||||
```
|
||||
Note any failures — these are regressions and must be treated as High bugs.
|
||||
|
||||
### 6. Write Unit Tests
|
||||
Before E2E tests, identify and test isolated logic with Vitest. Place tests **co-located** next to the source file (e.g. `src/hooks/useFeature.test.ts` next to `src/hooks/useFeature.ts`):
|
||||
Re-read the file afterwards to confirm it landed.
|
||||
|
||||
**What to unit test (evaluate each):**
|
||||
- Custom hooks with non-trivial logic (e.g. `useKanbanStorage`: localStorage read/write, error fallback)
|
||||
- Pure utility/transformation functions (e.g. drag-and-drop reorder logic)
|
||||
- Form validation logic (if extracted from components)
|
||||
## 5. Review with the user
|
||||
|
||||
**What NOT to unit test:**
|
||||
- Pure presentational components with no logic
|
||||
- Logic already fully covered by E2E tests
|
||||
Present: criteria passed/failed, bugs by severity, security findings, verdict.
|
||||
Then ask:
|
||||
> "Welche Bugs sollen zuerst behoben werden?"
|
||||
|
||||
For each unit test:
|
||||
- Test the happy path
|
||||
- Test error paths and edge cases (e.g. corrupt input, empty state)
|
||||
- Mock only external dependencies (localStorage, fetch) — not internal logic
|
||||
## 6. Wrap up
|
||||
|
||||
Run to confirm all pass: `npm test`
|
||||
|
||||
### 7. Write E2E Tests
|
||||
For each acceptance criterion that passed manual testing, write a Playwright test in `tests/PROJ-X-feature-name.spec.ts`:
|
||||
- One `test()` per acceptance criterion
|
||||
- Tests describe the user journey in plain language
|
||||
- Run to confirm all pass: `npm run test:e2e`
|
||||
|
||||
These tests become the permanent regression suite for this feature.
|
||||
|
||||
### 8. Document Results
|
||||
- Add QA Test Results section to the feature spec file (NOT a separate file)
|
||||
- Use the template from [test-template.md](test-template.md)
|
||||
|
||||
### 9. User Review
|
||||
Present test results with clear summary:
|
||||
- Total acceptance criteria: X passed, Y failed
|
||||
- Bugs found: breakdown by severity
|
||||
- Security audit: findings
|
||||
- Production-ready recommendation: YES or NO
|
||||
|
||||
Ask: "Which bugs should be fixed first?"
|
||||
|
||||
## Context Recovery
|
||||
If your context was compacted mid-task:
|
||||
1. Re-read the feature spec you're testing
|
||||
2. Re-read `features/INDEX.md` for current status
|
||||
3. Check if you already added QA results to the feature spec: search for "## QA Test Results"
|
||||
4. Run `git diff` to see what you've already documented
|
||||
5. Continue testing from where you left off - don't re-test passed criteria
|
||||
|
||||
## Bug Severity Levels
|
||||
- **Critical:** Security vulnerabilities, data loss, complete feature failure
|
||||
- **High:** Core functionality broken, blocking issues
|
||||
- **Medium:** Non-critical functionality issues, workarounds exist
|
||||
- **Low:** UX issues, cosmetic problems, minor inconveniences
|
||||
|
||||
## Important
|
||||
- NEVER fix bugs yourself - that is for Frontend/Backend skills
|
||||
- Focus: Find, Document, Prioritize
|
||||
- Be thorough and objective: report even small bugs
|
||||
|
||||
## Production-Ready Decision
|
||||
- **READY:** No Critical or High bugs remaining
|
||||
- **NOT READY:** Critical or High bugs exist (must be fixed first)
|
||||
|
||||
## Checklist
|
||||
- [ ] Feature spec fully read and understood
|
||||
- [ ] All acceptance criteria tested (each has pass/fail)
|
||||
- [ ] All documented edge cases tested
|
||||
- [ ] Additional edge cases identified and tested
|
||||
- [ ] Cross-browser tested (Chrome, Firefox, Safari)
|
||||
- [ ] Responsive tested (375px, 768px, 1440px)
|
||||
- [ ] Security audit completed (red-team perspective)
|
||||
- [ ] Regression test on related features
|
||||
- [ ] Every bug documented with severity + steps to reproduce
|
||||
- [ ] Screenshots added for visual bugs
|
||||
- [ ] Unit tests written for non-trivial hooks and utility functions (`npm test` passes)
|
||||
- [ ] E2E tests written for all passing acceptance criteria (`npm run test:e2e` passes)
|
||||
- [ ] QA section added to feature spec file
|
||||
- [ ] User has reviewed results and prioritized bugs
|
||||
- [ ] Production-ready decision made
|
||||
- [ ] `features/INDEX.md` status updated to "In Review" (at QA start)
|
||||
- [ ] `features/INDEX.md` status updated to "Approved" (if production-ready) OR kept "In Review" (if bugs remain)
|
||||
- [ ] Every acceptance criterion has an individual pass/fail
|
||||
- [ ] Documented and undocumented edge cases tested
|
||||
- [ ] Security audit done from a red-team angle
|
||||
- [ ] Regression check against deployed features
|
||||
- [ ] Unit tests for non-trivial logic (`npm test` passes)
|
||||
- [ ] E2E test per passing criterion (`npm run test:e2e` passes)
|
||||
- [ ] QA section written into the spec and verified
|
||||
- [ ] `features/INDEX.md` → **Approved** if no Critical/High, otherwise stays **In Review**
|
||||
|
||||
## Handoff
|
||||
If production-ready:
|
||||
> "All tests passed! Status updated to **Approved**. Next step: Run `/deploy` to deploy this feature to production."
|
||||
|
||||
If bugs found:
|
||||
> "Found [N] bugs ([severity breakdown]). Status remains **In Review**. The developer needs to fix these before deployment. After fixes, run `/qa` again."
|
||||
- Clean → "Alle Tests bestanden, Status **Approved**. Nächster Schritt: `/deploy`."
|
||||
- Bugs → "[N] Bugs gefunden ([Aufschlüsselung]). Status bleibt **In Review**.
|
||||
Erst `/frontend` bzw. `/backend` zum Beheben, danach nochmal `/qa`."
|
||||
|
||||
## Commit
|
||||
|
||||
## Git Commit
|
||||
```
|
||||
test(PROJ-X): Add QA test results for [feature name]
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user