Our review
Generates a structured QA test plan for customer CSS deployments, focusing on predicted breakages, risk assessment, and manual test steps.
Strengths
- Strict output format ensures consistent, actionable reports
- Targeted identification of critical breakages with confidence levels
- 300-line limit keeps reports concise and scoped
- Incorporates Git history to detect recurring issues
Limitations
- CSS-specific, does not cover other types of testing
- Requires specific directory structure (src/customers/[customer]/custom.css)
- Outputs only a report, no automated test execution
Use this skill before deploying custom CSS stylesheets for a client to get a quick risk analysis and manual test plan.
Do not use it for general non-CSS testing, or when you need full automated test suites rather than a manual test plan.
Security analysis
SafeThe skill instructs an AI to read files and generate a report without executing any dangerous commands, making it safe.
No concerns found
Examples
Generate a QA test plan for the CSS deployment for customer AcmeCorp. Analyze potential conflicts and provide a risk assessment.Analyze CSS for CustomerX and create a manual test plan to ensure no visual regressions after their custom styles are applied.I need a pre-deployment risk assessment for the new custom CSS for Client Y. Identify predicted breakages and test sessions.name: qa-css-analysis description: Generate focused QA test plans (300 lines max) for customer CSS deployments
⚠️ OUTPUT RULES - READ FIRST
Generate EXACTLY these 3 sections in this order:
- Predicted Breakages (3-7 issues max)
- Risk Assessment (single table)
- Manual Test Plan (test sessions with checkboxes)
Total length: 300 lines maximum
All other sections are FORBIDDEN unless explicitly valuable for THIS deployment.
When to Use This Skill
- User mentions: "QA test plan", "CSS conflicts", "analyze CSS for [customer]"
- Customer CSS deployment scenarios
- Pre-deployment risk assessment
Analysis Workflow
Step 1: Read Customer CSS
- Location:
src/customers/[customer]/custom.css - Flag: Global selectors, !important, element selectors
Step 2: Read Application Styles
- Core:
src/app/@core/components/ - Theme:
src/app/@theme/ - Pages:
src/app/pages/
Step 3: Detect Conflicts
- Compare selectors
- Check specificity + !important
- Predict cascade issues
Step 4: Check Git History
- Search: "CSS", "style", "[customer name]"
- Find patterns from past bugs
Step 5: Generate Report
Follow exact format below.
REQUIRED OUTPUT FORMAT
File: risk reports/qa_test_report_[customer].md
Structure (STRICT):
# QA Test Report - [Customer] CSS Deployment
## 🔍 Predicted Breakages
### Issue #1: [Short Title]
**Severity:** 🔴 CRITICAL
**Priority:** P1
**Confidence:** 95%
**What Breaks:**
- Component: [name]
- Expected: [normal behavior]
- After deploy: [broken behavior]
**Root Cause:**
```css
/* problematic CSS */
```
**Impact:**
- User: [how affected]
- Business: [consequences]
**Where to Test:**
- Page 1
- Page 2
**Test Steps:**
1. Navigate to [page]
2. Check [element]
3. Expected: [result]
4. If broken: [what happens]
[Repeat for issues #2-7 max]
---
## 📊 Risk Assessment
| Issue | Severity | Priority | Confidence | Impact |
|-------|----------|----------|------------|--------|
| [Issue 1] | 🔴 CRITICAL | P1 | 95% | [desc] |
| [Issue 2] | 🟡 HIGH | P2 | 90% | [desc] |
**Severity Key:**
- 🔴 CRITICAL: App unusable, blocks deployment
- 🟡 HIGH: Major visual/functional issue
- 🟢 MEDIUM: Minor issue, workarounds exist
- ⚪ LOW: Negligible impact
---
## 📋 Manual Test Plan
### Test Session 1: Critical Issues (XX min)
**Setup:**
- Browser: Chrome (latest)
- Environment: Test
#### Test 1.1: [Test Name]
- [ ] Step 1: [action]
- [ ] Step 2: [action]
- [ ] Expected: [result]
- [ ] If broken: [report what]
- [ ] Stop condition: Yes/No
[Repeat for sessions 2-3 max]
---
**END OF REPORT**
Optional Sections (Use Sparingly)
Include ONLY if critically valuable:
- Executive Summary (2-3 lines) - Deploy yes/no at top
- Stop Conditions - When to halt testing
- Time Estimates - Per session only
Do NOT add:
- Screenshots checklists
- Bug templates
- Historical context
- Reference info
- Success criteria
- Contact info
- Execution logs
- ASCII diagrams
Severity Guidelines
Confidence:
- 100%: Same selector + !important
- 90-95%: Global selector
- 80-90%: Similar selectors
- 70-80%: Potential conflict
- <70%: Low risk
Priority:
- P1: Blocks deployment
- P2: Test before deploy
- P3: Document only
Best Practices
- Check git history for patterns
- Focus on:
button,input,div, element selectors - Any
!important= red flag - Global selectors = dangerous
- Keep report under 300 lines
Output Checklist
Before saving, verify:
- [ ] Only 3 main sections
- [ ] 3-7 issues max
- [ ] Under 300 lines
- [ ] No forbidden sections
- [ ] Saved to:
risk reports/qa_test_report_[customer].md
Example Output Length
# QA Test Report - CustomerB CSS
## Predicted Breakages (7 issues × 20 lines = 140 lines)
## Risk Assessment (table = 15 lines)
## Manual Test Plan (3 sessions × 30 lines = 90 lines)
---
Total: ~250 lines ✅
TDD Red-Green-Refactor
Testing
Skill that guides Claude through the complete TDD cycle.
Web Accessibility Audit
Testing
Performs a comprehensive web accessibility audit following WCAG standards.
UAT Test Case Generator
Testing
Generates structured and comprehensive user acceptance test cases.