Build prompts page and shift from repo links to AI prompts#356
Build prompts page and shift from repo links to AI prompts#356
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
nit: there's an images of build ideas in the Prompt, "Extensions to consider" (You said it's AI generated, writing just in case)
It would be great! Or just suggest to use create eth if skill doesn't work for some reason. Without it AI doesn't understand what to do and slowly googling and fetching data from github and se-2 docs.
I think yes |
|
Thanks Rinat!
My reasoning was: since we already have those images, let's use them to make the "CTAs" better (in /start page and in portfolio page), but once in the build prompt page... remove them (It'd be a pain to create an image for each one). But open.
I think we can phrase that a bit better, yes haha. My mental model was: If we have a super specific prompt, everyone is going to end with the same build.... so these "extensions" would be something that the Agent can propose to the people. Maybe we can call them "Next iterations" (But yes, we need to rewrite those prompts from scratch!) |
| <p className="mt-2 text-base-content/70"> | ||
| AI-ready prompts for Ethereum build ideas. Copy a prompt into your AI agent and start building. | ||
| </p> |
There was a problem hiding this comment.
Maybe in this sentence we could suggest to init your repo with create-eth and then copy the prompt into your AI agent.
The DX is much better if you start with a fresh SE-2 repo than if you start with an empty repo even if you prompt it to initialize before doing anything else. Like Rinat said, it starts googling and reading a lot of SE-2 docs/repo if you start with an empty repo.
We could add something like: "For best results, start from a fresh Scaffold-ETH 2 project: npx create-eth@latest. After setup, come back and run your prompt."
Maybe the last sentence could be skipped too
There was a problem hiding this comment.
This is related to OP comment:
We might need to include the "SE-2" skill so it'd install SE-2 and do the thing (link to scaffoldeth.io/SKILL.md?)
and
scaffold-eth/create-eth-extensions#117 (comment)
I think for builds & extension it'd be great if we dont' need to require a working SE-2 instance.
Pabl0cks
left a comment
Pabl0cks
left a comment
There was a problem hiding this comment.
Love this! Added a comment in line with Rinat's feedback about starting from an empty repo.
During my tests, with opus 4.6 the short prompt worked pretty well. Even better than more detailed and "hand-holding" prompts. Maybe with dumber models the result may change and they may prefer a more constrained prompt, but with latest models it’s probably not worth adding extra complexity.
I tried also those prompts for the multisig (with probably worse results):
More detailed prompt
Build a Meta-Transaction Multisig Wallet dApp using Scaffold-ETH 2.
Core concept: An offchain-signature-based multisig wallet where signatures are
collected offchain (gasless for signers) and only the final execution transaction
goes on-chain. This is more gas-efficient than on-chain voting and teaches
ECDSA signature verification, meta-transactions, and the self-call pattern.
Smart contract (MetaMultiSigWallet.sol):
- Stores owners (mapping + events), signaturesRequired threshold, nonce, chainId
- Constructor takes chainId, initial owners array, and signaturesRequired
- onlySelf modifier: addSigner, removeSigner, updateSignaturesRequired can only
be called by the contract itself (through executeTransaction), so owner changes
must go through the multisig approval process
- getTransactionHash(nonce, to, value, data) → keccak256 packed hash including
contract address and chainId for replay protection
- executeTransaction(to, value, data, signatures[]): verifies each signature via
ECDSA.recover(), enforces ascending signer order to prevent duplicates,
requires validSignatures >= signaturesRequired, then calls to.call{value}(data)
- receive() to accept ETH deposits
- Use OpenZeppelin's ECDSA and MessageHashUtils libraries
Offchain signature pool (backend server):
- Simple Express server (can run with ts-node) storing pending transactions
in memory, keyed by contractAddress_chainId
- POST / → stores {hash, to, value, data, nonce, signatures[], signers[], ...}
- GET /:key → returns all pending transactions for that contract
- For local development, run on port 49832
Frontend (4 pages):
1. /multisig — Wallet overview: shows contract balance, QR code for receiving
funds, address, and history of executed transactions (from ExecuteTransaction
events)
2. /create — Propose a new transaction: select method (transferFunds, addSigner,
removeSigner), fill parameters. For owner management, use encodeFunctionData
to build calldata targeting the contract itself. Signs the transaction hash
with the connected wallet and POSTs to the pool server
3. /pool — View pending transactions from the pool server. Each transaction
shows: hash, nonce, to, value, data, number of valid signatures vs required.
Signers can sign (adds signature to pool) or execute (calls executeTransaction
on-chain with collected signatures)
4. /owners — View current owners (from Owner events) and signatures required.
Provides a form to propose addSigner/removeSigner transactions that
pre-populates the /create page with the correct calldata
Signing flow:
1. Proposer calls contract.getTransactionHash(nonce, to, value, data)
2. Signs the hash with walletClient.signMessage({ message: { raw: hash } })
3. Contract.recover(hash, signature) verifies the signer is an owner
4. Transaction + signature are POSTed to the pool server
5. Other signers fetch from pool, verify, and add their signatures
6. Once enough signatures are collected, any owner can call executeTransaction
on-chain with the sorted signatures array
Extensions to try:
- ERC-20 token transfers (add as a method option with encodeFunctionData)
- Persistent backend (replace in-memory store with a database)
- Off-chain EIP-712 typed signatures for better wallet UX
- Custom signer roles (proposer-only, signer-only, admin with veto)
Another detailed prompt
Build a MetaMultiSig Wallet dApp using Scaffold-ETH 2.
**Core architecture:** An off-chain signature-based multisig where owners sign transactions locally (no gas) and signatures are aggregated in a pool server. Only the final `executeTransaction()` call goes on-chain.
**Smart contract — `MetaMultiSigWallet.sol`:**
- State: `mapping(address => bool) isOwner`, `uint signaturesRequired`, `uint nonce`, `uint chainId`
- Transaction hash: `keccak256(abi.encodePacked(address(this), chainId, nonce, to, value, data))` — includes contract address and chainId to prevent cross-contract and cross-chain replay
- `executeTransaction(to, value, data, bytes[] signatures)`: verifies signatures using `ECDSA.recover()`, requires signatures sorted ascending by recovered signer address (enables duplicate detection), executes `to.call{value}(data)` if threshold met
- `addSigner` / `removeSigner` / `updateSignaturesRequired` all use an `onlySelf` modifier — they can only be called by the contract itself via `executeTransaction`, meaning owner management goes through the same voting flow as any transaction
- Events: `Deposit`, `ExecuteTransaction`, `Owner`
**Pool server (`backend-local/`):** A minimal Express server with in-memory storage. `POST /` stores transactions keyed by `contractAddress_chainId` with sub-key `txHash`. `GET /:key` returns all pending transactions for that contract. Each POST overwrites the previous entry for that hash, so signature accumulation works by re-posting the transaction with an updated `signatures[]` array.
**Frontend — 4 pages:**
- `/multisig`: Shows contract ETH balance, QR code for funding, and executed transaction history via `ExecuteTransaction` events
- `/create`: Owner proposes a transaction — calls `getTransactionHash()` on-chain, signs with `walletClient.signMessage({ message: { raw: hash } })`, verifies via `recover()` + `isOwner()`, POSTs to pool server. Reads `predefinedTxData` from `localStorage` to support pre-encoded owner management calldata from the Owners page
- `/pool`: Polls pool server every ~4s. For each pending tx, validates signatures by calling `recover()` and `isOwner()`. **Sign button**: signs locally, calls `getSortedSigList()` to sort all signatures by recovered signer address ascending, re-posts to pool. **Exec button** (enabled when `signatures.length >= signaturesRequired`): calls `contract.write.executeTransaction([to, value, data, sortedSigs])`
- `/owners`: Shows current owners from `Owner` event history. Uses viem's `encodeFunctionData({ abi, functionName: 'addSigner'/'removeSigner', args: [address, newThreshold] })` to encode calldata, stores it in `localStorage`, and redirects to `/create` — the contract's self-call pattern in action
**Key implementation details:**
- Signatures must be sorted by recovered signer address (ascending) before `executeTransaction` — the contract uses `require(recovered > duplicateGuard)` to detect duplicates
- `getPoolServerUrl(chainId)`: returns `http://localhost:49832/` for Hardhat, `https://multisigs.buidlguidl.com:49832/` for public chains
- Serialize `BigInt` values as strings when POSTing to the pool server
- Deploy with `args: [chainId, [ownerAddress], signaturesRequired]` — start with 1-of-1 for local testing
**Verify by:** Running the full flow — fund the contract, propose a transfer, sign it from a second wallet in a second browser window, execute it, confirm the balance decreases and the tx appears in the `/multisig` event history.
I agree that having images would make the build prompts page more visually compelling, i could see the cards with a copy button and a expand button, in case you just want to copy&paste and tweak in your agent. I'd only add images if we can automate the image creation, or 95% of it, if not I'd start with text-only probably. I've been playing with some prompts with nano banana pro, will send some examples to see how we feel about them. We can probably achieve a coherent aesthetic this way between all the different build prompts we create, but we probably need to create 3-4 variations in some cases because sometimes it generates weird or low effort stuff. AI generated build ideas images
|
|
Regarding images: I'd love to have a page with 100s of build ideas under a bunch of categories, where we keep adding as new ERC or patterns come out. I don't think having images for those makes sense in this case. But, if we want to have a more "curated" page (like having 10/15 build prompts), then the images might make sense. |
Agree, now I think that it's not worth it to add images for now, so voting for leaving it as is, and maybe removing current build ideas images later |
|
In order to create builds with the prompt in an non-scaffolded folder, I created a PR to tweak the SKILL.md a bit to fix some issues with Windows-Foundry and it trying to create the scaffolded instance in an existing folder. To test you can try this prompt: I've replaced the SKILL.md from SE-2 main url to my preview instance url to test. Please let me know how it works on your setups 🙏 |
Experimentation with SVG NFTI've been playing a bit with the SVG nft. With the generic prompt we have right now it had a creative 1shot here:
Then I crafted a prompt based on the old loogie repo, with more constraints and focused on the old repo features: Loogie promptAnd it created a loogie-like output: 
Personal thoughtsI think we could start with the simple build prompts we have right now, (adding extra context to scaffold the project) so the LLM can be more creative. This would allow us to develop a few build prompts more quickly. In future iterations, we could consider having the LLM ask the user for different variations or attributes related to each specific project. That way, the build process would have some rails, but they would be defined by the user needs. |
|
Thanks @Pabl0cks! This is great!
💯💯 agreee! So just to summarize everthing:
Check if ./packages/nextjs/scaffold.config.ts exists directly in the current working directory (do not search subdirectories). If it doesn't exist, this is not a Scaffold-ETH 2 project. Follow the instructions at https://docs.scaffoldeth.io/SKILL.md to scaffold it first. If it exists, continue directly with building.
I had this philosophy in my meta prompt builder when migrating extension from skills: philosohpy of meta prompt builder## Philosophy: The 7/10 Rule
On a scale of 1 to 10:
- **1** = Rigid step-by-step with exact code to copy (the old extension system)
- **10** = "Just read the docs and figure it out" with zero guidance
**We aim for 7.** That means:
- **Give examples as syntax references**, not as code to copy verbatim. Label them clearly — "Syntax example", "Reference implementation", "for reference". The AI should understand the pattern, not paste the code.
- **Don't dictate every decision.** Let the AI choose icons, decide page placement, pick component structure, design the UI. It knows the project context better than a static template.
- **Don't over-specify what the AI already knows.** If SE-2 has an `AGENTS.md` or the AI has access to project files, don't repeat that info in detail. A brief mention ("SE-2 uses DaisyUI + Tailwind") is enough.
- **Do provide the hard-to-discover knowledge.** Integration patterns between SE-2 and the technology, the correct import paths for virtual modules, SE-2-specific config bridges — this is what the AI genuinely needs and can't easily figure out on its own.
- **Do link to official docs** and encourage the AI to search the web or check docs for anything not covered. The skill isn't a complete reference for the technology — it's the SE-2 integration knowledge.
- **Don't hardcode dependency versions.** Use `latest` or minimum version ranges and point to npm/GitHub releases. Hardcoded versions go stale. The exception: if a specific version is known to break, note that.
- **Frame things as "here's how it works" not "do this".** Say "The config reads SE-2's deployed contracts" not "Create a file called `ponder.config.ts` with the following contents". |
4 participants
Summary
Shifts build ideas from linking to GitHub challenge repos to providing AI-ready prompts users can copy into their AI agent to start building.
/build-promptspage with accordion list: expand to read prompt, one-click copybuild-prompts/*.md), easy to add new ones/build-promptsinstead of GitHub repos, removed "View Build Idea" buttonTODO
We'd also need to add way more build ideas (and categories possible) but could be in another PR.
Really open, let me know what you guys think!
Images