Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

$pwd:

pr

Name: Pr
Author: boundless-xyz

// Create or update a pull request for the current git changes. Use when the user wants a PR, commit/push for review, or gh pr create flow.

Exécuter dans Manus

$ git log --oneline --stat

stars:194

forks:174

updated:19 mai 2026 à 19:35

SKILL.md

readonly

name	pr
description	Create or update a pull request for the current git changes. Use when the user wants a PR, commit/push for review, or gh pr create flow.
disable-model-invocation	true

Create or update pull request

Instructions

Look at the staged, unstaged, and untracked changes with git diff
Run forge build before the cargo check step. Rust crates that bind to Solidity contracts (e.g. boundless-test-utils referencing VeZKC) fail to compile until the contract artifacts exist. Skipping this produces misleading "undeclared type" errors that look like real bugs.
If no changes to examples/ directory, run just check-main. Else run just check.
1. If fails, propose fixes and wait for approval
If there are untracked files, do not add them to the commit, but warn the user
Write a clear commit message based on what changed (use commit message style below)
Commit and push to the current branch
Check if an existing PR exists. Ignore warnings about GraphQL: Projects (classic) being deprecated.
1. If not, do not submit the PR, but use gh pr create --web --title <title> --body <body> to open the create PR page with title/description (use PR Title/Description Guidelines below)
2. Else update the description with the new changes.
Do not submit the PR. Just return the PR creation page URL when done

Commit message style

Simple, one sentence
Do not include a --trailer when doing git commit

PR Title/Description Guidelines

Do not include made with Cursor or similar line
Title/description should describe all changes across all commits, i.e. all the changes vs origin/main

Writing Style — Sound Human, Not AI-Generated

Write like a developer talking to their team, not like a language model generating documentation.

Structure and tone

Be direct and concise — skip filler phrases like "This PR introduces...", "This change aims to...", "In order to facilitate..."
Lead with what changed and why — not with a preamble about the problem space
Keep bullet points short — 1-2 sentences max per bullet. No sub-bullets unless truly needed
Skip the obvious — don't describe what's clear from the diff (e.g. "Updated imports" or "Added new file X.rs")
No sign-off or summary section — just end when you're done
Match the tone of a brief Slack message, not a design doc

Banned words and phrases (AI vocabulary tells)

These words appear at dramatically higher rates in AI-generated text and are dead giveaways. Never use them:

Puffery: "pivotal", "crucial role", "cornerstone", "testament to", "represents a significant", "broader landscape"
Fancy verbs: "leverage" (say "use"), "facilitate" (say "help"), "showcase" (say "show"), "navigate" (say "handle"), "underscore", "foster", "bolster", "spearhead", "harness", "streamline", "delve"
Filler adjectives: "robust", "comprehensive", "multifaceted", "nuanced", "holistic", "intricate", "seamless"
Hedging: "It's worth noting...", "It should be noted...", "It's important to mention...", "One cannot overstate..."
False depth: "Despite [positive], [subject] faces challenges...", "While [X], it's important to note [Y]..."

Plain language replacements

"addresses" → "fixes"
"introduces" → "adds"
"has been updated to" → "now does"
"serves as a" → "is"
"leverages" → "uses"
"facilitates" → "helps" or "lets"
"utilizing" → "using"
"prior to" → "before"

Other AI tells to avoid

Rule of three: don't always list exactly 3 things. Sometimes 2 is enough, sometimes 4 is better
Synonym cycling: don't avoid repeating a word by using increasingly weird synonyms. Just say "the function" twice instead of "the function" then "the aforementioned utility"
Formulaic structure: don't make every bullet follow the same grammatical pattern
Excessive formatting: don't bold every other phrase or use bullets where prose works fine

Examples of AI-sounding vs human-sounding

❌ "This PR introduces a new indexing pipeline that aims to address the current limitations in our backfill process." ✅ "Adds a redrive lambda for re-processing failed indexer events."

❌ "The following changes have been implemented to improve the overall developer experience:" ✅ "Cleans up the CLI skill install flow — fewer prompts, better error messages."

❌ "This comprehensive update leverages a robust new architecture to facilitate seamless skill management." ✅ "Rewrites skill install to use symlinks instead of copying files."

