New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

QA Project Bootstrap

by petrkindlmann in petrkindlmann/qa-skills

Onboard a new QA engineer to an existing codebase, or audit an existing test architecture.

MITAuto-check: notesTesting & QA

Install QA Project Bootstrap

skills CLI
$ npx skills add petrkindlmann/qa-skills --skill qa-project-bootstrap -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install petrkindlmann/qa-skills qa-project-bootstrap --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/petrkindlmann/qa-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/qa-project-bootstrap .claude/skills/qa-project-bootstrap && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
qa-project-bootstrap
GitHub stars
165
Token cost
~5.2k tokens
SKILL.md length
2,738 words
Files
3 (incl. references)
Skills in repo
45
Repo updated
First seen
Licence
MIT

At a glance

Onboard a new QA engineer to an existing codebase, or audit an existing test architecture.

  • Works in 5 steps: Time to First Merged Test Is the Success… → Progressive Complexity → Document Tribal Knowledge → …
  • : QA onboarding
  • SKILL.md covers Quick Route, Discovery Questions, Core Principles and First 30 Days Checklist, plus 4 more sections
  • Calls npx

What it does

QA Project Bootstrap is an agent skill from petrkindlmann/qa-skills. Onboard a new QA engineer to an existing codebase, or audit an existing test architecture. Produces a 30-day ramp plan: codebase orientation, framework walkthrough, test architecture audit, mentorship pairing, and first-test guidance. Use when: "QA onboarding," "new tester," "ramp up," "test architecture audit," "first 30 days," "QA mentorship," "joining QA team." Not for: setting up QA on a brand-new project from scratch — use qa-start. Related: qa-start, qa-project-context, shift-left-testing, ai-qa-review.

Its SKILL.md is about 5.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files, including reference files (for example `references/audit-worksheets.md` and `references/framework-walkthrough.md`).

It sits in Testing & QA, covering QA and bug reports. The repository describes itself as: 50 QA and test-automation skills for Claude Code, Codex, Cursor, and any Agent Skills Standard runtime. The licence is MIT.

When your agent uses it

  • : QA onboarding
  • Test architecture audit
  • Joining QA team. Not for: setting up QA on a brand-new project from scratch — use qa-start

Example prompts

  • “QA onboarding,”
  • “new tester,”
  • “ramp up,”
  • “/qa-project-bootstrap”

Requirements

  • Node.js

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Time to First Merged Test Is the Success Metric
  2. Progressive Complexity
  3. Document Tribal Knowledge
  4. Pair First, Solo Second
  5. Make the Easy Path the Right Path

What it can do on your machine

Read from SKILL.md and the folder at commit b3bb61b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

QA Project Bootstrap loads about 5.2k tokens when it runs, and up to ~7.2k if it reads all its reference files. Until then it costs about 134 tokens; SKILL.md has 2,738 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~134
When it runs · the whole SKILL.md, loaded when a task matches
~5.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~7.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:97
    ] All environment variables configured (`.env.local`, test credentials)

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from petrkindlmann/qa-skills at commit b3bb61b, republished under its MIT licence (© petrkindlmann). 2,738 words, ~5,187 tokens.

Download SKILL.mdSave it as .claude/skills/qa-project-bootstrap/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
qa-project-bootstrap
description
Onboard a new QA engineer to an existing codebase, or audit an existing test architecture. Produces a 30-day ramp plan: codebase orientation, framework walkthrough, test architecture audit, mentorship pairing, and first-test guidance. Use when: "QA onboarding," "new tester," "ramp up," "test architecture audit," "first 30 days," "QA mentorship," "joining QA team." Not for: setting up QA on a brand-new project from scratch — use `qa-start`. Related: qa-start, qa-project-context, shift-left-testing, ai-qa-review.
license
MIT
metadata.author
kindlmann
metadata.version
2.0
metadata.category
process
<objective>
A new QA engineer pointed at the README and left to "figure it out" burns two weeks learning bad habits by trial and error, and an unaudited inherited suite hides flaky tests and coverage gaps that only surface in production. This skill reduces time to first merged test and produces three concrete artifacts: a 30-day ramp plan, a five-dimension test architecture audit, and a framework walkthrough doc. Every section serves the same metric — a real test merged to main and green in CI, fast.

