agentleFS
Aizaz-NoorAizaz-Noor/Agent-Startup-Skills/skills/test-engineer/SKILL.md

test-engineer

Skill2 starsChanged 7 months agoMITView on GitHub

QA and testing agent that writes unit tests, integration tests, and edge case coverage for the codebase. Triggers on: write tests, test coverage, QA, quality assurance, unit tests, integration tests, edge cases.

22 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use security-auditor, documentation-writer and 1 more.

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.
  • nahisahoSkill

    security-auditor

    security-auditor skill

    Also in 6 projects that use this

  • GitHubSkill

    documentation-writer

    Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.

    Also in 4 projects that use this

  • JeffallanSkill

    security-reviewer

    Identifies security vulnerabilities, generates structured audit reports with severity ratings, and provides actionable remediation guidance. Use when conducting security audits, reviewing code for vulnerabilities, or analyzing infrastructure security. Invoke for SAST scans, penetration testing, DevSecOps practices, cloud security reviews, dependency audits, secrets scanning, or compliance checks. Produces vulnerability reports, prioritized recommendations, and compliance checklists.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 14 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 18 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ensure the codebase works correctly by writing automated tests and identifying edge cases that the Coder may have missed.

    line 13
  2. Distinctive:

    After the codebase is implemented

    line 18
  3. Distinctive:

    When the user asks for test coverage

    line 19
  4. Distinctive:

    Before security audit (Phase 7 of SaaS Accelerator)

    line 20
  5. Distinctive:

    Test the happy path (expected inputs → expected outputs)

    line 32
  6. Distinctive:

    Test with invalid inputs (null, empty, wrong type)

    line 33
  7. Distinctive:

    Test boundary values (min/max limits)

    line 34
  8. Distinctive:

    Test successful request (correct status code and response body)

    line 38
  9. Distinctive:

    Test with missing required fields (expect 400)

    line 39
  10. Distinctive:

    Test without authentication on protected routes (expect 401)

    line 40
  11. Distinctive:

    Test with invalid data types (expect 422)

    line 41
  12. Very specific:

    Test files organized in a tests/ directory

    line 56
  13. Distinctive:

    Every API endpoint has at least one happy-path test

    line 61
  14. Distinctive:

    Every core business logic function has unit tests

    line 62
  15. Distinctive:

    Test runner is configured and documented

    line 64

“Common” is measured: kept by at least 6 in 10 of the 18 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

Test Engineer — Quality Assurance Agent

Purpose

Ensure the codebase works correctly by writing automated tests and identifying edge cases that the Coder may have missed.

When to Use

  • After the codebase is implemented
  • When the user asks for test coverage
  • Before security audit (Phase 7 of SaaS Accelerator)

Process

Step 1: Test Strategy

Define what to test:

  • Unit Tests: Individual functions and utilities
  • Integration Tests: API endpoints (request → response)
  • Edge Cases: Empty inputs, boundary values, unauthorized access

Step 2: Unit Tests

For each business logic function:

  • Test the happy path (expected inputs → expected outputs)
  • Test with invalid inputs (null, empty, wrong type)
  • Test boundary values (min/max limits)

Step 3: API Integration Tests

For each API endpoint:

  • Test successful request (correct status code and response body)
  • Test with missing required fields (expect 400)
  • Test without authentication on protected routes (expect 401)
  • Test with invalid data types (expect 422)

Step 4: Edge Case Identification

Systematically check:

  • What happens with an empty database?
  • What happens with duplicate entries?
  • What happens with very long strings?
  • What happens with concurrent requests?
  • What happens when an external service is unavailable?

Step 5: Test Runner Configuration

Generate the test runner config file (e.g., jest.config.js, pytest.ini) and a test run command in package.json scripts.

Output

  • Test files organized in a tests/ directory
  • testing_plan.md with coverage summary
  • Manual test checklist for things that cannot be automated

Exit Criteria

  • Every API endpoint has at least one happy-path test
  • Every core business logic function has unit tests
  • At least 5 edge cases are explicitly tested
  • Test runner is configured and documented

Download now (ZIP)

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.