> For the complete documentation index, see [llms.txt](https://docs.pepeunchained.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pepeunchained.com/contributing/contributing-docs.md). # Docs Style Guide and Page Template Rules for writing and editing pages in this folder. The docs are the single source of truth for the PEPU dev kit, so accuracy outranks polish. ## Voice * Present tense. State facts as facts, with no hedging. * Imperative steps: say what to do, then why. * Plain and precise. No hype words, no emoji, no marketing adjectives, no exclamation marks. * No work-log language: no session history ("earlier", "now fixed"), no first person ("we did"), no internal process notes. * Describe what the product does, not how far its development has progressed. Do not cite proof transactions or the dates something was checked. * Include a caveat only when it changes what the developer does, for example "Deposits are one-way; they can't be withdrawn." or "Sessions are stored in memory in the template; use a persistent store in production." * Every page must make it easier to build or to use. If it does not, cut it. * PEPU is a chain, not "an AI chain". Agent tooling is described as tooling that helps builders get PEPU facts right. Security guidance belongs in [Trust and Security Model](/concepts/trust-and-security.md) and [Security Reviews](/contracts-and-addresses/audits.md), written neutrally. ## Facts to respect * Mainnet only: chain ID `97741`. The testnet `97740` is not supported. Chain ID `3409` is the retired V1 chain. * Hosted endpoints: bundler `https://bundler.pepeunchained.com` and paymaster service `https://paymaster.pepeunchained.com`. They are the SDK defaults; keep the env var names `PEPU_BUNDLER_URL` and `PEPU_PAYMASTER_URL` as overrides. The ERC-7677 URL always embeds a token (`https://paymaster.pepeunchained.com/v2/paymaster/`), so there is no tokenless default; write `` and never a real one. Local development defaults (`http://localhost:4337`, `http://localhost:8788`) may stay for people running their own services. Never write a tunnel URL (no ngrok, no trycloudflare) anywhere. * The v2 paymaster is `PepuSponsoredPaymasterV7`. The v1 paymaster is retired. Deposits to v2 are one-way. * Multicall3 is at a PEPU-specific address, never the canonical one. Give full addresses, never truncated ones, in tables meant for copying. * Never state a feature is available if it is not live. ## Code samples use real SDK exports * Import only symbols that exist in `@pepu-chain/sdk` and its documented subpaths: `/privy`, `/privy/react`, `/privy/wagmi`, `/privy/server`, `/session`, `/session/server`, `/session/react`, `/session/kernel`, `/aa`, `/aa/kernel`, `/aa/react`, `/aa/react-direct`, `/paymaster`, `/paymaster/server`, `/combo`, `/combo/react`, `/doctor`. * If a symbol is not exported, do not invent it. Check `packages/sdk/src` and the exports test, or call the `pepu_sdk_exports` MCP tool. * Prefer SDK functions over hand-rolled infrastructure. Use raw viem or JSON-RPC only where the SDK has no equivalent, and say so. * Server-only code (Privy app secret, authorization key, claim attestation) is labeled server-only and never reads `NEXT_PUBLIC_` variables. * Never print or embed secrets, keys or real tokens. Use obvious placeholders. * Samples meant to compile live under `docs/snippets/` and are type-checked in CI. Pages include them and do not diverge from them. ## Page template ```markdown # Page Title One paragraph: what this page is for and who needs it. ## Prerequisites ## Steps or reference body ## What to expect ## Common failures ## Related ``` Rules: * One H1 per page, title case, matching the `SUMMARY.md` entry. * Reference pages use tables; procedures use numbered steps. * Every failure symptom names the cause and the fix. * Link with relative paths, for example from the docs root `[Session Keys](onboarding/session-keys.md)`. * Add every new page to `SUMMARY.md` in the same change. * Do not put Markdown link syntax inside `TODO` comments; the link checker reads them. ## Stubs and ownership New pages start as stubs: a title, a one-paragraph purpose and a `TODO(Dn)` comment listing the required sections. The owner replaces the stub and removes the TODO. | Writer | Folders | | ------ | ------------------------------------------------------------------------------------------------------------------------------------- | | D2 | `get-started/`, `onboarding/`, `concepts/`, `privy/`, `reference/env-vars.md`, glossary, FAQ | | D3 | `sdk/`, `recipes/`, `snippets/`, changelog | | D4 | `mcp/`, `agent-tooling/`, `templates/`, `cli/` | | D5 | `infra/`, `contracts/` | | D6 | generated pages (`reference/errors.md`, `reference/endpoints.md`, `sdk/errors.md`), `llms.txt`, `llms-full.txt`, `troubleshooting.md` | ## Checks * `node scripts/check-links.mjs` must report 0 broken links. * `docs/llms.txt` assumes each page URL mirrors its path; D6 keeps it current. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.pepeunchained.com/contributing/contributing-docs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.