agentleFS
jasonkneenjasonkneen/kiro/skills/quality-assurance/SKILL.md

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
  1. Distinctive:

    Ensure quality throughout the spec-driven development process with validation techniques, quality gates, and testing strategies.

    line 15
  2. Distinctive:

    Use quality assurance practices when:

    line 19
  3. Distinctive:

    Requirements-Driven Testing: Every test traces to a requirement

    line 28
  4. Distinctive:

    Conflict Detection: Check for contradictions

    line 55
  5. Distinctive:

    Completeness Analysis: Ensure all needs covered

    line 56
  6. Distinctive:

    Completeness Review: All design elements have tasks

    line 91
  7. Distinctive:

    Test individual functions/classes

    line 157
  8. Distinctive:

    Use real dependencies where practical

    line 163
  9. Distinctive:

    Test complete user journeys

    line 168
  10. Distinctive:

    Run tests: - verify they fail (red)

    line 177
  11. Distinctive:

    Validate: - ensure requirements satisfied

    line 180
  12. Distinctive:

    Use proper wait conditions

    line 202
  13. Distinctive:

    Use test doubles for external services

    line 211
  14. Distinctive:

    Add tests for uncovered paths

    line 217
  15. Distinctive:

    Use page object patterns for UI

    line 226
  16. Distinctive:

    Write tests first when possible

    line 301
  17. Distinctive:

    Use descriptive test names

    line 303
  18. Distinctive:

    Use metrics to drive improvements

    line 310

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Requirements-Driven Testing: Every test traces to a requirement
  2. Phase-Appropriate Validation: Different techniques for each phase
  3. Continuous Quality: Checks throughout development
  4. Automated Where Possible: Reduce manual effort
  5. 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:

  1. Self Review: Author checks completeness
  2. Stakeholder Review: Business validates requirements
  3. Technical Review: Team assesses feasibility
  4. 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:

  1. Architecture Review: Senior team validates design
  2. Security Review: Security implications assessed
  3. Performance Review: Performance characteristics evaluated
  4. 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:

  1. Completeness Review: All design elements have tasks
  2. Sequencing Review: Task order is logical
  3. Scope Review: Tasks are appropriately sized
  4. 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:

  1. Write tests first based on acceptance criteria
  2. Run tests - verify they fail (red)
  3. Write code - minimal to pass tests (green)
  4. Refactor - improve while keeping tests green
  5. 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 specified

Design 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 planned

Implementation 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 acceptable

Best Practices

Testing Best Practices

  1. Write tests first when possible
  2. Each test verifies one thing
  3. Use descriptive test names
  4. Maintain test independence
  5. Keep tests up-to-date

Quality Assurance Best Practices

  1. Find issues early (shift left)
  2. Automate everything possible
  3. Use metrics to drive improvements
  4. Make quality everyone's responsibility
  5. Continuous learning and improvement

Process Integration

  1. Link tests to requirements
  2. Provide quick feedback
  3. Focus testing on high-risk areas
  4. Keep documentation current
  5. 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?"

Download now (ZIP)

  • Other versions12 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 12

    1. liangdabiao/claude-data-analysis-ultra-main★ 282same name
    2. attilaszasz/sdd-pilot★ 98same name
    3. nahisaho/MUSUBI★ 74same name
    4. fmind/dot★ 11same name
    5. fmind/dotfiles★ 11same name
    6. liangdabiao/claudesdk-data-chat★ 4same name
    7. Ghosteken/agent-harness★ 2same name
    8. PhoenixNest/AGENT-GLOBAL-BASE★ 2same name
    9. axross/skills★ 1same name
    10. 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-labsSkill

      project-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

    • MicrosoftSkill

      agent-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.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.