These are the workflows I actually run my products with, written down so Claude can run them for you too. Each disk comes with the article about how it came to be. Pick one to read it, download it, or install a whole shelf. The Soxoa Ops disks are business routines, and their full articles live on soxoa.com. The John Lab disks are how I build, and their articles are here. Every SKILL.md is public on GitHub: soxoa-ops and john-lab.
Every disk is a v0.1.0 draft. The workflows behind them are real and have been run on my own products. The packaged skills are new, so try each one on a small task you can check before you rely on it.
Soxoa Ops Run the business · 15 disks · articles on soxoa.com
/plugin marketplace add johnarndt/soxoa-claude-plugins /plugin install soxoa-ops@soxoa-plugins
- S-01 Feedback Inbox Every customer quote kept verbatim, grouped into issues, ranked by how many people asked.
- S-02 Signup Pulse An email the moment someone signs up, a morning list of who got stuck, and a walk through the real funnel.
- S-03 Chief of Staff A daily brief built from commits and the requests typed into AI sessions: what moved, what's stuck, what was promised.
- S-04 Owner Actions Ends every agent session with a dated, copy-paste list of what only the owner can do, with proof for what's done.
- S-05 Claim Audit Grades copy against the 22 Laws and checks every number, logo and “compliant” against real evidence.
- S-06 Screenshot Moment Find the one screen a customer would share, then clear the gates, crops and bland previews hiding it.
- S-07 Ad Path Check Ten distinct ad concepts, exact targeting, and a click-through of every path to the payment step before launch.
- S-08 Prospect Brief Turn public business evidence into cited account hypotheses, contrary explanations, rejection rules, and unsent outreach drafts.
- S-09 Marketing Kit Create coordinated one-pagers, press facts, and content calendars from dated product truth, approved evidence, and brand assets.
- S-10 Site Paths Audit Compare a site's page inventory with its actual navigation paths and prepare relevant repairs for disconnected content.
- S-11 Voice Guide Turn authorized writing samples into channel-specific voice rules and a shareable drafting prompt.
- S-12 Evidence Article Produce a useful sourced article through distinct drafting, factual editing and style-review passes.
- S-13 Pitch Pack Find a public-interest angle in documented work and create outlet-specific articles, pitches and submission notes.
- S-14 Automation Scope Turn one recurring workflow into an automate, assist, discovery, or stop recommendation with review, acceptance, and illustrative economics.
- S-15 Output Review Review AI output against original source evidence with explicit omissions, false positives, source conflicts, and acceptance boundaries.
John Lab Build and make · 11 disks
/plugin marketplace add johnarndt/john-lab /plugin install john-lab@john-lab
- L-01 Feature Audit Inventory every user story, test each, fix, retest, all tracked in one CSV. No fixing before testing.
- L-02 Lane Orchestrator One planner, parallel builders in their own worktrees, reviewers who didn't write the code, and a spending rule.
- L-03 Safe Cutover Snapshot DNS, prove parity, cut over behind a health gate with automatic rollback, keep the old host warm.
- L-04 CVE Triage Sort advisories into exploitable, mitigated and noise by how the code really uses each package, then patch in batches.
- L-05 Store Submission A per-app folder with reviewer notes, device recordings and precise rejection replies for the App Store and Google Play.
- L-06 Release Receipt Connect the intended source, current live state, required gates, deployed components, and observed behavior in a dated release report.
- L-07 Job Recovery Retrieve the existing result before retrying, then separate replay evidence, source checks, and present spending.
- L-08 Writers' Room A scout, critics, a showrunner, a copywriter and a blind persona panel turn sources into a teleprompter script.
- L-09 Podcast Room Pitchers, a showrunner with a facts ledger, one segment at a time, and a transcript diff on every recording.
- L-10 Character Swap Turn one person in real footage into a character from reference images, while every other person, the graphics and the audio stay original. Ships with scripts.
- L-11 Hundred to Ten Write 100, score them on a rubric, cut 20% a round through a new lens each time, and keep the best 10.
No disks match that search. Try "video", "deploy" or "customers".
Your customers already told you what to build. You just can't find it.
A plain-file feedback inbox that keeps every customer quote verbatim, groups quotes into issues, and ranks what to work on by how many people asked. Free Claude skill.
Where it came from: I built it after realizing feedback was scattered across email, texts and app-store reviews. It now regroups every product's feedback every night.
Most small companies get plenty of feedback. It just lands in six places: a forwarded email, a text from a customer's spouse, an app-store review, a note from a sales call, a comment someone made in passing that you meant to write down. By the time you sit down to plan the next month, none of it is in front of you. So you plan from memory, and memory favors the loudest customer and the most recent complaint.
The fix is boring on purpose: one inbox, one file per issue, one ranked list.
Stop reading signup totals. Read the names.
An instant alert for every new account, a morning list of who got stuck and where, and a drop-off review that walks your real funnel. Free Claude skill.
Where it came from: I asked for an email on every signup and a morning list showing where each person was in the journey. Then we tore down every funnel.
A dashboard that says "7 signups this week" tells you almost nothing when you're small. Seven is small enough to know by name, and the useful question is about each of them: did Dana connect her data? Did Marcus ever come back after creating an account?
signup-pulse replaces the total with the people. It has three parts, and they're worth building in this order.
If AI agents work for you, someone has to write the daily report
A daily brief built from evidence, meaning the commits that landed and the requests typed into AI sessions, so an owner knows what moved, what's stuck and what was promised. Free Claude skill.
Where it came from: Every night since July, a job reads my git activity and agent sessions and emails me the day.
Once a team starts handing real work to AI agents, a new problem shows up at 6pm: nobody can say what got done today. Five sessions ran. Something got deployed. Somebody asked an agent to "fix the billing email" and it may or may not have happened. The work is spread across terminals, chat windows and repositories, and none of them summarize themselves.
A human chief of staff would fix this with a short note at the end of the day. chief-of-staff-brief writes that note, from evidence.
The list your AI can't finish for you
Agents can run commands, edit code and check results. They shouldn't pay, sign in as you, send to customers or make the call. A dated owner-action list draws that line every time. Free Claude skill.
Where it came from: My running John Actions files: what the agent finished and verified versus the clicks only I can make.
The usual way AI work goes wrong for a business owner isn't a dramatic failure. It's quieter than that. The agent finishes, reports success, and three things are still waiting on the owner. Nobody wrote them down. The payment webhook isn't on. The new sender domain isn't verified. A decision about the free tier is sitting in paragraph nine of a long reply. A week later something is broken, and it turns out it was never set up.
owner-actions exists so that every piece of agent work ends with one clear handoff.
Audit your homepage like a skeptical buyer would
A positioning and claims review that grades your copy against the 22 Immutable Laws of Marketing and checks every number, logo and "compliant" against the evidence you actually have. Free Claude skill.
Where it came from: A positioning audit across my sites that stripped out every stat I couldn't prove.
There's a moment in every small company's marketing when someone writes "trusted by hundreds of teams" because it sounds like what a real company would say. Then a ticker gets added. Then a toast that pops up saying someone in Ohio just signed up. Each one feels harmless. A careful buyer sees all of it, and once one claim looks invented, they stop believing the others.
claim-audit reads your site the way that buyer does. It asks two questions: does the page own one clear idea, and is every claim on it true and provable today?
Your product already has a moment people would share. It's just hidden.
Find the one screen a customer would screenshot and send to a friend, then clear the gates, crops and generic previews that keep it from spreading. Free Claude skill.
Where it came from: A team of agents went through five of my products looking for the moment someone would screenshot and send to a friend.
Ask an owner what makes customers talk about them and you'll usually hear about a feature. Ask what a customer would actually screenshot and text to a friend, and the answer is almost always something smaller and more personal: a result with their own name on it, their own words turned into something useful, a number about their business they didn't know.
We ran this exercise across the products Soxoa operates. Every one of them already had that moment in shipped code. And every one got in its own way in the same few ways.
Before you spend a dollar on ads, click your own ad
Ten ad concepts with real hooks, exact targeting, and a click-by-click check that every ad's path works through to the payment step. Free Claude skill.
Where it came from: Getting ready to run Meta ads: ten concepts, then making sure every click could actually reach a card on trial.
Small businesses usually lose ad money in two places. The first is the one everybody talks about: a weak hook nobody stops for. The second is quieter and more expensive. Someone clicks, lands on a page that doesn't match the ad, gets lost on a phone-sized form, or reaches a payment step that errors. You paid for that click, and you never find out what happened.
ad-path-check handles both, and treats the second as the bigger risk.
A prospect brief should tell you when to stop
Turn public business evidence into cited account hypotheses, contrary explanations, rejection rules, and unsent outreach drafts.
Where it came from: October 2026 MentionedOn kit recorded 25 sourced business records, five opportunity briefs, and unsent drafts; Intakra kit recorded 25 researched organizations and five sourced walkthroughs with alternative explanations and rejection rules. Neither kit established buyer intent or customer conversion.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Offer and fit criteria
- Business websites or supplied source documents
- Research date and geography
- Existing outreach restrictions
You get back
- Cited account brief
- Observed-fact versus hypothesis separation
- Contrary evidence and rejection rules
- Missing-fact validation step
- Optional unsent outreach draft
A business opens a second location. Your research tool adds it to a list. Someone writes an email about growing pains. Nobody has established that the business has the problem you sell a solution for.
The missing step is a brief that connects a real observation to a plausible need, then tries to disprove the connection. That is the workflow behind research-prospect-brief, a draft Claude skill drawn from research kits we prepared in October 2026.
One kit contained 25 sourced business research records and five opportunity briefs. Another contained 25 researched organizations and five target-account walkthroughs. Both included unsent outreach drafts. Those are completed research artifacts. They are not evidence that a buyer expressed intent, a campaign converted, or a pilot produced customer results.
Read the full article on soxoa.com
Use research-prospect-brief on these three business websites and dated announcements. Our offer is appointment-intake automation. Return sourced briefs, alternative explanations, a rejection rule, and unsent drafts. Treat buyer intent as unknown.
Build the marketing kit around one dated truth sheet
Create coordinated one-pagers, press facts, and content calendars from dated product truth, approved evidence, and brand assets.
Where it came from: August 30, 2026 package covered four owned brands. Verification recorded 16 PDFs and visual inspection of 76 rendered pages, corrections/rerenders, dated content calendars, and eight video compositions. August source truth is historical and must not be treated as current pricing or capability evidence.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Dated product truth sheet
- Audience and campaign dates
- Approved claims and evidence
- Brand guide and assets
- Desired deliverables
You get back
- Claim register
- Coordinated editable marketing assets
- Calendar with evidence and owners
- Rendered exports when tools permit
- Delivery manifest and unresolved approvals
The one-pager says one thing. The press document uses last month's price. The content calendar promises a feature that was still a draft when someone copied it. Every asset looks finished, and the campaign disagrees with itself.
This is usually a source-control problem before it is a copywriting problem. A useful marketing kit starts with a dated record of what the product does, what the offer includes, and what evidence supports the claims. Every adaptation should carry those boundaries forward.
The build-marketing-kit draft Claude skill comes from a four-brand package completed in August 2026. That work included 16 PDFs covering brand guides, one-pagers, press material, and content calendars. Its verification record documents rendering and visual inspection of all 76 PDF pages, with corrections and rerenders. It also included editable sources and media assets.
Those checks describe the August package. They do not establish that its prices, positioning, or product behavior remain current today. The new skill packages the method and still needs testing in Claude.
Read the full article on soxoa.com
Use build-marketing-kit for this launch. Create a one-pager, press facts, draft founder quotes, and a four-week calendar from the attached truth sheet and brand guide. Flag claims needing fresh evidence.
Your useful pages may be missing from your own navigation
Compare a site's page inventory with its actual navigation paths and prepare relevant repairs for disconnected content.
Where it came from: The saved Soxoa audit recorded 118 sitemap pages all returning 200, no missing descriptions or canonicals, and 11 pages disconnected from the audited link graph. A subsequent release receipt recorded a homepage-to-hub path and hub links to all ten child problem pages. The related Intakra receipt records 173 public pages verified and 74 disconnected pages reconnected. These are navigation outcomes, not measured search-ranking gains.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Public homepage and entry points
- Sitemap or URL inventory
- Allowed domains and crawl scope
You get back
- Dated crawl and reachability summary
- Disconnected-page findings
- Prioritized parent and hub link plan
- Before/after verification checklist
A business publishes useful answers, adds them to the sitemap, and waits for them to work. Each page loads. Each has a title and description. A visitor starting at the homepage still has no practical way to find the answers.
We encountered that gap in the Soxoa site audit. The saved audit showed 118 sitemap pages returning successful responses, with no missing descriptions or canonicals in the recorded checks. Eleven pages in the problems section were disconnected from the audited internal-link graph. The navigation repair gave that section a path from the homepage through a hub to its ten individual answers.
That experience became the basis for audit-site-discoverability, a Claude skill draft for examining the relationship between a site's page inventory and its navigation. The draft has not yet been behaviorally tested in Claude.
Read the full article on soxoa.com
Use audit-site-discoverability on our public homepage and sitemap. Stay within the supplied domain and exclude account and checkout paths. Find useful pages disconnected from the homepage link graph. Recommend a small set of relevant parent or hub links. Report crawl limits and give me a verification checklist. Make no site changes.
Build a voice guide from the writing you already have
Turn authorized writing samples into channel-specific voice rules and a shareable drafting prompt.
Where it came from: An August 2026 study produced a private voice guide, source audit and shareable prompt from cleaned and attributed writing, observed public material, preferences and one narrowly supported meeting register.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Authorized writing samples
- Intended channels and audiences
- Authorship and assistance context
- Current writing preferences
You get back
- Core voice description
- Register cards
- Shareable drafting prompt
- Private source and uncertainty ledger
Most people asking AI to write in their voice hand it three recent posts. The model copies the short paragraphs, repeats a favorite phrase and turns every subject into the same performance.
The missing piece is context. An email asking for a refund, a comment on a colleague's post and a business article serve different jobs. A useful voice guide explains those differences so the next draft can make the right choice.
We have already done the underlying work. A voice study completed in August 2026 used cleaned, attributed writing, observed public posts, explicit preferences and a narrowly supported meeting register. It produced a detailed private guide and a separate shareable prompt. The reusable method is the skill here. The person's private correspondence stays private.
Read the full article on soxoa.com
Use build-voice-guide on these authorized samples. Build separate cards for operational email and long-form articles. Distinguish authored, edited and synthetic material. Keep all private excerpts out of the shareable prompt.
Give every article a claim ledger before you give it a hook
Produce a useful sourced article through distinct drafting, factual editing and style-review passes.
Where it came from: The September 16 local AI-visibility article retained source notes, drafts 01 through 05, editor and style reviews, and a final draft with no material unresolved editorial issues. Publication was not performed.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Reader question
- Intended publisher and voice
- Primary sources or retained test evidence
- Commercial interests to disclose
You get back
- Complete article draft
- Claim ledger
- Source notes
- Resolved review findings and remaining limits
The sentence that makes an article more interesting is often the sentence its sources cannot support. A small product test becomes a market trend. Search impressions become demand. A proposed customer workflow becomes a case study.
The fix starts before the first paragraph. Write down what the evidence actually establishes, then build the article around that.
In September 2026, we used this approach for an article about local AI visibility. The retained work includes source notes, successive drafts, editorial reviews and a final article. The writing moved through copywriting, factual editing and a separate style review. The final record described a completed draft with no unresolved material editorial issues. It did not claim the article had been published.
That workflow is reusable because the difficult decisions repeat across subjects.
Read the full article on soxoa.com
Use write-evidence-article to explain this workflow to a small-business owner. Build a claim ledger from the attached sources. Keep observations, estimates and illustrative examples distinct. Review the draft for factual scope and formulaic writing before returning it.
Turn completed work into a pitch an editor can use
Find a public-interest angle in documented work and create outlet-specific articles, pitches and submission notes.
Where it came from: The September 2026 Sacramento pack contained ten articles and outlet-specific pitches with sources, guideline limitations and commercial disclosures. Later work addressed an editor comment in a shared draft.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Documented completed work
- Target reader or geography
- Relevant author background
- Publication targets and constraints
You get back
- Full article drafts
- Tailored pitches
- Guideline and source notes
- Submission and exclusivity status checklist
A founder can spend weeks building something and still have nothing useful to send an editor. The work may be real. The pitch explains only what the product does.
An editor needs a reader consequence: a local decision, a documented pattern, a surprising limitation or a practice worth examining. The product can establish why you know the subject. It does not supply the whole story.
We used this approach in a Sacramento editorial project in September 2026. The completed collection included ten articles, publication-specific pitches, source notes and commercial disclosures. The subjects came from work already underway. Later revisions addressed an editor's comments on a shared draft. Those are concrete deliverables and editorial work. They do not establish that every article was accepted or published.
The reusable skill is the process that connects documented experience to a suitable publication.
Read the full article on soxoa.com
Use build-editorial-pitch-pack to find two local editorial angles in this completed project. Verify current official submission rules for the proposed outlets. Draft one full article and tailored pitches, disclose my commercial interest, and keep everything unsent.
Scope the review step before you price the automation
Turn one recurring workflow into an automate, assist, discovery, or stop recommendation with review, acceptance, and illustrative economics.
Where it came from: October 14, 2026 Soxoa invoice-intake engagement kit completed proposal/SOW templates, discovery rubric, acceptance protocol, delivery and handoff materials, and a private fee/capacity model. It explicitly claimed no client implementation, measured savings, or executed client acceptance. Existing automation-planning skill supplies narrower MCP calculation routing.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Current process and ordinary/difficult examples
- Volume and timing evidence
- Approved tools/data and output destination
- Operating owner and reviewer
- Economic assumptions and acceptance needs
You get back
- Current workflow map
- Recommendation with evidence
- Bounded pilot scope and exclusions
- Proposed acceptance plan
- Illustrative base/downside economics
- Missing decisions and owners
A team spends hours rekeying invoices. An automation demo extracts the fields in seconds. The proposal multiplies those seconds across the monthly volume and declares the savings.
The proposal still needs to account for checking, corrections, duplicates, exceptions, and the person who owns the result. Those details determine whether the workflow improves the operation or simply moves the work into a different screen.
The scope-automation-opportunity draft Claude skill comes from an invoice-intake engagement kit prepared in October 2026. The completed kit included proposal and statement-of-work templates, a discovery rubric, an acceptance protocol, a delivery playbook, a handoff workbook, and a private fee/capacity model. It was a planning and delivery package. It contained no completed client implementation or measured client savings.
The transferable method is to define one bounded workflow, put evidence around the decision to build it, and specify what a useful result would require.
Read the full article on soxoa.com
Use scope-automation-opportunity on our invoice-intake notes and timing log. Recommend automate, assist, discovery, or stop. Keep payment approval human, include downside economics, and propose a finite acceptance plan. Label unmeasured assumptions.
A correct total can hide an incorrect AI answer
Review AI output against original source evidence with explicit omissions, false positives, source conflicts, and acceptance boundaries.
Where it came from: Portravo source-review work defined frozen acceptance gates across complete input coverage, schedules, counts, conflicts, scope, mapping, pricing, and independent source review. An independent scorer review reproduced synthetic fail-open paths including impossible citations, duplicate marks, and contradictions. This establishes historical method provenance, not accuracy of the newly authored Claude skill.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Authorized original sources and revisions
- Unchanged raw result
- Task scope
- Prospective acceptance criteria
You get back
- Source-linked claim ledger
- Coverage and unsupported-claim findings
- Bounded acceptance verdict
- Unresolved evidence and next checks
An AI result arrives with a neat table, a confidence score, and the number you expected. The temptation is to approve it and move on. That becomes expensive when the table contains the right total for the wrong reasons.
In our construction takeoff review work, we had to evaluate quantities, specifications, missing scope, and conflicting plan evidence together. The useful method was a claim ledger tied to the original source. The same approach applies to invoice extraction, research summaries, and reports assembled from several documents.
The evaluate-ai-output skill packages that method for Claude. The historical review process supplies the foundation. The new Claude package remains an untested draft.
Read the full article on soxoa.com
Use evaluate-ai-output to review this extraction against the original document. Preserve the raw result. Build a claim ledger covering required fields, omissions, unsupported additions, and source conflicts. Explain the denominator for any accuracy metric. State which conclusions the available evidence cannot support.
717 user stories, four phases, one spreadsheet
The QA ritual I run on every product I own: inventory every user story from the code, test each one, fix, retest. As a Claude skill.
Where it came from: My four-phase QA ritual, run at 132, 175 and 464 stories, then 717 across the portfolio.
When AI writes most of your code, you lose track of what your app does. Not in a dramatic way. You just stop knowing. Did the password reset still work after last week's auth change? Does a canceled subscription actually lose access? You don't know, and "looks fine" isn't an answer.
So I stopped asking "is it broken?" and started asking "does each of these user stories pass?" That one has an answer.
Four phases, in order
1. Inventory. Read the code, not the marketing site, and write down every user story: routes, API handlers, emails, webhooks, admin screens, billing states, permission checks. Include the unhappy paths too: wrong password, expired link, declined card, someone else's ID pasted into the URL.
2. Test. Run every story against a real local or staging build and record PASS, PARTIAL, FAIL or BLOCKED with evidence. No fixing in this phase. Even an obvious one-line bug gets written down and left alone. Fixing as you go is how you end up with half a test pass and a mess of changes nobody reviewed.
3. Fix. Work through the failures in priority order, one commit each, every one referenced in the tracker. Anything that needs me personally, like a dashboard setting or a real payment, gets marked "deferred: owner" and lands on my to-do list.
4. Retest. Rerun everything that was fixed, plus everything that shares code with a fix.
All of it lives in one CSV in the repo: ID, area, priority, user story, expected behavior, code reference, how to test it, then one column per phase. Each phase also writes a dated ledger.
The receipts
I've run this on my own products at 132, 175 and 464 stories, then across the whole portfolio at 717. On that portfolio run, 659 passed on the first try, 28 failed and were fixed, 26 turned out to need no fix, and 4 were blocked on me or blocked by design. The 464-story pass on my document tools found 198 defects, and 176 got fixed in the same cycle.
The numbers aren't the point. The point is that afterward I could say exactly what was tested and what wasn't.
What went wrong, so you don't repeat it
- "Deployed" in a note doesn't mean deployed. One product served a different branch for weeks while my notes said the fixes were live. Now the last step checks the live site and the commit it's actually running.
- Two sessions, one repo, chaos. Run one audit per repo at a time.
- Rotations fail quietly. A rotated database password that never reached the app took down hundreds of pages. Any credential change now triggers a retest of login, database and webhooks.
- Cross-tenant checks go first. Put account A's IDs into account B's requests on every endpoint. That's the bug class worth the whole exercise.
The safety rules are in the skill too: the test suite has to pass before you start, nothing gets sent to real customers, payments run only in test mode, and paid API calls are capped.
Steal it
The skill is feature-audit in my John Lab plugin. Point it at a repo and say "audit this app."
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labOne planner, three builders, and reviewers who didn't write the code
How I run several AI coding agents on one hard problem without them breaking each other's work, with frozen contracts, separate worktrees, independent reviews and a strict spending rule.
Where it came from: How I ran a planner model and several builder agents on one hard construction-takeoff build.
The first time I pointed three AI agents at the same hard problem, they finished fast and broke each other's work. One changed a shared type. Another was building on the old version. The third wrote tests that mocked the exact code the first one had broken, so everything passed.
What fixed it was organization, not a better model.
The cast
- A strategy reviewer. The strongest model I have reads the goal and the code and writes the plan: architecture, lanes, which files each lane owns, and what "done" means. It doesn't write production code.
- Lanes. Builder agents, each owning a set of files and one deliverable.
- Independent reviewers. Fresh sessions that never saw how a lane reasoned. They get the code and the acceptance criteria, and they write reproduction scripts, not opinions.
- Root. The coordinator, either me or one session acting for me. Root assigns ownership, can overrule the planner, integrates the work and decides on release. Only root merges.
Two things get frozen early
The shared contract. One lane writes the shared interfaces first, and root freezes them. A later change is published as v2 next to v1, never edited in place, so nobody's foundation shifts under them.
Acceptance. The definition of done is hashed and frozen. Later additions can make it stricter but never looser. That stops anyone from quietly moving the goalposts when a test is hard to pass, and that includes me.
Everything is a file
Each lane writes an append-only status log. Root keeps timestamped coordinator notes. Reviews are JSON with a verdict, findings, the evidence that passed, the limits of what was checked, and the exact commit reviewed. When an agent hits a usage limit at 2am, the next session reads the files and picks up where it stopped.
The spending rule
This is the rule I'd put first if you're paying for API credits. Development and review run on the subscription. API credits are only for running the product itself, capped per run and tied to a frozen code hash. If a lane runs out of usage, it stops and saves its work. It never switches to a paid route to keep going.
I added this after a build burned through a shared credit balance halfway through a test run and returned a payment error. Now the rule goes into every lane's instructions.
What I learned
- Mocks lie. Reviewers now have to exercise at least one real path per lane.
- Sharing a working folder isn't isolation. File ownership alone wasn't enough, so each lane now gets its own git worktree.
- Interrupt with evidence. When root stops a lane, the message says what was found and that the original goal still stands. Otherwise the agent decides it's been given a new task.
- The planner can be wrong. I've overruled it, and the decision file says why. One of its shortcuts would have hidden failures, and that's never acceptable.
- Check the layer. When three rounds of fixes don't move the result, ask whether the problem is in a different part of the system than the one you're fixing. That question saved me a week.
Steal it
The skill is lane-orchestrator in my John Lab plugin.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labMoving live sites without breaking them
Snapshot first, prove parity, cut over with a health gate and automatic rollback, and keep the old host warm. The checklist I used to move my sites off Vercel, as a Claude skill.
Where it came from: The checklist from moving my sites off Vercel and onto Cloudflare, plus the guarded release script.
In October I moved most of my sites from Vercel to Cloudflare. The goal was that nobody would notice. That takes a checklist, because every migration outage I've caused or seen came down to one of three things: a DNS record nobody saved, a secret that didn't come across, or a scheduled job that ran in two places or in none.
Snapshot before you touch anything
Before any DNS change, the script saves every record in the zone, plus routes and scheduled jobs on both hosts, to a timestamped file only I can read. Snapshots are never overwritten. If the cutover goes wrong, rollback restores that exact file. I have more of these snapshot files in my home folder than I'd like to admit, and every one of them has been worth keeping.
Prove parity before cutover day
The new build runs on staging, and a parity script requests every important URL from both live and staging and compares status codes, redirects, titles, canonical links and structured data. The target is zero differences, not "a few, but they look fine." It also checks that sessions issued by the old host still work on the new one, so nobody gets logged out mid-move.
The cutover is a script, not a series of clicks
- Snapshot.
- Preflight, which refuses to run unless the live commit is in the branch being deployed, every secret resolves, a signed webhook test returns 200 and a bad signature returns 400, and parity shows zero differences.
- Turn off scheduled jobs on the old host.
- Point DNS at the new host, without touching the mail records.
- Poll the health endpoint until it reports the new platform at the right commit, or roll back automatically.
- Turn on scheduled jobs on the new host.
- Freeze the old host and take a second snapshot.
The old host stays warm for a week. Decommissioning needs my explicit OK.
Where it bit me anyway
- Cron didn't fire. After one cutover, the new host's scheduled jobs just never ran. Nothing failed loudly. I found out because something downstream stopped updating. Now there's a freshness monitor that alerts when a job misses its slot.
- Some secrets can't be read back. The old host stored one as write-only, so preflight refused to go, which was the right call. The fix was a planned rotation, or a temporary bridge that accepts both old and new sessions.
- Live moved six times in one day. I was shipping fixes while preparing the cutover. Re-merge the live commit right before you cut.
- The cache ignored the hostname. www and the bare domain shared cache entries until I added an explicit redirect rule.
Every deploy after that
The same discipline became my normal release. The deploy command refuses a dirty tree, a commit that isn't HEAD, or one that doesn't contain the last live commit. Afterward it checks the version endpoint and rechecks every URL in the sitemap. On the last soxoa.com release, all 118 came back 200.
Steal it
The skill is safe-cutover in my John Lab plugin.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-lab40 new critical CVEs before breakfast
Most advisories don't matter for your app. A few matter a lot. How I sort them by how the code actually uses each package, and fix them without breaking anything.
Where it came from: My dependency audits, and the morning an alert reported 40 new critical CVEs.
One October morning my CVE check emailed me: 40 new high or critical advisories since the last baseline. My first instinct was "fix it all." That's the wrong instinct, and it's how you break production on a Monday.
Three buckets
Every advisory goes into one of three buckets, and the deciding question is always how this code uses the package:
- (a) Exploitable. The vulnerable path is reachable from something an attacker controls in production: a request, an upload, a webhook. The clearest example I've had was a spreadsheet library with a known parsing flaw, used to parse files users uploaded.
- (b) Real but mitigated. Reachable only in build tools, dev servers or admin-only paths, or blocked by another layer. Write down what's doing the mitigating.
- (c) Noise. Not reachable, not shipped, or the vulnerable function is never called.
Each verdict cites the file or import that decides it. In my July audit, a long list of advisories came down to five that were actually exploitable. Several were old framework versions with middleware auth bypasses, which almost always land in bucket (a).
Fix in small batches
- Batch 1: patch and minor upgrades that clear the (a) items. Run tests after each repo.
- Batch 2: major upgrades, one at a time, after reading the release notes and manually checking the feature it affects.
- No clean fix? Mitigate instead: validate or sandbox the input, plan a library swap, or remove the code path. I deferred one upgrade because the fix changed how the product's core input format was parsed. That's a product change, not a security patch.
Rules I keep
- Don't edit a repo someone else (or another agent session) is actively working in. Audit it read-only and hand over the list.
- Never run a forced audit fix across everything. It applies major upgrades blindly.
- Commit per repo. Deploy only when I say so.
- Never weaken a security control to make an advisory disappear.
The quiet repos got fixed in one pass, and their advisory count dropped by about a quarter. The active ones got a prioritized list instead of surprise commits.
Steal it
The skill is cve-triage in my John Lab plugin. Paste the audit email and say "triage this."
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labApple rejected all five of my apps the same week
App review rejections are rarely about code. They're about missing evidence. The submission folder and reply method I use now, as a Claude skill.
Where it came from: Five iOS apps, five rejections in one week, and the folder I keep now so it doesn't happen again.
In September I submitted five iOS apps. All five came back rejected under the same guideline, 2.1, asking for more information: recordings on a physical device and detailed answers to a list of questions. None of the rejections were about bugs. Every one was about evidence I hadn't included.
So now I include it before anyone asks.
One folder per app
Every submission gets a folder with a checklist, review notes for the reviewer, draft replies, device recordings, screenshots at every required size, and a build check covering version, build number, signing, entitlements and the privacy manifest. One STATUS.md file across all the apps shows the build, the review state, the reviewer's last message and the next action.
The checklist that would have saved me a week
- A demo account made for review, never my own, with exact steps to reach every feature.
- Physical-device recordings for anything involving hardware, sensors, purchases or account deletion, included up front.
- Privacy answers that match what the app actually sends.
- Screenshots of the real app, no mocked features.
- Release mode chosen ahead of time. I switched one app from manual to automatic release after approval so it wouldn't sit waiting on me.
- On Android, internal testing first, the data safety form, the target SDK requirement, and the upload key kept outside the repo.
Answering a rejection
- Quote the guideline and the reviewer's exact question.
- Answer every part, in their order, one paragraph each. When Apple asked what feedback I'd given on two apps and what changed because of it, the answer that worked was one concrete example per app. No essays.
- Attach the recording that proves it.
- If the reviewer is right, fix the build and say plainly what changed.
The skill drafts the reply. I send it. I also sign in to the consoles, accept the agreements and press submit myself. Store credentials and signing keys never go in the repo or in chat.
Steal it
The skill is store-submission-kit in my John Lab plugin.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labA release needs a receipt that says what is actually live
Connect the intended source, current live state, required gates, deployed components, and observed behavior in a dated release report.
Where it came from: Historical Portravo releases required fresh live-source ancestry, paired app/compute source, migration and idle-state gates, and public health verification. Current Portravo and Soxoa receipts retain source identity, check results, observed behavior, and configuration-preservation evidence. The portable skill deliberately uses each project's declared rules and grants no mutation authority.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Current project release policy
- Candidate source or artifact identity
- Live version and health endpoints
- Test results and deployment evidence
- Authorized configuration and migration metadata
You get back
- Readiness verdict or post-release receipt
- Evidence-linked gates table
- Source and component identity verification
- Explicit unresolved checks and next action
The build succeeds, the deployment command exits, and the homepage loads. Someone asks whether the change is live. The honest answer depends on what those three observations actually establish.
Across our product releases, the useful record became a dated receipt connecting the intended source, required checks, deployed components, and observed public behavior. It made later reviews much easier because the evidence traveled with the conclusion.
The verify-release-readiness Claude skill draft packages that review method. It can assess a candidate release or inspect evidence from a completed rollout. The new package has not been behaviorally tested in Claude, and running the review gives it no authority to deploy.
Tie each check to the source being released
Test results are useful when they identify what was tested. A passing suite from yesterday's commit may leave today's change unexamined. A clean build can package a branch that lacks a fix already serving customers.
The review therefore starts with source identity. It records the candidate, the current live version, the repository context, and any ancestry requirement in the project's release policy. It also checks whether local changes make the intended artifact ambiguous.
This is particularly useful when several agents or people can release the same product. The branch that was current at the start of a task can be behind production by the time a build finishes. A fresh check closes that gap before anyone makes a release decision.
Verify the system's actual compatibility rule
An application may depend on a separate worker, container, or processing service. Some systems require both components to run the same source revision. Others deliberately release them independently through compatible interfaces.
The skill reads the project's rule and checks evidence against it. It should never invent a same-commit requirement for every architecture. Where exact pairing is required, observing only the app leaves half the release unverified.
Data changes create another dependency. A migration plan needs to be compared with the current migration ledger. A candidate can contain an apparently new migration whose identifier was used by another release. Readiness review should expose the collision before deployment, while leaving the database unchanged.
Separate evidence levels in the receipt
An illustrative release table might look like this:
| Check | Evidence | Conclusion |
|---|---|---|
| Intended source | Public version response matches candidate | Source observed at that endpoint |
| Required tests | Results tied to candidate | Declared test scope passed |
| App and processor | Both report the required revision | Pairing rule satisfied |
| Configuration | Binding names and types match | Metadata preserved |
| Purchase workflow | No transaction exercised | Commerce outcome remains unverified |
That last row is useful. A receipt becomes misleading when it turns a health check into an end-to-end business claim. Likewise, preserved binding metadata cannot prove that secret values are unchanged or that a fresh application request used them.
A known baseline test failure should remain visible too. Reproducing it on unchanged code can support an assessment of relevance, but the suite still contains a failure. Accurate wording preserves the distinction.
Ask for a readiness report before the release decision
Use a request such as:
Use verify-release-readiness to review this candidate against our current release policy. Compare it with the live source, map required checks to their evidence, and identify unresolved component, migration, runtime, and behavior gates. Use read-only access. Return a dated report with a clear boundary between readiness and authorization.
Supply the candidate identity, live endpoints, project instructions, and available test or deployment records. If a required gate needs access Claude does not have, the report should name the gap. Missing in-flight job data cannot become an assumption that the system is idle.
A person responsible for the release still makes the deployment decision and manages recovery. The skill's job is to make that decision reviewable. Start by applying it to one completed release and check whether its receipt could explain the rollout to someone who missed the conversation.
Use verify-release-readiness to review this candidate against our current release policy. Compare it with the live source, map required checks to their evidence, and identify unresolved component, migration, runtime, and behavior gates. Use read-only access. Return a dated report with a clear boundary between readiness and authorization.
Recover an interrupted AI document job before starting another one
Retrieve the existing result before retrying, then separate replay evidence, source checks, and present spending.
Where it came from: October 21 verification replayed the same pre-existing completed synthetic Dokyumi request twice and read the same saved extraction. It did not establish a fresh extraction or new debit.
Package status: Draft package; structurally checked; not verified in Claude.
You give it
- Existing job/request identity
- Source document identity
- Schema/settings
- Authorized status and result tools
You get back
- Recovered result or unresolved state
- Source and schema match
- Replay and debit evidence receipt
- Next action
The invoice upload appears to hang. The page refreshes. The result is gone, so the obvious next move is to upload the file again.
The service may already have finished the first job. A failed screen and a failed operation are different events. Repeating the upload can leave you with two results, two charges, or two downstream entries for the same invoice.
The recover-document-job skill gives Claude a procedure for finding the existing result and reporting what happened before anyone starts another operation.
The saved request is the starting point
In an October Dokyumi verification, two calls replayed the same pre-existing completed synthetic invoice request. Both returned the same extraction identity. Reading the saved extraction confirmed that it was already complete.
That record demonstrated recovery of a saved result. It did not demonstrate a fresh extraction, a new charge, or general extraction accuracy. That distinction is the useful part of the workflow. A response can carry the original processing time and credits used without describing work performed by the recovery call.
The reusable skill preserves that distinction. It starts with the existing job, the source document, the intended schema, and the last known state. Claude uses whatever authorized status and retrieval tools the service actually provides. The skill itself does not add a connection to an extraction service.
Match the document before trusting the result
Consider an illustrative case: an accounts-payable operator submits invoice.pdf and loses the browser connection. The saved job reports complete, but another upload has the same filename.
A filename is too weak to settle the identity. The operator needs the service's attachment identity, a source hash, or another reliable match. Claude should also compare the schema and processing settings. A result for a different invoice or an earlier schema can be perfectly valid and still be the wrong result.
Once identity is established, the skill separates the possible states. A completed job needs retrieval. A running job needs observation through the documented status mechanism. A failed job needs the service's retry rules. An inaccessible job remains unknown. None of those states is improved by pretending a timeout settled the question.
A replay needs its own evidence
A job ID, a provider's historical request ID, and a client idempotency key are separate objects. An idempotency key is the identity a service may use to recognize a repeated operation. Its behavior depends on the service, including how long it is retained and which request fields must stay the same.
The skill tells Claude to check those rules before replaying anything. If a call only retrieves an existing result, the recovery can continue within the authorized task. If it may begin new processing or spend credits, the authorization must cover that action. Changing the source or schema may create a new operation even when the filename stays the same.
The receipt should make the distinction readable: existing result recovered; source identity matched; schema matched; important fields checked against the invoice; saved replay confirmed; current charge evidence unavailable. If a live ledger establishes whether money moved, record that separately from historical credits metadata.
Recovery ends with a usable handoff
An illustrative request is:
Use recover-document-job to inspect this interrupted invoice request. Retrieve the existing result if it is complete. Match the source and schema, check the required fields, and tell me whether the evidence shows a replay or new processing. Do not start another extraction.
Claude should return either the recovered artifact and its checks or a specific unresolved condition. An extraction that passes schema validation still needs review against the source. Recovery also does not approve the invoice or enter it into the accounting system.
Start with one interrupted job whose source and original identity are available. The useful first outcome is modest: the right result, tied to the right request, with a clear account of what remains to be checked.
Use recover-document-job to inspect this interrupted invoice request. Retrieve the saved result, match source and schema, and distinguish replay evidence from new processing. Do not start another extraction.
I fired my one AI copywriter and hired a writers' room
Seven roles, ten stages, a show bible and a blind audience panel. How I write my talking-head videos with Claude, and the skill you can steal.
Where it came from: The producer behind my talking-head videos: seven roles, ten stages, and a weekly AI launches show.
The first time I asked an AI to write my short videos, I got exactly what you'd expect: smooth, confident and forgettable. Every hook was "Here's the thing nobody tells you about AI." I could have filmed fifty and no one would have stopped scrolling.
So I stopped asking one model for one draft and built a room.
The cast
Every role is the same model with a different job and the same show bible:
- Scout pitches twice as many angles as I need, and every angle has to react to something real: a trending post, a launch, a commit I made that day. No link, no pitch.
- Provocateur scores for tension. Would anyone argue?
- Strategist scores for fit. Does this help the business owners my products serve?
- Skeptic scores for truth. It's the only role allowed to say "must."
- Showrunner picks the episodes and writes the brief.
- Copywriter drafts, and then has to answer every note.
- The panel is four people who don't exist: an HVAC owner scrolling Reels at 9pm, a credit-union marketing VP, a sales VP who wants something she can forward to her team, and a lender's ops lead who's been burned by vendors. They score hooks blind, shuffled, with no idea which one the room liked.
Ten stages, every one saved to disk
Scout → pitch meeting → pick → draft → critique → revise → red-line check → blind panel → final cut → "own the take."
Two rules do most of the work. First, the copywriter can't ignore a note. Every one gets "accepted" (and changed) or "rebutted" with a reason. Second, only the Skeptic can block. Everyone else's "must" gets downgraded to "should." That keeps the room from sanding every idea down to nothing while still guaranteeing nothing false gets through.
On the first real run, five of six drafts failed the first red-line check. The copywriter accepted 134 notes and rebutted 4. That's the point. Most of the value happens in the round you'd skip if you were writing alone.
The bible
The bible is one file that every role reads. It covers who I am, how I talk, the panel personas, the pillars, the spice dial (1 is useful, 5 picks a fight) and the red lines: no facts beyond the sources, a post on X is "someone claimed," nothing that identifies a customer, no legal conclusions, no punching down.
When I give feedback, it goes into the bible, so the next run inherits it. "These aren't from what's trending." "This is for LinkedIn, not TikTok." "The teleprompter just says the sentence. Give me the whole script." "The music is too loud." All of that is in there now.
The last stage is the one I read
"Own the take" rewrites the final cut into 150 to 220 words I read aloud on a voice-following teleprompter. No hedges, no placeholders, no @handles. It has to sound like me, because I'm the one on camera.
There's also a weekly variant. The scout finds AI launches from the last seven days with working links, and the room builds a roundup with a use / watch / skip verdict for each one.
Steal it
The skill is writers-room in my John Lab plugin. Write your bible first. It's the part that makes the room yours.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labA podcast written by a room and checked by a transcript
Pitchers, a showrunner with a facts ledger, one segment at a time, and a transcript diff so the recording says what the script says. How After the Demo gets made.
Where it came from: How After the Demo, my two-host podcast, gets written, recorded and checked.
After the writers' room worked for short videos, I wanted the same thing for long form: a podcast about what happens after the AI demo, when someone actually has to run the thing. Two hosts, me and a co-host, recorded with AI voices including my own cloned one, built from real material.
Long form breaks in new ways. A 20-minute episode has to stay consistent across segments, and AI voices drift from the script. Two additions handle that.
The room, stretched out
- Three pitchers with different lenses (the listener, the operator, the provocateur) pitch angles from the week's material.
- A showrunner builds the rundown: cold open, intro, three to five segments of a few minutes each, outro. It also builds a facts ledger, every fact the episode is allowed to use, with its source.
- One segment at a time. The head writer drafts the dialogue, an editor critiques it with a red-line veto, and the writer revises. Then the segment is recorded and checked before the next one is written. That's what keeps voice and running jokes consistent.
The transcript check
The step I'd tell anyone to copy is this one. After recording, transcribe the audio locally and diff it against the script. Any line that drifted, dropped a word or mangled a product name gets re-recorded. The recorder also refuses to run if a banned word appears in the text, and a pronunciation map handles brand names.
Smaller rules came from listening: write numbers as words, keep the same voice settings and seed for the whole episode, level speech to around -16 LUFS, and keep music well under the voices. The synthetic co-host never claims a personal history. Sponsor mentions go in the show notes, not the conversation, and each episode mentions two products at most.
The result
Five episodes are live on soxoa.com/podcast and the major podcast apps. Every one went through the same stages, so I can trace any line back to the rundown and any fact back to its source.
Steal it
The skill is podcast-room in my John Lab plugin. It pairs with writers-room: use the same show bible for both.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labSwapping one player for a mascot without touching anyone else
Why every full-frame AI video editor picked the wrong person, and the pipeline that finally worked: track one person, edit a crop, paste back only the character. As a Claude skill with its scripts.
Where it came from: Trying to make a Higgsfield-style shot myself: one player in a football clip turned into a mascot, after full-frame editors kept swapping the wrong person.
I wanted the kind of shot Higgsfield and Genjutsu make look easy. Take a real football clip, pick one player, and turn him into a plush mascot that catches the touchdown pass. The crowd, the other 20-something players, the score bug and the TOUCHDOWN graphic all stay exactly as broadcast. It should look filmed, not pasted.
The first few attempts were bad in the same way. A full-frame video editor reads "replace the receiver with the mascot" and guesses which receiver you meant. Mine guessed wrong. It recoloured a whole team's uniforms, garbled the score bug, and in one version the mascot was already holding the ball before the catch.
The fix wasn't a better prompt. It was taking the guessing away from the model.
Track one person, edit a crop, paste back only the character
The pipeline has three ideas, and everything else is plumbing.
- Point at the person instead of describing them. SAM2, Meta's open video segmentation model, takes three or four clicks on the target (helmet, jersey, legs) and a couple of negative clicks on whoever is touching him, then tracks him through the shot in both directions. It runs locally. Anyone standing in front of the target gets tracked too, so they stay real and on top.
- Give the editor a crop where the target is the obvious subject. A smoothed 9:16 virtual camera follows the tracked player at about twice his height. Now when the video model, Happy Horse on Sunra, is told to replace "the player kept at the centre", there's only one candidate.
- Paste back only the character. SAM2 runs again on the model's output to cut out the mascot with its own matte. That matte, plus the original player's outline so no trace of him survives, minus the occluders and the graphics, is the only part of the frame that changes. Every other pixel is the original broadcast.
The graphics need their own trick because SAM2 can't track them. Static overlays like the score bug come from pixel stillness: over a stretch where the camera pans, pixels that barely change are graphics. The animated TOUCHDOWN stinger gets a colour key. Both are protected on top of the composite.
The prompt rules I learned the hard way
- Identify the target by position and action, never by another player's number. "Keep #53 human" printed a 53 on the mascot.
- Say no text on the character: plain fur, no jersey, no numbers, no letters.
- Give the prop timeline in seconds. "Empty paws on the route, catches the ball at about 3 seconds, spikes it at about 5." Without it, the mascot started the play already holding the ball.
- Tell it to keep everything else unchanged: other players, uniforms, field, crowd, camera motion and graphics.
The dead ends, so you can skip them
| Tried | What happened |
|---|---|
| Full-frame edit with Kling O3 or Happy Horse | Wrong player, recoloured team, garbled graphics |
| Wan VACE masked inpainting with pose skeletons and keyframes | Right place, but the identity melted between keyframes |
| Wan 2.2 Animate Replace on the crop | Ignored a non-human reference and drew a smeared person |
| Pasting back a padded hull around the original player | A blurry halo of redrawn background around the character |
| SAM2 on the broadcast graphics | Caught fragments, then drifted onto players |
Each of those cost real credits and an afternoon. The table is in the skill so Claude doesn't try them again.
What it costs
Everything is local and free except the edit: tracking, cropping, matting, compositing, relabelling a lower-third and the final encode. Happy Horse runs about 21 Sunra credits per second of input, so a 9-second clip is around 190. The skill quotes the cost and waits for my OK before it spends anything.
Use it on footage you're allowed to use
This is a tool for turning a person into an obviously fictional character, on footage you own or have the rights to edit, with a character you have the rights to use. It isn't for making a real person appear to do something they didn't. If you relabel a lower-third, it's parody, and the clip gets shared as edited. Those rules are written into the skill.
Steal it
The skill is video-character-swap in my John Lab plugin. It's the one skill there that ships with scripts: SAM2 tracking, the tracked crop, the composite with graphics protection, the lower-third relabel and a one-time setup. Read them before you run them.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-labMake 100, keep 10
Eleven rounds, eleven different reasons to cut. The distillation method I use for tweets, hooks and headlines, packaged as a Claude skill.
Where it came from: The tweet session where I asked for 100 drafts and eleven rounds of cuts.
I asked Claude for ten spicy tweets. I didn't like them. I asked for twenty. Closer, but they talked about things I'd never post. Then I tried something different: make 100, grade them, and cut 20% at a time until there are ten left.
That third attempt gave me the only list I've actually used.
Why it works
When you ask for ten good lines, you get the model's idea of ten average lines. When you ask for a hundred, you get range: the safe ones, the weird ones, the ones that are almost great. Then the cutting does the work, and the trick is that each round cuts for a different reason.
If every round uses the same score, you end up with ten versions of the same tweet. When each round looks through a new lens, a survivor has to be good in eleven different ways.
The rounds I ran
| Round | Count | Cut for |
|---|---|---|
| 1 | 100 → 80 | lowest score |
| 2 | → 64 | near-duplicates |
| 3 | → 51 | nobody would reply |
| 4 | → 41 | no receipts, generic |
| 5 | → 33 | sounds like a LinkedIn carousel |
| 6 | → 26 | could hurt me as a consultant |
| 7 | → 21 | loses head-to-head on its topic |
| 8 | → 17 | a stranger wouldn't share it |
| 9 | → 14 | needs the video to make sense |
| 10 | → 11 | merge and tighten |
| 11 | → 10 | final cut |
The rubric was five criteria worth five points each: hook, spice, receipts, voice, and safe for someone who sells expertise. Every line was tagged with the video it came from, so I could see which of my filmed takes produced the best material. Two of the final ten came from scripts I hadn't filmed yet, which told me what to shoot next.
Survivors get better along the way
It isn't just elimination. Lines get tightened between rounds, two halves get merged, and a strong closer from a dead tweet gets moved onto a survivor. Every merge is written down, and so is every cut and its reason, so I can pull something back if the room got it wrong.
Get the no-go list first
The biggest lesson came before round one. My first two batches failed because I hadn't said what I won't post. Don't run yourself down. Don't talk about revenue. Don't mention that one project. The skill now asks for a no-go list before it writes anything, and any line that breaks it counts as a bug, not a cut.
Two style rules came out of this too: lowercase, and no em dashes. People spot those as AI now.
Steal it
It works for anything short: tweets, hooks, headlines, subject lines, product names, ad copy. The skill is hundred-to-ten in my John Lab plugin.
/plugin marketplace add johnarndt/john-lab
/plugin install john-lab@john-lab