# From QA to /autoqa

AutoQA is a skill we built at Parcha to automate QA on our product. It's open source in our Parcha Skills repo. https://github.com/Parcha-ai/parcha-skills/

Canonical: https://agentrun.ai/blog/from-qa-to-autoqa
Published: 2026-11-03T18:19:54.000Z
Author: Miguel Rios Berrios

[_AutoQA_](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa) _is a skill we built at Parcha to automate QA on our product. It's open source in our Parcha Skills repo._ [_https://github.com/Parcha-ai/parcha-skills/_](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa)

We have a team member whose job used to be QA: whenever the product changed, he clicked around and figured out what was working and what wasn't. With agents this good, that work started to become redundant, so he moved to building QA agents that now handle about 90% of it for him. He spends his time on the parts that need a person: the complicated flows, the new things, and the ones that are more qualitative.

As our agents do more work on their own, running for hours or days, knowing that the work in a PR is good matters more than ever. We use unit tests, integration tests and, where it applies, proofs in Lean, but for product work that changes what people see and do, I don't think there's a replacement for QA. We also can't QA everything with people when we open close to a thousand PRs a week across our repos (more in our busiest weeks), and not every PR has the same impact or surface area.

## What it does

We made it public so there's a baseline skill that works for anyone. It looks at a PR, works out the surface area of the change, proposes a QA plan, and then the agent runs it. The agent needs to be able to write and run code, and for changes to the product experience it helps to give it a browser. That can be Playwright, the Chrome DevTools MCP or anything else that lets it test live.

Not everyone does QA the same way, and the skill wouldn't be much use if it had to work out every flow from scratch. So it reads an [AUTOQA.md](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa) file in your repo, where you or your agent declare the flows that always get tested, the flows to test when certain files change, and what to do when a flow fails. Some failures are flaky, some are deterministic and matter, some are critical to the business, and some are an acceptable risk.

```
Required in every run:

- health and authenticated/unauthenticated gates;
- deployed-SHA match (the preview serves the head under test);
- every selected DIFF behavior and its nearest persistence/worker/storage seam.

...

- Long non-Claude turns can trip the stale-run watchdog on models that emit few
  status messages ("Brain run became stale"); treat watchdog kills as
  environment, not product.
```

_Example of two sections of our_ [_AUTOQA.md_](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa) _(trimmed)_

Keeping the flows in [AUTOQA.md](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa) instead of in the skill is what lets it grow with you. A skill you install tends to stay as it was, and the flows in it would go stale. [AUTOQA.md](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa) can also tell the agent when to change the file itself, for example when the product changes and a flow isn't needed anymore. Ours is 570 lines now and has changed 28 times since July.

## Where it came from

I made the first version in July, out of a procedure we already had. A teammate had written a doc on how to test every [grep.ai](https://grep.ai/) feature end to end, and I asked an agent to find it and turn it into a skill:

```
please use [skillify] and [writing-great-skills] and skill-creator to turn this into a selfqa skill. make it generic for any kind of repo (in  unc-skill) then add specific insturctions for our repo and all features and means t o test (chrome dev tools, api endpoints etc) by reading that doc.
```

_Example of the prompt that started it (typos mine)_

The next day I renamed it and split it in two: one /autoqa skill for any repo, and a config file for ours, which became [AUTOQA.md](https://github.com/Parcha-ai/parcha-skills/tree/main/autoqa), and we published it on July 21.

## How much we use it

Most of our PRs now get an autoqa report, and nearly all of them are posted by agents while they ship the PR on their own. It's part of our ship process, the skill our agents follow to take a PR from open to merged.

![Chart of the share of main-repository pull requests with an AutoQA report, increasing from July to October.](/blog/imported-writing/from-qa-to-autoqa/e960aecfb947b2aa.png)

I also had a hunch that autoqa means we write fewer QA plans for people, and that the ones we do write are denser and more complicated. The plans we file for our QA engineer in Linear point that way.

![Two charts show fewer QA plans filed after AutoQA and more words per remaining plan.](/blog/imported-writing/from-qa-to-autoqa/d82b34232d5ee347.png)

  

It has become a key part of how we keep shipping more without introducing simple, easy-to-spot bugs, and it lets us put our attention where it matters, including QA on complex changes, on product surfaces, and anywhere an autonomous agent still isn't enough.