Before starting: Check for .agents/qa-project-context.md in the project root. If it exists, it answers most discovery questions and provides the technical context for onboarding. If it does not, creating it is the first action item. </objective>

Quick Route

This skill serves three distinct jobs. Identify yours, jump to the section, skip the rest.

SituationJump toOutput
Onboarding a new person to an existing teamFirst 30 Days Checklist → Mentorship PatternsA 30-day ramp plan with owners and dates
Inherited an existing suite with no onboarding/docsTest Architecture Audit (scope by team_maturity)A 1-2 page findings doc, five dimensions
Need the reference doc for anyone writing testsFramework Walkthrough TemplateA project-specific walkthrough.md

A real onboarding usually needs all three; a quick health check needs only the audit.

Discovery Questions

Who Is Being Onboarded?

  1. New QA engineer or developer contributing to tests? QA engineers need test strategy context and codebase orientation. Developers contributing tests need framework patterns and conventions. The ramp-up path differs significantly.

  2. Experience level with the test framework? First time with Playwright/Cypress/pytest? Experienced but new to this codebase? Advanced and just needs conventions? This determines how much framework walkthrough to include.

  3. Solo QA or joining an existing QA team? Solo QA needs to establish conventions from scratch. Joining a team means learning existing patterns and contributing within established norms.

Project State

  1. Is there an existing test framework? If yes: how healthy is it? If no: framework selection is step one (see test-strategy skill).

  2. Does the project have a .agents/qa-project-context.md? If not, creating one is a high-priority onboarding task -- it forces the new person to document what they learn, which benefits the entire team.

  3. Is local environment setup documented? Can a new person run the full stack and execute tests within the first day? If setup takes more than 2 hours, the process needs fixing before onboarding.

Access and Tooling
  1. Are all required accounts and permissions set up? Repository access, CI dashboard, staging environment, test data accounts, bug tracker, communication channels. Missing access on day one wastes time and creates frustration.

Core Principles

1. Time to First Merged Test Is the Success Metric

The single most important measure of onboarding success is how quickly the new person gets a real test merged into the main branch. Not a tutorial exercise, not a local-only experiment -- a real test that runs in CI and validates real product behavior. Target: within the first two weeks.

2. Progressive Complexity

Start simple, increase difficulty gradually. First test: a smoke test or page-load verification. Second test: a form interaction. Third test: a multi-step user flow. By week three, the new person is writing tests for sprint stories. Throwing someone into the deep end with a complex multi-service flow on day one creates anxiety and bad habits.

3. Document Tribal Knowledge

Every time a new person asks a question that is not answered in documentation, that is tribal knowledge escaping. The onboarding process should capture these answers in permanent form -- ideally in .agents/qa-project-context.md, the framework walkthrough doc, or code comments. The new person is the best person to write this documentation because they know exactly what was missing.

4. Pair First, Solo Second

The first 3 tests should be written in a pair -- the new person driving, an experienced team member navigating. Pairing transfers tacit knowledge (why we do things this way, not just how) and builds confidence faster than reading documentation alone.

5. Make the Easy Path the Right Path

If the correct way to write a test is harder than the wrong way, people will write tests the wrong way. Ensure that test utilities, fixtures, page objects, and data factories make the recommended patterns the path of least resistance. If a new person has to fight the framework to follow conventions, fix the framework.

Calibrate to your team maturity (set team_maturity in .agents/qa-project-context.md):

  • startup — Focus on days 1–10: get one test framework running and one critical path covered. Skip process ceremony until you have a working baseline.
  • growing — Full 30-day plan: framework selection, CI integration, coverage baseline, team conventions documented.
  • established — 30-day plan plus: audit existing suite for anti-patterns, propose tooling upgrades, establish metrics baseline, schedule recurring quality reviews.

