Add cursor folder

.cursor/rules/content-types.mdc

@@ -0,0 +1,106 @@
+---
+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 usually determines the content type and structure expectations.
+`get-started/` is a mix of onboarding topics; see that section for when quickstart rules apply.
+
+## Folder-to-type mapping
+
+### `concepts/` and `learn/` - Explanation
+
+- Explain **why** something exists and **how** it works at a high level.
+- Provide context: design decisions, historical reasons, trade-offs, and alternatives.
+- Make connections to other parts of the system or to broader concepts.
+- Do not include step-by-step instructions. Link to related guides or quickstarts instead.
+- Keep explanation closely bounded. Do not let instructions or reference details creep in.
+- End every concept page with a "Next steps" section linking to actionable content.
+- Example: `smart-accounts-kit/concepts/smart-accounts.md`
+
+### `guides/` and `how-to/` - How-to
+
+- Goal-oriented steps that help the reader achieve a specific outcome.
+- Title the page with the goal (for example, "Configure gas limits"), not a generic label.
+- 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.
+- Omit the unnecessary. Practical usability matters more than completeness.
+- Do not digress into explanations or teaching. Link to concept pages instead.
+- Example: `smart-accounts-kit/guides/advanced-permissions/execute-on-metamask-users-behalf.md`
+
+### `quickstart/` and `get-started/`
+
+The folder name alone does not imply a single content type for every file under `get-started/`.
+
+**Tutorial-adjacent quickstart** (end-to-end, copy-paste-and-run path to a working integration)
+applies only when:
+
+- The file lives under a `quickstart/` directory, or
+- The file lives under `get-started/` and **quickstart** appears in the file or directory name
+  (for example, `smart-account-quickstart/index.md`).
+
+For those quickstart pages:
+
+- 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.
+
+**Other `get-started/` pages** are onboarding essentials readers should see before the rest of
+the docs: installation, system requirements, supported networks, supported clients, dashboard
+setup, and similar. They are not necessarily quickstarts. Choose structure based on the topic
+(how-to steps, short explanation, or reference-style facts) and match conventions of neighboring
+pages in the same `get-started/` section.
+
+Examples:
+
+- Quickstart: `smart-accounts-kit/get-started/smart-account-quickstart/index.md`
+- Onboarding in `get-started/` (not quickstart): `smart-accounts-kit/get-started/install.md`
+
+### `reference/` - Reference
+
+- Precise, complete, structured descriptions of APIs, methods, parameters, and return values.
+- Describe and only describe. Be austere, neutral, and factual.
+- 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.
+- Adopt standard patterns. Consistent structure lets readers find information quickly.
+- Mirror the structure of the API or code itself (for example, one section per method or endpoint).
+- Include short usage examples to illustrate parameters and return values.
+- Keep explanatory prose to the minimum needed to use the API correctly.
+- Do not include tutorials or extended how-to steps.
+- Examples: `snaps/reference/config-options.md`,
+  `smart-accounts-kit/reference/delegation/delegation-scopes.md`,
+  `services/reference/solana/json-rpc-methods`
+
+### `tutorials/` - Tutorial
+
+- Learning-oriented, reproducible, end-to-end walkthrough.
+- State what the reader will build or accomplish at the very start.
+- Do not assume the reader has prior knowledge of the subject or tools.
+- Deliver visible results early and often. Each step should produce output the reader can verify.
+- Show expected output (for example, "You should see `Server running on port 3000`").
+- Ruthlessly minimize explanation. Keep the focus on doing, not theory. Link to concept pages for
+  deeper understanding.
+- Ignore options and alternatives. Guide the reader along a single path to a successful conclusion.
+- Provide a complete working project or code sample.
+- Aspire to perfect reliability. Test every step. A learner who doesn't get the expected result
+  loses confidence immediately.
+- Example: `src/pages/tutorials/create-wallet-ai-agent.md`
+
+### `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.
+- Example: `smart-accounts-kit/troubleshooting/allowance-exceeded.md`
+
+## Frontmatter
+
+For required and optional documentation frontmatter (`description`, `keywords`, `sidebar_label`,
+`title` vs duplicate H1), see **Frontmatter** in `markdown-formatting.mdc`.

.cursor/rules/contributor-workflow.mdc

@@ -0,0 +1,82 @@
+---
+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 dashboard  | `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)
+
+## 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
+
+See the **Links** section in `markdown-formatting.mdc`.

.cursor/rules/editorial-voice.mdc

@@ -0,0 +1,60 @@
+---
+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 ("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," and "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 or learn a skill, not for marketing purposes.
+
+## Sentence construction
+
+- Lead with what's most important. Front-load keywords for scanning.
+- Start sentences with a verb when possible. Edit out "you can" and "there is/are" phrasing.
+- Use the Oxford (serial) comma in lists of three or more items (for example, "Android, iOS, and
+  Windows").
+- Do not start sentences with "So," "Basically," or "Actually."
+
+## Punctuation and formatting
+
+- Do not use em dashes or en dashes. Use commas, parentheses, semicolons, or rephrase the sentence.
+- Use only one space after periods, question marks, and colons.
+- Use sentence case for all headings and titles. Never use title case.
+- Do not end headings, subheadings, or UI titles with periods.
+- Use backticks for inline code, file names, and URLs referenced in prose.
+- Use bold for UI element names (buttons, menu items, field labels).
+
+## Developer content
+
+- List prerequisites before the first step. Suggest good practices (for example, "secure private
+  keys," "protect RPC endpoints in production").
+- Write code samples that are readable, can be copied and pasted, and work as expected. Do not
+  include shell prompts (for example, `user@host $`) in code blocks.
+- Use angle-bracket placeholders for user-supplied values (for example, `<YOUR_API_KEY>`).
+
+## 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.
+- No jargon without definition. If a term must be used, define it on first use or link to a
+  glossary entry.

.cursor/rules/markdown-formatting.mdc

@@ -0,0 +1,64 @@
+---
+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.
+- Write code samples that can be copied, pasted, and run as-is. Do not include shell prompts
+  (for example, `user@host $`) or trailing comments that break execution.
+- Use angle-bracket placeholders for values the reader must supply
+  (for example, `<YOUR_INFURA_API_KEY>`).
+
+## Tabs
+
+- Use Docusaurus `<Tabs>` and `<TabItem>` components to display parallel content such as code
+  samples in different languages or package-manager commands.
+- Import `Tabs` and `TabItem` from `@theme/Tabs` and `@theme/TabItem` at the top of the file.
+
+## 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](https://markdowntable.com/) if needed.
+
+## Frontmatter
+
+- 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`.