frontend-playbook

Guide Ethereum dApp frontend teams through Next.js/Scaffold-ETH2 production deployment.

1|Updated Apr 25, 2026
One-click install
npx skills add https://github.com/collat-labs/collat --skill frontend-playbook-collat-labs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: frontend-playbook
Source: https://github.com/collat-labs/collat/tree/main/.agents/skills/ethskills/frontend-playbook
Command: npx skills add https://github.com/collat-labs/collat --skill frontend-playbook-collat-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents production-ready Ethereum frontend deployments from failing due to fork-mode misconfiguration, stale builds, IPFS export quirks, and incorrect production/ENS/metadata setup.

Core Features & Use Cases

  • Fork-mode setup: Ensures you test against real on-chain state by using fork mode instead of an empty local chain, with correct target network settings for the frontend.
  • Production deployment workflows: Provides end-to-end guidance for deploying either via IPFS (recommended) or Vercel (alternative), including monorepo-specific Vercel configuration.
  • ENS subdomain + IPFS content hash: Guides creating/pointing ENS subdomains to the correct IPFS CID and verifying onchain content hashes and gateway responses.
  • Build verification checklist: Defines a practical QA process (code QA, Foundry tests, real browser walkthrough) plus an IPFS routing verification and stale build detection routine.

Use case example: you finished building a new Collat-style Ethereum dApp frontend and need a repeatable procedure to deploy it to IPFS with correct routes, correct OG metadata, and a working ENS link.

Quick Start

Ask for the full production checkout: fork-mode setup with correct targetNetworks, an IPFS static export checklist (including trailingSlash and localStorage polyfill), CID verification, then ENS subdomain transactions and final gateway/OG verification.

Frequently Asked Questions about frontend-playbook

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I deploy a Scaffold-ETH 2 frontend to IPFS with Next.js static export?

Deploying a Scaffold-ETH 2 frontend to IPFS requires configuring Next.js static export settings with trailingSlash and assets, then generating an IPFS content hash for routing. The process includes building the static frontend and pinning the exported output to IPFS, followed by gateway verification to ensure routes resolve correctly.

Why is my Ethereum dApp frontend failing in fork mode with incorrect chain-id targeting?

Ethereum dApp frontend failure in fork mode typically occurs when the frontend does not target chains.foundry in the targetNetworks configuration. Fixing fork-mode misconfiguration involves updating the target network settings so the frontend reads real on-chain state from the forked chain instead of an empty local chain.

What is the correct way to point an ENS subdomain to an IPFS content hash?

Pointing an ENS subdomain to an IPFS content hash involves submitting an ENS subdomain transaction that links the subdomain to the correct IPFS CID. After the transaction confirms, you must verify the onchain content hash and check that the ENS gateway returns the expected frontend response.

Can I deploy a Scaffold-ETH 2 dApp to Vercel instead of IPFS?

Yes, you can deploy a Scaffold-ETH 2 dApp to Vercel as an alternative to IPFS. Vercel deployment requires specific monorepo configuration to handle the Scaffold-ETH 2 project structure, ensuring build settings and environment variables target the correct Ethereum network and frontend package.

What is included in a production deployment checklist for an Ethereum dApp frontend?

A production deployment checklist for an Ethereum dApp frontend includes code QA, Foundry tests, and a real browser walkthrough. It also covers IPFS routing verification, stale build detection, OpenGraph metadata validation, and end-to-end gateway checks to ensure the deployed dApp functions correctly in production.

How do I prevent stale builds when deploying a Next.js dApp frontend to IPFS?

Preventing stale builds when deploying a Next.js dApp frontend to IPFS requires a specific detection routine during the build verification phase. You must verify the generated IPFS CID matches the latest build output and validate that gateway responses serve the updated static assets rather than cached or outdated content.