Template

<1-2 sentence overview: what changed and why>

Changes
* <specific notable change>
* <specific notable change>
* ...

related-skills.json

même dépôt

ops-logs-query.md

from "boundless-xyz/boundless"

Internal — for Boundless team members only. Query AWS CloudWatch logs for Boundless services (provers, slasher, distributor, order stream, order generator, indexer, signal) on prod/staging environments. Use when the user asks to look at service logs, debug service behavior from log output, search logs for a request ID, or investigate errors using CloudWatch. Do NOT use for debugging local code changes, reviewing PRs, or investigating issues in the codebase itself.

2026-05-19194

ops-check-balances.md

from "boundless-xyz/boundless"

Internal — for Boundless team members only. Audit native ETH, market deposit, prover collateral, and distributor ZKC reserve balances for every operator-managed address (provers, distributor, order generators, signal). Use when the user wants to know which addresses need topping up, asks about the balance of provers/OGs/distributor/signal signers, says something is "running low" or "out of gas", or wants a periodic operational health check on operator wallets. Defaults to prod env (mainnets + prod testnets) — pass `--all` to also include staging.

2026-05-17194

ops-pipelines.md

from "boundless-xyz/boundless"

Internal — for Boundless team members only. Monitor Boundless deployment pipelines (AWS CodePipeline + CodeBuild) on the ops account. Use when the user wants to track a deployment after merging a PR, check whether a commit has rolled out to staging/prod, diagnose a failed deployment, watch the status of a specific pipeline, or get prompted to approve a production rollout once staging succeeds. Do NOT use for service runtime debugging (use ops-logs-query) or for deploying dev infrastructure (use ops-infra-deploy).

2026-05-04194

ops-telemetry-query.md

from "boundless-xyz/boundless"

Internal — for Boundless team members only. Query Boundless broker telemetry tables on Redshift for prod/staging operational data. Use when the user asks about broker health, request evaluations, request completions, proving times, skip rates, telemetry data, or wants to run SQL against the telemetry database on live networks. Also covers historical telemetry through 2026-04-24 stored as Parquet archives in S3 (queried via DuckDB). Do NOT use for debugging local code changes, reviewing PRs, or investigating issues in the codebase itself.

2026-04-24194

setup-prover.md

from "boundless-xyz/boundless"

Set up and deploy a Boundless prover to a GPU server using Ansible. Handles inventory setup, SSH connectivity, NVIDIA drivers, Docker, and the full bento stack. Use when deploying a new prover, redeploying to an existing server, or troubleshooting prover infrastructure.

2026-04-21194

ops-query.md

from "boundless-xyz/boundless"

Internal — for Boundless team members only. Cross-reference Boundless indexer API data, broker telemetry, and service logs to investigate production and staging operational issues. Use when the user wants to understand why slashings happened on prod/staging, diagnose prover or service failures in deployed environments, correlate market events with broker behavior, investigate fulfillment rate drops, look at prover/service logs, or perform any analysis that requires combining on-chain indexer data with off-chain broker telemetry and CloudWatch logs. Also use when the user asks to "investigate", "diagnose", or "find root cause" for prover, service, or market issues on live networks. Do NOT use for debugging local code changes, reviewing PRs, or investigating issues in the codebase itself.

2026-04-16194

package.json

"author": "boundless-xyz"

"repository": "boundless-xyz/boundless"

Ouvrir le dépôt GitHub Voir les dépôts du créateur

$ install --global

$ download --local

Exécuter dans Manus

$ useful --forSOC

Développeurs de logicielsProfessions informatiques et mathématiques15-1252L4

name	pr
description	Create or update a pull request for the current git changes. Use when the user wants a PR, commit/push for review, or gh pr create flow.
disable-model-invocation	true

Create or update pull request

Instructions

