{"owner":"MystenLabs","repo":"sui","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\n## Crate-specific CLAUDE.md files\nWhen a sub-crate's CLAUDE.md conflicts with this file, the sub-crate's instructions win.\n\n## Individual Preferences\nIndividual preferences supersede and extend project preferences:\n- @CLAUDE.local.md if present.\n\n## Essential Development Commands\n\n### License comments\n\nAll applicable source code files must start with the following license in comments at the top of the file:\n\n    Copyright (c) Mysten Labs, Inc.\n    SPDX-License-Identifier: Apache-2.0\n\n### Building and Installation\n\n```bash\n# Build a specific crate. Generally don't need to do release build.\ncargo build -p sui-core\n\n# Check code without code generation or linking (preferred)\ncargo check\n```\n\n### Testing\n\n```bash\n# Run e2e tests. simtests must be run with `cargo simtest` to avoid false negatives\ncargo simtest -p sui-e2e-tests\n\n# Run Rust unittests. skip simulation tests as they may cause false negatives with `cargo nextest`\nSUI_SKIP_SIMTESTS=1 cargo nextest run -p <crate-name>\n```\n\n**Important Notes for Testing:**\n- When compiling or running tests in this repository, set timeout limits to at least 10 minutes due to the large codebase size\n- For faster iteration, use -p to select only the most relevant packages for testing. Use multiple `-p` flags if necessary, e.g. `cargo nextest run -p sui-types -p sui-core`\n- Use `cargo nextest run --lib` to run only library tests and skip integration tests for faster feedback\n- Use a scoped `cargo insta test` for the relevant package when snapshots are affected. Inspect the generated snapshot diffs. If they match the intended changes, update them with `cargo insta accept`. Do not accept unrelated snapshot changes.\n- Consult crate-specific CLAUDE.md files for instructions on which tests to run, when changing files in those crates\n\n### Linting and Formatting\n\n```bash\n# Formats & lints all Rust & Move (can be slow).\n./scripts/lint.sh\n\n# For formatting:\ncargo fmt --all\n\n# Lint a single crate in `crates/`, `consensus/`, `sui-execution/`:\ncargo xclippy -p <crate-name>\n\n# Linting all crates in `external-crates/`: cd into the crate directory and run:\ncargo move-clippy\n```\n\n## High-Level Architecture\n\n### Core Components Structure\n\n```\nsui/\n├── crates/                             # Main Rust crates\n│   ├── sui-core/                       # Core blockchain logic\n│   ├── sui-node/                       # Validator node implementation\n│   ├── sui-framework/                  # Move system packages & stdlib\n│   ├── sui-types/                      # Core type definitions\n│   ├── sui-json-rpc/                   # JSON-RPC API server\n│   ├── sui-indexer-alt-graphql/        # GraphQL API server\n│   └── sui-indexer-alt/                # Blockchain data indexer\n├── consensus/                          # Consensus mechanism (Mysticeti)\n├── sui-execution/                      # Move execution layer with versions\n├── dapps/                              # Frontend applications\n└── external-crates/                    # Move compiler and VM\n```\n\n### Key Architectural Patterns\n\n1. **Authority System**: Sui uses a set of validators (authorities) that process transactions in parallel. Each authority maintains its own state and participates in Mysticeti consensus.\n\n2. **Data Model**: Sui supports an object data model where each object has a unique ID and version. Accounts can also own balances.\n\n3. **Transaction Flow**:\n   - User → Fullnode → Validators\n   - All user transactions require consensus voting and commit before execution.\n   - Pre and post-consensus fastpath executions have been removed. Surviving mentions of \"fastpath\" refer to consensus transaction-voting logic, owned object logic, or should be reworded or removed. There is no longer a separate execution path called fastpath.\n\n4. **Storage Layer**:\n   - Uses RocksDB or Tidehunter for persistent storage on Sui nodes.\n   - Separate stores for permanent, per-epoch, checkpoint, consensus and indexing data\n\n5. **Execution Pipeline**:\n   - Consensus output → Execution → Effects commitment\n   - Move VM executes smart contracts with gas metering\n   - Parallel execution for non-conflicting transactions\n\n## Development Notes\n\n### Build flags\n\nSui binaries like sui-node built with `release` profile have `panic=abort` enabled.\n\n### Test-Only Code\n\nUse `#[cfg(test)]` for test-only code used within the same crate. Use `#[cfg(feature = \"testing\")]` for test-only code that must be callable cross-crate. For the `testing` feature: define `testing = []` in the crate's `Cargo.toml`, and callers must propagate it via `features = [\"testing\"]` in their dependency declaration.\n\nUse `#[tokio::test]` for async tests, not `#[test]`.\n\n### Protocol Config Changes:\n\nWhen modifying `crates/sui-protocol-config/src/lib.rs`, always invoke `/protocol-config` to verify changes are safe. Incorrect changes can break network consensus.\n\n### Raising a PR:\n\nWhen opening or updating a PR in this repo, always invoke the `/send-pr` skill.\n\n### Comment Writing Guidelines\n\n**Do NOT comment the obvious** - comments should not simply repeat what the code does.\n**When to comment**:\n- Non-obvious algorithms or business logic\n- Temporary exclusions, timeouts, or thresholds and their reasoning\n- Complex calculations where the \"why\" isn't immediately clear\n- Subtle race conditions or threading considerations\n- Assumptions about external state or preconditions\n\n**When NOT to comment**:\n- Simple variable assignments\n- Standard library usage\n- Self-descriptive function calls\n- Basic control flow (if/for/while)\n","AGENTS.md":"# Repository Guidelines\n\nCheck the root `CLAUDE.md` file for repo defaults.\nConsult crate-specific `CLAUDE.md` or `AGENTS.md` files when changing files in those crates.\n"},"files":{"CLAUDE.md":"# CLAUDE.md\n\n## Crate-specific CLAUDE.md files\nWhen a sub-crate's CLAUDE.md conflicts with this file, the sub-crate's instructions win.\n\n## Individual Preferences\nIndividual preferences supersede and extend project preferences:\n- @CLAUDE.local.md if present.\n\n## Essential Development Commands\n\n### License comments\n\nAll applicable source code files must start with the following license in comments at the top of the file:\n\n    Copyright (c) Mysten Labs, Inc.\n    SPDX-License-Identifier: Apache-2.0\n\n### Building and Installation\n\n```bash\n# Build a specific crate. Generally don't need to do release build.\ncargo build -p sui-core\n\n# Check code without code generation or linking (preferred)\ncargo check\n```\n\n### Testing\n\n```bash\n# Run e2e tests. simtests must be run with `cargo simtest` to avoid false negatives\ncargo simtest -p sui-e2e-tests\n\n# Run Rust unittests. skip simulation tests as they may cause false negatives with `cargo nextest`\nSUI_SKIP_SIMTESTS=1 cargo nextest run -p <crate-name>\n```\n\n**Important Notes for Testing:**\n- When compiling or running tests in this repository, set timeout limits to at least 10 minutes due to the large codebase size\n- For faster iteration, use -p to select only the most relevant packages for testing. Use multiple `-p` flags if necessary, e.g. `cargo nextest run -p sui-types -p sui-core`\n- Use `cargo nextest run --lib` to run only library tests and skip integration tests for faster feedback\n- Use a scoped `cargo insta test` for the relevant package when snapshots are affected. Inspect the generated snapshot diffs. If they match the intended changes, update them with `cargo insta accept`. Do not accept unrelated snapshot changes.\n- Consult crate-specific CLAUDE.md files for instructions on which tests to run, when changing files in those crates\n\n### Linting and Formatting\n\n```bash\n# Formats & lints all Rust & Move (can be slow).\n./scripts/lint.sh\n\n# For formatting:\ncargo fmt --all\n\n# Lint a single crate in `crates/`, `consensus/`, `sui-execution/`:\ncargo xclippy -p <crate-name>\n\n# Linting all crates in `external-crates/`: cd into the crate directory and run:\ncargo move-clippy\n```\n\n## High-Level Architecture\n\n### Core Components Structure\n\n```\nsui/\n├── crates/                             # Main Rust crates\n│   ├── sui-core/                       # Core blockchain logic\n│   ├── sui-node/                       # Validator node implementation\n│   ├── sui-framework/                  # Move system packages & stdlib\n│   ├── sui-types/                      # Core type definitions\n│   ├── sui-json-rpc/                   # JSON-RPC API server\n│   ├── sui-indexer-alt-graphql/        # GraphQL API server\n│   └── sui-indexer-alt/                # Blockchain data indexer\n├── consensus/                          # Consensus mechanism (Mysticeti)\n├── sui-execution/                      # Move execution layer with versions\n├── dapps/                              # Frontend applications\n└── external-crates/                    # Move compiler and VM\n```\n\n### Key Architectural Patterns\n\n1. **Authority System**: Sui uses a set of validators (authorities) that process transactions in parallel. Each authority maintains its own state and participates in Mysticeti consensus.\n\n2. **Data Model**: Sui supports an object data model where each object has a unique ID and version. Accounts can also own balances.\n\n3. **Transaction Flow**:\n   - User → Fullnode → Validators\n   - All user transactions require consensus voting and commit before execution.\n   - Pre and post-consensus fastpath executions have been removed. Surviving mentions of \"fastpath\" refer to consensus transaction-voting logic, owned object logic, or should be reworded or removed. There is no longer a separate execution path called fastpath.\n\n4. **Storage Layer**:\n   - Uses RocksDB or Tidehunter for persistent storage on Sui nodes.\n   - Separate stores for permanent, per-epoch, checkpoint, consensus and indexing data\n\n5. **Execution Pipeline**:\n   - Consensus output → Execution → Effects commitment\n   - Move VM executes smart contracts with gas metering\n   - Parallel execution for non-conflicting transactions\n\n## Development Notes\n\n### Build flags\n\nSui binaries like sui-node built with `release` profile have `panic=abort` enabled.\n\n### Test-Only Code\n\nUse `#[cfg(test)]` for test-only code used within the same crate. Use `#[cfg(feature = \"testing\")]` for test-only code that must be callable cross-crate. For the `testing` feature: define `testing = []` in the crate's `Cargo.toml`, and callers must propagate it via `features = [\"testing\"]` in their dependency declaration.\n\nUse `#[tokio::test]` for async tests, not `#[test]`.\n\n### Protocol Config Changes:\n\nWhen modifying `crates/sui-protocol-config/src/lib.rs`, always invoke `/protocol-config` to verify changes are safe. Incorrect changes can break network consensus.\n\n### Raising a PR:\n\nWhen opening or updating a PR in this repo, always invoke the `/send-pr` skill.\n\n### Comment Writing Guidelines\n\n**Do NOT comment the obvious** - comments should not simply repeat what the code does.\n**When to comment**:\n- Non-obvious algorithms or business logic\n- Temporary exclusions, timeouts, or thresholds and their reasoning\n- Complex calculations where the \"why\" isn't immediately clear\n- Subtle race conditions or threading considerations\n- Assumptions about external state or preconditions\n\n**When NOT to comment**:\n- Simple variable assignments\n- Standard library usage\n- Self-descriptive function calls\n- Basic control flow (if/for/while)\n","AGENTS.md":"# Repository Guidelines\n\nCheck the root `CLAUDE.md` file for repo defaults.\nConsult crate-specific `CLAUDE.md` or `AGENTS.md` files when changing files in those crates.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\n## Crate-specific CLAUDE.md files\nWhen a sub-crate's CLAUDE.md conflicts with this file, the sub-crate's instructions win.\n\n## Individual Preferences\nIndividual preferences supersede and extend project preferences:\n- @CLAUDE.local.md if present.\n\n## Essential Development Commands\n\n### License comments\n\nAll applicable source code files must start with the following license in comments at the top of the file:\n\n    Copyright (c) Mysten Labs, Inc.\n    SPDX-License-Identifier: Apache-2.0\n\n### Building and Installation\n\n```bash\n# Build a specific crate. Generally don't need to do release build.\ncargo build -p sui-core\n\n# Check code without code generation or linking (preferred)\ncargo check\n```\n\n### Testing\n\n```bash\n# Run e2e tests. simtests must be run with `cargo simtest` to avoid false negatives\ncargo simtest -p sui-e2e-tests\n\n# Run Rust unittests. skip simulation tests as they may cause false negatives with `cargo nextest`\nSUI_SKIP_SIMTESTS=1 cargo nextest run -p <crate-name>\n```\n\n**Important Notes for Testing:**\n- When compiling or running tests in this repository, set timeout limits to at least 10 minutes due to the large codebase size\n- For faster iteration, use -p to select only the most relevant packages for testing. Use multiple `-p` flags if necessary, e.g. `cargo nextest run -p sui-types -p sui-core`\n- Use `cargo nextest run --lib` to run only library tests and skip integration tests for faster feedback\n- Use a scoped `cargo insta test` for the relevant package when snapshots are affected. Inspect the generated snapshot diffs. If they match the intended changes, update them with `cargo insta accept`. Do not accept unrelated snapshot changes.\n- Consult crate-specific CLAUDE.md files for instructions on which tests to run, when changing files in those crates\n\n### Linting and Formatting\n\n```bash\n# Formats & lints all Rust & Move (can be slow).\n./scripts/lint.sh\n\n# For formatting:\ncargo fmt --all\n\n# Lint a single crate in `crates/`, `consensus/`, `sui-execution/`:\ncargo xclippy -p <crate-name>\n\n# Linting all crates in `external-crates/`: cd into the crate directory and run:\ncargo move-clippy\n```\n\n## High-Level Architecture\n\n### Core Components Structure\n\n```\nsui/\n├── crates/                             # Main Rust crates\n│   ├── sui-core/                       # Core blockchain logic\n│   ├── sui-node/                       # Validator node implementation\n│   ├── sui-framework/                  # Move system packages & stdlib\n│   ├── sui-types/                      # Core type definitions\n│   ├── sui-json-rpc/                   # JSON-RPC API server\n│   ├── sui-indexer-alt-graphql/        # GraphQL API server\n│   └── sui-indexer-alt/                # Blockchain data indexer\n├── consensus/                          # Consensus mechanism (Mysticeti)\n├── sui-execution/                      # Move execution layer with versions\n├── dapps/                              # Frontend applications\n└── external-crates/                    # Move compiler and VM\n```\n\n### Key Architectural Patterns\n\n1. **Authority System**: Sui uses a set of validators (authorities) that process transactions in parallel. Each authority maintains its own state and participates in Mysticeti consensus.\n\n2. **Data Model**: Sui supports an object data model where each object has a unique ID and version. Accounts can also own balances.\n\n3. **Transaction Flow**:\n   - User → Fullnode → Validators\n   - All user transactions require consensus voting and commit before execution.\n   - Pre and post-consensus fastpath executions have been removed. Surviving mentions of \"fastpath\" refer to consensus transaction-voting logic, owned object logic, or should be reworded or removed. There is no longer a separate execution path called fastpath.\n\n4. **Storage Layer**:\n   - Uses RocksDB or Tidehunter for persistent storage on Sui nodes.\n   - Separate stores for permanent, per-epoch, checkpoint, consensus and indexing data\n\n5. **Execution Pipeline**:\n   - Consensus output → Execution → Effects commitment\n   - Move VM executes smart contracts with gas metering\n   - Parallel execution for non-conflicting transactions\n\n## Development Notes\n\n### Build flags\n\nSui binaries like sui-node built with `release` profile have `panic=abort` enabled.\n\n### Test-Only Code\n\nUse `#[cfg(test)]` for test-only code used within the same crate. Use `#[cfg(feature = \"testing\")]` for test-only code that must be callable cross-crate. For the `testing` feature: define `testing = []` in the crate's `Cargo.toml`, and callers must propagate it via `features = [\"testing\"]` in their dependency declaration.\n\nUse `#[tokio::test]` for async tests, not `#[test]`.\n\n### Protocol Config Changes:\n\nWhen modifying `crates/sui-protocol-config/src/lib.rs`, always invoke `/protocol-config` to verify changes are safe. Incorrect changes can break network consensus.\n\n### Raising a PR:\n\nWhen opening or updating a PR in this repo, always invoke the `/send-pr` skill.\n\n### Comment Writing Guidelines\n\n**Do NOT comment the obvious** - comments should not simply repeat what the code does.\n**When to comment**:\n- Non-obvious algorithms or business logic\n- Temporary exclusions, timeouts, or thresholds and their reasoning\n- Complex calculations where the \"why\" isn't immediately clear\n- Subtle race conditions or threading considerations\n- Assumptions about external state or preconditions\n\n**When NOT to comment**:\n- Simple variable assignments\n- Standard library usage\n- Self-descriptive function calls\n- Basic control flow (if/for/while)\n","category":"root","tokens":1385},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\nCheck the root `CLAUDE.md` file for repo defaults.\nConsult crate-specific `CLAUDE.md` or `AGENTS.md` files when changing files in those crates.\n","category":"root","tokens":43}]}