First 30 Days Checklist

Week 1: Environment, Access, and Orientation

Day 1-2: Setup

  • Repository cloned and building locally
  • All environment variables configured (.env.local, test credentials)
  • Application running locally (frontend + backend + database)
  • Test suite runs locally and passes (or known failures are documented)
  • IDE configured with recommended extensions (test runner plugin, linter, formatter)
  • Access granted: CI dashboard, staging environment, bug tracker, team channels

Day 3-4: Orientation

  • Read .agents/qa-project-context.md (or create it if it does not exist)
  • Walk through the test directory structure with a team member
  • Understand the test pyramid: how many unit, integration, and E2E tests exist
  • Review the CI pipeline: what runs on PR, what runs nightly, what blocks merge
  • Identify the top 5 critical user flows (these will be the first testing targets)
  • Attend one Three Amigos or sprint planning session as an observer
  • Working with the team's AI assistants: Identify which coding agents the team uses (Claude Code, Codex, Cursor, Gemini CLI, etc.), where their context lives (.agents/qa-project-context.md, CLAUDE.md, AGENTS.md), which prompts/skills are house style, and which tasks the team explicitly does NOT delegate to AI. Produce a short "AI assistants we use, what they're good at, what to never let them do" doc as a Day 4 deliverable. If the team automates Playwright via an agent, note that agent-driven Playwright now has its own @playwright/cli (daemon architecture, playwright-cli commands, token-efficient) — distinct from the npx playwright test runner the framework walkthrough documents.

Day 5: First Small Win

  • Run a single test in debug/headed mode and understand what it does
  • Modify one assertion in an existing test, verify it fails as expected, revert
  • Read 3 existing tests and annotate what each section does (setup, action, assertion)
Week 2: First Real Test
  • Identify a simple, low-risk test to write (page loads, element visibility, basic navigation)
  • Write the test using existing page objects and fixtures (pair with a team member)
  • Run the test locally, ensure it passes reliably (3 consecutive runs)
  • Open a PR, receive feedback, iterate
  • Test passes in CI
  • First test merged
Week 3: Sprint Contribution
  • Pick up a sprint story's QA work (with mentorship)
  • Write tests covering the story's acceptance criteria
  • Identify at least one edge case not covered by acceptance criteria
  • Participate actively in Three Amigos or story refinement (ask questions)
  • Review one existing PR for test quality (using the PR review checklist from shift-left-testing)
Week 4: Independence Milestones
  • Write and merge a multi-step E2E test without pairing
  • Participate in bug triage and articulate testing gaps
  • Contribute to .agents/qa-project-context.md with new learnings
  • Present test results/findings at sprint review or team standup
  • Self-assess: which test patterns feel comfortable? Which need more practice?

Test Architecture Audit

When joining an existing project, assess the health of the test suite before writing new tests. This audit takes 2-4 hours and produces a clear picture of the current state.

Scope the audit by team_maturity (from .agents/qa-project-context.md) — a one-size-fits-all audit wastes a startup's time and underserves an established team:

  • startup — Skip the full audit. Confirm one path is covered and one framework runs; spend the saved hours getting a first test merged.
  • growing — Run all five dimensions once to establish a baseline; defer recurring reviews.
  • established — Full five-dimension audit plus recurring quality reviews on a schedule (e.g. monthly), with the findings doc tracked over time.
What to Assess

Assess five dimensions, each with a fill-in worksheet:

  • Coverage and Distribution — test counts by layer, pyramid shape, code coverage and trend.
  • Reliability — flaky test rate, top flakiest tests, quarantine count and age.
  • CI Health — full suite and per-stage duration, parallelism, pass rate, retry rate.
  • Technical Debt — skipped tests, waitForTimeout/force: true usage, hardcoded data, assertionless tests, deprecated APIs, stale AI-generated tests, stale feature flags.
  • Conventions — page objects, fixtures, factories, naming, shared utilities, tagging.

