quality-assurance
Skill753 starsChanged 11 months agoMITView on GitHub
Comprehensive testing and validation strategies for spec-driven development. Learn phase-specific validation techniques, quality gates, and testing approaches to ensure high-quality implementation.
We split this skill into the rules it gives an agent
18 rules. 0 are common, 18 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
18
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Ensure quality throughout the spec-driven development process with validation techniques, quality gates, and testing strategies.
- Distinctive: line 19
Use quality assurance practices when:
- Distinctive: line 28
Requirements-Driven Testing: Every test traces to a requirement
- Distinctive: line 55
Conflict Detection: Check for contradictions
- Distinctive: line 56
Completeness Analysis: Ensure all needs covered
- Distinctive: line 91
Completeness Review: All design elements have tasks
- Distinctive: line 157
Test individual functions/classes
- Distinctive: line 163
Use real dependencies where practical
- Distinctive: line 168
Test complete user journeys
- Distinctive: line 177
Run tests: - verify they fail (red)
- Distinctive: line 180
Validate: - ensure requirements satisfied
- Distinctive: line 202
Use proper wait conditions
- Distinctive: line 211
Use test doubles for external services
- Distinctive: line 217
Add tests for uncovered paths
- Distinctive: line 226
Use page object patterns for UI
- Distinctive: line 301
Write tests first when possible
- Distinctive: line 303
Use descriptive test names
- Distinctive: line 310
Use metrics to drive improvements
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Quality Assurance
Ensure quality throughout the spec-driven development process with validation techniques, quality gates, and testing strategies.
When to Use This Skill
Use quality assurance practices when:
- Completing any spec phase (requirements, design, tasks)
- Transitioning between phases
- Implementing features from specs
- Reviewing completed work
- Establishing team quality standards
Core Principles
- Requirements-Driven Testing: Every test traces to a requirement
- Phase-Appropriate Validation: Different techniques for each phase
- Continuous Quality: Checks throughout development
- Automated Where Possible: Reduce manual effort
- Fast Feedback: Catch issues early
Phase-Specific Validation
Requirements Phase Validation
Quality Checklist:
- All user stories have acceptance criteria
- Requirements are unambiguous and specific
- Each requirement can be validated/tested
- EARS format used consistently
- Requirements link to business objectives
- No conflicting requirements
Review Process:
- Self Review: Author checks completeness
- Stakeholder Review: Business validates requirements
- Technical Review: Team assesses feasibility
- Approval: Formal sign-off before design
Validation Techniques:
- Scenario Walkthroughs: Step through user journeys
- Edge Case Analysis: Identify boundary conditions
- Conflict Detection: Check for contradictions
- Completeness Analysis: Ensure all needs covered
Design Phase Validation
Quality Checklist:
- Design addresses all requirements
- Scalability considerations documented
- Maintainability assessed
- Security addressed
- Performance requirements considered
- External integrations defined
Review Process:
- Architecture Review: Senior team validates design
- Security Review: Security implications assessed
- Performance Review: Performance characteristics evaluated
- Integration Review: External dependencies validated
Validation Techniques:
- Design Walkthroughs: Step through system interactions
- Threat Modeling: Identify security vulnerabilities
- Performance Modeling: Estimate system performance
- Dependency Analysis: Map external requirements
Tasks Phase Validation
Quality Checklist:
- Each task has clear deliverables
- Task sequence is logical
- All design elements covered
- Each task can be validated
- Tasks appropriately sized (2-4 hours)
- Dependencies clearly defined
Review Process:
- Completeness Review: All design elements have tasks
- Sequencing Review: Task order is logical
- Scope Review: Tasks are appropriately sized
- Dependency Review: Dependencies clear
Quality Gates
Requirements Phase Exit Criteria
- All user stories follow proper format
- Acceptance criteria use EARS format
- Requirements are testable and measurable
- No conflicting requirements
- Stakeholders have approved
- Edge cases documented
Design Phase Exit Criteria
- Architecture addresses all requirements
- Non-functional requirements addressed
- External dependencies identified
- Data models clearly defined
- Error handling documented
- Security considerations addressed
- Technical review completed
Tasks Phase Exit Criteria
- All design elements have tasks
- Tasks properly sequenced
- Each task is actionable
- Requirements references included
- Test approach defined
- Task breakdown reviewed
Task-Level Quality Gates
Before Starting:
- Task requirements understood
- Test strategy defined
- Dependencies available
- Environment ready
During Implementation:
- Code follows standards
- Tests written alongside code
- Coverage meets thresholds (80%+)
- No critical vulnerabilities
Before Marking Complete:
- All tests pass
- Code review completed
- Documentation updated
- Requirements validated
Testing Strategies
Test Pyramid
/\
/ \ E2E Tests (10%)
/____\ Integration Tests (20%)
/ \
/________\ Unit Tests (70%)Unit Testing
- Fast execution (< 1 second per test)
- Test individual functions/classes
- Mock external dependencies
- Target 80%+ coverage
Integration Testing
- Test component interactions
- Use real dependencies where practical
- Validate API contracts
- Test critical workflows
End-to-End Testing
- Test complete user journeys
- Production-like environment
- Focus on critical business flows
- Minimal but comprehensive
Test-Driven Development
For each task:
- Write tests first based on acceptance criteria
- Run tests - verify they fail (red)
- Write code - minimal to pass tests (green)
- Refactor - improve while keeping tests green
- Validate - ensure requirements satisfied
Quality Metrics
Code Quality
- Line Coverage: % of code lines executed
- Branch Coverage: % of code branches tested
- Cyclomatic Complexity: Code complexity
- Technical Debt: Accumulated issues
Testing Effectiveness
- Test Pass Rate: % of tests passing
- Execution Time: Time to run tests
- Defect Detection Rate: Bugs found by tests vs production
- Test Maintenance: Time spent maintaining tests
Common Quality Issues
Flaky Tests
Symptoms: Tests pass/fail inconsistently Solutions:
- Identify timing dependencies
- Use proper wait conditions
- Isolate test data
- Fix race conditions
Slow Test Suites
Symptoms: Tests take too long Solutions:
- Parallelize execution
- Optimize database operations
- Use test doubles for external services
- Profile and optimize slow tests
Low Coverage
Symptoms: Insufficient code coverage Solutions:
- Add tests for uncovered paths
- Focus on critical business logic
- Use mutation testing
- Set coverage gates in CI
Test Maintenance Burden
Symptoms: Tests require frequent updates Solutions:
- Improve test design
- Use page object patterns for UI
- Reduce coupling to implementation
- Regular test refactoring
Validation Checklists
Requirements Validation
## Requirements Review
**Completeness:**
- [ ] All user roles addressed
- [ ] Happy path scenarios covered
- [ ] Edge cases documented
- [ ] Error cases handled
- [ ] Business rules captured
**Clarity:**
- [ ] Precise language used
- [ ] No ambiguous terms
- [ ] Technical jargon avoided
- [ ] Behaviors are specific
**Testability:**
- [ ] Each requirement verifiable
- [ ] Success criteria observable
- [ ] Inputs/outputs specifiedDesign Validation
## Design Review
**Architecture:**
- [ ] Requirements addressed
- [ ] Components well-defined
- [ ] Interfaces specified
- [ ] Data flow documented
**Quality Attributes:**
- [ ] Performance considered
- [ ] Security addressed
- [ ] Scalability planned
- [ ] Maintainability assessed
**Risks:**
- [ ] Single points of failure identified
- [ ] Bottlenecks documented
- [ ] Mitigations plannedImplementation Validation
## Implementation Review
**Code Quality:**
- [ ] Follows standards
- [ ] Well-documented
- [ ] Tests included
- [ ] No security issues
**Requirements:**
- [ ] All criteria met
- [ ] Edge cases handled
- [ ] Error handling complete
**Integration:**
- [ ] Works with existing code
- [ ] APIs functioning
- [ ] Performance acceptableBest Practices
Testing Best Practices
- Write tests first when possible
- Each test verifies one thing
- Use descriptive test names
- Maintain test independence
- Keep tests up-to-date
Quality Assurance Best Practices
- Find issues early (shift left)
- Automate everything possible
- Use metrics to drive improvements
- Make quality everyone's responsibility
- Continuous learning and improvement
Process Integration
- Link tests to requirements
- Provide quick feedback
- Focus testing on high-risk areas
- Keep documentation current
- Integrate tools with workflow
Quick Reference
Phase Transition Questions:
- Requirements → Design: "Does design address all requirements?"
- Design → Tasks: "Do tasks cover all design elements?"
- Tasks → Implementation: "Does code satisfy task specifications?"
Quality Gate Questions:
- "Is this testable and measurable?"
- "Have we considered what could go wrong?"
- "Would another developer understand this?"
- "Does this meet our standards?"
Other versions12 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 12
- liangdabiao/claude-data-analysis-ultra-main★ 282same name
- attilaszasz/sdd-pilot★ 98same name
- nahisaho/MUSUBI★ 74same name
- fmind/dot★ 11same name
- fmind/dotfiles★ 11same name
- liangdabiao/claudesdk-data-chat★ 4same name
- Ghosteken/agent-harness★ 2same name
- PhoenixNest/AGENT-GLOBAL-BASE★ 2same name
- axross/skills★ 1same name
- brylie/compendium★ 1same name
2 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use project-scaffolding and agent-evaluation.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
third-order-labsSkillproject-scaffolding
Templates, directory conventions, and document structure for long-form fiction projects. Contains the full template library — documents are created as the project needs them, not all at once.
Also in 3 projects that use this
MicrosoftSkillagent-evaluation
Help a learner evaluate and observe an AI agent on Microsoft Foundry — quality/safety evaluators, tracing, and reading results. Use for Lesson 3 tasks: measuring agent performance, adding observability, or interpreting evaluation output.
Also in 3 projects that use this
In this repository7 other files it gives its agents.
- ai-promptingSkill
- create-steering-documentsSkill
- design-documentationSkill
- requirements-engineeringSkill
- spec-driven-developmentSkill
- task-breakdownSkill
- troubleshootingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

