← ClaudeAtlas

profilelisted

Build a profile from a test suite that already exists, by reading it. Drafts profile.yaml and CONVENTIONS.md describing what the repo actually does, so generated tests match the repo instead of a generic example. Use when a project has tests but no profile fits, when generated code does not match the house style, or when the user says my repo already has tests.
eduramos21/qa-automation-framework · ★ 0 · Data & Documents · score 66
Install: claude install-skill eduramos21/qa-automation-framework
# Build a profile from an existing suite Input: `$ARGUMENTS`. A stack name, a path to a suite, or nothing, in which case find the suites and ask which one. Most repos that need this already have hundreds of tests and a house style nobody wrote down. The job is to write it down, from the code, without correcting it on the way past. ## The one rule **Describe what the repo does. Do not prescribe what it should do.** If their page objects contain assertions, the conventions say page objects contain assertions. If half the suite uses `data-qa` and the shipped profile prefers `getByRole`, the conventions say `data-qa`. You will see things worth changing. Put them in a separate report at the end, never inside `CONVENTIONS.md`. The moment the conventions file mixes "what we do" with "what we should do", every agent that reads it writes code in a style the repo does not use, the reviewer rejects it, and the whole thing gets uninstalled. Improving the suite is `/qa:audit` and `/qa:fix`. This is not that. ## Steps **1. Find the starting point.** List the shipped profiles. If one matches the language and runner, copy it and edit. If none does, start from `profiles/_template`. Either way the copy goes in `<project>/profiles/<name>/`, because project profiles win over the plugin's and this description belongs to this repo. ```bash cp -r <plugin>/profiles/ts-playwright <project>/profiles/acme-web ``` Name it after the repo or the stack, not after the runner. `acme-web` ages bett