/rapid-fire-testing

⛔ THE ONE NON-NEGOTIABLE RULE (read this first, every time)

Once this skill is invoked, you DO NOT STOP until the artifact(s) exist. Not once. Not for anything.

• You do NOT pause to ask permission.
• You do NOT stop to reflect scope back and wait for "y/n".
• You do NOT require the person to engage, confirm, choose, or greenlight mid-flight.
• You do NOT ask which approach to take — you pick one and produce.
• If you are uncertain about a detail (a brand, a model, an exact price), you make your best honest call, state your confidence, and KEEP GOING. The person will modify any finished artifact if it's wrong. Producing a wrong-but-editable listing is correct. Stopping to ask is a failure.
• The ONLY legitimate breaks are the two named in "When To Break Posture" below: a hard external dependency you physically cannot satisfy (a credential/account only the person has), or a write into a real shared production system. Uncertainty is NEVER a legitimate break.

If the person hands you N items, you produce N artifacts in one continuous run. You report when they ALL exist — not before, and not in between with a question.

Example (opt-in context — the rule itself is general)

This rule is as strict as it is because of a real case: a batch of listings where stopping mid-run would have meant re-deriving context on every restart, when the instruction was to never stop work under any circumstances once invoked, until the listings are done. The rule generalizes beyond that one example: whatever the person hands you, you don't stop until the artifact(s) exist.

Per-message coherence/scope-gate hooks are satisfied ONCE at the start and never used as a reason to stop the run.

Trigger

