agentleFS
Sign inStart free
JakeschincariolJakeschincariol/replica-skill/replica-test/SKILL.md

replica-test

Skill399 starsChanged 40 days agoMITView on GitHub

Clicks through every flow of an app clone and tests it for bugs: a test plan generated from the recon flows with happy paths and edge cases, Playwright end-to-end tests where possible, a browser click-through where not, and bug reports in a fixed format with severity, steps and evidence. Use when the user says "test my clone", "find bugs", "QA this", "click through everything", "write e2e tests", "does it work", or after /replica-build or /replica-backend.

  • Installs packages

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test your clone, not the original: Never load test, fuzz, script or hammer the original app's servers.

    line 21
  2. Very specific:

    Use roles and labels for selectors (getByRole('button', { name: 'Book' })), never CSS classes.

    line 44
  3. Very specific:

    Add to every spec: fail on console errors, fail on any 5xx response, and an axe accessibility scan (@axe-core/playwright) on each screen.

    line 52
  4. Very specific:

    Every bug goes in replica/bugs.md in the bug-report.md format: an ID, a severity, exact steps, expected, actual, evidence.

    line 64
  5. Distinctive:

    Only report what you reproduced.

    line 74

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

replica-test

Reads the flows in replica/recon.md. Writes replica/test-plan.md, replica/bugs.md, and end-to-end tests in the project (e2e/). Templates in this folder: test-plan.md, bug-report.md, e2e.example.spec.ts.

The rule

Test your clone, not the original. Never load test, fuzz, script or hammer the original app's servers. Using the original by hand, as a normal user, to see how it behaves is fine.

Step 1: the plan

For every flow F01, F02... in the recon map, write:

  • Happy path: the steps, and what the user should see at the end.
  • Edge cases that apply. Go down this list for every flow: empty input, very long input, emoji and accents, two tabs at once, double click on submit, back button mid-flow, refresh mid-flow, slow network, offline, expired session, second user's data (must be invisible), time zones and daylight saving, mobile width, keyboard only, screen reader labels.
  • Negative cases: wrong password, card declined (Stripe test card 4000 0000 0000 0002), permission denied, deleted record.

Number every case: F01-H1, F01-E3, F01-N2.

Step 2: automate what you can

Playwright, one spec per flow, against the local dev server with seed data. Use roles and labels for selectors (getByRole('button', { name: 'Book' })), never CSS classes. See e2e.example.spec.ts.

npm i -D @playwright/test && npx playwright install chromium
npx playwright test

Add to every spec: fail on console errors, fail on any 5xx response, and an axe accessibility scan (@axe-core/playwright) on each screen.

Step 3: click through the rest

What cannot be automated (emails arriving, OAuth with real providers, payments end to end, visual glitches) gets a manual pass. If a browser tool is available, drive the local clone with it and screenshot each step. Otherwise give the user the checklist and wait for answers.

Step 4: report bugs

Every bug goes in replica/bugs.md in the bug-report.md format: an ID, a severity, exact steps, expected, actual, evidence. Severity:

means
S1data loss, security hole, payments wrong, core flow blocked
S2a feature broken, no workaround
S3broken with a workaround, or visibly wrong
S4cosmetic

Only report what you reproduced. "Might be an issue" goes in a separate "to check" list.

Step 5: fix loop

Fix S1 and S2 first. For every fix: write the failing test first, fix, watch it pass, keep the test. Re-run the whole suite after each batch. Update bugs.md with the commit that fixed each one.

Output

test-plan.md, the specs, bugs.md, and a summary: cases run, passed, failed, bugs by severity, fixed so far. Ship nothing with an open S1. Next: /replica-diff.

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.

Check your setup, free