{"owner":"rust-lang","repo":"rust","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":4833,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"rust":{"command":"npx","args":["-y","@modelcontextprotocol/server-rust"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (rust.mdc)"],"skills":{"AGENTS.md":"# Agent instructions\n\n## LLM usage policy\n\nFollow the Rust project's [LLM usage policy]. It applies to all LLM-generated\ntext even if a human later edits it.\n\n[LLM usage policy]: https://forge.rust-lang.org/policies/llm-usage.html\n\n### When a gate fails\n\nWhen a rule identifies banned work, **STOP** that work. A named reviewer, tests,\nuser confirmation, or later human editing cannot permit it. Do not ask for\nprerequisites, promise to proceed later, or offer the work under another name,\nsuch as a draft, template, or paste-ready outline. A rule may explicitly permit\nnarrower preliminary work; Soundness requires test-only work before stopping.\n\nState why the work is banned and give the route required by the triggering rule.\nReading, explaining, summarizing, reviewing, and suggesting possible solutions\nfor the user to implement from scratch remain allowed if independently requested.\nAlongside any text that could potentially be used as a substitute for prohibited text, include *in the same response turn* a reminder of the policies against text originally created by an LLM, even if given during a previous turn of the session. Do not proactively continue test planning or patch design, or produce paste-ready\nprohibited text, unless the triggering rule requires test-only work.\n\n### Personal use exemption\n\nThe [policy permits][allowed use] any LLM use where the user is the only one who\nsees the output. If the user states, in this conversation, that a change is for\npersonal use, prototyping, or experimentation with no intent to upstream the\nchange, then any gates that would prevent the change no longer apply.\nDo not infer this; a statement from the user is required.\n\nBefore the first edit under this exemption, state once that the resulting code,\ncomments, and documentation are LLM-generated and cannot later be contributed\nwithout arranging with a reviewer, and cite the gate(s) that prohibit this.\n\nIf the user later asks to push, open a pull request, or otherwise share work\nmade under this exemption, STOP and follow the gate-failure protocol.\nExplaining your edits and findings to the user to help them contribute\nappropriately is encouraged.\n\n[allowed use]: https://forge.rust-lang.org/policies/llm-usage.html#-allowed\n\n### Before any edit\n\nApply these gates in order before editing the repository, including tests:\n\n1. [External repositories](#external-repositories): route externally maintained\n   source to its owning repository.\n2. [Prohibited text](#prohibited-text): stop if the change requires the agent to\n   author prohibited text.\n3. [Reviewer](#reviewer): require a named reviewer unless the change qualifies\n   for the local-development exception.\n\nIf investigation reveals a new output category or owner, reapply the relevant\ngate before the next edit. For a mechanical rewrite, follow\n[Mechanical rewrites](#mechanical-rewrites) before the first mutation.\n\n### External repositories\n\nBefore modifying a subtree, submodule, or `src/tools` code, identify its owner\nusing [`CONTRIBUTING.md`](CONTRIBUTING.md#making-changes-to-subtrees-and-submodules)\nand the [external repositories] guide. Treat Cargo, Clippy, rustfmt, Miri,\nrust-analyzer, and other externally maintained tools as ownership checks before\nimplementation. If the user says the bug or change is in one of these tools,\ndo not investigate or ask for a reviewer here; route the user to its repository.\nEditing externally maintained source in this checkout is banned; follow the\n[gate-failure protocol]. Only update its integration pointer when explicitly\nrequested.\nFor example, if the user says a bug is in Cargo itself, route the user to\n`rust-lang/cargo` immediately; do not request a reviewer for this checkout.\n\n[external repositories]: src/doc/rustc-dev-guide/src/external-repos.md\n[gate-failure protocol]: #when-a-gate-fails\n\n### Prohibited text\n\nNever generate or rewrite non-trivial PR descriptions, issue bodies, public\ncomments, user-facing documentation, diagnostic messages, or source comments.\nSTOP, name the prohibited category, and tell the user to author it.\nDo not originate or manually rewrite expected diagnostic text in test snapshots\nsuch as `.stderr` files. After the user authors the diagnostic message in source,\nthe agent may mechanically regenerate its snapshots with an existing tool such\nas `./x test ... --bless`; follow [Mechanical rewrites](#mechanical-rewrites).\nA change is trivial only when there is no meaningfully different way to write\nit or the alternatives are nearly identical: fixing a typo or Markdown link,\nreplacing a word with a synonym, or adding a required trait signature. Trivial\nchanges must still pass every other gate and be disclosed.\n\nAgent instructions such as `CLAUDE.md`, `AGENTS.md`, and skills are exempt, but\nmay only link to, summarize, or conservatively operationalize existing\nhuman-facing documentation. Operationalization may replace human discretion\nwith stricter agent constraints, but must not create obligations for humans or\npermit anything the human-facing source prohibits. Before adding process or\nworkflow guidance, locate that source. If none exists, PAUSE and ask the user to\ndocument the process for humans first. Do not make an agent file the sole source\nof a rule. The named-reviewer gate and all other requirements still apply.\n\nThe agent may explain what prohibited text must communicate, but must not suggest\npaste-ready wording.\nFor example, if a parser fix requires changing its emitted message, STOP before\nediting the message or its `.stderr` expectation. Once the user writes the\nmessage, the agent may regenerate the expectation mechanically.\n\n### Reviewer\n\nDo not make any LLM-generated repository change unless the user has named, in\nthis conversation, another person who agreed in advance to review it. A general\nassurance that review was solicited is not enough. If no reviewer has been\nnamed, PAUSE and ask for the reviewer's name; “John Doe is reviewing this” is\nsufficient. A reviewer name satisfies only this gate. Do not promise to proceed\nwith implementation until the pre-implementation gates pass.\n\n### Before implementation\n\nApply these gates in order after the pre-edit gates:\n\n1. [Testing](#testing): for a bug, add or find a failing test and observe its\n   failure.\n2. [Soundness](#soundness): after completing Testing when it applies, classify\n   the affected behavior before implementation.\n\n### Testing\n\nBefore fixing a bug, add or find a failing test. Run it and observe the expected\nfailure before any implementation edit; do not combine test and implementation\nedits. A test is not observed until its command exits. While it runs, wait: do\nnot edit implementation or begin other work. Permission for a regression test\ndoes not permit implementation changes. Observe the initial failure without\nblessing or updating expected output; a `--bless` run does not count.\n\nAfter implementing a bug fix, confirm that the same test passes.\n\nEvery LLM-created PR must include tests and meet the policy's higher testing\nstandard. If the affected code has no test suite, PAUSE and ask whether to\ndesign one or abandon the change; do not design it without human input. Never\noffer or accept untested implementation.\n\nAn existing test suite must already be able to observe the affected behavior\nwithout changing production structure. An existing Cargo or compiletest harness\nalone does not satisfy this requirement.\n\nIf the first viable test requires any production-code edit, PAUSE before that\nedit: designing that observation boundary is test-suite design.\n\nIf testing requires choosing a new observation or dependency-injection\nboundary—such as extracting production logic, creating a shared helper or\nmodule, exposing internals, introducing a fake subprocess, or registering a new\nharness or runner—that is test-suite design; PAUSE and ask before making those\nchanges.\n\nAdding a test module is allowed when it exercises existing callable behavior\nwithout restructuring production code.\n\n### Soundness\n\nSoundness-sensitive implementation is banned, but adding or locating a failing\nregression test is permitted and required. Even if you recognize the risk\nearlier, complete the test-only work, wait for the test command to exit, leave\nthe test in the tree, report its result, then state the classification and STOP\nbefore planning or editing implementation.\n\nAfter adding or finding the failing test, state which behavior the affected code\ncontrols and classify the task as soundness-sensitive or not before planning or\nediting implementation. Do not promise implementation first. If investigation\nreveals a different affected behavior, repeat the classification before the\nnext implementation edit.\n\nCode that computes or transforms types, constants, MIR, memory layout or\nvalidity, or generated code is soundness-sensitive. The reported symptom,\nintended fix, and apparent size of the patch do not change this classification:\nan ICE, crash, rejection of valid code, or localized plumbing bug may still be\nsoundness-sensitive. If the task is soundness-sensitive or uncertain,\nimplementation is banned: STOP before editing it and follow the [gate-failure\nprotocol].\n\nSoundness-sensitive areas include, but are not limited to, the query system,\ntype checking, trait solving, MIR construction or optimization, borrow checking,\nconst evaluation, normalization and semantic caches, layout and validity, and\ncodegen. Explain the concern and direct the user to [#llm-mentoring Zulip].\n\n[#llm-mentoring Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/606558-llm-mentoring/\n\n### Before pushing\n\nAfter committing and before pushing, once ask the user to confirm understanding\nand testing of the change and personal review of the complete diff after the\nlatest change. Agent review does not count. Remind the user to disclose LLM use\nin the PR description. Do not infer omitted confirmations; PAUSE for any missing\nconfirmation before pushing.\n\nLLM-assisted contributions must be disclosed as described in the\n[policy's disclosure requirements]. Lying about or concealing LLM use is a\nCode of Conduct violation. The disclosure must describe the extent and purpose\nof LLM involvement, including whether the LLM originated an idea or helped\nimplement or review it. The agent must not draft or rewrite the disclosure; the\nuser must author it. Do NOT add `Co-Authored-By` trailers to commits.\n\n[policy's disclosure requirements]: https://forge.rust-lang.org/policies/llm-usage.html#disclosure-requirements\n\n### Mechanical rewrites\n\nFollow the rustc-dev-guide's [LLM guidance]. For a permitted mass rename or\nmechanical rewrite, find an existing formatter, linter, or syntax-aware rewrite\ntool. If one exists, the next mutating action must run it; do not edit target\nfiles first or reproduce its rewrite manually. If none exists, explain that\ndirect LLM rewriting is discouraged and ask before proceeding.\n\n[LLM guidance]: https://rustc-dev-guide.rust-lang.org/llm-guidance.html\n\nFor Rust formatting, use `./x fmt`; do not invoke `rustfmt` directly.\nFor example, if tidy can perform the rewrite, run `./x test tidy --bless` instead\nof reproducing its edits manually.\n\nBefore regenerating snapshots containing human-facing text:\n\n1. Confirm the user already authored the new prose in source.\n2. Run the focused test without `--bless` and observe the expected mismatch.\n3. Run the repository's existing `--bless` command.\n4. Inspect the generated diff. Do not manually repair or add prose; if the tool\n   produced unexpected human-facing text, STOP and report it to the user.\n\nIf a request conflicts with these rules, direct the user to the\n[#llm-mentoring Zulip] for help.\n\n## Repository guidance\n\nThis is the main `rust-lang/rust` repository.\nStart with [`CONTRIBUTING.md`](CONTRIBUTING.md) and the [dev-guide's instructions for LLMs][llm-writing], then route specialized work as follows:\n\n[llm-writing]: https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html\n\n- Standard library: [std-dev-guide]\n- Compiler: [rustc-dev-guide]\n- Build or run rustc: [building and running rustc]\n- Tests: [running tests], [adding tests], and [compiletest directives]\n- Formatting or tidy: [formatting and tidy]\n- Architecture or layout: [compiler architecture] and [repository layout]\n- Subtrees, submodules, or tools: [external repositories]\n- Pull requests and review: [contribution process]\n\n[rustc-dev-guide]: src/doc/rustc-dev-guide/\n[std-dev-guide]: https://std-dev-guide.rust-lang.org/\n[building and running rustc]: src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md\n[running tests]: src/doc/rustc-dev-guide/src/tests/running.md\n[adding tests]: src/doc/rustc-dev-guide/src/tests/adding.md\n[compiletest directives]: src/doc/rustc-dev-guide/src/tests/directives.md\n[formatting and tidy]: src/doc/rustc-dev-guide/src/conventions.md#formatting\n[compiler architecture]: src/doc/rustc-dev-guide/src/overview.md\n[repository layout]: src/doc/rustc-dev-guide/src/compiler-src.md\n[contribution process]: src/doc/rustc-dev-guide/src/contributing.md\n\n[`x.py` is the build tool for this repository][building and running rustc].\nInvoke it as `./x`, the default entry point for builds, tests, and formatting.\nDo not invoke Cargo directly unless the relevant in-tree documentation\nexplicitly requires it.\n\nFor source comments the policy permits an agent to write, explain why the code\nor decision exists rather than restating what the code does.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/plugin.json)",".cursorrules (rust.mdc)":"# Rust + Solana (Anchor) Best Practices\n\n## Program Structure\n- Structure Solana programs using `Anchor` framework standards\n- Place program entrypoint logic in `lib.rs`, not `main.rs`\n- Organize handlers into modules (e.g., `initialize`, `update`, `close`)\n- Separate state definitions, errors, instructions, and utils\n- Group reusable logic under a `utils` module (e.g., account validation)\n- Use `declare_id!()` to define program ID\n\n## Anchor Framework\n- Use `#[derive(Accounts)]` for all instruction contexts\n- Validate accounts strictly using constraint macros (e.g., `#[account(mut)]`, `seeds`, `bump]`)\n- Define all state structs with `#[account]` and `#[derive(AnchorSerialize, AnchorDeserialize)]`\n- Prefer `Init`, `Close`, `Realloc`, `Mut`, and constraint macros to avoid manual deserialization\n- Use `ctx.accounts` to access validated context accounts\n- Handle CPI (Cross-Program Invocation) calls via Anchor’s CPI helpers\n\n## Serialization\n- Use **Borsh** or Anchor's custom serializer (not Serde) for on-chain data\n- Always include `#[account(zero_copy)]` or `#[repr(C)]` for packed structures\n- Avoid floating point types — use `u64`, `u128`, or fixed-point math\n- Zero out or close unused accounts to reduce rent costs\n\n## Testing\n- Write tests in TypeScript using Anchor’s Mocha + Chai setup (`tests/*.ts`)\n- Use `anchor.workspace.MyProgram` to load deployed contracts\n- Use `provider.simulate()` to inspect failed txs\n- Spin up a local validator (`anchor test`) and reset between tests\n- Airdrop SOL to wallets with `provider.connection.requestAirdrop(...)`\n- Validate program logs using `tx.confirmation.logMessages`\n\n## Solana SDK (Manual)\n- Use `solana_program` crate when not using Anchor (bare-metal programs)\n- Carefully deserialize accounts using `AccountInfo`, `try_from_slice_unchecked`\n- Use `solana_program::msg!` for lightweight debugging logs\n- Verify accounts via `is_signer`, `is_writable`, `key == expected`\n- Never panic! Use `ProgramError::Custom(u32)` or `ErrorCode` enums\n\n## Security Patterns\n- Always validate `msg.sender`/signer with `account_info.is_signer`\n- Prevent replay attacks via `seeds`, `bump`, and unique PDAs\n- Use strict size checks before reallocating or deserializing\n- Avoid unsafe unchecked casting; prefer Anchor deserialization\n- For CPIs, validate `target_program` against expected program ID\n- When using randomness, never rely on timestamps — use oracles or off-chain VRFs\n\n## Performance\n- Prefer zero-copy deserialization when accounts are large\n- Minimize compute usage; avoid loops and recursion\n- Avoid memory reallocations mid-instruction\n- Use `#[account(zero_copy)]` and `#[repr(packed)]` for tight layout\n- Profile compute units with `solana logs` and `anchor run`\n\n## Dev Workflow\n- Use `anchor init` to scaffold projects\n- Add Anchor IDL support for front-end usage (JSON ABI)\n- Use `anchor build`, `anchor deploy`, `anchor test` consistently\n- Use separate `Anchor.toml` environments for devnet/mainnet/localnet\n- Format all Rust code with `cargo fmt`, lint with `cargo clippy`\n- Keep `Cargo.lock` checked into `programs/` but not root\n\n## Documentation\n- Use `///` Rust doc comments for all instructions and accounts\n- Include doc examples for each instruction\n- Document PDA derivation logic and bump seed expectations\n- Maintain up-to-date `README.md` with test commands and deployment steps\n\n## Wallet & Network Handling\n- Use `anchorProvider.wallet.publicKey` for signer verification in tests\n- Do not hardcode keypairs — use env-based loading (`process.env.ANCHOR_WALLET`)\n- Deploy with clear `cluster` targets (`localnet`, `devnet`, `mainnet`)\n- Use `anchor keys sync` to propagate program ID changes\n- Commit `target/idl/` and `target/types/` to share with front end\n\n## CI/CD & Deploy\n- Use GitHub Actions with `solana-cli`, `anchor-cli`, and `node` installed\n- Run `anchor test` in CI for every PR\n- Use `solana program deploy` with explicit `--program-id` on production deploys\n- Upload IDLs to a central registry (e.g., GitHub, IPFS, or `anchor.cloud`)"},"files":{"AGENTS.md":"# Agent instructions\n\n## LLM usage policy\n\nFollow the Rust project's [LLM usage policy]. It applies to all LLM-generated\ntext even if a human later edits it.\n\n[LLM usage policy]: https://forge.rust-lang.org/policies/llm-usage.html\n\n### When a gate fails\n\nWhen a rule identifies banned work, **STOP** that work. A named reviewer, tests,\nuser confirmation, or later human editing cannot permit it. Do not ask for\nprerequisites, promise to proceed later, or offer the work under another name,\nsuch as a draft, template, or paste-ready outline. A rule may explicitly permit\nnarrower preliminary work; Soundness requires test-only work before stopping.\n\nState why the work is banned and give the route required by the triggering rule.\nReading, explaining, summarizing, reviewing, and suggesting possible solutions\nfor the user to implement from scratch remain allowed if independently requested.\nAlongside any text that could potentially be used as a substitute for prohibited text, include *in the same response turn* a reminder of the policies against text originally created by an LLM, even if given during a previous turn of the session. Do not proactively continue test planning or patch design, or produce paste-ready\nprohibited text, unless the triggering rule requires test-only work.\n\n### Personal use exemption\n\nThe [policy permits][allowed use] any LLM use where the user is the only one who\nsees the output. If the user states, in this conversation, that a change is for\npersonal use, prototyping, or experimentation with no intent to upstream the\nchange, then any gates that would prevent the change no longer apply.\nDo not infer this; a statement from the user is required.\n\nBefore the first edit under this exemption, state once that the resulting code,\ncomments, and documentation are LLM-generated and cannot later be contributed\nwithout arranging with a reviewer, and cite the gate(s) that prohibit this.\n\nIf the user later asks to push, open a pull request, or otherwise share work\nmade under this exemption, STOP and follow the gate-failure protocol.\nExplaining your edits and findings to the user to help them contribute\nappropriately is encouraged.\n\n[allowed use]: https://forge.rust-lang.org/policies/llm-usage.html#-allowed\n\n### Before any edit\n\nApply these gates in order before editing the repository, including tests:\n\n1. [External repositories](#external-repositories): route externally maintained\n   source to its owning repository.\n2. [Prohibited text](#prohibited-text): stop if the change requires the agent to\n   author prohibited text.\n3. [Reviewer](#reviewer): require a named reviewer unless the change qualifies\n   for the local-development exception.\n\nIf investigation reveals a new output category or owner, reapply the relevant\ngate before the next edit. For a mechanical rewrite, follow\n[Mechanical rewrites](#mechanical-rewrites) before the first mutation.\n\n### External repositories\n\nBefore modifying a subtree, submodule, or `src/tools` code, identify its owner\nusing [`CONTRIBUTING.md`](CONTRIBUTING.md#making-changes-to-subtrees-and-submodules)\nand the [external repositories] guide. Treat Cargo, Clippy, rustfmt, Miri,\nrust-analyzer, and other externally maintained tools as ownership checks before\nimplementation. If the user says the bug or change is in one of these tools,\ndo not investigate or ask for a reviewer here; route the user to its repository.\nEditing externally maintained source in this checkout is banned; follow the\n[gate-failure protocol]. Only update its integration pointer when explicitly\nrequested.\nFor example, if the user says a bug is in Cargo itself, route the user to\n`rust-lang/cargo` immediately; do not request a reviewer for this checkout.\n\n[external repositories]: src/doc/rustc-dev-guide/src/external-repos.md\n[gate-failure protocol]: #when-a-gate-fails\n\n### Prohibited text\n\nNever generate or rewrite non-trivial PR descriptions, issue bodies, public\ncomments, user-facing documentation, diagnostic messages, or source comments.\nSTOP, name the prohibited category, and tell the user to author it.\nDo not originate or manually rewrite expected diagnostic text in test snapshots\nsuch as `.stderr` files. After the user authors the diagnostic message in source,\nthe agent may mechanically regenerate its snapshots with an existing tool such\nas `./x test ... --bless`; follow [Mechanical rewrites](#mechanical-rewrites).\nA change is trivial only when there is no meaningfully different way to write\nit or the alternatives are nearly identical: fixing a typo or Markdown link,\nreplacing a word with a synonym, or adding a required trait signature. Trivial\nchanges must still pass every other gate and be disclosed.\n\nAgent instructions such as `CLAUDE.md`, `AGENTS.md`, and skills are exempt, but\nmay only link to, summarize, or conservatively operationalize existing\nhuman-facing documentation. Operationalization may replace human discretion\nwith stricter agent constraints, but must not create obligations for humans or\npermit anything the human-facing source prohibits. Before adding process or\nworkflow guidance, locate that source. If none exists, PAUSE and ask the user to\ndocument the process for humans first. Do not make an agent file the sole source\nof a rule. The named-reviewer gate and all other requirements still apply.\n\nThe agent may explain what prohibited text must communicate, but must not suggest\npaste-ready wording.\nFor example, if a parser fix requires changing its emitted message, STOP before\nediting the message or its `.stderr` expectation. Once the user writes the\nmessage, the agent may regenerate the expectation mechanically.\n\n### Reviewer\n\nDo not make any LLM-generated repository change unless the user has named, in\nthis conversation, another person who agreed in advance to review it. A general\nassurance that review was solicited is not enough. If no reviewer has been\nnamed, PAUSE and ask for the reviewer's name; “John Doe is reviewing this” is\nsufficient. A reviewer name satisfies only this gate. Do not promise to proceed\nwith implementation until the pre-implementation gates pass.\n\n### Before implementation\n\nApply these gates in order after the pre-edit gates:\n\n1. [Testing](#testing): for a bug, add or find a failing test and observe its\n   failure.\n2. [Soundness](#soundness): after completing Testing when it applies, classify\n   the affected behavior before implementation.\n\n### Testing\n\nBefore fixing a bug, add or find a failing test. Run it and observe the expected\nfailure before any implementation edit; do not combine test and implementation\nedits. A test is not observed until its command exits. While it runs, wait: do\nnot edit implementation or begin other work. Permission for a regression test\ndoes not permit implementation changes. Observe the initial failure without\nblessing or updating expected output; a `--bless` run does not count.\n\nAfter implementing a bug fix, confirm that the same test passes.\n\nEvery LLM-created PR must include tests and meet the policy's higher testing\nstandard. If the affected code has no test suite, PAUSE and ask whether to\ndesign one or abandon the change; do not design it without human input. Never\noffer or accept untested implementation.\n\nAn existing test suite must already be able to observe the affected behavior\nwithout changing production structure. An existing Cargo or compiletest harness\nalone does not satisfy this requirement.\n\nIf the first viable test requires any production-code edit, PAUSE before that\nedit: designing that observation boundary is test-suite design.\n\nIf testing requires choosing a new observation or dependency-injection\nboundary—such as extracting production logic, creating a shared helper or\nmodule, exposing internals, introducing a fake subprocess, or registering a new\nharness or runner—that is test-suite design; PAUSE and ask before making those\nchanges.\n\nAdding a test module is allowed when it exercises existing callable behavior\nwithout restructuring production code.\n\n### Soundness\n\nSoundness-sensitive implementation is banned, but adding or locating a failing\nregression test is permitted and required. Even if you recognize the risk\nearlier, complete the test-only work, wait for the test command to exit, leave\nthe test in the tree, report its result, then state the classification and STOP\nbefore planning or editing implementation.\n\nAfter adding or finding the failing test, state which behavior the affected code\ncontrols and classify the task as soundness-sensitive or not before planning or\nediting implementation. Do not promise implementation first. If investigation\nreveals a different affected behavior, repeat the classification before the\nnext implementation edit.\n\nCode that computes or transforms types, constants, MIR, memory layout or\nvalidity, or generated code is soundness-sensitive. The reported symptom,\nintended fix, and apparent size of the patch do not change this classification:\nan ICE, crash, rejection of valid code, or localized plumbing bug may still be\nsoundness-sensitive. If the task is soundness-sensitive or uncertain,\nimplementation is banned: STOP before editing it and follow the [gate-failure\nprotocol].\n\nSoundness-sensitive areas include, but are not limited to, the query system,\ntype checking, trait solving, MIR construction or optimization, borrow checking,\nconst evaluation, normalization and semantic caches, layout and validity, and\ncodegen. Explain the concern and direct the user to [#llm-mentoring Zulip].\n\n[#llm-mentoring Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/606558-llm-mentoring/\n\n### Before pushing\n\nAfter committing and before pushing, once ask the user to confirm understanding\nand testing of the change and personal review of the complete diff after the\nlatest change. Agent review does not count. Remind the user to disclose LLM use\nin the PR description. Do not infer omitted confirmations; PAUSE for any missing\nconfirmation before pushing.\n\nLLM-assisted contributions must be disclosed as described in the\n[policy's disclosure requirements]. Lying about or concealing LLM use is a\nCode of Conduct violation. The disclosure must describe the extent and purpose\nof LLM involvement, including whether the LLM originated an idea or helped\nimplement or review it. The agent must not draft or rewrite the disclosure; the\nuser must author it. Do NOT add `Co-Authored-By` trailers to commits.\n\n[policy's disclosure requirements]: https://forge.rust-lang.org/policies/llm-usage.html#disclosure-requirements\n\n### Mechanical rewrites\n\nFollow the rustc-dev-guide's [LLM guidance]. For a permitted mass rename or\nmechanical rewrite, find an existing formatter, linter, or syntax-aware rewrite\ntool. If one exists, the next mutating action must run it; do not edit target\nfiles first or reproduce its rewrite manually. If none exists, explain that\ndirect LLM rewriting is discouraged and ask before proceeding.\n\n[LLM guidance]: https://rustc-dev-guide.rust-lang.org/llm-guidance.html\n\nFor Rust formatting, use `./x fmt`; do not invoke `rustfmt` directly.\nFor example, if tidy can perform the rewrite, run `./x test tidy --bless` instead\nof reproducing its edits manually.\n\nBefore regenerating snapshots containing human-facing text:\n\n1. Confirm the user already authored the new prose in source.\n2. Run the focused test without `--bless` and observe the expected mismatch.\n3. Run the repository's existing `--bless` command.\n4. Inspect the generated diff. Do not manually repair or add prose; if the tool\n   produced unexpected human-facing text, STOP and report it to the user.\n\nIf a request conflicts with these rules, direct the user to the\n[#llm-mentoring Zulip] for help.\n\n## Repository guidance\n\nThis is the main `rust-lang/rust` repository.\nStart with [`CONTRIBUTING.md`](CONTRIBUTING.md) and the [dev-guide's instructions for LLMs][llm-writing], then route specialized work as follows:\n\n[llm-writing]: https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html\n\n- Standard library: [std-dev-guide]\n- Compiler: [rustc-dev-guide]\n- Build or run rustc: [building and running rustc]\n- Tests: [running tests], [adding tests], and [compiletest directives]\n- Formatting or tidy: [formatting and tidy]\n- Architecture or layout: [compiler architecture] and [repository layout]\n- Subtrees, submodules, or tools: [external repositories]\n- Pull requests and review: [contribution process]\n\n[rustc-dev-guide]: src/doc/rustc-dev-guide/\n[std-dev-guide]: https://std-dev-guide.rust-lang.org/\n[building and running rustc]: src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md\n[running tests]: src/doc/rustc-dev-guide/src/tests/running.md\n[adding tests]: src/doc/rustc-dev-guide/src/tests/adding.md\n[compiletest directives]: src/doc/rustc-dev-guide/src/tests/directives.md\n[formatting and tidy]: src/doc/rustc-dev-guide/src/conventions.md#formatting\n[compiler architecture]: src/doc/rustc-dev-guide/src/overview.md\n[repository layout]: src/doc/rustc-dev-guide/src/compiler-src.md\n[contribution process]: src/doc/rustc-dev-guide/src/contributing.md\n\n[`x.py` is the build tool for this repository][building and running rustc].\nInvoke it as `./x`, the default entry point for builds, tests, and formatting.\nDo not invoke Cargo directly unless the relevant in-tree documentation\nexplicitly requires it.\n\nFor source comments the policy permits an agent to write, explain why the code\nor decision exists rather than restating what the code does.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/plugin.json)",".cursorrules (rust.mdc)":"# Rust + Solana (Anchor) Best Practices\n\n## Program Structure\n- Structure Solana programs using `Anchor` framework standards\n- Place program entrypoint logic in `lib.rs`, not `main.rs`\n- Organize handlers into modules (e.g., `initialize`, `update`, `close`)\n- Separate state definitions, errors, instructions, and utils\n- Group reusable logic under a `utils` module (e.g., account validation)\n- Use `declare_id!()` to define program ID\n\n## Anchor Framework\n- Use `#[derive(Accounts)]` for all instruction contexts\n- Validate accounts strictly using constraint macros (e.g., `#[account(mut)]`, `seeds`, `bump]`)\n- Define all state structs with `#[account]` and `#[derive(AnchorSerialize, AnchorDeserialize)]`\n- Prefer `Init`, `Close`, `Realloc`, `Mut`, and constraint macros to avoid manual deserialization\n- Use `ctx.accounts` to access validated context accounts\n- Handle CPI (Cross-Program Invocation) calls via Anchor’s CPI helpers\n\n## Serialization\n- Use **Borsh** or Anchor's custom serializer (not Serde) for on-chain data\n- Always include `#[account(zero_copy)]` or `#[repr(C)]` for packed structures\n- Avoid floating point types — use `u64`, `u128`, or fixed-point math\n- Zero out or close unused accounts to reduce rent costs\n\n## Testing\n- Write tests in TypeScript using Anchor’s Mocha + Chai setup (`tests/*.ts`)\n- Use `anchor.workspace.MyProgram` to load deployed contracts\n- Use `provider.simulate()` to inspect failed txs\n- Spin up a local validator (`anchor test`) and reset between tests\n- Airdrop SOL to wallets with `provider.connection.requestAirdrop(...)`\n- Validate program logs using `tx.confirmation.logMessages`\n\n## Solana SDK (Manual)\n- Use `solana_program` crate when not using Anchor (bare-metal programs)\n- Carefully deserialize accounts using `AccountInfo`, `try_from_slice_unchecked`\n- Use `solana_program::msg!` for lightweight debugging logs\n- Verify accounts via `is_signer`, `is_writable`, `key == expected`\n- Never panic! Use `ProgramError::Custom(u32)` or `ErrorCode` enums\n\n## Security Patterns\n- Always validate `msg.sender`/signer with `account_info.is_signer`\n- Prevent replay attacks via `seeds`, `bump`, and unique PDAs\n- Use strict size checks before reallocating or deserializing\n- Avoid unsafe unchecked casting; prefer Anchor deserialization\n- For CPIs, validate `target_program` against expected program ID\n- When using randomness, never rely on timestamps — use oracles or off-chain VRFs\n\n## Performance\n- Prefer zero-copy deserialization when accounts are large\n- Minimize compute usage; avoid loops and recursion\n- Avoid memory reallocations mid-instruction\n- Use `#[account(zero_copy)]` and `#[repr(packed)]` for tight layout\n- Profile compute units with `solana logs` and `anchor run`\n\n## Dev Workflow\n- Use `anchor init` to scaffold projects\n- Add Anchor IDL support for front-end usage (JSON ABI)\n- Use `anchor build`, `anchor deploy`, `anchor test` consistently\n- Use separate `Anchor.toml` environments for devnet/mainnet/localnet\n- Format all Rust code with `cargo fmt`, lint with `cargo clippy`\n- Keep `Cargo.lock` checked into `programs/` but not root\n\n## Documentation\n- Use `///` Rust doc comments for all instructions and accounts\n- Include doc examples for each instruction\n- Document PDA derivation logic and bump seed expectations\n- Maintain up-to-date `README.md` with test commands and deployment steps\n\n## Wallet & Network Handling\n- Use `anchorProvider.wallet.publicKey` for signer verification in tests\n- Do not hardcode keypairs — use env-based loading (`process.env.ANCHOR_WALLET`)\n- Deploy with clear `cluster` targets (`localnet`, `devnet`, `mainnet`)\n- Use `anchor keys sync` to propagate program ID changes\n- Commit `target/idl/` and `target/types/` to share with front end\n\n## CI/CD & Deploy\n- Use GitHub Actions with `solana-cli`, `anchor-cli`, and `node` installed\n- Run `anchor test` in CI for every PR\n- Use `solana program deploy` with explicit `--program-id` on production deploys\n- Upload IDLs to a central registry (e.g., GitHub, IPFS, or `anchor.cloud`)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/rust-lang/rust/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent instructions\n\n## LLM usage policy\n\nFollow the Rust project's [LLM usage policy]. It applies to all LLM-generated\ntext even if a human later edits it.\n\n[LLM usage policy]: https://forge.rust-lang.org/policies/llm-usage.html\n\n### When a gate fails\n\nWhen a rule identifies banned work, **STOP** that work. A named reviewer, tests,\nuser confirmation, or later human editing cannot permit it. Do not ask for\nprerequisites, promise to proceed later, or offer the work under another name,\nsuch as a draft, template, or paste-ready outline. A rule may explicitly permit\nnarrower preliminary work; Soundness requires test-only work before stopping.\n\nState why the work is banned and give the route required by the triggering rule.\nReading, explaining, summarizing, reviewing, and suggesting possible solutions\nfor the user to implement from scratch remain allowed if independently requested.\nAlongside any text that could potentially be used as a substitute for prohibited text, include *in the same response turn* a reminder of the policies against text originally created by an LLM, even if given during a previous turn of the session. Do not proactively continue test planning or patch design, or produce paste-ready\nprohibited text, unless the triggering rule requires test-only work.\n\n### Personal use exemption\n\nThe [policy permits][allowed use] any LLM use where the user is the only one who\nsees the output. If the user states, in this conversation, that a change is for\npersonal use, prototyping, or experimentation with no intent to upstream the\nchange, then any gates that would prevent the change no longer apply.\nDo not infer this; a statement from the user is required.\n\nBefore the first edit under this exemption, state once that the resulting code,\ncomments, and documentation are LLM-generated and cannot later be contributed\nwithout arranging with a reviewer, and cite the gate(s) that prohibit this.\n\nIf the user later asks to push, open a pull request, or otherwise share work\nmade under this exemption, STOP and follow the gate-failure protocol.\nExplaining your edits and findings to the user to help them contribute\nappropriately is encouraged.\n\n[allowed use]: https://forge.rust-lang.org/policies/llm-usage.html#-allowed\n\n### Before any edit\n\nApply these gates in order before editing the repository, including tests:\n\n1. [External repositories](#external-repositories): route externally maintained\n   source to its owning repository.\n2. [Prohibited text](#prohibited-text): stop if the change requires the agent to\n   author prohibited text.\n3. [Reviewer](#reviewer): require a named reviewer unless the change qualifies\n   for the local-development exception.\n\nIf investigation reveals a new output category or owner, reapply the relevant\ngate before the next edit. For a mechanical rewrite, follow\n[Mechanical rewrites](#mechanical-rewrites) before the first mutation.\n\n### External repositories\n\nBefore modifying a subtree, submodule, or `src/tools` code, identify its owner\nusing [`CONTRIBUTING.md`](CONTRIBUTING.md#making-changes-to-subtrees-and-submodules)\nand the [external repositories] guide. Treat Cargo, Clippy, rustfmt, Miri,\nrust-analyzer, and other externally maintained tools as ownership checks before\nimplementation. If the user says the bug or change is in one of these tools,\ndo not investigate or ask for a reviewer here; route the user to its repository.\nEditing externally maintained source in this checkout is banned; follow the\n[gate-failure protocol]. Only update its integration pointer when explicitly\nrequested.\nFor example, if the user says a bug is in Cargo itself, route the user to\n`rust-lang/cargo` immediately; do not request a reviewer for this checkout.\n\n[external repositories]: src/doc/rustc-dev-guide/src/external-repos.md\n[gate-failure protocol]: #when-a-gate-fails\n\n### Prohibited text\n\nNever generate or rewrite non-trivial PR descriptions, issue bodies, public\ncomments, user-facing documentation, diagnostic messages, or source comments.\nSTOP, name the prohibited category, and tell the user to author it.\nDo not originate or manually rewrite expected diagnostic text in test snapshots\nsuch as `.stderr` files. After the user authors the diagnostic message in source,\nthe agent may mechanically regenerate its snapshots with an existing tool such\nas `./x test ... --bless`; follow [Mechanical rewrites](#mechanical-rewrites).\nA change is trivial only when there is no meaningfully different way to write\nit or the alternatives are nearly identical: fixing a typo or Markdown link,\nreplacing a word with a synonym, or adding a required trait signature. Trivial\nchanges must still pass every other gate and be disclosed.\n\nAgent instructions such as `CLAUDE.md`, `AGENTS.md`, and skills are exempt, but\nmay only link to, summarize, or conservatively operationalize existing\nhuman-facing documentation. Operationalization may replace human discretion\nwith stricter agent constraints, but must not create obligations for humans or\npermit anything the human-facing source prohibits. Before adding process or\nworkflow guidance, locate that source. If none exists, PAUSE and ask the user to\ndocument the process for humans first. Do not make an agent file the sole source\nof a rule. The named-reviewer gate and all other requirements still apply.\n\nThe agent may explain what prohibited text must communicate, but must not suggest\npaste-ready wording.\nFor example, if a parser fix requires changing its emitted message, STOP before\nediting the message or its `.stderr` expectation. Once the user writes the\nmessage, the agent may regenerate the expectation mechanically.\n\n### Reviewer\n\nDo not make any LLM-generated repository change unless the user has named, in\nthis conversation, another person who agreed in advance to review it. A general\nassurance that review was solicited is not enough. If no reviewer has been\nnamed, PAUSE and ask for the reviewer's name; “John Doe is reviewing this” is\nsufficient. A reviewer name satisfies only this gate. Do not promise to proceed\nwith implementation until the pre-implementation gates pass.\n\n### Before implementation\n\nApply these gates in order after the pre-edit gates:\n\n1. [Testing](#testing): for a bug, add or find a failing test and observe its\n   failure.\n2. [Soundness](#soundness): after completing Testing when it applies, classify\n   the affected behavior before implementation.\n\n### Testing\n\nBefore fixing a bug, add or find a failing test. Run it and observe the expected\nfailure before any implementation edit; do not combine test and implementation\nedits. A test is not observed until its command exits. While it runs, wait: do\nnot edit implementation or begin other work. Permission for a regression test\ndoes not permit implementation changes. Observe the initial failure without\nblessing or updating expected output; a `--bless` run does not count.\n\nAfter implementing a bug fix, confirm that the same test passes.\n\nEvery LLM-created PR must include tests and meet the policy's higher testing\nstandard. If the affected code has no test suite, PAUSE and ask whether to\ndesign one or abandon the change; do not design it without human input. Never\noffer or accept untested implementation.\n\nAn existing test suite must already be able to observe the affected behavior\nwithout changing production structure. An existing Cargo or compiletest harness\nalone does not satisfy this requirement.\n\nIf the first viable test requires any production-code edit, PAUSE before that\nedit: designing that observation boundary is test-suite design.\n\nIf testing requires choosing a new observation or dependency-injection\nboundary—such as extracting production logic, creating a shared helper or\nmodule, exposing internals, introducing a fake subprocess, or registering a new\nharness or runner—that is test-suite design; PAUSE and ask before making those\nchanges.\n\nAdding a test module is allowed when it exercises existing callable behavior\nwithout restructuring production code.\n\n### Soundness\n\nSoundness-sensitive implementation is banned, but adding or locating a failing\nregression test is permitted and required. Even if you recognize the risk\nearlier, complete the test-only work, wait for the test command to exit, leave\nthe test in the tree, report its result, then state the classification and STOP\nbefore planning or editing implementation.\n\nAfter adding or finding the failing test, state which behavior the affected code\ncontrols and classify the task as soundness-sensitive or not before planning or\nediting implementation. Do not promise implementation first. If investigation\nreveals a different affected behavior, repeat the classification before the\nnext implementation edit.\n\nCode that computes or transforms types, constants, MIR, memory layout or\nvalidity, or generated code is soundness-sensitive. The reported symptom,\nintended fix, and apparent size of the patch do not change this classification:\nan ICE, crash, rejection of valid code, or localized plumbing bug may still be\nsoundness-sensitive. If the task is soundness-sensitive or uncertain,\nimplementation is banned: STOP before editing it and follow the [gate-failure\nprotocol].\n\nSoundness-sensitive areas include, but are not limited to, the query system,\ntype checking, trait solving, MIR construction or optimization, borrow checking,\nconst evaluation, normalization and semantic caches, layout and validity, and\ncodegen. Explain the concern and direct the user to [#llm-mentoring Zulip].\n\n[#llm-mentoring Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/606558-llm-mentoring/\n\n### Before pushing\n\nAfter committing and before pushing, once ask the user to confirm understanding\nand testing of the change and personal review of the complete diff after the\nlatest change. Agent review does not count. Remind the user to disclose LLM use\nin the PR description. Do not infer omitted confirmations; PAUSE for any missing\nconfirmation before pushing.\n\nLLM-assisted contributions must be disclosed as described in the\n[policy's disclosure requirements]. Lying about or concealing LLM use is a\nCode of Conduct violation. The disclosure must describe the extent and purpose\nof LLM involvement, including whether the LLM originated an idea or helped\nimplement or review it. The agent must not draft or rewrite the disclosure; the\nuser must author it. Do NOT add `Co-Authored-By` trailers to commits.\n\n[policy's disclosure requirements]: https://forge.rust-lang.org/policies/llm-usage.html#disclosure-requirements\n\n### Mechanical rewrites\n\nFollow the rustc-dev-guide's [LLM guidance]. For a permitted mass rename or\nmechanical rewrite, find an existing formatter, linter, or syntax-aware rewrite\ntool. If one exists, the next mutating action must run it; do not edit target\nfiles first or reproduce its rewrite manually. If none exists, explain that\ndirect LLM rewriting is discouraged and ask before proceeding.\n\n[LLM guidance]: https://rustc-dev-guide.rust-lang.org/llm-guidance.html\n\nFor Rust formatting, use `./x fmt`; do not invoke `rustfmt` directly.\nFor example, if tidy can perform the rewrite, run `./x test tidy --bless` instead\nof reproducing its edits manually.\n\nBefore regenerating snapshots containing human-facing text:\n\n1. Confirm the user already authored the new prose in source.\n2. Run the focused test without `--bless` and observe the expected mismatch.\n3. Run the repository's existing `--bless` command.\n4. Inspect the generated diff. Do not manually repair or add prose; if the tool\n   produced unexpected human-facing text, STOP and report it to the user.\n\nIf a request conflicts with these rules, direct the user to the\n[#llm-mentoring Zulip] for help.\n\n## Repository guidance\n\nThis is the main `rust-lang/rust` repository.\nStart with [`CONTRIBUTING.md`](CONTRIBUTING.md) and the [dev-guide's instructions for LLMs][llm-writing], then route specialized work as follows:\n\n[llm-writing]: https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html\n\n- Standard library: [std-dev-guide]\n- Compiler: [rustc-dev-guide]\n- Build or run rustc: [building and running rustc]\n- Tests: [running tests], [adding tests], and [compiletest directives]\n- Formatting or tidy: [formatting and tidy]\n- Architecture or layout: [compiler architecture] and [repository layout]\n- Subtrees, submodules, or tools: [external repositories]\n- Pull requests and review: [contribution process]\n\n[rustc-dev-guide]: src/doc/rustc-dev-guide/\n[std-dev-guide]: https://std-dev-guide.rust-lang.org/\n[building and running rustc]: src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md\n[running tests]: src/doc/rustc-dev-guide/src/tests/running.md\n[adding tests]: src/doc/rustc-dev-guide/src/tests/adding.md\n[compiletest directives]: src/doc/rustc-dev-guide/src/tests/directives.md\n[formatting and tidy]: src/doc/rustc-dev-guide/src/conventions.md#formatting\n[compiler architecture]: src/doc/rustc-dev-guide/src/overview.md\n[repository layout]: src/doc/rustc-dev-guide/src/compiler-src.md\n[contribution process]: src/doc/rustc-dev-guide/src/contributing.md\n\n[`x.py` is the build tool for this repository][building and running rustc].\nInvoke it as `./x`, the default entry point for builds, tests, and formatting.\nDo not invoke Cargo directly unless the relevant in-tree documentation\nexplicitly requires it.\n\nFor source comments the policy permits an agent to write, explain why the code\nor decision exists rather than restating what the code does.\n","isInternal":false,"tokens":2908,"sizeBytes":13435},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":193},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":179},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/rust-lang/rust/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":172},{"name":".cursorrules","path":".cursorrules (rust.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/rust.mdc","title":"Rust best practices for Solana smart contract development using Anchor framework and Solana SDK","category":"cursor-rule","format":"markdown","content":"# Rust + Solana (Anchor) Best Practices\n\n## Program Structure\n- Structure Solana programs using `Anchor` framework standards\n- Place program entrypoint logic in `lib.rs`, not `main.rs`\n- Organize handlers into modules (e.g., `initialize`, `update`, `close`)\n- Separate state definitions, errors, instructions, and utils\n- Group reusable logic under a `utils` module (e.g., account validation)\n- Use `declare_id!()` to define program ID\n\n## Anchor Framework\n- Use `#[derive(Accounts)]` for all instruction contexts\n- Validate accounts strictly using constraint macros (e.g., `#[account(mut)]`, `seeds`, `bump]`)\n- Define all state structs with `#[account]` and `#[derive(AnchorSerialize, AnchorDeserialize)]`\n- Prefer `Init`, `Close`, `Realloc`, `Mut`, and constraint macros to avoid manual deserialization\n- Use `ctx.accounts` to access validated context accounts\n- Handle CPI (Cross-Program Invocation) calls via Anchor’s CPI helpers\n\n## Serialization\n- Use **Borsh** or Anchor's custom serializer (not Serde) for on-chain data\n- Always include `#[account(zero_copy)]` or `#[repr(C)]` for packed structures\n- Avoid floating point types — use `u64`, `u128`, or fixed-point math\n- Zero out or close unused accounts to reduce rent costs\n\n## Testing\n- Write tests in TypeScript using Anchor’s Mocha + Chai setup (`tests/*.ts`)\n- Use `anchor.workspace.MyProgram` to load deployed contracts\n- Use `provider.simulate()` to inspect failed txs\n- Spin up a local validator (`anchor test`) and reset between tests\n- Airdrop SOL to wallets with `provider.connection.requestAirdrop(...)`\n- Validate program logs using `tx.confirmation.logMessages`\n\n## Solana SDK (Manual)\n- Use `solana_program` crate when not using Anchor (bare-metal programs)\n- Carefully deserialize accounts using `AccountInfo`, `try_from_slice_unchecked`\n- Use `solana_program::msg!` for lightweight debugging logs\n- Verify accounts via `is_signer`, `is_writable`, `key == expected`\n- Never panic! Use `ProgramError::Custom(u32)` or `ErrorCode` enums\n\n## Security Patterns\n- Always validate `msg.sender`/signer with `account_info.is_signer`\n- Prevent replay attacks via `seeds`, `bump`, and unique PDAs\n- Use strict size checks before reallocating or deserializing\n- Avoid unsafe unchecked casting; prefer Anchor deserialization\n- For CPIs, validate `target_program` against expected program ID\n- When using randomness, never rely on timestamps — use oracles or off-chain VRFs\n\n## Performance\n- Prefer zero-copy deserialization when accounts are large\n- Minimize compute usage; avoid loops and recursion\n- Avoid memory reallocations mid-instruction\n- Use `#[account(zero_copy)]` and `#[repr(packed)]` for tight layout\n- Profile compute units with `solana logs` and `anchor run`\n\n## Dev Workflow\n- Use `anchor init` to scaffold projects\n- Add Anchor IDL support for front-end usage (JSON ABI)\n- Use `anchor build`, `anchor deploy`, `anchor test` consistently\n- Use separate `Anchor.toml` environments for devnet/mainnet/localnet\n- Format all Rust code with `cargo fmt`, lint with `cargo clippy`\n- Keep `Cargo.lock` checked into `programs/` but not root\n\n## Documentation\n- Use `///` Rust doc comments for all instructions and accounts\n- Include doc examples for each instruction\n- Document PDA derivation logic and bump seed expectations\n- Maintain up-to-date `README.md` with test commands and deployment steps\n\n## Wallet & Network Handling\n- Use `anchorProvider.wallet.publicKey` for signer verification in tests\n- Do not hardcode keypairs — use env-based loading (`process.env.ANCHOR_WALLET`)\n- Deploy with clear `cluster` targets (`localnet`, `devnet`, `mainnet`)\n- Use `anchor keys sync` to propagate program ID changes\n- Commit `target/idl/` and `target/types/` to share with front end\n\n## CI/CD & Deploy\n- Use GitHub Actions with `solana-cli`, `anchor-cli`, and `node` installed\n- Run `anchor test` in CI for every PR\n- Use `solana program deploy` with explicit `--program-id` on production deploys\n- Upload IDLs to a central registry (e.g., GitHub, IPFS, or `anchor.cloud`)","frontmatter":{"description":"Rust best practices for Solana smart contract development using Anchor framework and Solana SDK","globs":"programs/**/*.rs, src/**/*.rs, tests/**/*.ts","alwaysApply":false},"tokens":1025,"sizeBytes":4049}],"systemPromptSnippet":"<yakaai_skills repo=\"rust-lang/rust\">\n<!-- File: AGENTS.md (Tokens: ~2908 | Category: root-instruction) -->\n# Agent instructions\n\n## LLM usage policy\n\nFollow the Rust project's [LLM usage policy]. It applies to all LLM-generated\ntext even if a human later edits it.\n\n[LLM usage policy]: https://forge.rust-lang.org/policies/llm-usage.html\n\n### When a gate fails\n\nWhen a rule identifies banned work, **STOP** that work. A named reviewer, tests,\nuser confirmation, or later human editing cannot permit it. Do not ask for\nprerequisites, promise to proceed later, or offer the work under another name,\nsuch as a draft, template, or paste-ready outline. A rule may explicitly permit\nnarrower preliminary work; Soundness requires test-only work before stopping.\n\nState why the work is banned and give the route required by the triggering rule.\nReading, explaining, summarizing, reviewing, and suggesting possible solutions\nfor the user to implement from scratch remain allowed if independently requested.\nAlongside any text that could potentially be used as a substitute for prohibited text, include *in the same response turn* a reminder of the policies against text originally created by an LLM, even if given during a previous turn of the session. Do not proactively continue test planning or patch design, or produce paste-ready\nprohibited text, unless the triggering rule requires test-only work.\n\n### Personal use exemption\n\nThe [policy permits][allowed use] any LLM use where the user is the only one who\nsees the output. If the user states, in this conversation, that a change is for\npersonal use, prototyping, or experimentation with no intent to upstream the\nchange, then any gates that would prevent the change no longer apply.\nDo not infer this; a statement from the user is required.\n\nBefore the first edit under this exemption, state once that the resulting code,\ncomments, and documentation are LLM-generated and cannot later be contributed\nwithout arranging with a reviewer, and cite the gate(s) that prohibit this.\n\nIf the user later asks to push, open a pull request, or otherwise share work\nmade under this exemption, STOP and follow the gate-failure protocol.\nExplaining your edits and findings to the user to help them contribute\nappropriately is encouraged.\n\n[allowed use]: https://forge.rust-lang.org/policies/llm-usage.html#-allowed\n\n### Before any edit\n\nApply these gates in order before editing the repository, including tests:\n\n1. [External repositories](#external-repositories): route externally maintained\n   source to its owning repository.\n2. [Prohibited text](#prohibited-text): stop if the change requires the agent to\n   author prohibited text.\n3. [Reviewer](#reviewer): require a named reviewer unless the change qualifies\n   for the local-development exception.\n\nIf investigation reveals a new output category or owner, reapply the relevant\ngate before the next edit. For a mechanical rewrite, follow\n[Mechanical rewrites](#mechanical-rewrites) before the first mutation.\n\n### External repositories\n\nBefore modifying a subtree, submodule, or `src/tools` code, identify its owner\nusing [`CONTRIBUTING.md`](CONTRIBUTING.md#making-changes-to-subtrees-and-submodules)\nand the [external repositories] guide. Treat Cargo, Clippy, rustfmt, Miri,\nrust-analyzer, and other externally maintained tools as ownership checks before\nimplementation. If the user says the bug or change is in one of these tools,\ndo not investigate or ask for a reviewer here; route the user to its repository.\nEditing externally maintained source in this checkout is banned; follow the\n[gate-failure protocol]. Only update its integration pointer when explicitly\nrequested.\nFor example, if the user says a bug is in Cargo itself, route the user to\n`rust-lang/cargo` immediately; do not request a reviewer for this checkout.\n\n[external repositories]: src/doc/rustc-dev-guide/src/external-repos.md\n[gate-failure protocol]: #when-a-gate-fails\n\n### Prohibited text\n\nNever generate or rewrite non-trivial PR descriptions, issue bodies, public\ncomments, user-facing documentation, diagnostic messages, or source comments.\nSTOP, name the prohibited category, and tell the user to author it.\nDo not originate or manually rewrite expected diagnostic text in test snapshots\nsuch as `.stderr` files. After the user authors the diagnostic message in source,\nthe agent may mechanically regenerate its snapshots with an existing tool such\nas `./x test ... --bless`; follow [Mechanical rewrites](#mechanical-rewrites).\nA change is trivial only when there is no meaningfully different way to write\nit or the alternatives are nearly identical: fixing a typo or Markdown link,\nreplacing a word with a synonym, or adding a required trait signature. Trivial\nchanges must still pass every other gate and be disclosed.\n\nAgent instructions such as `CLAUDE.md`, `AGENTS.md`, and skills are exempt, but\nmay only link to, summarize, or conservatively operationalize existing\nhuman-facing documentation. Operationalization may replace human discretion\nwith stricter agent constraints, but must not create obligations for humans or\npermit anything the human-facing source prohibits. Before adding process or\nworkflow guidance, locate that source. If none exists, PAUSE and ask the user to\ndocument the process for humans first. Do not make an agent file the sole source\nof a rule. The named-reviewer gate and all other requirements still apply.\n\nThe agent may explain what prohibited text must communicate, but must not suggest\npaste-ready wording.\nFor example, if a parser fix requires changing its emitted message, STOP before\nediting the message or its `.stderr` expectation. Once the user writes the\nmessage, the agent may regenerate the expectation mechanically.\n\n### Reviewer\n\nDo not make any LLM-generated repository change unless the user has named, in\nthis conversation, another person who agreed in advance to review it. A general\nassurance that review was solicited is not enough. If no reviewer has been\nnamed, PAUSE and ask for the reviewer's name; “John Doe is reviewing this” is\nsufficient. A reviewer name satisfies only this gate. Do not promise to proceed\nwith implementation until the pre-implementation gates pass.\n\n### Before implementation\n\nApply these gates in order after the pre-edit gates:\n\n1. [Testing](#testing): for a bug, add or find a failing test and observe its\n   failure.\n2. [Soundness](#soundness): after completing Testing when it applies, classify\n   the affected behavior before implementation.\n\n### Testing\n\nBefore fixing a bug, add or find a failing test. Run it and observe the expected\nfailure before any implementation edit; do not combine test and implementation\nedits. A test is not observed until its command exits. While it runs, wait: do\nnot edit implementation or begin other work. Permission for a regression test\ndoes not permit implementation changes. Observe the initial failure without\nblessing or updating expected output; a `--bless` run does not count.\n\nAfter implementing a bug fix, confirm that the same test passes.\n\nEvery LLM-created PR must include tests and meet the policy's higher testing\nstandard. If the affected code has no test suite, PAUSE and ask whether to\ndesign one or abandon the change; do not design it without human input. Never\noffer or accept untested implementation.\n\nAn existing test suite must already be able to observe the affected behavior\nwithout changing production structure. An existing Cargo or compiletest harness\nalone does not satisfy this requirement.\n\nIf the first viable test requires any production-code edit, PAUSE before that\nedit: designing that observation boundary is test-suite design.\n\nIf testing requires choosing a new observation or dependency-injection\nboundary—such as extracting production logic, creating a shared helper or\nmodule, exposing internals, introducing a fake subprocess, or registering a new\nharness or runner—that is test-suite design; PAUSE and ask before making those\nchanges.\n\nAdding a test module is allowed when it exercises existing callable behavior\nwithout restructuring production code.\n\n### Soundness\n\nSoundness-sensitive implementation is banned, but adding or locating a failing\nregression test is permitted and required. Even if you recognize the risk\nearlier, complete the test-only work, wait for the test command to exit, leave\nthe test in the tree, report its result, then state the classification and STOP\nbefore planning or editing implementation.\n\nAfter adding or finding the failing test, state which behavior the affected code\ncontrols and classify the task as soundness-sensitive or not before planning or\nediting implementation. Do not promise implementation first. If investigation\nreveals a different affected behavior, repeat the classification before the\nnext implementation edit.\n\nCode that computes or transforms types, constants, MIR, memory layout or\nvalidity, or generated code is soundness-sensitive. The reported symptom,\nintended fix, and apparent size of the patch do not change this classification:\nan ICE, crash, rejection of valid code, or localized plumbing bug may still be\nsoundness-sensitive. If the task is soundness-sensitive or uncertain,\nimplementation is banned: STOP before editing it and follow the [gate-failure\nprotocol].\n\nSoundness-sensitive areas include, but are not limited to, the query system,\ntype checking, trait solving, MIR construction or optimization, borrow checking,\nconst evaluation, normalization and semantic caches, layout and validity, and\ncodegen. Explain the concern and direct the user to [#llm-mentoring Zulip].\n\n[#llm-mentoring Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/606558-llm-mentoring/\n\n### Before pushing\n\nAfter committing and before pushing, once ask the user to confirm understanding\nand testing of the change and personal review of the complete diff after the\nlatest change. Agent review does not count. Remind the user to disclose LLM use\nin the PR description. Do not infer omitted confirmations; PAUSE for any missing\nconfirmation before pushing.\n\nLLM-assisted contributions must be disclosed as described in the\n[policy's disclosure requirements]. Lying about or concealing LLM use is a\nCode of Conduct violation. The disclosure must describe the extent and purpose\nof LLM involvement, including whether the LLM originated an idea or helped\nimplement or review it. The agent must not draft or rewrite the disclosure; the\nuser must author it. Do NOT add `Co-Authored-By` trailers to commits.\n\n[policy's disclosure requirements]: https://forge.rust-lang.org/policies/llm-usage.html#disclosure-requirements\n\n### Mechanical rewrites\n\nFollow the rustc-dev-guide's [LLM guidance]. For a permitted mass rename or\nmechanical rewrite, find an existing formatter, linter, or syntax-aware rewrite\ntool. If one exists, the next mutating action must run it; do not edit target\nfiles first or reproduce its rewrite manually. If none exists, explain that\ndirect LLM rewriting is discouraged and ask before proceeding.\n\n[LLM guidance]: https://rustc-dev-guide.rust-lang.org/llm-guidance.html\n\nFor Rust formatting, use `./x fmt`; do not invoke `rustfmt` directly.\nFor example, if tidy can perform the rewrite, run `./x test tidy --bless` instead\nof reproducing its edits manually.\n\nBefore regenerating snapshots containing human-facing text:\n\n1. Confirm the user already authored the new prose in source.\n2. Run the focused test without `--bless` and observe the expected mismatch.\n3. Run the repository's existing `--bless` command.\n4. Inspect the generated diff. Do not manually repair or add prose; if the tool\n   produced unexpected human-facing text, STOP and report it to the user.\n\nIf a request conflicts with these rules, direct the user to the\n[#llm-mentoring Zulip] for help.\n\n## Repository guidance\n\nThis is the main `rust-lang/rust` repository.\nStart with [`CONTRIBUTING.md`](CONTRIBUTING.md) and the [dev-guide's instructions for LLMs][llm-writing], then route specialized work as follows:\n\n[llm-writing]: https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html\n\n- Standard library: [std-dev-guide]\n- Compiler: [rustc-dev-guide]\n- Build or run rustc: [building and running rustc]\n- Tests: [running tests], [adding tests], and [compiletest directives]\n- Formatting or tidy: [formatting and tidy]\n- Architecture or layout: [compiler architecture] and [repository layout]\n- Subtrees, submodules, or tools: [external repositories]\n- Pull requests and review: [contribution process]\n\n[rustc-dev-guide]: src/doc/rustc-dev-guide/\n[std-dev-guide]: https://std-dev-guide.rust-lang.org/\n[building and running rustc]: src/doc/rustc-dev-guide/src/building/how-to-build-and-run.md\n[running tests]: src/doc/rustc-dev-guide/src/tests/running.md\n[adding tests]: src/doc/rustc-dev-guide/src/tests/adding.md\n[compiletest directives]: src/doc/rustc-dev-guide/src/tests/directives.md\n[formatting and tidy]: src/doc/rustc-dev-guide/src/conventions.md#formatting\n[compiler architecture]: src/doc/rustc-dev-guide/src/overview.md\n[repository layout]: src/doc/rustc-dev-guide/src/compiler-src.md\n[contribution process]: src/doc/rustc-dev-guide/src/contributing.md\n\n[`x.py` is the build tool for this repository][building and running rustc].\nInvoke it as `./x`, the default entry point for builds, tests, and formatting.\nDo not invoke Cargo directly unless the relevant in-tree documentation\nexplicitly requires it.\n\nFor source comments the policy permits an agent to write, explain why the code\nor decision exists rather than restating what the code does.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/rust-lang/rust/HEAD/.cursor/mcp.json)\n\n<!-- File: .cursorrules (rust.mdc) (Tokens: ~1025 | Category: cursor-rule) -->\n# Rust + Solana (Anchor) Best Practices\n\n## Program Structure\n- Structure Solana programs using `Anchor` framework standards\n- Place program entrypoint logic in `lib.rs`, not `main.rs`\n- Organize handlers into modules (e.g., `initialize`, `update`, `close`)\n- Separate state definitions, errors, instructions, and utils\n- Group reusable logic under a `utils` module (e.g., account validation)\n- Use `declare_id!()` to define program ID\n\n## Anchor Framework\n- Use `#[derive(Accounts)]` for all instruction contexts\n- Validate accounts strictly using constraint macros (e.g., `#[account(mut)]`, `seeds`, `bump]`)\n- Define all state structs with `#[account]` and `#[derive(AnchorSerialize, AnchorDeserialize)]`\n- Prefer `Init`, `Close`, `Realloc`, `Mut`, and constraint macros to avoid manual deserialization\n- Use `ctx.accounts` to access validated context accounts\n- Handle CPI (Cross-Program Invocation) calls via Anchor’s CPI helpers\n\n## Serialization\n- Use **Borsh** or Anchor's custom serializer (not Serde) for on-chain data\n- Always include `#[account(zero_copy)]` or `#[repr(C)]` for packed structures\n- Avoid floating point types — use `u64`, `u128`, or fixed-point math\n- Zero out or close unused accounts to reduce rent costs\n\n## Testing\n- Write tests in TypeScript using Anchor’s Mocha + Chai setup (`tests/*.ts`)\n- Use `anchor.workspace.MyProgram` to load deployed contracts\n- Use `provider.simulate()` to inspect failed txs\n- Spin up a local validator (`anchor test`) and reset between tests\n- Airdrop SOL to wallets with `provider.connection.requestAirdrop(...)`\n- Validate program logs using `tx.confirmation.logMessages`\n\n## Solana SDK (Manual)\n- Use `solana_program` crate when not using Anchor (bare-metal programs)\n- Carefully deserialize accounts using `AccountInfo`, `try_from_slice_unchecked`\n- Use `solana_program::msg!` for lightweight debugging logs\n- Verify accounts via `is_signer`, `is_writable`, `key == expected`\n- Never panic! Use `ProgramError::Custom(u32)` or `ErrorCode` enums\n\n## Security Patterns\n- Always validate `msg.sender`/signer with `account_info.is_signer`\n- Prevent replay attacks via `seeds`, `bump`, and unique PDAs\n- Use strict size checks before reallocating or deserializing\n- Avoid unsafe unchecked casting; prefer Anchor deserialization\n- For CPIs, validate `target_program` against expected program ID\n- When using randomness, never rely on timestamps — use oracles or off-chain VRFs\n\n## Performance\n- Prefer zero-copy deserialization when accounts are large\n- Minimize compute usage; avoid loops and recursion\n- Avoid memory reallocations mid-instruction\n- Use `#[account(zero_copy)]` and `#[repr(packed)]` for tight layout\n- Profile compute units with `solana logs` and `anchor run`\n\n## Dev Workflow\n- Use `anchor init` to scaffold projects\n- Add Anchor IDL support for front-end usage (JSON ABI)\n- Use `anchor build`, `anchor deploy`, `anchor test` consistently\n- Use separate `Anchor.toml` environments for devnet/mainnet/localnet\n- Format all Rust code with `cargo fmt`, lint with `cargo clippy`\n- Keep `Cargo.lock` checked into `programs/` but not root\n\n## Documentation\n- Use `///` Rust doc comments for all instructions and accounts\n- Include doc examples for each instruction\n- Document PDA derivation logic and bump seed expectations\n- Maintain up-to-date `README.md` with test commands and deployment steps\n\n## Wallet & Network Handling\n- Use `anchorProvider.wallet.publicKey` for signer verification in tests\n- Do not hardcode keypairs — use env-based loading (`process.env.ANCHOR_WALLET`)\n- Deploy with clear `cluster` targets (`localnet`, `devnet`, `mainnet`)\n- Use `anchor keys sync` to propagate program ID changes\n- Commit `target/idl/` and `target/types/` to share with front end\n\n## CI/CD & Deploy\n- Use GitHub Actions with `solana-cli`, `anchor-cli`, and `node` installed\n- Run `anchor test` in CI for every PR\n- Use `solana program deploy` with explicit `--program-id` on production deploys\n- Upload IDLs to a central registry (e.g., GitHub, IPFS, or `anchor.cloud`)\n</yakaai_skills>"}