> ## Documentation Index
> Fetch the complete documentation index at: https://docs.launchblitz.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Build with Scrapestein

> Describe an automation, approve its expected behavior, and let Scrapestein build and test the graph.

Scrapestein is the graph-building agent inside the Scrapist editor. It can create a new graph or improve the currently selected graph. It works in an isolated draft until you approve the final save and activation.

## Start A Session

<Steps>
  <Step title="Open Scrapestein">
    Open a graph in the editor, expand the right sidebar if needed, and select **Scrapestein**.
  </Step>

  <Step title="Choose the target">
    Select **Improve this graph** to start from the selected version, or **Create a new graph** to start with an empty draft.
  </Step>

  <Step title="Describe the complete behavior">
    Include the event source, matching rules, output actions, launch platforms, naming, images, fee sharing, and any important edge cases.
  </Step>

  <Step title="Choose a model and thinking level">
    **Luna** favors speed, **Terra** balances speed and complex planning, and **Sol** is intended for the most demanding work. A higher thinking level can use more AI credits.
  </Step>

  <Step title="Draft expected behavior">
    Click **Draft expected behavior**. Scrapestein begins with test events and expected side effects before changing a graph.
  </Step>
</Steps>

Scrapestein keeps your request and its replies in one conversation. The workflow sections appear in that conversation as work progresses, with generated examples and reviews placed beside the discussion that produced them.

## Review Expected Behavior

Scrapestein proposes examples before it builds. Each example contains an input event and the side effects that should result.

1. Expand every test.
2. Check the author, post type, text, media, and other event fields.
3. Check the number and details of expected launches, trades, trace notifications, or other effects. Test matching does not enforce effect order.
4. Edit the test name, description, input event, or expected effects when needed.
5. Add or remove tests until the contract covers both successful and rejected events.
6. Click **Confirm expected behavior**.

This is the main behavior confirmation. Scrapestein may still ask a question when a missing detail would materially change the workflow.

<Tip>
  Include negative tests. For example, if only one account should trigger a launch, add tests for a different account, a similar handle, a missing address, and an invalid address.
</Tip>

## Follow The Build

After approval, the conversation progresses through these sections:

| Section | What Scrapestein does |
| - | - |
| **Plan** | Maps the approved examples to a small main graph and reusable functions. |
| **Functions** | Builds focused functions and connects them to the main graph. |
| **Test** | Materializes the approved examples, compiles the draft, and runs tests. |
| **Clean up** | Reviews structure, removes unnecessary complexity, and repeats failed checks. |
| **Variables** | Exposes settings you are likely to change, such as wallets, amounts, authors, and limits. |
| **Create** | Presents the exact tested draft for final approval. |

You can send a correction at any point when the agent is waiting. While it is running, the send control becomes a stop button.

## Approve The Final Graph

Scrapestein does not save or activate the finished draft without final approval.

* For a new graph, the final action is **Create and activate graph**.
* For an existing graph, the final action is **Save new version and activate**.

The approval applies only to the exact reviewed and tested draft. If that draft changes, Scrapestein must prepare a new final review.

<Warning>
  Final approval can activate launch or trading actions. Verify exposed variables, wallets, buy amounts, fees, launchpads, and instance limits before approving.
</Warning>

## Improve An Existing Graph

Select the graph and exact version in the resource controls before starting the session. **Improve this graph** uses that version as the baseline and saves successful work as a new version. The baseline remains available.

If the selected graph changes while the session is open, Scrapestein will not silently apply an outdated draft. Reopen or restart the session against the version you want to change.

## Resume Or Stop Work

Sessions are durable. Return to **Scrapestein** to reopen an earlier session and continue from its current step. The session list also shows its phase, model, and AI credits used.

* Use the stop button to cancel the current run. Its conversation remains in the session list, but a cancelled run cannot continue.
* A recoverable save or activation can be resumed without rebuilding the graph or repeating the same approval.
* Delete a session when you no longer need its conversation or draft. Billing audit records remain.

<Tip>
  AI credit use is shown below the conversation while a session is open. Start with clear behavior and concrete examples to reduce avoidable clarification and revision calls.
</Tip>

## Write A Strong Request

State behavior, not canvas layout. A useful request includes:

* The source event, such as a tweet, Truth Social post, Instagram post, story, profile change, or follow change.
* Exact author and post-type matching rules.
* How to select or validate addresses, names, tickers, and media.
* Every action that should happen, including whether sibling actions are independent.
* Exact launchpads and image styles when they matter.
* Which settings should remain editable as exposed variables.

Example:

