Add cursor folder

.cursor/rules/content-types.mdc

@@ -0,0 +1,70 @@
+---
+description: Maps folder conventions to Diataxis content types so AI tools produce the right structure for each doc category.
+globs: ["**/*.md", "**/*.mdx"]
+alwaysApply: false
+---
+
+# Content types (Diataxis)
+
+This repository follows the [Diataxis framework](https://diataxis.fr/) to organize documentation by
+function. The folder a file lives in determines the content type and structure expectations.
+
+## Folder-to-type mapping
+
+### `concepts/` and `learn/` — Explanation
+
+- Explain **why** something exists and **how** it works at a high level.
+- Do not include step-by-step instructions. Link to related guides or quickstarts instead.
+- End every concept page with a "Next steps" section linking to actionable content.
+
+### `guides/` and `how-to/` — How-to
+
+- Goal-oriented steps that help the reader achieve a specific outcome.
+- State the goal in the first sentence or heading.
+- List prerequisites before the first step.
+- Number the steps. Each step should contain one action.
+- Assume the reader has basic knowledge of the product.
+
+### `quickstart/` and `get-started/` — Tutorial-adjacent quickstart
+
+- End-to-end, copy-paste-and-run path to a working integration.
+- State what the reader will build or achieve.
+- Provide complete, working code that can be copied and pasted.
+- Keep the scope narrow. Link to guides for extended scenarios.
+
+### `reference/` — Reference
+
+- Precise, complete, structured descriptions of APIs, methods, parameters, and return values.
+- Match the parameter format used in surrounding reference pages. Some areas use tables (name,
+  type, required/optional, description); others use nested bulleted lists (for example, JSON-RPC
+  method docs in Services). Be consistent with the existing convention in the same product section.
+- Keep explanatory prose to the minimum needed to use the API correctly.
+- Do not include tutorials or extended how-to steps.
+
+### `tutorials/` — Tutorial
+
+- Learning-oriented, reproducible, end-to-end walkthrough.
+- Do not assume the reader has prior knowledge of the subject or tools.
+- Explain every step. Include expected output where helpful.
+- Provide a complete working project or code sample.
+
+### `troubleshooting/` — Problem/solution
+
+- State the symptom or error message first, then the fix.
+- One problem per section or page.
+- Include the exact error text when available so readers can search for it.
+
+## Frontmatter requirements
+
+Every new page must include at minimum:
+
+- `description`: one-sentence summary for SEO and link previews.
+
+Optional (use sparingly):
+
+- `sidebar_label`: only when the default sidebar text would be too long or wordy for the nav.
+  See **Front-matter** in `markdown-formatting.mdc`.
+
+Also recommended:
+
+- `keywords`: array of relevant search terms.

.cursor/rules/contributor-workflow.mdc

@@ -0,0 +1,86 @@
+---
+description: Workflow rules for contributors and reviewers covering sidebar updates, redirects, verification, and PR expectations.
+alwaysApply: true
+---
+
+# Contributor workflow
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for the full contribution process. The rules below highlight
+the requirements that are most often missed.
+
+## Sidebar updates
+
+Every new documentation page must be added to the appropriate sidebar file:
+
+| Product            | Sidebar file             |
+|--------------------|--------------------------|
+| MetaMask Connect   | `mm-connect-sidebar.js`  |
+| Embedded Wallets   | `ew-sidebar.js`          |
+| Smart Accounts Kit | `gator-sidebar.js`       |
+| Services           | `services-sidebar.js`    |
+| Developer Tools    | `dashboard-sidebar.js`   |
+| Snaps              | `snaps-sidebar.js`       |
+
+## Redirects
+
+Every deleted, renamed, or moved page must have a redirect added in `vercel.json`. Docusaurus is
+configured with `onBrokenLinks: 'throw'`, so broken internal links will fail the build.
+
+## Factual accuracy
+
+Do not state as fact any API behavior, parameter, or return value that you have not verified
+against the codebase or published reference. If you are uncertain, add a review comment or
+admonition noting the uncertainty. This rule applies to both human and AI-assisted contributions.
+
+## Images
+
+Place images in the product's designated asset folder:
+
+- `metamask-connect/*/_assets/`
+- `static/img/embedded-wallets/` (Embedded Wallets product images)
+- `smart-accounts-kit/assets/`
+- `services/images/`
+- `snaps/assets/`
+- `static/img/` (for site-wide assets)
+
+Use white or `#1b1b1d` backgrounds for light/dark mode compatibility.
+
+## Update rule files for structural changes
+
+When a change affects the structure, naming, or conventions of a product area, update the
+corresponding `.cursor/rules/` file in the same PR. Examples of changes that require a rule update:
+
+- Renaming a product or changing its branding (update the product rule file and `terminology.mdc`).
+- Adding, removing, or renaming top-level content folders (update the product rule file and
+  `content-types.mdc` if a new folder pattern is introduced).
+- Changing the parameter documentation format in a reference section (update the product rule file
+  and `content-types.mdc`).
+- Moving image storage to a different directory (update `contributor-workflow.mdc` and the product
+  rule file).
+- Adding a new product area to the repository (create a new `product-*.mdc` rule file and add the
+  product to the table in `contributor-workflow.mdc` and `AGENTS.md`).
+- Changing sidebar file names or adding new sidebar files (update the sidebar table above and the
+  product rule file).
+- Introducing new shared partials or generated-content patterns (update the product rule file).
+
+Keeping rule files current prevents stale guidance from producing incorrect contributions.
+
+## CI linting
+
+Pull requests are checked by a Vale-based linter
+([docs-spelling-check](https://github.com/Consensys/github-actions/tree/main/docs-spelling-check))
+that enforces Microsoft style, Consensys terminology, and spelling. Fix any linter warnings before
+requesting review. If a warning is a false positive, add the term to the Vale vocabulary file rather
+than rewriting valid technical language.
+
+## Pull requests
+
+- Summarize what changed and why in the PR description. Do not just list files.
+- Link the related issue using `fixes #<number>` when applicable.
+- Preview locally with `npm start` before requesting review.
+
+## Cross-product links
+
+- Use relative file paths for links within the same product section.
+- Use absolute URL paths (for example, `/snaps/learn/about-snaps`) for links that cross product
+  boundaries.

.cursor/rules/editorial-voice.mdc

@@ -0,0 +1,42 @@
+---
+description: Editorial voice and tone rules aligned with the Microsoft Writing Style Guide and Consensys documentation standards.
+globs: ["**/*.md", "**/*.mdx"]
+alwaysApply: false
+---
+
+# Editorial voice
+
+Follow the [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/)
+and the [Consensys documentation style guide](https://docs-template.consensys.net/contribute/style-guide).
+The rules below are the most actionable subset for AI-assisted editing.
+
+## Voice and tone
+
+- Use active voice and present tense.
+- Write in second person. Address the reader as "you."
+- Use contractions naturally ("you can," "it's," "don't"). Be informal but not sloppy.
+- Refer to the reader's application as "your dapp" (not "the dapp" or "your application").
+- Refer to the reader as "you" (not "the developer," "the user," or "users").
+- Dapp developers (our readers) in turn have users. It's ok to use users in that context.
+
+## Clarity
+
+- Get to the point in the first sentence of every section. Does it answer "what:, "why", "when"?
+- Use short, simple sentences. Remove nonessential or redundant words.
+- Break up three or more paragraphs with subheadings, lists, tables, code samples, or admonitions.
+- Write for developers who want to accomplish a task, not for marketing purposes.
+
+## Punctuation and formatting
+
+- Do not use em dashes or en dashes. Use commas, parentheses, semicolons, or rephrase the sentence.
+- Use sentence case for all headings and titles.
+- Use descriptive link text. Do not use "click here" or bare URLs as link text.
+- Use backticks for inline code, file names, and URLs referenced in prose.
+- Use bold for UI element names (buttons, menu items, field labels).
+
+## What to avoid
+
+- No marketing language, superlatives, or promotional tone ("best-in-class," "powerful," "seamless").
+- No slang, figures of speech, or culturally specific idioms.
+- No run-on sentences.
+- Do not start sentences with "So," "Basically," or "Actually."

.cursor/rules/markdown-formatting.mdc

@@ -0,0 +1,54 @@
+---
+description: Markdown formatting conventions for the MetaMask documentation site (Docusaurus).
+globs: ["**/*.md", "**/*.mdx"]
+alwaysApply: false
+---
+
+# Markdown formatting
+
+Follow the [Consensys Markdown formatting guide](https://docs-template.consensys.net/contribute/format-markdown)
+for full details. The rules below cover the most common conventions.
+
+## Line length and sentence breaks
+
+- Wrap lines at roughly 100 columns.
+- Start each new sentence on a new line, even if the previous line is short. This makes diffs
+  easier to review.
+
+## Links
+
+- Use relative file paths for links within the same product (for example, `./concepts/scopes.md`).
+- Use absolute URL paths for cross-product links (for example, `/snaps/learn/about-snaps`).
+- Use descriptive link text. Do not use "click here" or bare URLs.
+- Use absolute links on `CardList` components.
+
+## Code blocks
+
+- Always specify the language on fenced code blocks (` ```javascript `, ` ```bash `, etc.).
+- Use double quotes in JavaScript code samples.
+- Indent code with two spaces, not four.
+- For npm install commands, use ` ```bash npm2yarn ` fences to produce automatic npm/yarn tabs.
+
+## Admonitions
+
+- Use Docusaurus admonitions: `:::note`, `:::tip`, `:::caution`, `:::info`, `:::danger`.
+- Add a custom title on the same line only when it helps scanning (for example, `:::caution important`).
+- Do not nest admonitions.
+
+## Tables
+
+- Align table columns in the source Markdown for readability.
+- Use a tool like [Markdown Table Formatter](http://markdowntable.com/) if needed.
+
+## Front-matter
+
+- Required: `description` (one sentence for SEO and previews).
+- Recommended: `keywords` (array).
+- `sidebar_label`: optional. Use sparingly—only when the default sidebar text (usually from the
+  page title) would be too long or wordy for the navigation. Omit when the default is fine.
+- If the frontmatter contains a `title` field, do not add a separate top-level `# Heading` to
+  avoid a duplicate H1.
+
+## File and folder names
+
+- Use lowercase letters and dashes only (for example, `send-transactions.md`, not `sendTransactions.md`).

.cursor/rules/product-embedded-wallets.mdc

@@ -0,0 +1,55 @@
+---
+description: Product-specific guidance for Embedded Wallets documentation, including naming, content organization, and SDK conventions.
+globs: ["embedded-wallets/**/*.md", "embedded-wallets/**/*.mdx"]
+alwaysApply: false
+---
+
+# Embedded Wallets
+
+## Product naming
+
+- The product name is **MetaMask Embedded Wallets**.
+- Use **Embedded Wallets** (capitalized) as the short form in prose.
+- The SDKs are **MetaMask Embedded Wallet SDKs** (formerly Plug and Play).
+- Package names and code identifiers still use `web3auth` (for example, `@web3auth/modal`). Do not
+  rename these in code samples.
+- Do not describe Embedded Wallets as a "wallet." It is **embedded wallet infrastructure** that
+  developers integrate into their applications.
+
+## Content organization
+
+Embedded Wallets uses domain-oriented folders rather than strict Diataxis categories:
+
+| Folder               | Content                                          |
+|----------------------|--------------------------------------------------|
+| Root (`README.mdx`)  | Product overview and positioning                 |
+| `sdk/`               | Per-platform integration docs (React, Vue, JS, Node, Android, iOS, React Native, Flutter, Unity, Unreal) |
+| `authentication/`    | Auth methods by type (social, basic, custom)     |
+| `features/`          | Product capabilities (MPC, smart accounts, funding, NFT minting, session management) |
+| `dashboard/`         | Developer console and project configuration      |
+| `connect-blockchain/`| Chain-specific connection guides (EVM, Solana, other) |
+| `infrastructure/`    | Architecture and security (MPC, SSS, nodes)      |
+| `troubleshooting/`   | Problem/solution pages                           |
+
+When adding new content, place it in the domain folder that best matches the topic. Do not create
+new top-level folders without discussing with the documentation team.
+
+## SDK documentation
+
+- Each platform SDK has its own subfolder under `sdk/` with a consistent structure: `README.mdx`,
+  `usage/` or equivalent, `advanced/`, and (where applicable) `migration-guides/`.
+- Shared SDK snippets live in `sdk/_common/`. Reuse these partials where possible instead of
+  duplicating content.
+- Chain-specific connection snippets live in `connect-blockchain/` as underscore-prefixed files
+  (for example, `_evm-chains.mdx`).
+
+## Images
+
+Embedded Wallets images are stored in `static/img/embedded-wallets/`, not alongside the Markdown
+source files. Use `@site/static/img/embedded-wallets/...` imports in MDX.
+
+## Sidebar
+
+The sidebar configuration is in [ew-sidebar.js](ew-sidebar.js). It groups SDKs by platform
+category (Web, Mobile and Gaming, Backend) using HTML helpers imported from
+`./src/utils/w3a-sdk-map.js`.

.cursor/rules/product-metamask-connect.mdc

@@ -0,0 +1,42 @@
+---
+description: Product-specific guidance for MetaMask Connect documentation, including terminology, CAIP standards, and content organization.
+globs: ["metamask-connect/**/*.md", "metamask-connect/**/*.mdx"]
+alwaysApply: false
+---
+
+# MetaMask Connect
+
+## Product naming
+
+- The product name is **MetaMask Connect**. Do not call it "MetaMask SDK." The SDK is the
+  underlying library; MetaMask Connect is the product and documentation brand.
+- When referring to the npm package, use the package name in backticks (for example,
+  `@metamask/sdk`).
+
+## Content organization
+
+MetaMask Connect has three sub-areas, each with its own quickstart, guides, and reference:
+
+| Sub-area   | Path                        | Focus                                     |
+|------------|-----------------------------|-------------------------------------------|
+| EVM        | `metamask-connect/evm/`     | Ethereum and EVM-compatible chains        |
+| Multichain | `metamask-connect/multichain/` | Cross-chain using CAIP standards       |
+| Solana     | `metamask-connect/solana/`  | Solana-specific integration               |
+
+## CAIP standards (Multichain)
+
+Multichain documentation uses Chain Agnostic Improvement Proposals (CAIPs). Use these terms
+consistently:
+
+- **Scopes** (CAIP-2): chain identifiers such as `eip155:1` or `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp`.
+- **Account IDs** (CAIP-10): chain-qualified account identifiers such as `eip155:1:0xabc...`.
+- **Sessions** (CAIP-25): an authorized connection grouping approved scopes and accounts.
+
+## EVM conventions
+
+- Reference the `window.ethereum` provider when discussing the injected provider.
+- Mention EIP-6963 (Multi Injected Provider Discovery) where relevant for provider detection.
+
+## Sidebar
+
+The sidebar configuration is in [mm-connect-sidebar.js](mm-connect-sidebar.js).