See references/audit-worksheets.md for the copy-and-fill worksheets covering all five dimensions.

Audit Output

Produce a short document (1-2 pages) summarizing findings, categorized as:

  • Strengths: What the existing suite does well (preserve and learn from these)
  • Gaps: Missing coverage areas, undertested critical paths
  • Risks: Flaky tests, stale quarantines, declining coverage
  • Quick Wins: Improvements achievable in 1-2 sprints (fix flaky tests, add missing happy-path coverage)
  • Strategic Work: Improvements requiring sustained investment (refactor test architecture, add integration layer)

Framework Walkthrough Template

Create this document for your project. It is the primary reference for anyone writing tests. It has six sections:

  1. Architecture Overview — framework, language, config location, and the annotated directory tree.
  2. How to Run Tests — the full set of run commands (all tests, single file, grep, headed, debug, UI mode, per-browser, report).
  3. How to Write a New Test (Step by Step) — the six-step location/reuse/write/run/PR flow plus the Arrange-Act-Assert test template.
  4. How to Debug Failures — local vs CI failure playbooks and common failure-pattern decoder.
  5. Common Patterns and Conventions — project-specific examples for auth fixtures, data factories, assertion specificity, and selector priority.
  6. Where to Find Help — the routing table for questions about patterns, failures, product behavior, and docs.

See references/framework-walkthrough.md for the full template with all code blocks, directory trees, and command lists to copy and adapt.

Codebase Orientation Guide

Walk through these areas with the new person in a 60-90 minute session.

Show full SKILL.md (1,101 more words)Show less
Test Directory Structure Tour

Walk through the actual directory tree, explaining:

  • Why tests are organized this way (by feature, not by type)
  • Where to find page objects for each product area
  • Where shared utilities live and what they do
  • Where test data and fixtures are defined
  • Where CI configuration lives
Shared Utilities Inventory
UtilityLocationPurposeExample
Auth fixturefixtures/auth.fixture.tsProvides authenticated sessions{ adminPage, userPage }
Data factoryhelpers/factories.tsCreates test data via APIcreateTestUser({ role: 'editor' })
API clienthelpers/api-client.tsDirect API calls for setup/teardownapiClient.delete('/users/' + id)
Accessibility helperhelpers/a11y.tsaxe-core wrappercheckAccessibility(page, testInfo)
Assertionshelpers/assertions.tsCustom matcherstoHaveToast('Saved')
Page Objects Walk-Through

Show the existing page objects and explain:

  • Base page class and its contract (abstract path, waitForReady)
  • How component objects compose with page objects
  • Naming conventions (file name matches route: checkout.page.ts for /checkout)
  • How to add a new page object (copy-modify pattern from the simplest existing one)
CI Pipeline Walk-Through

Open the CI configuration and trace through:

  • What triggers the pipeline (push, PR, schedule)
  • What stages run and in what order
  • Where test artifacts go (reports, traces, screenshots)
  • How to find and interpret a failed test in CI
  • How to re-run a failed job

Mentorship Patterns

Pair on First 3 Tests

The experienced team member sits with the new person for their first three tests:

  1. Test 1: Navigator/Driver. Experienced person explains the approach and makes key decisions. New person types and asks "why?" at each step. Goal: understand the workflow.
  2. Test 2: Co-pilots. Both contribute equally. New person makes more decisions, experienced person fills gaps. Goal: build confidence.
  3. Test 3: Observer. New person drives entirely. Experienced person observes and gives feedback only when asked or when the approach would cause problems. Goal: independence.
Review All PRs for First 2 Weeks

Every PR from the new person gets a thorough, supportive review for the first two weeks. Not just "LGTM" -- specific feedback on:

  • Pattern adherence (are they using page objects correctly?)
  • Selector strategy (are they using stable locators?)
  • Assertion quality (are assertions specific enough?)
  • Test isolation (any shared state risks?)
  • Naming (does the test name describe behavior?)

After two weeks, reduce to standard review depth.