> When `elonmusk` posts a valid Solana contract address in an original tweet, use the first valid address. Launch a Pump.fun coin named and ticked `elon`, use standard ASCII artwork, and send its fee share to that address. Also launch a Four.meme coin whose name and ticker are the first four address characters, using gold-on-black ASCII artwork. Expose only the settings needed to fund and submit both launches. Do nothing for other authors or posts without a valid address.

For an address-driven dual launch like this, review the contract and plan for these details:

* Model an original post as **TWEET** with the exact author handle, body text, and image list. Decide explicitly whether replies, quotes, and retweets should also trigger.
* Make every eligibility input affect the result. Compare the broken tweet's **Author Handle** with `elonmusk` using `==`, combine that result with **Extract Solana Pubkeys > Matched?** through **And**, and use the combined result to gate execution. Merely declaring an `author_handle` function input does not enforce the author rule if nothing reads it.
* Treat the address as a Solana public key when it feeds **Pump.fun Fee Share From Wallet**. Connect it to the exact `recipient` input, which accepts one scalar `string` containing a valid Solana public key. Connect the node's `fee_share` output to the Pump.fun launch. Do not connect the recipient address to the launch action's `wallet` input; that wallet funds and signs the launch. Select the first valid public key when several appear, and include invalid, missing, and multiple-address tests.
* The extracted address may be missing, so pass it through **If Exists** before either launch. Only send the unwrapped address to required launch inputs, and keep both launches off the execution path when no address exists.
* Expect two launch effects from the same eligible event. Use the canonical platform IDs `pump_fun` for the Solana launch and `four_meme` for the BNB launch, with strict names and tickers where the request determines them.
* An execution output connects to one next action. Chain the two impure launch-function calls on the eligible path instead of connecting one execution output to both calls. Do not place **Await TX Response** between them when the second launch does not depend on the first transaction's confirmation.
* Keep address selection and the derived four-character name or ticker in a pure function. Keep each launch responsibility focused in an impure function.
* Treat `ASCII` and `BNB_GOLD` as graph-building requirements, not launch-effect fields. Require an image in the tests, then verify that the Pump.fun image path uses `ASCII` and the Four.meme path uses `BNB_GOLD` during graph review.
* Make Pump.fun fee sharing **Strict** in the positive test and use that fixture's concrete address with 10,000 basis points. See [Testing](/scrapist/testing#match-the-right-details) for the assertion shape.

### Cover The Address And Author Boundary

Use at least these scenarios for the example request:

| Event | Expected result |
| - | - |
| Original `elonmusk` tweet containing one valid Solana public key | One strict `pump_fun` launch and one strict `four_meme` launch. |
| Original `elonmusk` tweet with no address | No effects. |
| Original tweet from a different author containing the same valid address | No effects. |
| Original `elonmusk` tweet containing a malformed marker such as `CA: not-a-solana-address` | No effects. |
| Original `elonmusk` tweet containing a valid address followed by punctuation | Both launches use the clean extracted address. |
| Original `elonmusk` tweet containing an otherwise address-like value with the invalid Base58 character `0` | No effects. |

For every positive case, make the Pump.fun name and ticker exactly `elon`. Make the Four.meme name and ticker exactly the first four characters of the extracted address. Require an image for both effects, and inspect the graph to verify the renderer styles because launch effects do not record `ASCII` or `BNB_GOLD`.

If the seven launch settings are still intentionally unset while Scrapestein tests the draft, every scenario should supply explicit test-only values for them. Test-only wallet, amount, tip, and Gwei values do not become the graph's saved defaults.

### Review The Seven Launch Settings

For this request, Scrapestein should present these required, fund-sensitive settings together during the **Variables** review:

| Setting | Used by |
| - | - |
| Pump.fun wallet | Funds and signs the Solana launch. |
| Four.meme wallet | Funds and signs the BNB launch. |
| Pump.fun buy amount | Sets the initial Pump.fun buy. |
| Four.meme buy amount | Sets the initial Four.meme buy. |
| Pump.fun tip amount | Sets the Solana launch tip. |
| Four.meme tip amount | Sets the BNB launch tip. |
| Four.meme Gwei | Sets the BNB gas price. |

Each exposed setting needs its own **Get Variable** node connected to the matching function input. Declaring the variable without that getter does not use it. Review all seven values together before approving the draft.

A Solana launch has no gas or Gwei input. Do not invent website, X, bundle, or suggest-only variables unless the request asks for them or the existing graph already uses them.

See [Events](/scrapist/node-reference/events), [Launch and action nodes](/scrapist/node-reference/action), [Pump.fun fee sharing](/scrapist/node-reference/data#configure-pumpfun-fee-sharing), and [Test automations](/scrapist/testing) for supported behavior.