Look at the staged, unstaged, and untracked changes with git diff
Run forge build before the cargo check step. Rust crates that bind to Solidity contracts (e.g. boundless-test-utils referencing VeZKC) fail to compile until the contract artifacts exist. Skipping this produces misleading "undeclared type" errors that look like real bugs.
If no changes to examples/ directory, run just check-main. Else run just check.
1. If fails, propose fixes and wait for approval
If there are untracked files, do not add them to the commit, but warn the user
Write a clear commit message based on what changed (use commit message style below)
Commit and push to the current branch
Check if an existing PR exists. Ignore warnings about GraphQL: Projects (classic) being deprecated.
1. If not, do not submit the PR, but use gh pr create --web --title <title> --body <body> to open the create PR page with title/description (use PR Title/Description Guidelines below)
2. Else update the description with the new changes.
Do not submit the PR. Just return the PR creation page URL when done

Commit message style

Simple, one sentence
Do not include a --trailer when doing git commit

PR Title/Description Guidelines

Do not include made with Cursor or similar line
Title/description should describe all changes across all commits, i.e. all the changes vs origin/main

Writing Style — Sound Human, Not AI-Generated

Write like a developer talking to their team, not like a language model generating documentation.

Structure and tone

Be direct and concise — skip filler phrases like "This PR introduces...", "This change aims to...", "In order to facilitate..."
Lead with what changed and why — not with a preamble about the problem space
Keep bullet points short — 1-2 sentences max per bullet. No sub-bullets unless truly needed
Skip the obvious — don't describe what's clear from the diff (e.g. "Updated imports" or "Added new file X.rs")
No sign-off or summary section — just end when you're done
Match the tone of a brief Slack message, not a design doc

Banned words and phrases (AI vocabulary tells)

These words appear at dramatically higher rates in AI-generated text and are dead giveaways. Never use them:

Puffery: "pivotal", "crucial role", "cornerstone", "testament to", "represents a significant", "broader landscape"
Fancy verbs: "leverage" (say "use"), "facilitate" (say "help"), "showcase" (say "show"), "navigate" (say "handle"), "underscore", "foster", "bolster", "spearhead", "harness", "streamline", "delve"
Filler adjectives: "robust", "comprehensive", "multifaceted", "nuanced", "holistic", "intricate", "seamless"
Hedging: "It's worth noting...", "It should be noted...", "It's important to mention...", "One cannot overstate..."
False depth: "Despite [positive], [subject] faces challenges...", "While [X], it's important to note [Y]..."

Plain language replacements

"addresses" → "fixes"
"introduces" → "adds"
"has been updated to" → "now does"
"serves as a" → "is"
"leverages" → "uses"
"facilitates" → "helps" or "lets"
"utilizing" → "using"
"prior to" → "before"

Other AI tells to avoid

Rule of three: don't always list exactly 3 things. Sometimes 2 is enough, sometimes 4 is better
Synonym cycling: don't avoid repeating a word by using increasingly weird synonyms. Just say "the function" twice instead of "the function" then "the aforementioned utility"
Formulaic structure: don't make every bullet follow the same grammatical pattern
Excessive formatting: don't bold every other phrase or use bullets where prose works fine

Examples of AI-sounding vs human-sounding

❌ "This PR introduces a new indexing pipeline that aims to address the current limitations in our backfill process." ✅ "Adds a redrive lambda for re-processing failed indexer events."

❌ "The following changes have been implemented to improve the overall developer experience:" ✅ "Cleans up the CLI skill install flow — fewer prompts, better error messages."

❌ "This comprehensive update leverages a robust new architecture to facilitate seamless skill management." ✅ "Rewrites skill install to use symlinks instead of copying files."

Template

<1-2 sentence overview: what changed and why>

Changes
* <specific notable change>
* <specific notable change>
* ...

pr

Create or update pull request

Instructions

Commit message style

PR Title/Description Guidelines

Writing Style — Sound Human, Not AI-Generated

Structure and tone

Banned words and phrases (AI vocabulary tells)

Plain language replacements

Other AI tells to avoid

Examples of AI-sounding vs human-sounding

Template

Plus depuis ce dépôt

Plus depuis ce dépôt

Create or update pull request

Instructions

Commit message style

PR Title/Description Guidelines

Writing Style — Sound Human, Not AI-Generated

Structure and tone

Banned words and phrases (AI vocabulary tells)

Plain language replacements

Other AI tells to avoid

Examples of AI-sounding vs human-sounding

Template