Testing Buddy System

Assign a testing buddy -- a specific person the new team member can ask any question without hesitation. The buddy:

  • Checks in daily for the first week ("What are you stuck on?")
  • Is available for ad-hoc questions without scheduling
  • Reviews all PRs with educational comments (explain the "why")
  • Introduces the new person to team norms and unwritten rules
Progressive Responsibility Ramp
Week 1-2:  Write tests for existing, well-understood features (smoke, basic flows)
Week 3-4:  Write tests for current sprint stories (with pairing available)
Week 5-6:  Write tests independently, review others' PRs
Week 7-8:  Contribute to test architecture (new fixtures, utilities, page objects)
Month 3+:  Lead test planning for a feature area, mentor the next new person

Anti-Patterns

Sink or Swim Onboarding

Giving a new person repository access, pointing them at the README, and expecting them to figure it out. This produces weeks of wasted time, bad habits learned from trial and error, and early attrition. Structured onboarding with pairing pays for itself in the first sprint.

Tutorial-Only Onboarding

Spending two weeks on framework tutorials and toy exercises before touching the real codebase. Tutorials teach syntax; they do not teach project conventions, domain knowledge, or team workflow. Minimize tutorials (1-2 hours max) and move to real tests quickly.

No Documentation, All Tribal Knowledge

When the answer to every question is "ask Sarah," the team has a bus factor of one and onboarding depends entirely on Sarah's availability. Document conventions in .agents/qa-project-context.md and the framework walkthrough. If something is important enough to explain verbally, it is important enough to write down.

Perfectionism Paralysis

Expecting the new person's first test to be perfect. The first test should be functional and following basic conventions. Code quality improves with each PR review cycle. Blocking a first PR on style nits or advanced patterns destroys confidence and delays the first win.

Ignoring the Onboarding Experience

Not soliciting feedback from the person being onboarded. They experienced the process firsthand and know exactly what was missing, confusing, or wasted time. Conduct a 15-minute feedback session at the end of week 2 and week 4. Use their feedback to improve onboarding for the next person.

Copy-Paste Without Understanding

The new person copies an existing test, changes the locators and URL, and calls it done. The test works but they do not understand why. Pairing and code review should focus on the "why" behind each pattern. If someone cannot explain why a fixture is structured a certain way, they will misuse it when the context differs.

Verification

Prove the artifacts hold before declaring onboarding complete. Cheapest check first.

  1. The first merged test is stable, not lucky. Run it repeated to rule out flakiness, then confirm CI is green.
    • npx playwright test <new-test> --repeat-each=3 exits 0 (3 consecutive passes locally)
    • The PR's CI check is green on the same test
  2. The audit doc is complete, not a stub. Open the findings doc and confirm all five dimensions (coverage/distribution, reliability, CI health, technical debt, conventions) are filled, and findings are categorized into strengths / gaps / risks / quick wins / strategic work. A startup that scoped out the audit (see team_maturity) records that decision instead.
  3. The context file parses and is populated. .agents/qa-project-context.md exists and carries framework, critical paths, team structure, and risk areas — not a high-level placeholder.

Done When

  • At least one working test merged to the repo, passing in CI, and stable across 3 local repeats (--repeat-each=3 exits 0) — proves the local and pipeline setup end-to-end.
  • Test architecture audit doc exists with all five dimensions filled and findings categorized (strengths, gaps, risks, quick wins, strategic work) — or, for a startup team_maturity, the doc records the explicit decision to scope it out.
  • Every Week-1 Day-1/2 setup item has a recorded owner and a target date; blocking items are filed as tracked tickets.
  • .agents/qa-project-context.md exists and is populated with framework, critical paths, team structure, and risk areas (not a placeholder).
  • Test framework selected with rationale recorded (evaluated alternatives, decision written down) — or marked N/A when inheriting an existing framework.

