For the practitioner, not the buyer
A test automation consultant whose own kickoff email is still typed by hand is a doctor smoking on the way to the cardiology ward.
Every other guide on this topic is a vendor list. Accenture, Tricentis, Qualitest, ImpactQA, with a Selenium-versus-Playwright sidebar you have read fifty times. This piece is for the people who write those suites for a living. The argument is that the same discipline you sell to clients (codegen, page objects, fixtures, scheduled CI) applies to a consulting practice, and that the cleanest off-the-shelf implementation of it lives in a file at ~/.clone/memory/rituals/default-kickoff.md.
What follows is the mapping. QA primitive on the left, consulting equivalent on the right. The reference implementation is in the live marketing repo, file paths and line numbers in line.
The mapping in one diff
npx playwright codegen writes a spec. Clone writes a ritual. Same idea, different file.
Open src/components/how-it-works.tsx on cl0ne.ai and read step 03 (lines 42 through 58). The product observes you draft a kickoff email twelve times, extracts the three rules you follow without thinking, asks a single yes-or-no question, and writes the ritual. That is what codegen does for a Playwright test.
Below, the spec a QA consultant emits on a normal Tuesday next to the ritual Clone emits when applied to that consultant's own kickoff workflow. Both are re-runnable. Both have triggers, steps, and assertions. The right side is shorter because the ritual file delegates the "how to drive Gmail" primitives to the Computer Agent layer, exactly the way a page object hides selectors from a Playwright test.
Codegen output, two flavours
// $ npx playwright codegen https://app.client.com
// Output: tests/checkout.spec.ts
import { test, expect } from '@playwright/test';
test('user can complete checkout', async ({ page }) => {
await page.goto('https://app.client.com');
await page.getByRole('button', { name: 'Sign in' }).click();
await page.getByLabel('Email').fill('user@acme.com');
await page.getByLabel('Password').fill('hunter2');
await page.getByRole('button', { name: 'Continue' }).click();
await page.getByRole('link', { name: 'Cart' }).click();
await expect(page.getByText('Total: $148.00')).toBeVisible();
await page.getByRole('button', { name: 'Place order' }).click();
await expect(page.getByText('Order confirmed')).toBeVisible();
});QA primitive on the left. Consulting equivalent on the right.
Six concepts you already use, applied to your own practice.
Treat the consulting practice the way you treat a client codebase: there is a contract that defines done, there are recorded sessions you can replay, there is shared state that wants to live in one place, there are scheduled runs and there are assertions. Six rows, one per primitive.
Discovery → SOW
In a QA engagement you scope the suite. In your own practice the equivalent artifact is the SOW. Both are the contract that says what 'done' looks like. Treat your kickoff email as the deploy script that ships the SOW.
Codegen → ritual mining
Playwright codegen records you driving the app once and writes a re-runnable spec. Clone observes you driving Gmail once (kickoff email, attach SOW, cc the assistant), reads the last twelve runs, and writes a re-runnable ritual. how-it-works.tsx step 03 lines 44-56 is the codegen UI for consulting.
Page object → memory layer
A QA suite isolates selectors in page objects so a UI change touches one file. Clone isolates client-specific data (your CRM contacts, your SOW templates, your voice) in ~/.clone/memory/. Switch from HubSpot to Pipedrive and you change one layer, not every ritual.
Fixtures → templates
Test fixtures seed a known state before a run. Your kickoff fixture is the SOW PDF in the engagement folder. Your invoice fixture is last month's billable export from Timely. Clone reads them in place; you don't re-upload.
Cron CI → scheduled rituals
Your QA pipeline runs the suite on a schedule. Clone runs your rituals on a schedule. Step 04 of how-it-works.tsx pins the most common one to '⏱ Every Monday 8:00am'. That string is a cron expression for the consulting business.
Assertions → review queue
A failing assertion blocks a deploy. A failing ritual lands in your review queue instead of the client's inbox. The cc rule for contracts above $10K is an assertion. The 'SOW PDF must be attached' rule is an assertion. Clone never sends; you approve.
The uncopyable detail
Every Monday 8:00am
on line 63 is a cron expression in disguise.Open src/components/how-it-works.tsx. Step 04, lines 60 through 76. The body of the step is a Monday morning run that pulls last week's billable hours from Timely, generates six invoices in QuickBooks, sends them to clients via email, logs outreach in HubSpot, and drafts the Friday retro in Notion. The total it cites at line 73: 4.2 hours of admin completed while you were asleep.
Operationally, the trigger string ⏱ Every Monday 8:00am on line 63 is cron: "0 8 * * 1" applied to a consulting business. The same expression syntax you would drop into a GitHub Actions workflow to run your own QA suite. The difference is the runner: Playwright drives page; Clone drives your already-logged-in Gmail tab.
The practitioner's Tuesday
What it looks like when you apply your own discipline to your own week.
Toggle to compare. The "before" column is the typical week of a senior test automation consultant whose own ops are still manual. The "after" column is the same person, same client roster, same skill, after one weekend of seeding rituals from their last twelve real runs.
Tuesday 8am you open the laptop, sip coffee, check four client Slacks, write the post-discovery follow-up email to a new lead, attach the SOW you drafted last night, cc your assistant by hand, paste the meeting notes in HubSpot, and start your billable work at 9:30. End of week you reconcile Timely with QuickBooks for two hours and email six invoices on Sunday night. Every step is muscle memory. None of it is recorded anywhere as a re-runnable artifact.
- Kickoff email composed by hand, twelve times a quarter
- Friday retro typed from scratch in Notion every week
- Monday invoicing pushes billable work to Tuesday afternoon
- Zero artifacts you can grep, diff, or hand to a junior
The codegen session, transcribed
One sentence in. One markdown ritual out. Twelve real emails read.
This is a real Clone session, abbreviated. The pattern extraction is the same three-rule shape that ships in the step 03 component (personal opening line, attach SOW PDF, cc the assistant when the contract is above $10K). The output is a markdown file with a trigger, steps, and assertions. The thirteenth kickoff drafts itself the next time the trigger fires.
The argument in one paragraph
Practice what you sell, on the practice that sells it.
The thing a QA consultant is genuinely good at is taking a human-driven, multi-step browser flow and turning it into a re-runnable artifact with assertions. That skill is fungible. Pointed at the client's checkout page it produces a Playwright spec and a green CI build. Pointed at your own kickoff email it produces a markdown ritual and a Gmail draft queued for review. The translation cost is zero because the primitives are the same: trigger, steps, assertions, schedule.
What blocks most practitioners from doing this is not skill, it is the absence of a runner. You can write your own consulting-ops Playwright wrapper, of course. You can spend a weekend stitching together a Node script that drives Gmail via IMAP, QuickBooks via the Intuit API, HubSpot via the v3 CRM API, and your filesystem via fs. You will then spend the following six months maintaining four API integrations and writing your own selector library. Or you point a computer-use agent at the apps you already have logged in, let it read your real history, and let it write the ritual. The runtime is already there.
The next two sections show what that looks like end to end on Clone, and what the day-to-day cost of running it is.
“The thirteenth kickoff lands as a Gmail draft, in your voice, with the SOW PDF attached and the right cc, before you finish coffee.”
From the codegen reference in how-it-works.tsx step 03, on cl0ne.ai
One practical note on the runner
Clone is not Playwright. Closer in posture to Anthropic computer-use.
For a QA audience the distinction matters. Playwright drives a browser via the Chrome DevTools Protocol from a Node process, usually in a clean profile, with deterministic selectors and a test runner that handles parallelism and reporting. Clone drives your existing logged-in browser sessions and your existing desktop apps via OS-level accessibility, screen reading, and click/type primitives. There is no headless mode and no parallel worker pool, because the workload is one consultant's personal browser, not a CI matrix.
The architectural commitment is in src/components/architecture.tsx line 46: "Client files, emails, contracts, and transcripts never leave your computer." Memory and the Computer Agent run on your Mac. The Planner (the LLM that decides which app to open and which step to take next) can route to a local Llama 3 on an M-series Mac for fully on-device operation, or to a cloud LLM when you want faster reasoning. For a consultant whose engagements include an NDA, the local-only configuration is the default.
The trade-off, honestly: a Clone ritual is more brittle than a tightly-asserted Playwright spec, because the underlying app DOM is not stable and the runner is reading the screen, not a test fixture. The mitigation is the review queue. A bad ritual run lands in your Gmail drafts, not your client's inbox. The first month you audit ten or twelve drafts per ritual and tighten the assertions; from month two you opt into auto-send on the rituals you trust.
Want a codegen session on your own consulting practice?
30 minutes with the Clone team. Bring twelve real kickoff emails, a recent SOW, and the last four Friday retros. We will mine the patterns live, write the first three ritual files to disk, and have you reviewing the next-week drafts on the call.
Common questions from QA practitioners on this angle
Is this a guide to hiring a test automation consulting firm, or something else?
Something else. Most articles for this topic compare Accenture, Tricentis, Qualitest, ImpactQA and the rest of the enterprise QA roster, then run a Selenium-vs-Playwright table you have read fifty times. This piece is for the practitioner: the test automation consultant whose own kickoff emails, weekly status reports, and end-of-month invoicing are still typed by hand. The argument is that the same discipline you sell to clients (codegen, page objects, fixtures, scheduled CI) applies to a consulting practice, and that Clone is the closest off-the-shelf implementation of it.
What is the parallel between Playwright codegen and Clone's pattern-mining?
Both observe a human driving a real browser session and write out a re-runnable artifact. Playwright codegen records your clicks and selectors and emits a TypeScript spec at tests/example.spec.ts. Clone observes you draft a kickoff email twelve times, extracts the three rules you follow without thinking (personal opening line, attach SOW PDF, cc your assistant when the contract is above $10K), and emits a markdown ritual at ~/.clone/memory/rituals/default-kickoff.md. The reference UI is in src/components/how-it-works.tsx lines 44-56 on cl0ne.ai.
Why a markdown file instead of a YAML or JSON DSL?
Because the consulting practitioner is the maintainer, not a CI engineer. A markdown ritual file reads like a runbook, gets edited by hand when a client's preferences change, and survives diff review the same way a Playwright spec does. The trigger, the steps, and the assertions are all in one file. You can grep ~/.clone/memory/rituals/ to see every automated workflow your practice runs, the same way you can grep tests/ to see every spec a QA suite runs.
What is the consulting equivalent of a CI cron schedule?
Step 04 of how-it-works.tsx, lines 60-76. The literal string at line 63 is '⏱ Every Monday 8:00am' and the body of the step is a Monday morning run that pulls billable hours from Timely, generates six invoices in QuickBooks, sends them via email, logs outreach in HubSpot, and drafts the Friday retro in Notion. Operationally that is cron: '0 8 * * 1' applied to a consulting business. Same expression syntax you would put in a GitHub Actions workflow for a test suite.
Where is the equivalent of page object isolation?
In the Memory layer. src/components/architecture.tsx lines 24-29 of the marketing site call it out as a distinct architectural layer with the sublabel 'Your clients, voice, templates, history'. Switching from HubSpot to Pipedrive in a real consulting practice is the equivalent of swapping a page object: you change the selectors in one place, every ritual that reads from CRM keeps working. The principle that drives this is in lines 56-58: 'Tool agnostic by design. Clone uses the apps you already pay for.'
What is the equivalent of an assertion failure?
A draft that lands in your Gmail review queue instead of the client's inbox. Every Clone ritual ships with a default review-then-approve gate. The principle is in src/components/architecture.tsx lines 60-65: 'Every action Clone takes is logged and reversible. Preview drafts before they send. See every file it touched. Roll back an entire morning of work with one click if you need to.' If a ritual writes a draft where the SOW PDF attachment is missing, you see it in drafts and never send it. Same posture as a red CI build that blocks a deploy.
Does Clone actually ship Playwright under the hood?
No, and the distinction matters for a QA audience. Playwright drives a browser via the Chrome DevTools Protocol from a Node process. Clone drives your existing logged-in browser sessions and your existing desktop apps via OS-level accessibility, screen reading, and click/type primitives. It is closer in posture to Anthropic's computer-use model than to a Playwright runner. The architectural commitment in src/components/architecture.tsx line 46 is explicit: 'Client files, emails, contracts, and transcripts never leave your computer.' Memory and the Computer Agent run on your Mac.
Why would a test automation consultant care about this on a Tuesday?
Because the operations of a consulting practice are exactly the kind of repetitive, deterministic, multi-step browser flows you spend the rest of your week automating for clients. A four-step kickoff email is a four-step Playwright test. A six-invoice Monday morning is a parameterised test running over a fixture array. The unique thing a Clone-style ritual does is observe you do it once on real data and codegen the artifact, instead of asking you to write the spec by hand. For a practitioner who already values codegen the leap is small.
What does 'test automation consulting' look like when the firm itself is automated?
Concretely, the firm's ~/.clone/memory/rituals/ directory holds a file per workflow: default-kickoff for new client onboarding, post-call-followup for the 24-hour after-discovery email, friday-status for the Friday client roll-up, monthly-invoicing for the Monday 8am cron, renewal-nudge-14d and renewal-nudge-7d for the retainer cadence, scope-creep-reply for the change-order template. Each is one English sentence in, one markdown file out, and re-runnable indefinitely. The firm sells QA suites to clients and runs an analogous suite on itself.
What is the honest downside of treating consulting ops like a test suite?
Three. First, a ritual mined from twelve rushed kickoffs will replay the rush; the fix is to consciously run the next two or three by hand the way you actually want to. Second, edge cases (a brand-new engagement type with no prior pattern) get nothing useful from the clone; you write that one by hand the first time and let observation kick in on run two or three. Third, auto-send is a footgun; leave the default review queue on for the first month, audit ten or twelve drafts, then opt into auto-send per ritual when you trust it.
Where can I verify the codegen parallel in the live site?
Open src/components/how-it-works.tsx on cl0ne.ai. Step 03 is at lines 42-58. Lines 44-53 are the three rules the pattern-mining UI surfaces verbatim. Line 56 contains the literal string "Saved as 'default-kickoff'". Step 04 is at lines 60-76 and the cron string '⏱ Every Monday 8:00am' is on line 63. The corresponding architectural commitment to local-first execution is in src/components/architecture.tsx line 46: 'Client files, emails, contracts, and transcripts never leave your computer.'
Other angles on the same product
Adjacent guides if this argument lands
AI Clone for Consultants: Operational, Not Avatar
The same product engine framed for the broader consultant audience. Anchor: how-it-works.tsx step 03 ships the pattern-mining UI verbatim, twelve emails in, three rules out, one ritual saved.
Workflow Automation Consulting
Adjacent territory: when a client asks for workflow automation, what is the honest answer in the era of computer-use agents.
Best CRM for a Small Consulting Business
If your kickoff ritual depends on the CRM, this is the upstream decision. The piece argues for keeping the CRM lean and pushing logic into rituals instead.