Merge upstream v2.7.0-alpha.2

Author: github-actions[bot]

.cursor/commands/create-pr.md

@@ -0,0 +1,17 @@
+---
+name: check-github-cli
+description: Ensure GitHub CLI (gh) is installed and authenticated before running gh commands; guide the user to configure it if not
+---
+# Check GitHub CLI Availability
+
+Use this skill whenever a workflow or command requires the GitHub CLI (`gh`). Before running any `gh` commands:
+
+1. **Check installation and auth**: Run `gh auth status`. If it reports "not logged in" or the command is not found:
+   - **If `gh` is not installed**: Ask the user to install it (e.g. `brew install gh` on macOS, or see [GitHub CLI](https://cli.github.com/)) and then authenticate.
+   - **If `gh` is installed but not configured**: Ask the user to configure it themselves. Provide these instructions to help them:
+     - Run `gh auth login` and follow the prompts (choose HTTPS or SSH, authenticate via browser or token).
+     - Ensure the account has the permissions needed for the operation (e.g. read access to the repository, or read/write if the task requires it).
+   - Do not attempt to authenticate on the user's behalf; only guide them with the commands and link to [GitHub CLI authentication docs](https://cli.github.com/manual/gh_auth_login).
+2. **If `gh auth status` succeeds**: Proceed with the steps that require `gh`.
+
+Other skills that depend on `gh` (e.g. get-checks-status) should instruct the agent to ensure GitHub CLI is ready first by following this skill.

.cursor/commands/deploy-demo.md

@@ -0,0 +1,62 @@
+---
+name: create-pr
+description: Create a well-structured pull request with proper description, labels, and reviewers
+disable-model-invocation: true
+---
+# Create PR
+
+## Prerequisites: GitHub CLI
+
+This workflow uses `gh` to check for existing PRs, fetch issue details, and create the PR. **Follow the check-github-cli skill** first (ensure `gh auth status` succeeds; if not, guide the user to install/configure `gh` and do not proceed). The account needs read access to the repo and write access to create PRs and manage labels.
+
+## Overview
+
+Create a well-structured pull request with proper description, labels, and reviewers.
+
+## Steps
+
+_Note:_ In the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`.
+
+### 1. Check that a PR is not already open for this branch
+
+- Get the current branch: `git branch --show-current`.
+- List open PRs for that branch: `gh pr list --head <BRANCH> --state open`.
+- If a PR exists, do **only** the PR summary (see step 3: write the description content as if for the PR, but do not create or update the PR). Skip steps 2, 3 (create/update), and 4. Tell the user the PR is already open and link to it.
+
+### 2. Prepare the branch
+
+- Ensure all changes are committed:
+  - `git status` to see uncommitted changes.
+  - If there are changes: `git add` (as appropriate), then `git commit -m "..."` with a clear message.
+- Push the branch: `git push -u origin <BRANCH>` (or `git push` if upstream is already set).
+- Verify the branch is up to date with main:
+  - `git fetch origin main` then compare: e.g. `git rev-list --left-right --count origin/main...HEAD` (expect `0	N` for “main has nothing we don’t have”) or merge/rebase if the user wants: `git merge origin/main`.
+- Resolve any merge conflicts before continuing.
+
+### 3. Write the PR description
+
+- Use the template from `./docs/PULL_REQUEST_TEMPLATE.md` as the base. Read it and fill in each section.
+- **Issue number from branch name:** If the branch name matches the pattern `issue-\d+` (e.g. `issue-123`), extract the number (e.g. `git branch --show-current | grep -oE 'issue-[0-9]+' | grep -oE '[0-9]+'`), then:
+  - Fetch the issue: `gh issue view <ISSUE_NUMBER>`.
+  - At the very beginning of the **"Description and Related Issue(s)"** section, include: `Resolves #<ISSUE_NUMBER>`.
+- **Summary of changes:** Summarize the changes clearly and concisely in no more than two paragraphs. Use bullet points if needed. Be precise; keep the description short.
+- **Environment variable changes:** If any env vars were added, changed, or documented:
+  - Compare or read `./docs/ENVS.md` (and the validator/ENVS docs if relevant) to list what changed.
+  - Add a separate section listing each variable change and the **purpose** of each (why it was added/changed).
+    - **Bad:** "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` environment variable to the documentation."
+    - **Good:** "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` to group transaction fees into one section on the transaction page."
+    - **Good:** "Extended possible values for `NEXT_PUBLIC_VIEWS_TX_ADDITIONAL_FIELDS` with set_max_gas_limit to display the maximum gas price set by the transaction sender."
+    - **Good:** "Introduced a new option, `"fee reception"`, for the `NEXT_PUBLIC_NETWORK_VERIFICATION_TYPE` variable."
+- **Checklist:** Keep the "Checklist for PR Author" section from the template and check the items that apply (e.g. tested locally, tests added, ENVS/docs/validator updated if env vars changed).
+- When the description is ready, **ask the user for confirmation or changes** before creating the PR (step 4).
+
+### 4. Create the PR and set labels
+
+- Create the pull request with a descriptive title. Use draft mode if the user asked for it:
+  - `gh pr create --title "Your descriptive title" --body-file /path/to/body.md` (and add `--draft` if draft).
+  - Or paste the body inline if preferred; ensure the filled template is used.
+- Add labels:
+  - If anything was added or changed in `./docs/ENVS.md`, add the **"ENVs"** label: `gh pr edit <PR_NUMBER> --add-label "ENVs"` (or add labels during `gh pr create` if your `gh` version supports it).
+  - If `package.json` has changed (check with `git diff origin/main -- package.json`), add the **"dependencies"** label.
+  - If the branch name contained an issue number (pattern `issue-\d+`), copy all labels from that issue onto the PR: get labels with `gh issue view <ISSUE_NUMBER> --json labels -q '.labels[].name'`, then add each: `gh pr edit <PR_NUMBER> --add-label "<LABEL>"`.
+- Include a clickable link to the created PR in the command output (e.g. from `gh pr view --web` or the URL printed by `gh pr create`).

.cursor/commands/get-checks-status.md

@@ -0,0 +1,59 @@
+---
+name: deploy-demo
+description: Create a GitHub deployment for the current branch using the deploy-review workflow
+disable-model-invocation: true
+---
+# Deploy demo
+
+## Prerequisites: GitHub CLI
+
+This workflow uses `gh` to trigger and monitor the deployment workflow. **Follow the check-github-cli skill** first (ensure `gh auth status` succeeds; if not, guide the user to install/configure `gh` and do not proceed). The account needs permission to trigger workflows and read the repository.
+
+## Overview
+
+Create a GitHub deployment for the current branch using `.github/workflows/deploy-review.yml` (workflow name: "Deploy review environment").
+
+## Steps
+
+_Note:_ In the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`.
+
+### 1. Ensure all changes are pushed to remote
+
+- Check status: `git status`. If there are uncommitted changes, ask the user to commit and push, or run `git add` / `git commit` and then push.
+- Push the current branch: `git push origin $(git branch --show-current)` (or `git push` if upstream is set). Abort if push fails.
+
+### 2. Check for an already running deployment for the current branch
+
+- Get current branch: `git branch --show-current`.
+- List runs for the deploy-review workflow on this branch that are in progress or queued:
+  - `gh run list --workflow=deploy-review.yml --branch <BRANCH> --status in_progress`
+  - `gh run list --workflow=deploy-review.yml --branch <BRANCH> --status queued`
+- If any run is returned, **abort the command** and tell the user a deployment is already running for this branch (include a link to the run).
+
+### 3. Resolve the "envs_preset" workflow input (optional)
+
+- **Get valid options from the workflow file (single source of truth):** Read `.github/workflows/deploy-review.yml` and extract the list of allowed values from `on.workflow_dispatch.inputs.envs_preset.options` (the YAML array under that key). Do not hardcode or copy the preset list into this skill — always read it from the file.
+- Infer from the user’s prompt which preset they want. Examples:
+  - "deploy a demo for base" or "deploy with base preset" → preset `base`
+  - "spin up a demo using main preset" → preset `main`
+- **If the user did not mention any preset:** skip passing `envs_preset` (the workflow uses its default).
+- **Validate the chosen preset:** Check that the user’s chosen preset is one of the values in the options list you extracted from the workflow file. If it is not in that list, notify the user (you can show the valid options from the file) and **abort the command**.
+
+### 4. Trigger the workflow and capture the run ID
+
+- Run the workflow from the current branch (use the branch name from step 1 or 2):
+  - Without preset: `gh workflow run deploy-review.yml --ref <BRANCH>`
+  - With preset: `gh workflow run deploy-review.yml --ref <BRANCH> -f envs_preset=<PRESET>`
+- The CLI does not print the new run ID. To get it: wait a few seconds, then list the latest run for this workflow and branch: `gh run list --workflow=deploy-review.yml --branch <BRANCH> --limit 1`. Use that run’s ID for the next steps.
+
+### 5. Monitor the workflow until it completes
+
+- Watch the run: `gh run watch <RUN_ID>` (polls until completion).
+- Track the outcome: success, failure, or cancelled (from the watch output or from `gh run view <RUN_ID>`).
+- When completed, get outputs and deployment URL: `gh run view <RUN_ID>` and, if available, `gh run view <RUN_ID> --log` or job outputs. The deployment URL may appear in the workflow summary or in job outputs; extract it and include it in the notification.
+
+### 6. Send system notifications with results
+
+- **When the workflow is triggered:** Notify the user that the deployment has been started (include a link to the run).
+- **When the workflow completes:** Notify with the final status (success, failure, or cancelled), the deployment URL if available, and any other relevant outputs.
+- **On failure:** Notify with the error and details (e.g. failed job/step from `gh run view <RUN_ID>` or `gh run view <RUN_ID> --log-failed`).