Reference Files (in references/)

  • framework-walkthrough.md — The full framework walkthrough template: architecture overview, run commands, new-test step-by-step and template, debug playbooks, conventions, and help routing.
  • audit-worksheets.md — Copy-and-fill worksheets for the test architecture audit (coverage, reliability, CI health, technical debt, conventions).
  • qa-project-context -- The project context file is the foundation for onboarding. Create it if it does not exist; update it as part of onboarding.
  • playwright-automation -- Framework-specific patterns, page object model, fixtures, and CI integration for Playwright-based projects.
  • shift-left-testing -- Introduces the new person to the team's shift-left practices: Three Amigos, PR review, Definition of Done.
  • test-strategy -- Understanding the overall testing strategy gives the new person context for why tests are structured the way they are.
  • test-reliability -- Understanding flaky test patterns and quarantine management helps the new person avoid creating unreliable tests.

© petrkindlmann, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (references) in skills/qa-project-bootstrap of petrkindlmann/qa-skills.

  • SKILL.md
  • references/audit-worksheets.md
  • references/framework-walkthrough.md

Open the folder on GitHubat commit b3bb61b

Compare with similar skills

QA Project Bootstrap next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

QA Project Bootstrap compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
QA Project Bootstrap this skillpetrkindlmann/qa-skills165—~5.2kAutomated safety check: NotesMIT
Reproduce Chat Statesdifferent-ai/openwork24k—~673Automated safety check: PassCustom licence
Dynamo Jira TicketDynamoDS/Dynamo2k—~1.1kAutomated safety check: PassApache-2.0
Minimal Run And Auditlllllllama/RigorPilot-Skills4972 repos~691Automated safety check: PassMIT
Moav E2EMotherofallVPNs/MoaV448—~1.9kAutomated safety check: NotesMIT
Anchor Reprolynxlangya/techne1051 repos~1.2kAutomated safety check: PassMIT