Direct invocation: /rapid-fire-testing <idea> (or /rapid-fire-testing followed by an idea anywhere in the person's message).

The idea is whatever the person has named — automate X, prove Y works, see if Z is feasible. Treat that named idea as the thing to be tested and enter the protocol immediately.

What this skill IS (and what it isn't)

IS: A rapid-iteration posture for racing to the first piece of tangible evidence that proves (or disproves) whether an idea can produce a desirable outcome.

ISN'T:

• A planning skill (do not produce plans, produce artifacts)
• A brainstorming skill (the idea is given — your job is to test it)
• A full-build skill (you are not shipping a feature, you are gathering evidence)
• A confirmation-loop skill (you do NOT stop for permission between steps)

The boundary against neighboring skills:

• /brainstorming explores options — this skill resolves a single bet.
• /feature-completion-ux-test validates a finished feature — this skill validates an unproven idea.
• /governer gates risky work — call it only if you genuinely need to write into shared systems, not as a stalling tactic.

The Core Posture

The person is testing whether the idea can result in a tangible outcome that is desirable, in the most direct way possible. The person does NOT want you to:

• Custom-build from scratch when an open-source repo already exists
• Stop for permission between steps
• Spend ten hours and ten confirmations getting to a strategy that won't work
• Polish prompts, write specs, or build scaffolding before the first evidence point
• Loop a human into the work until the fundamental evidence has been gathered

The person DOES want you to:

• Identify the single piece of evidence that proves the strategy has merit
• Take the most direct path to producing that evidence
• Lean on open-source tooling that you can pull into a scratch directory in this project and try
• Work continuously in a loop toward the evidence, not toward a plan
• Produce an actual artifact the person can evaluate

The Five-Minute Test

"If there's a way for you to test your best idea on this in five minutes and determine if it's actually gonna work with actual evidence, that would be the right path forward."

Before doing anything else, ask: what is the smallest possible artifact that, if it exists, proves this idea has merit?

Examples:

• T - automate facebook customer service → the smallest proof is one real reply sent back to one real message in Facebook Marketplace. Not a perfect reply. Not a polished system. One message, sent.
• T - create videos with this new Claude tool → the smallest proof is one actually-generated video, relevant to the person's domain, that the person can watch right now.
• T - automate cold outreach to family offices → the smallest proof is one personalized outreach message generated from a real prospect's public data, not a sent message (that would require alignment first).

The evidence point is whatever, when seen by the person, will give them enough signal to say "keep going" or "kill it."

Protocol — Run In Order, Don't Stop

1. /reflect

Open with /reflect so the work is observable. State:

• The verbatim T - idea
• Your interpretation of the desirable outcome
• Your deduced "first piece of tangible evidence" (the artifact that, if it lands, proves merit)
• The most direct path you can imagine to producing it
• Whether an open-source repo, MCP tool, or existing IX capability likely shortcuts the path

2. Open-Source / Existing-Tool Scan

Before writing any custom code, check whether someone has already done most of the work:

• If institutional-memory search is set up (agent_find or your local equivalent — see /alignment-harness:harness-setup), query it with the idea phrased as a question to find existing tooling, skills, or knowledge already in this project. If nothing is set up, grep this repo's own docs and skills instead.
• Search GitHub for the obvious open-source project (e.g. for T - automate facebook customer service, search for "facebook marketplace bot", "messenger automation", "FB chat API wrapper")
• Check if an MCP tool the person has already installed can do it (look at the connected MCP servers in your context)

Pull the most promising candidate into a scratch directory in this project as a test, not as an adoption decision. If it's a repo, clone it into a scratch dir. If it's an MCP tool, read its capabilities and pick the single most representative call.

3. Pick The Exemplary Test Case

For the chosen tool, ask: what makes this tool unique, and what test case best showcases that uniqueness while also being relevant to the person's actual goal?

This is where institutional-memory search (or, absent that, a quick read of the person's own recent work) earns its keep — pull context about what the person is actually working on so the test artifact lands in their world, not in toy-example world.

4. Produce The Artifact

Take the most direct path to producing the single piece of evidence. Skip:

• Robustness
• Edge cases
• Error handling beyond "don't break the person's machine"
• Prompt polish
• Configuration scaffolding

Keep:

• A real input
• A real output
• A clear path for the person to see the output

5. Hand The Artifact To The Person

Use /how-to-talk-like-the-founder to write the closing message — its name is historical; it calibrates to whichever person you're actually working with. If that skill hasn't been calibrated with this person's own voice yet (no samples on file), don't silently write in a generic tone and let them assume that's the harness's real voice — say so plainly in the handoff: "here's the artifact — I don't have your writing voice calibrated yet, so this is a plain, factual handoff," and let the substance of the evidence carry it. That never blocks the artifact from landing on time. Whatever format the artifact is in:

• Video / image / audio → drop directly into chat if possible; if not, save into an organized folder in your notes (if you keep one) and point the person at it
• Generated message / email / reply → paste the full text in chat
• Generated link / deployed page → give the clickable URL FIRST, then one short sentence on what it shows and why
• Code / file artifact → give the clickable file path FIRST, then the consumption path

The closing message has three parts, in this order:

1. The URL or artifact (clickable, no preamble)
2. What the person will see when they open it (one sentence, in the calibrated voice)
3. Why this proves (or fails to prove) the idea has merit (one sentence, in the calibrated voice)

When To Break Posture

You will stay in the loop until evidence is in hand. The ONLY legitimate breaks:

• /ask — if a genuinely external dependency blocks you (credential the person must provide, an account that doesn't exist yet, a piece of context only the person has). Use the /ask protocol: synthesize, predict, score, route. Don't break posture for "should I use library A or library B" — pick one and try it.
• /governer — if the most direct path would write into a shared production system (real customer DB, real email send to real users, real payment, real deploy). Score it, route it, but do NOT use governer as a stalling tactic on local exploration.
• Tool that's actually broken — report immediately per the "Report Tool Failures Immediately" rule. Don't silently switch strategies.

Anything else — including uncertainty, intermediate questions, "should I keep going" — is NOT a legitimate break. Keep working toward the artifact.

Observable Evidence Trail

Throughout the loop, surface (briefly) that you are following the posture:

• Print the deduced "first evidence point" so the person can correct it if you misread the idea
• When you find an open-source candidate, name it and link it
• When you pick a test case, name what makes it exemplary for the tool
• When you produce the artifact, lead with the artifact itself, not narration about it

This is the difference between observable rapid iteration and a black-box "trust me, I'm working."

Anti-Patterns (what triggers a /rapid-fire-testing failure)

• Producing a plan instead of an artifact
• Asking the person to choose between approaches before you've tried one
• Building scaffolding (folders, configs, abstractions) before producing evidence
• Stopping at "I researched it, here's what I found" without attempting to produce the artifact
• Polishing the artifact past "good enough to evaluate"
• Hiding the artifact at the bottom of a long status update — the artifact leads

Example Walkthrough

Person's message: T - automate facebook customer service

Agent move 1 (/reflect):

Verbatim idea: automate facebook customer service. Interpretation: the person wants to know if an agent can handle the marketing/customer-service loop on Facebook (likely Marketplace, given context) without a human in the loop for every message. First evidence point: one real reply sent back to a real message in Facebook Marketplace. If that works, the strategy has merit. If it can't be done without harming the account or breaking ToS in a way that kills the strategy, kill it now. Most direct path: find an existing open-source FB Messenger / Marketplace bot, see if it can read one inbound message and send one outbound reply against the person's test account.

Agent move 2 (open-source scan): searches GitHub for "facebook marketplace bot", finds 2-3 candidates, picks the most-starred maintained one, pulls into a scratch dir in this project.

Agent move 3 (test case): pulls a real inbound message from the person's Marketplace inbox (or uses a test message the person sends to themselves from a second account). Generates a reply with Claude. Sends it.

Agent move 4 (artifact): the reply lands in the test conversation. Agent screenshots or links to the conversation.

Agent move 5 (handoff in the calibrated voice):

https://facebook.com/marketplace/inbox/

That thread shows a message I sent automatically — pulled your inbound, generated a reply, sent it back, no human touch.

This proves the loop closes end-to-end. The next question is quality, not feasibility — which is the right question to be stuck on.

That's a complete /rapid-fire-testing cycle.

Done Criteria

The skill exits when:

• An artifact exists that the person can evaluate in under 60 seconds of their time
• The artifact is delivered with a /how-to-talk-like-the-founder closing in URL-first format
• The person has enough signal to say "keep going" or "kill it"

Not before.