Similar skills

  • Reproduce Chat States

    different-ai/openwork

    Fires known chat states in the running OpenWork desktop app, such as provider errors, retries and tool steps, so you can check how each renders.

    24k GitHub stars~673 tokensUpdated today
    Testing & QAAuto-check passed

  • Dynamo Jira Ticket

    DynamoDS/Dynamo

    Create structured Jira tickets for Dynamo from bug reports, failing tests, or feature requests.

    2k GitHub stars~1.1k tokensUpdated today
    Testing & QAAuto-check passed

  • Minimal Run And Audit

    lllllllama/RigorPilot-Skills

    Rigor Run skill for README-first deep learning repo reproduction.

    497 GitHub starsUsed in 2 repos~691 tokens
    Testing & QAAuto-check passed

  • Moav E2E

    MotherofallVPNs/MoaV

    Run and debug MoaV's end-to-end tests — real protocol connectivity (client-test.sh) and the moav CLI smoke test — against a LIVE server, via the self-hosted e2e workflow or a local test VPS.

    448 GitHub stars~1.9k tokensUpdated yesterday
    Testing & QAAuto-check: notes

  • Anchor Repro

    lynxlangya/techne

    Reproduce a behavioral bug before fixing it, record the failing probe, and verify the fix with the same probe.

    105 GitHub starsUsed in 1 repo~1.2k tokens
    Testing & QAAuto-check passed

  • Creating A Coral Task

    Human-Agent-Society/CORAL

    Author a new CORAL task — the three pieces that must line up (task.yaml, seed/, a packaged grader/), the coral init → coral validate → smoke-test loop, and how to pick a grader pattern (stdout…

    1k GitHub stars~2.2k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

More from petrkindlmann/qa-skills

All 45 skills in this repo

  • Accessibility Testing

    petrkindlmann/qa-skills

    Test for WCAG 2.2 AA compliance with axe-core + Playwright, keyboard navigation audits, screen reader testing, ARIA pattern validation, and legal compliance mapping (ADA, EAA, Section 508).

    165 GitHub stars~4.5k tokensUpdated 3 mo ago
    Auto-check passed

  • Agentic Browser Testing

    petrkindlmann/qa-skills

    Goal-driven E2E testing where a browser agent (Playwright MCP / computer-use) reads a natural-language goal and explores the app via the accessibility tree to assert outcomes — no pre-written script.

    165 GitHub stars~4.5k tokensUpdated 3 mo ago
    Auto-check passed

  • AI Test Generation

    petrkindlmann/qa-skills

    Use AI to write NEW test code from specs, PRDs, user stories, code diffs, bug reports, or OpenAPI specs.

    165 GitHub stars~4.8k tokensUpdated 3 mo ago
    Auto-check passed

  • API Testing

    petrkindlmann/qa-skills

    Test REST and GraphQL APIs with Playwright APIRequestContext, Supertest, or standalone HTTP clients.

    165 GitHub stars~2.7k tokensUpdated 3 mo ago
    Auto-check passed

  • CI CD Integration

    petrkindlmann/qa-skills

    Design CI/CD pipelines that run test suites. An agent skill from petrkindlmann/qa-skills.

    165 GitHub stars~4.8k tokensUpdated 3 mo ago
    Auto-check passed

  • Compliance Testing

    petrkindlmann/qa-skills

    Test for regulatory compliance: GDPR/CMP consent verification, Google Consent Mode v2, Global Privacy Control (GPC), CCPA/US state opt-out, EU AI Act Article 50 transparency, Better Ads Standards…

    165 GitHub stars~4.6k tokensUpdated 3 mo ago
    Auto-check passed

Categories

Questions about QA Project Bootstrap

What does QA Project Bootstrap do?

Onboard a new QA engineer to an existing codebase, or audit an existing test architecture. QA Project Bootstrap is an agent skill from petrkindlmann/qa-skills. Onboard a new QA engineer to an existing codebase, or audit an existing test architecture.

When should I use QA Project Bootstrap?

QA Project Bootstrap fits situations like: : QA onboarding; test architecture audit; joining QA team. Not for: setting up QA on a brand-new project from scratch — use qa-start.

How do I install QA Project Bootstrap in Claude Code?

Run `npx skills add petrkindlmann/qa-skills --skill qa-project-bootstrap -a claude-code`. Or copy the skill folder (skills/qa-project-bootstrap in petrkindlmann/qa-skills) into .claude/skills/qa-project-bootstrap in your project. Claude Code loads it when a task matches its description.

How do I install QA Project Bootstrap in Codex?

Run `npx skills add petrkindlmann/qa-skills --skill qa-project-bootstrap -a codex`. Or copy the skill folder (skills/qa-project-bootstrap in petrkindlmann/qa-skills) into .agents/skills/qa-project-bootstrap in your project. Codex loads it when a task matches its description.

Can I use QA Project Bootstrap in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add petrkindlmann/qa-skills --skill qa-project-bootstrap -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/qa-project-bootstrap, .gemini/skills/qa-project-bootstrap, .github/skills/qa-project-bootstrap and .opencode/skills/qa-project-bootstrap in your project.

What does QA Project Bootstrap need to run?

Going by SKILL.md and its folder, QA Project Bootstrap needs the command-line tools its instructions call (npx). Our summary lists: Node.js.

Does QA Project Bootstrap access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is QA Project Bootstrap safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does QA Project Bootstrap use?

QA Project Bootstrap is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does QA Project Bootstrap use?

About 5.2k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2k tokens, read only when the agent opens those files.

What are the alternatives to QA Project Bootstrap?

Skills that share tags, products or a category with QA Project Bootstrap: Reproduce Chat States (different-ai/openwork, 24k stars), Dynamo Jira Ticket (DynamoDS/Dynamo, 2k stars), Minimal Run And Audit (lllllllama/RigorPilot-Skills, 497 stars) and Moav E2E (MotherofallVPNs/MoaV, 448 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains QA Project Bootstrap?

petrkindlmann (a GitHub user) maintains it in petrkindlmann/qa-skills, which has 165 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on June 10, 2026.

Source: petrkindlmann/qa-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.