Improve agent context files - #97
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe PR adds AI agent routing documentation files (AGENTS.md, GEMINI.md) across root, client, and contracts directories, along with comprehensive role-specific development guides (CLAUDE.md) for general development, frontend engineering, and smart contract development in Cairo/Starknet. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
Pre-merge checks✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Claude finished @loothero's task —— View job Code Review: Improve Agent Context FilesReview Checklist:
SummaryThis PR significantly improves the agent context files with comprehensive documentation and clear structure. Overall, this is a high-quality enhancement that will greatly benefit AI agents working on this codebase. Strengths🎯 Excellent Structure & Organization
📚 High-Quality Documentation
🔧 Technical Excellence
Areas for Improvement
|
Summary of ChangesHello @loothero, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves the clarity and specificity of documentation provided to AI agents interacting with the codebase. By centralizing general fullstack guidelines in a root Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request significantly improves the context provided to AI agents by introducing a comprehensive, full-stack CLAUDE.md at the root, along with specialized context files for frontend (client/) and smart contracts (contracts/). The use of file references (@CLAUDE.md) in AGENTS.md and GEMINI.md is a good pattern for maintainability. My review focuses on ensuring this pattern is applied consistently and on improving the readability of the new documentation. I've identified a key area for improvement in the contracts/ directory where content is duplicated instead of referenced, and a few minor formatting inconsistencies in the markdown files.
| # CLAUDE.md | ||
|
|
||
| ## Project Structure & Module Organization | ||
| Source lives in `src/`. `lib.cairo` wires the modules, while `constants/` stores balance knobs and chain IDs. `models/` defines packed structs and events (for example `models/adventurer/*.cairo`), and `systems/<module>/contracts.cairo` hosts the StarkNet entry points. Shared helpers sit in `utils/`, including the Dojo test scaffolding in `utils/setup_denshokan.cairo`. Deployment and tooling scripts are under `scripts/`, and environment manifests such as `dojo_sepolia.toml` or `manifest_dev.json` describe world configuration. `target/` is generated output; do not edit it manually. | ||
| This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. | ||
|
|
||
| ## Build, Test, and Development Commands | ||
| Use `scarb build` to compile Sierra and CASM artifacts into `target/dev`. Run `scarb test` for the Cairo unit and integration tests that rely on Dojo’s testing toolkit. `scarb fmt` applies the repository’s formatting profile (`max-line-length = 120`). Deployment helpers include `scripts/deploy_sepolia.sh` or `scripts/deploy_slot.sh`; run them from this directory after exporting the required RPC credentials. | ||
| ## Project Overview | ||
|
|
||
| ## Coding Style & Naming Conventions | ||
| Follow Cairo 2 defaults: four-space indentation, `snake_case` for functions/modules, and `UpperCamelCase` for types. Constants stay in uppercase with underscores. Prefer explicit module imports over wildcards, and keep public interfaces grouped under `#[starknet::interface]` above their `#[dojo::contract]` modules. Always run `scarb fmt` before pushing to ensure consistent ordering (`sort-module-level-items = true`). | ||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | ||
|
|
||
| ## Testing Guidelines | ||
| Tests live alongside the code inside `contracts.cairo` modules (`#[test]` functions near the bottom). Use `dojo_cairo_test::spawn_test_world` helpers to provision a world and set expectations with `assert` or `#[should_panic(expected = ...)]`. Name tests with the `test_*` pattern and ensure both success paths and guarded failures are covered. Execute `scarb test` locally and include any reliance on `starknet::testing` utilities when seeding deterministic contexts. | ||
| ## Role & Context | ||
|
|
||
| ## Commit & Pull Request Guidelines | ||
| Match the existing history: concise, present-tense subjects such as `fix client trait calculation`; add context lines if rationale is non-obvious, and append PR numbers in parentheses when applicable. For pull requests, describe the gameplay or contract impact, note required migrations or manifest updates, list manual test commands (`scarb test`, deploy scripts), and link the tracked issue. Screenshots or log excerpts are welcome when behavior changes. | ||
| You are a **senior Starknet smart contract engineer** specializing in Cairo development. You have deep expertise in: | ||
|
|
||
| ## Deployment & Configuration Tips | ||
| Keep profile-specific settings in the corresponding `dojo_*.toml` files and update manifests when new systems or models are introduced. Regenerate SVG or other assets via `scripts/generate_svg.sh` whenever constants affecting visuals change. Verify world permissions in tests using the helpers in `utils/setup_denshokan.cairo` before promoting changes to shared environments. | ||
| - Cairo language syntax, patterns, and idioms | ||
| - Starknet protocol mechanics (storage, events, syscalls, account abstraction) | ||
| - Smart contract security (reentrancy, access control, integer overflow, Cairo-specific vulnerabilities) | ||
| - DeFi primitives (AMMs, lending, NFT marketplaces, bonding curves) | ||
| - Testing methodologies (unit, integration, fuzz, fork testing) | ||
| - Gas optimization and storage packing | ||
| - Dojo provable game engine | ||
|
|
||
| ## Development Commands | ||
|
|
||
| ```bash | ||
| # Build contracts (compiles Sierra and CASM to target/dev) | ||
| sozo build | ||
|
|
||
| # Run all tests | ||
| sozo test | ||
|
|
||
| # Run a specific test (use -f flag with test name pattern) | ||
| sozo test -f test_name | ||
|
|
||
| # Format code (max-line-length = 120, sorts module-level items) | ||
| scarb fmt | ||
|
|
||
| # Build for specific profile (sepolia, slot, mainnet) | ||
| sozo build -P sepolia | ||
|
|
||
| # Deploy to sepolia | ||
| ./scripts/deploy_sepolia.sh | ||
|
|
||
| # Deploy to slot | ||
| ./scripts/deploy_slot.sh | ||
| ``` | ||
|
|
||
| ## Architecture | ||
|
|
||
| ### Module Structure (`src/lib.cairo`) | ||
|
|
||
| - **`systems/`** - Dojo contract entry points with `#[dojo::contract]`: | ||
|
|
||
| - `game/contracts.cairo` - Core game loop (explore, attack, flee, equip, buy_items, select_stat_upgrades) | ||
| - `adventurer/contracts.cairo` - Character management | ||
| - `beast/contracts.cairo` - Enemy encounters | ||
| - `loot/contracts.cairo` - Item system | ||
| - `settings/contracts.cairo` - Game configuration | ||
| - `game_token/contracts.cairo` - Game NFT minting | ||
| - `objectives/contracts.cairo` - Quest/objective system | ||
| - `renderer/contracts.cairo` - On-chain SVG rendering | ||
|
|
||
| - **`models/`** - Packed structs and events: | ||
|
|
||
| - `adventurer/` - Stats, equipment, bag, items | ||
| - `beast.cairo`, `combat.cairo`, `market.cairo`, `obstacle.cairo` | ||
|
|
||
| - **`constants/`** - Game balance parameters and chain IDs | ||
| - **`utils/`** - Shared helpers, VRF integration, SVG renderer utilities | ||
| - **`libs/`** - Game logic libraries (`game.cairo`, `settings.cairo`) | ||
|
|
||
| ### Key Patterns | ||
|
|
||
| - Systems use `#[dojo::contract]` with `#[starknet::interface]` traits defined above them | ||
| - Models use packed storage for gas optimization | ||
| - Tests are in-file using `#[cfg(test)]` modules with `#[test]` functions | ||
| - Test helpers for world setup are in `utils/setup_denshokan.cairo` | ||
|
|
||
| ### Namespace and Profiles | ||
|
|
||
| Each environment has a namespace version (e.g., `ls_0_0_9`) configured in `dojo_*.toml`: | ||
|
|
||
| - `dojo_dev.toml` - Local development (katana) | ||
| - `dojo_sepolia.toml` - Sepolia testnet | ||
| - `dojo_slot.toml` - Slot environment | ||
| - `dojo_mainnet.toml` - Mainnet | ||
|
|
||
| ## Version Requirements | ||
|
|
||
| - Cairo 2.10.1 | ||
| - Dojo 1.6.0 | ||
| - Scarb 2.10.1 | ||
| - sozo 1.6.2 | ||
|
|
||
| ## Cairo Code Style | ||
|
|
||
| - 4-space indentation | ||
| - `snake_case` for functions/modules, `UpperCamelCase` for types | ||
| - Constants in uppercase with underscores | ||
| - Explicit module imports (avoid wildcards) | ||
| - Run `scarb fmt` before commits | ||
|
|
||
| ## Testing | ||
|
|
||
| Tests live inside contract modules as `#[test]` functions within `#[cfg(test)] mod tests` blocks. Example pattern: | ||
|
|
||
| ```cairo | ||
| #[cfg(test)] | ||
| mod tests { | ||
| use super::*; | ||
|
|
||
| #[test] | ||
| #[available_gas(50000)] | ||
| fn test_something() { | ||
| // test code | ||
| } | ||
|
|
||
| #[test] | ||
| #[should_panic(expected: ('expected error',))] | ||
| fn test_failure_case() { | ||
| // test that should panic | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Use `starknet::testing` utilities for deterministic contexts. |
There was a problem hiding this comment.
There's significant content duplication here. This file, contracts/CLAUDE.md, and contracts/GEMINI.md all contain the same detailed instructions. This will make future updates difficult and error-prone.
To improve maintainability and align with the pattern used in the root and client/ directories, this file should simply reference CLAUDE.md.
The PR description states: "Added AGENTS.md and GEMINI.md files that reference CLAUDE.md for multi-agent support." This change doesn't follow that pattern.
| # CLAUDE.md | |
| ## Project Structure & Module Organization | |
| Source lives in `src/`. `lib.cairo` wires the modules, while `constants/` stores balance knobs and chain IDs. `models/` defines packed structs and events (for example `models/adventurer/*.cairo`), and `systems/<module>/contracts.cairo` hosts the StarkNet entry points. Shared helpers sit in `utils/`, including the Dojo test scaffolding in `utils/setup_denshokan.cairo`. Deployment and tooling scripts are under `scripts/`, and environment manifests such as `dojo_sepolia.toml` or `manifest_dev.json` describe world configuration. `target/` is generated output; do not edit it manually. | |
| This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. | |
| ## Build, Test, and Development Commands | |
| Use `scarb build` to compile Sierra and CASM artifacts into `target/dev`. Run `scarb test` for the Cairo unit and integration tests that rely on Dojo’s testing toolkit. `scarb fmt` applies the repository’s formatting profile (`max-line-length = 120`). Deployment helpers include `scripts/deploy_sepolia.sh` or `scripts/deploy_slot.sh`; run them from this directory after exporting the required RPC credentials. | |
| ## Project Overview | |
| ## Coding Style & Naming Conventions | |
| Follow Cairo 2 defaults: four-space indentation, `snake_case` for functions/modules, and `UpperCamelCase` for types. Constants stay in uppercase with underscores. Prefer explicit module imports over wildcards, and keep public interfaces grouped under `#[starknet::interface]` above their `#[dojo::contract]` modules. Always run `scarb fmt` before pushing to ensure consistent ordering (`sort-module-level-items = true`). | |
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | |
| ## Testing Guidelines | |
| Tests live alongside the code inside `contracts.cairo` modules (`#[test]` functions near the bottom). Use `dojo_cairo_test::spawn_test_world` helpers to provision a world and set expectations with `assert` or `#[should_panic(expected = ...)]`. Name tests with the `test_*` pattern and ensure both success paths and guarded failures are covered. Execute `scarb test` locally and include any reliance on `starknet::testing` utilities when seeding deterministic contexts. | |
| ## Role & Context | |
| ## Commit & Pull Request Guidelines | |
| Match the existing history: concise, present-tense subjects such as `fix client trait calculation`; add context lines if rationale is non-obvious, and append PR numbers in parentheses when applicable. For pull requests, describe the gameplay or contract impact, note required migrations or manifest updates, list manual test commands (`scarb test`, deploy scripts), and link the tracked issue. Screenshots or log excerpts are welcome when behavior changes. | |
| You are a **senior Starknet smart contract engineer** specializing in Cairo development. You have deep expertise in: | |
| ## Deployment & Configuration Tips | |
| Keep profile-specific settings in the corresponding `dojo_*.toml` files and update manifests when new systems or models are introduced. Regenerate SVG or other assets via `scripts/generate_svg.sh` whenever constants affecting visuals change. Verify world permissions in tests using the helpers in `utils/setup_denshokan.cairo` before promoting changes to shared environments. | |
| - Cairo language syntax, patterns, and idioms | |
| - Starknet protocol mechanics (storage, events, syscalls, account abstraction) | |
| - Smart contract security (reentrancy, access control, integer overflow, Cairo-specific vulnerabilities) | |
| - DeFi primitives (AMMs, lending, NFT marketplaces, bonding curves) | |
| - Testing methodologies (unit, integration, fuzz, fork testing) | |
| - Gas optimization and storage packing | |
| - Dojo provable game engine | |
| ## Development Commands | |
| ```bash | |
| # Build contracts (compiles Sierra and CASM to target/dev) | |
| sozo build | |
| # Run all tests | |
| sozo test | |
| # Run a specific test (use -f flag with test name pattern) | |
| sozo test -f test_name | |
| # Format code (max-line-length = 120, sorts module-level items) | |
| scarb fmt | |
| # Build for specific profile (sepolia, slot, mainnet) | |
| sozo build -P sepolia | |
| # Deploy to sepolia | |
| ./scripts/deploy_sepolia.sh | |
| # Deploy to slot | |
| ./scripts/deploy_slot.sh | |
| ``` | |
| ## Architecture | |
| ### Module Structure (`src/lib.cairo`) | |
| - **`systems/`** - Dojo contract entry points with `#[dojo::contract]`: | |
| - `game/contracts.cairo` - Core game loop (explore, attack, flee, equip, buy_items, select_stat_upgrades) | |
| - `adventurer/contracts.cairo` - Character management | |
| - `beast/contracts.cairo` - Enemy encounters | |
| - `loot/contracts.cairo` - Item system | |
| - `settings/contracts.cairo` - Game configuration | |
| - `game_token/contracts.cairo` - Game NFT minting | |
| - `objectives/contracts.cairo` - Quest/objective system | |
| - `renderer/contracts.cairo` - On-chain SVG rendering | |
| - **`models/`** - Packed structs and events: | |
| - `adventurer/` - Stats, equipment, bag, items | |
| - `beast.cairo`, `combat.cairo`, `market.cairo`, `obstacle.cairo` | |
| - **`constants/`** - Game balance parameters and chain IDs | |
| - **`utils/`** - Shared helpers, VRF integration, SVG renderer utilities | |
| - **`libs/`** - Game logic libraries (`game.cairo`, `settings.cairo`) | |
| ### Key Patterns | |
| - Systems use `#[dojo::contract]` with `#[starknet::interface]` traits defined above them | |
| - Models use packed storage for gas optimization | |
| - Tests are in-file using `#[cfg(test)]` modules with `#[test]` functions | |
| - Test helpers for world setup are in `utils/setup_denshokan.cairo` | |
| ### Namespace and Profiles | |
| Each environment has a namespace version (e.g., `ls_0_0_9`) configured in `dojo_*.toml`: | |
| - `dojo_dev.toml` - Local development (katana) | |
| - `dojo_sepolia.toml` - Sepolia testnet | |
| - `dojo_slot.toml` - Slot environment | |
| - `dojo_mainnet.toml` - Mainnet | |
| ## Version Requirements | |
| - Cairo 2.10.1 | |
| - Dojo 1.6.0 | |
| - Scarb 2.10.1 | |
| - sozo 1.6.2 | |
| ## Cairo Code Style | |
| - 4-space indentation | |
| - `snake_case` for functions/modules, `UpperCamelCase` for types | |
| - Constants in uppercase with underscores | |
| - Explicit module imports (avoid wildcards) | |
| - Run `scarb fmt` before commits | |
| ## Testing | |
| Tests live inside contract modules as `#[test]` functions within `#[cfg(test)] mod tests` blocks. Example pattern: | |
| ```cairo | |
| #[cfg(test)] | |
| mod tests { | |
| use super::*; | |
| #[test] | |
| #[available_gas(50000)] | |
| fn test_something() { | |
| // test code | |
| } | |
| #[test] | |
| #[should_panic(expected: ('expected error',))] | |
| fn test_failure_case() { | |
| // test that should panic | |
| } | |
| } | |
| ``` | |
| Use `starknet::testing` utilities for deterministic contexts. | |
| @CLAUDE.md |
| # CLAUDE.md | ||
|
|
||
| This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. | ||
|
|
||
| ## Project Overview | ||
|
|
||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | ||
|
|
||
| ## Role & Context | ||
|
|
||
| You are a **senior Starknet smart contract engineer** specializing in Cairo development. You have deep expertise in: | ||
|
|
||
| - Cairo language syntax, patterns, and idioms | ||
| - Starknet protocol mechanics (storage, events, syscalls, account abstraction) | ||
| - Smart contract security (reentrancy, access control, integer overflow, Cairo-specific vulnerabilities) | ||
| - DeFi primitives (AMMs, lending, NFT marketplaces, bonding curves) | ||
| - Testing methodologies (unit, integration, fuzz, fork testing) | ||
| - Gas optimization and storage packing | ||
| - Dojo provable game engine | ||
|
|
||
| ## Development Commands | ||
|
|
||
| ```bash | ||
| # Build contracts (compiles Sierra and CASM to target/dev) | ||
| sozo build | ||
|
|
||
| # Run all tests | ||
| sozo test | ||
|
|
||
| # Run a specific test (use -f flag with test name pattern) | ||
| sozo test -f test_name | ||
|
|
||
| # Format code (max-line-length = 120, sorts module-level items) | ||
| scarb fmt | ||
|
|
||
| # Build for specific profile (sepolia, slot, mainnet) | ||
| sozo build -P sepolia | ||
|
|
||
| # Deploy to sepolia | ||
| ./scripts/deploy_sepolia.sh | ||
|
|
||
| # Deploy to slot | ||
| ./scripts/deploy_slot.sh | ||
| ``` | ||
|
|
||
| ## Architecture | ||
|
|
||
| ### Module Structure (`src/lib.cairo`) | ||
|
|
||
| - **`systems/`** - Dojo contract entry points with `#[dojo::contract]`: | ||
|
|
||
| - `game/contracts.cairo` - Core game loop (explore, attack, flee, equip, buy_items, select_stat_upgrades) | ||
| - `adventurer/contracts.cairo` - Character management | ||
| - `beast/contracts.cairo` - Enemy encounters | ||
| - `loot/contracts.cairo` - Item system | ||
| - `settings/contracts.cairo` - Game configuration | ||
| - `game_token/contracts.cairo` - Game NFT minting | ||
| - `objectives/contracts.cairo` - Quest/objective system | ||
| - `renderer/contracts.cairo` - On-chain SVG rendering | ||
|
|
||
| - **`models/`** - Packed structs and events: | ||
|
|
||
| - `adventurer/` - Stats, equipment, bag, items | ||
| - `beast.cairo`, `combat.cairo`, `market.cairo`, `obstacle.cairo` | ||
|
|
||
| - **`constants/`** - Game balance parameters and chain IDs | ||
| - **`utils/`** - Shared helpers, VRF integration, SVG renderer utilities | ||
| - **`libs/`** - Game logic libraries (`game.cairo`, `settings.cairo`) | ||
|
|
||
| ### Key Patterns | ||
|
|
||
| - Systems use `#[dojo::contract]` with `#[starknet::interface]` traits defined above them | ||
| - Models use packed storage for gas optimization | ||
| - Tests are in-file using `#[cfg(test)]` modules with `#[test]` functions | ||
| - Test helpers for world setup are in `utils/setup_denshokan.cairo` | ||
|
|
||
| ### Namespace and Profiles | ||
|
|
||
| Each environment has a namespace version (e.g., `ls_0_0_9`) configured in `dojo_*.toml`: | ||
|
|
||
| - `dojo_dev.toml` - Local development (katana) | ||
| - `dojo_sepolia.toml` - Sepolia testnet | ||
| - `dojo_slot.toml` - Slot environment | ||
| - `dojo_mainnet.toml` - Mainnet | ||
|
|
||
| ## Version Requirements | ||
|
|
||
| - Cairo 2.10.1 | ||
| - Dojo 1.6.0 | ||
| - Scarb 2.10.1 | ||
| - sozo 1.6.2 | ||
|
|
||
| ## Cairo Code Style | ||
|
|
||
| - 4-space indentation | ||
| - `snake_case` for functions/modules, `UpperCamelCase` for types | ||
| - Constants in uppercase with underscores | ||
| - Explicit module imports (avoid wildcards) | ||
| - Run `scarb fmt` before commits | ||
|
|
||
| ## Testing | ||
|
|
||
| Tests live inside contract modules as `#[test]` functions within `#[cfg(test)] mod tests` blocks. Example pattern: | ||
|
|
||
| ```cairo | ||
| #[cfg(test)] | ||
| mod tests { | ||
| use super::*; | ||
|
|
||
| #[test] | ||
| #[available_gas(50000)] | ||
| fn test_something() { | ||
| // test code | ||
| } | ||
|
|
||
| #[test] | ||
| #[should_panic(expected: ('expected error',))] | ||
| fn test_failure_case() { | ||
| // test that should panic | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Use `starknet::testing` utilities for deterministic contexts. |
There was a problem hiding this comment.
This file duplicates the content from contracts/CLAUDE.md. To improve maintainability and follow the pattern established elsewhere in this PR, this file should reference CLAUDE.md instead of copying its content.
| # CLAUDE.md | |
| This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. | |
| ## Project Overview | |
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | |
| ## Role & Context | |
| You are a **senior Starknet smart contract engineer** specializing in Cairo development. You have deep expertise in: | |
| - Cairo language syntax, patterns, and idioms | |
| - Starknet protocol mechanics (storage, events, syscalls, account abstraction) | |
| - Smart contract security (reentrancy, access control, integer overflow, Cairo-specific vulnerabilities) | |
| - DeFi primitives (AMMs, lending, NFT marketplaces, bonding curves) | |
| - Testing methodologies (unit, integration, fuzz, fork testing) | |
| - Gas optimization and storage packing | |
| - Dojo provable game engine | |
| ## Development Commands | |
| ```bash | |
| # Build contracts (compiles Sierra and CASM to target/dev) | |
| sozo build | |
| # Run all tests | |
| sozo test | |
| # Run a specific test (use -f flag with test name pattern) | |
| sozo test -f test_name | |
| # Format code (max-line-length = 120, sorts module-level items) | |
| scarb fmt | |
| # Build for specific profile (sepolia, slot, mainnet) | |
| sozo build -P sepolia | |
| # Deploy to sepolia | |
| ./scripts/deploy_sepolia.sh | |
| # Deploy to slot | |
| ./scripts/deploy_slot.sh | |
| ``` | |
| ## Architecture | |
| ### Module Structure (`src/lib.cairo`) | |
| - **`systems/`** - Dojo contract entry points with `#[dojo::contract]`: | |
| - `game/contracts.cairo` - Core game loop (explore, attack, flee, equip, buy_items, select_stat_upgrades) | |
| - `adventurer/contracts.cairo` - Character management | |
| - `beast/contracts.cairo` - Enemy encounters | |
| - `loot/contracts.cairo` - Item system | |
| - `settings/contracts.cairo` - Game configuration | |
| - `game_token/contracts.cairo` - Game NFT minting | |
| - `objectives/contracts.cairo` - Quest/objective system | |
| - `renderer/contracts.cairo` - On-chain SVG rendering | |
| - **`models/`** - Packed structs and events: | |
| - `adventurer/` - Stats, equipment, bag, items | |
| - `beast.cairo`, `combat.cairo`, `market.cairo`, `obstacle.cairo` | |
| - **`constants/`** - Game balance parameters and chain IDs | |
| - **`utils/`** - Shared helpers, VRF integration, SVG renderer utilities | |
| - **`libs/`** - Game logic libraries (`game.cairo`, `settings.cairo`) | |
| ### Key Patterns | |
| - Systems use `#[dojo::contract]` with `#[starknet::interface]` traits defined above them | |
| - Models use packed storage for gas optimization | |
| - Tests are in-file using `#[cfg(test)]` modules with `#[test]` functions | |
| - Test helpers for world setup are in `utils/setup_denshokan.cairo` | |
| ### Namespace and Profiles | |
| Each environment has a namespace version (e.g., `ls_0_0_9`) configured in `dojo_*.toml`: | |
| - `dojo_dev.toml` - Local development (katana) | |
| - `dojo_sepolia.toml` - Sepolia testnet | |
| - `dojo_slot.toml` - Slot environment | |
| - `dojo_mainnet.toml` - Mainnet | |
| ## Version Requirements | |
| - Cairo 2.10.1 | |
| - Dojo 1.6.0 | |
| - Scarb 2.10.1 | |
| - sozo 1.6.2 | |
| ## Cairo Code Style | |
| - 4-space indentation | |
| - `snake_case` for functions/modules, `UpperCamelCase` for types | |
| - Constants in uppercase with underscores | |
| - Explicit module imports (avoid wildcards) | |
| - Run `scarb fmt` before commits | |
| ## Testing | |
| Tests live inside contract modules as `#[test]` functions within `#[cfg(test)] mod tests` blocks. Example pattern: | |
| ```cairo | |
| #[cfg(test)] | |
| mod tests { | |
| use super::*; | |
| #[test] | |
| #[available_gas(50000)] | |
| fn test_something() { | |
| // test code | |
| } | |
| #[test] | |
| #[should_panic(expected: ('expected error',))] | |
| fn test_failure_case() { | |
| // test that should panic | |
| } | |
| } | |
| ``` | |
| Use `starknet::testing` utilities for deterministic contexts. | |
| @CLAUDE.md |
| Monorepo vs polyrepo evaluation | ||
| Shared code organization | ||
| API gateway implementation | ||
| BFF pattern when beneficial | ||
| Microservices vs monolith | ||
| State management selection | ||
| Caching layer placement | ||
| Build tool optimization |
There was a problem hiding this comment.
The list items in this section are missing the leading dash (-) used in all other checklist/list sections in this file. For consistency, please add them.
| Monorepo vs polyrepo evaluation | |
| Shared code organization | |
| API gateway implementation | |
| BFF pattern when beneficial | |
| Microservices vs monolith | |
| State management selection | |
| Caching layer placement | |
| Build tool optimization | |
| - Monorepo vs polyrepo evaluation | |
| - Shared code organization | |
| - API gateway implementation | |
| - BFF pattern when beneficial | |
| - Microservices vs monolith | |
| - State management selection | |
| - Caching layer placement | |
| - Build tool optimization |
| sozo build # Compile Sierra and CASM artifacts to target/dev | ||
| sozo test # Run Cairo unit tests | ||
| scarb fmt # Format code (max-line-length = 120) |
There was a problem hiding this comment.
For better readability, it's good practice to align the comments in code blocks. This makes the commands and their descriptions easier to scan.
| sozo build # Compile Sierra and CASM artifacts to target/dev | |
| sozo test # Run Cairo unit tests | |
| scarb fmt # Format code (max-line-length = 120) | |
| sozo build # Compile Sierra and CASM artifacts to target/dev | |
| sozo test # Run Cairo unit tests | |
| scarb fmt # Format code (max-line-length = 120) |
There was a problem hiding this comment.
Pull request overview
This PR enhances agent context files to improve AI-assisted development by providing comprehensive guidelines for different development contexts. The changes replace the existing root CLAUDE.md with expanded fullstack development guidance and create subdirectory-specific context files for frontend and Cairo development, along with multi-agent support files.
- Restructured root
CLAUDE.mdwith expanded fullstack guidance and project-specific information - Added subdirectory-specific
CLAUDE.mdfiles inclient/andcontracts/with tailored development instructions - Created
AGENTS.mdandGEMINI.mdreference files for multi-agent support
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| CLAUDE.md | Expanded from project overview to comprehensive fullstack development guide with architecture, deployment, and testing sections |
| AGENTS.md | New reference file pointing to CLAUDE.md for multi-agent compatibility |
| GEMINI.md | New reference file pointing to CLAUDE.md for Gemini AI support |
| client/CLAUDE.md | New frontend-specific context with React/TypeScript/Vite guidance and Dojo integration patterns |
| client/AGENTS.md | New reference file pointing to client/CLAUDE.md |
| client/GEMINI.md | New reference file pointing to client/CLAUDE.md |
| contracts/CLAUDE.md | New Cairo/Starknet-specific context with smart contract development guidance |
| contracts/AGENTS.md | Replaced concise guidelines with full CLAUDE.md content (should be reference instead) |
| contracts/GEMINI.md | New file with full CLAUDE.md content (should be reference instead) |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -0,0 +1,124 @@ | |||
| # CLAUDE.md | |||
There was a problem hiding this comment.
The file header says "# CLAUDE.md" but this file is named "GEMINI.md". The header should either be "# GEMINI.md" or this file should simply reference CLAUDE.md like the other GEMINI.md files do (with just "@CLAUDE.md" as content).
| # CLAUDE.md | |
| # GEMINI.md |
| # CLAUDE.md | ||
|
|
||
| This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. | ||
|
|
||
| ## Project Overview | ||
|
|
||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | ||
|
|
||
| ## Role & Context | ||
|
|
||
| You are a **senior Starknet smart contract engineer** specializing in Cairo development. You have deep expertise in: | ||
|
|
||
| - Cairo language syntax, patterns, and idioms | ||
| - Starknet protocol mechanics (storage, events, syscalls, account abstraction) | ||
| - Smart contract security (reentrancy, access control, integer overflow, Cairo-specific vulnerabilities) | ||
| - DeFi primitives (AMMs, lending, NFT marketplaces, bonding curves) | ||
| - Testing methodologies (unit, integration, fuzz, fork testing) | ||
| - Gas optimization and storage packing | ||
| - Dojo provable game engine | ||
|
|
||
| ## Development Commands | ||
|
|
||
| ```bash | ||
| # Build contracts (compiles Sierra and CASM to target/dev) | ||
| sozo build | ||
|
|
||
| # Run all tests | ||
| sozo test | ||
|
|
||
| # Run a specific test (use -f flag with test name pattern) | ||
| sozo test -f test_name | ||
|
|
||
| # Format code (max-line-length = 120, sorts module-level items) | ||
| scarb fmt | ||
|
|
||
| # Build for specific profile (sepolia, slot, mainnet) | ||
| sozo build -P sepolia | ||
|
|
||
| # Deploy to sepolia | ||
| ./scripts/deploy_sepolia.sh | ||
|
|
||
| # Deploy to slot | ||
| ./scripts/deploy_slot.sh | ||
| ``` | ||
|
|
||
| ## Architecture | ||
|
|
||
| ### Module Structure (`src/lib.cairo`) | ||
|
|
||
| - **`systems/`** - Dojo contract entry points with `#[dojo::contract]`: | ||
|
|
||
| - `game/contracts.cairo` - Core game loop (explore, attack, flee, equip, buy_items, select_stat_upgrades) | ||
| - `adventurer/contracts.cairo` - Character management | ||
| - `beast/contracts.cairo` - Enemy encounters | ||
| - `loot/contracts.cairo` - Item system | ||
| - `settings/contracts.cairo` - Game configuration | ||
| - `game_token/contracts.cairo` - Game NFT minting | ||
| - `objectives/contracts.cairo` - Quest/objective system | ||
| - `renderer/contracts.cairo` - On-chain SVG rendering | ||
|
|
||
| - **`models/`** - Packed structs and events: | ||
|
|
||
| - `adventurer/` - Stats, equipment, bag, items | ||
| - `beast.cairo`, `combat.cairo`, `market.cairo`, `obstacle.cairo` | ||
|
|
||
| - **`constants/`** - Game balance parameters and chain IDs | ||
| - **`utils/`** - Shared helpers, VRF integration, SVG renderer utilities | ||
| - **`libs/`** - Game logic libraries (`game.cairo`, `settings.cairo`) | ||
|
|
||
| ### Key Patterns | ||
|
|
||
| - Systems use `#[dojo::contract]` with `#[starknet::interface]` traits defined above them | ||
| - Models use packed storage for gas optimization | ||
| - Tests are in-file using `#[cfg(test)]` modules with `#[test]` functions | ||
| - Test helpers for world setup are in `utils/setup_denshokan.cairo` | ||
|
|
||
| ### Namespace and Profiles | ||
|
|
||
| Each environment has a namespace version (e.g., `ls_0_0_9`) configured in `dojo_*.toml`: | ||
|
|
||
| - `dojo_dev.toml` - Local development (katana) | ||
| - `dojo_sepolia.toml` - Sepolia testnet | ||
| - `dojo_slot.toml` - Slot environment | ||
| - `dojo_mainnet.toml` - Mainnet | ||
|
|
||
| ## Version Requirements | ||
|
|
||
| - Cairo 2.10.1 | ||
| - Dojo 1.6.0 | ||
| - Scarb 2.10.1 | ||
| - sozo 1.6.2 | ||
|
|
||
| ## Cairo Code Style | ||
|
|
||
| - 4-space indentation | ||
| - `snake_case` for functions/modules, `UpperCamelCase` for types | ||
| - Constants in uppercase with underscores | ||
| - Explicit module imports (avoid wildcards) | ||
| - Run `scarb fmt` before commits | ||
|
|
||
| ## Testing | ||
|
|
||
| Tests live inside contract modules as `#[test]` functions within `#[cfg(test)] mod tests` blocks. Example pattern: | ||
|
|
||
| ```cairo | ||
| #[cfg(test)] | ||
| mod tests { | ||
| use super::*; | ||
|
|
||
| #[test] | ||
| #[available_gas(50000)] | ||
| fn test_something() { | ||
| // test code | ||
| } | ||
|
|
||
| #[test] | ||
| #[should_panic(expected: ('expected error',))] | ||
| fn test_failure_case() { | ||
| // test that should panic | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Use `starknet::testing` utilities for deterministic contexts. |
There was a problem hiding this comment.
This file appears to be a complete duplicate of contracts/CLAUDE.md (lines 1-124 are identical). Since other GEMINI.md files in the repository simply contain "@CLAUDE.md" to reference the main context file, this file should follow the same pattern for consistency. The entire content should be replaced with just "@CLAUDE.md".
| @@ -1,19 +1,124 @@ | |||
| # Repository Guidelines | |||
| # CLAUDE.md | |||
There was a problem hiding this comment.
The file header says "# CLAUDE.md" but this file is named "AGENTS.md". This creates confusion about the file's purpose. Similar to the GEMINI.md files, if this is meant to reference CLAUDE.md, the header should match the actual filename or be removed in favor of just the reference.
| # CLAUDE.md | |
| # AGENTS.md |
| # CLAUDE.md | ||
|
|
||
| ## Project Structure & Module Organization | ||
| Source lives in `src/`. `lib.cairo` wires the modules, while `constants/` stores balance knobs and chain IDs. `models/` defines packed structs and events (for example `models/adventurer/*.cairo`), and `systems/<module>/contracts.cairo` hosts the StarkNet entry points. Shared helpers sit in `utils/`, including the Dojo test scaffolding in `utils/setup_denshokan.cairo`. Deployment and tooling scripts are under `scripts/`, and environment manifests such as `dojo_sepolia.toml` or `manifest_dev.json` describe world configuration. `target/` is generated output; do not edit it manually. | ||
| This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. | ||
|
|
||
| ## Build, Test, and Development Commands | ||
| Use `scarb build` to compile Sierra and CASM artifacts into `target/dev`. Run `scarb test` for the Cairo unit and integration tests that rely on Dojo’s testing toolkit. `scarb fmt` applies the repository’s formatting profile (`max-line-length = 120`). Deployment helpers include `scripts/deploy_sepolia.sh` or `scripts/deploy_slot.sh`; run them from this directory after exporting the required RPC credentials. | ||
| ## Project Overview | ||
|
|
||
| ## Coding Style & Naming Conventions | ||
| Follow Cairo 2 defaults: four-space indentation, `snake_case` for functions/modules, and `UpperCamelCase` for types. Constants stay in uppercase with underscores. Prefer explicit module imports over wildcards, and keep public interfaces grouped under `#[starknet::interface]` above their `#[dojo::contract]` modules. Always run `scarb fmt` before pushing to ensure consistent ordering (`sort-module-level-items = true`). | ||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | ||
|
|
||
| ## Testing Guidelines | ||
| Tests live alongside the code inside `contracts.cairo` modules (`#[test]` functions near the bottom). Use `dojo_cairo_test::spawn_test_world` helpers to provision a world and set expectations with `assert` or `#[should_panic(expected = ...)]`. Name tests with the `test_*` pattern and ensure both success paths and guarded failures are covered. Execute `scarb test` locally and include any reliance on `starknet::testing` utilities when seeding deterministic contexts. | ||
| ## Role & Context | ||
|
|
||
| ## Commit & Pull Request Guidelines | ||
| Match the existing history: concise, present-tense subjects such as `fix client trait calculation`; add context lines if rationale is non-obvious, and append PR numbers in parentheses when applicable. For pull requests, describe the gameplay or contract impact, note required migrations or manifest updates, list manual test commands (`scarb test`, deploy scripts), and link the tracked issue. Screenshots or log excerpts are welcome when behavior changes. | ||
| You are a **senior Starknet smart contract engineer** specializing in Cairo development. You have deep expertise in: | ||
|
|
||
| ## Deployment & Configuration Tips | ||
| Keep profile-specific settings in the corresponding `dojo_*.toml` files and update manifests when new systems or models are introduced. Regenerate SVG or other assets via `scripts/generate_svg.sh` whenever constants affecting visuals change. Verify world permissions in tests using the helpers in `utils/setup_denshokan.cairo` before promoting changes to shared environments. | ||
| - Cairo language syntax, patterns, and idioms | ||
| - Starknet protocol mechanics (storage, events, syscalls, account abstraction) | ||
| - Smart contract security (reentrancy, access control, integer overflow, Cairo-specific vulnerabilities) | ||
| - DeFi primitives (AMMs, lending, NFT marketplaces, bonding curves) | ||
| - Testing methodologies (unit, integration, fuzz, fork testing) | ||
| - Gas optimization and storage packing | ||
| - Dojo provable game engine | ||
|
|
||
| ## Development Commands | ||
|
|
||
| ```bash | ||
| # Build contracts (compiles Sierra and CASM to target/dev) | ||
| sozo build | ||
|
|
||
| # Run all tests | ||
| sozo test | ||
|
|
||
| # Run a specific test (use -f flag with test name pattern) | ||
| sozo test -f test_name | ||
|
|
||
| # Format code (max-line-length = 120, sorts module-level items) | ||
| scarb fmt | ||
|
|
||
| # Build for specific profile (sepolia, slot, mainnet) | ||
| sozo build -P sepolia | ||
|
|
||
| # Deploy to sepolia | ||
| ./scripts/deploy_sepolia.sh | ||
|
|
||
| # Deploy to slot | ||
| ./scripts/deploy_slot.sh | ||
| ``` | ||
|
|
||
| ## Architecture | ||
|
|
||
| ### Module Structure (`src/lib.cairo`) | ||
|
|
||
| - **`systems/`** - Dojo contract entry points with `#[dojo::contract]`: | ||
|
|
||
| - `game/contracts.cairo` - Core game loop (explore, attack, flee, equip, buy_items, select_stat_upgrades) | ||
| - `adventurer/contracts.cairo` - Character management | ||
| - `beast/contracts.cairo` - Enemy encounters | ||
| - `loot/contracts.cairo` - Item system | ||
| - `settings/contracts.cairo` - Game configuration | ||
| - `game_token/contracts.cairo` - Game NFT minting | ||
| - `objectives/contracts.cairo` - Quest/objective system | ||
| - `renderer/contracts.cairo` - On-chain SVG rendering | ||
|
|
||
| - **`models/`** - Packed structs and events: | ||
|
|
||
| - `adventurer/` - Stats, equipment, bag, items | ||
| - `beast.cairo`, `combat.cairo`, `market.cairo`, `obstacle.cairo` | ||
|
|
||
| - **`constants/`** - Game balance parameters and chain IDs | ||
| - **`utils/`** - Shared helpers, VRF integration, SVG renderer utilities | ||
| - **`libs/`** - Game logic libraries (`game.cairo`, `settings.cairo`) | ||
|
|
||
| ### Key Patterns | ||
|
|
||
| - Systems use `#[dojo::contract]` with `#[starknet::interface]` traits defined above them | ||
| - Models use packed storage for gas optimization | ||
| - Tests are in-file using `#[cfg(test)]` modules with `#[test]` functions | ||
| - Test helpers for world setup are in `utils/setup_denshokan.cairo` | ||
|
|
||
| ### Namespace and Profiles | ||
|
|
||
| Each environment has a namespace version (e.g., `ls_0_0_9`) configured in `dojo_*.toml`: | ||
|
|
||
| - `dojo_dev.toml` - Local development (katana) | ||
| - `dojo_sepolia.toml` - Sepolia testnet | ||
| - `dojo_slot.toml` - Slot environment | ||
| - `dojo_mainnet.toml` - Mainnet | ||
|
|
||
| ## Version Requirements | ||
|
|
||
| - Cairo 2.10.1 | ||
| - Dojo 1.6.0 | ||
| - Scarb 2.10.1 | ||
| - sozo 1.6.2 | ||
|
|
||
| ## Cairo Code Style | ||
|
|
||
| - 4-space indentation | ||
| - `snake_case` for functions/modules, `UpperCamelCase` for types | ||
| - Constants in uppercase with underscores | ||
| - Explicit module imports (avoid wildcards) | ||
| - Run `scarb fmt` before commits | ||
|
|
||
| ## Testing | ||
|
|
||
| Tests live inside contract modules as `#[test]` functions within `#[cfg(test)] mod tests` blocks. Example pattern: | ||
|
|
||
| ```cairo | ||
| #[cfg(test)] | ||
| mod tests { | ||
| use super::*; | ||
|
|
||
| #[test] | ||
| #[available_gas(50000)] | ||
| fn test_something() { | ||
| // test code | ||
| } | ||
|
|
||
| #[test] | ||
| #[should_panic(expected: ('expected error',))] | ||
| fn test_failure_case() { | ||
| // test that should panic | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Use `starknet::testing` utilities for deterministic contexts. |
There was a problem hiding this comment.
This file duplicates all the content from contracts/CLAUDE.md (lines 1-124). Following the pattern established by client/AGENTS.md and the root AGENTS.md, this file should contain only "@CLAUDE.md" to avoid content duplication and maintenance issues. Having duplicate content in multiple files means updates must be made in multiple places, increasing the risk of inconsistencies.
| @@ -0,0 +1,118 @@ | |||
| ## Role & Context | |||
|
|
|||
| You are a senior frontend developer specializing in modern web applications with deep expertise in React 18+, Vite 5+, and TypeScript 5+. Your primary focus is building performant, accessible, and maintainable user interfaces on top of decentralize networks like Ethereum and Starknet. | |||
There was a problem hiding this comment.
Typo: "decentralize" should be "decentralized" to properly modify "networks".
| You are a senior frontend developer specializing in modern web applications with deep expertise in React 18+, Vite 5+, and TypeScript 5+. Your primary focus is building performant, accessible, and maintainable user interfaces on top of decentralize networks like Ethereum and Starknet. | |
| You are a senior frontend developer specializing in modern web applications with deep expertise in React 18+, Vite 5+, and TypeScript 5+. Your primary focus is building performant, accessible, and maintainable user interfaces on top of decentralized networks like Ethereum and Starknet. |
| ## Fullstack development checklist | ||
|
|
||
| - Database schema aligned with API contracts | ||
| - Type-safe API implementation with shared types | ||
| - Frontend components matching backend capabilities | ||
| - Authentication flow spanning all layers | ||
| - Consistent error handling throughout stack | ||
| - End-to-end testing covering user journeys | ||
| - Performance optimization at each layer | ||
| - Deployment pipeline for entire feature | ||
|
|
||
| ## Data flow architecture | ||
|
|
||
| - Database design with proper relationships | ||
| - API endpoints following RESTful/GraphQL patterns | ||
| - Frontend state management synchronized with backend | ||
| - Optimistic updates with proper rollback | ||
| - Caching strategy across all layers | ||
| - Real-time synchronization when needed | ||
| - Consistent validation rules throughout | ||
| - Type safety from database to UI | ||
|
|
||
| ## Real-time implementation | ||
|
|
||
| - WebSocket server configuration | ||
| - Frontend WebSocket client setup | ||
| - Event-driven architecture design | ||
| - Message queue integration | ||
| - Presence system implementation | ||
| - Conflict resolution strategies | ||
| - Reconnection handling | ||
| - Scalable pub/sub patterns | ||
|
|
||
| ## Testing strategy | ||
|
|
||
| - Unit tests for business logic (backend & frontend) | ||
| - Integration tests for API endpoints | ||
| - Component tests for UI elements | ||
| - End-to-end tests for complete features | ||
| - Performance tests across stack | ||
| - Load testing for scalability | ||
| - Security testing throughout | ||
| - Cross-browser compatibility | ||
|
|
||
| ## Architecture decisions | ||
|
|
||
| Monorepo vs polyrepo evaluation | ||
| Shared code organization | ||
| API gateway implementation | ||
| BFF pattern when beneficial | ||
| Microservices vs monolith | ||
| State management selection | ||
| Caching layer placement | ||
| Build tool optimization | ||
|
|
||
| ## Performance optimization | ||
|
|
||
| - Database query optimization | ||
| - API response time improvement | ||
| - Frontend bundle size reduction | ||
| - Image and asset optimization | ||
| - Lazy loading implementation | ||
| - Server-side rendering decisions | ||
| - CDN strategy planning | ||
| - Cache invalidation patterns | ||
|
|
||
| ## Deployment pipeline | ||
|
|
||
| Infrastructure as code setup | ||
| CI/CD pipeline configuration | ||
| Environment management strategy | ||
| Database migration automation | ||
| Feature flag implementation | ||
| Blue-green deployment setup | ||
| Rollback procedures | ||
| Monitoring integration |
There was a problem hiding this comment.
This section appears to be generic fullstack guidance that doesn't apply to this specific project architecture. The project uses Cairo smart contracts (not a traditional backend with database schemas) and a React frontend. Concepts like "Database schema aligned with API contracts", "Database design with proper relationships", "WebSocket server configuration", and "Database query optimization" are not relevant to a blockchain-based application where state is managed on-chain. Consider replacing this with guidance specific to blockchain fullstack development (contract-to-frontend integration, event handling, state synchronization from chain, etc.).
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In @CLAUDE.md:
- Line 84: Replace the unhyphenated phrase "onchain" with the hyphenated form
"on-chain" in the sentence that currently reads "Death Mountain is a
token-agnostic, no-code onchain dungeon creator built on Starknet using Cairo
and the Dojo framework." so it becomes "no-code on-chain dungeon creator";
update only that token in the CLAUDE.md content to follow technical writing
conventions for compound adjectives.
In @client/CLAUDE.md:
- Line 7: Replace the nonstandard "onchain" token in the CLAUDE.md description
with the hyphenated form "on-chain" for consistency; specifically update the
sentence containing "token-agnostic onchain dungeon creator" to read
"token-agnostic on-chain dungeon creator" and ensure any other occurrences of
"onchain" in CLAUDE.md are similarly hyphenated to match project and industry
style.
In @contracts/AGENTS.md:
- Line 7: Replace the non-standard "onchain" with the hyphenated form "on-chain"
in the sentence starting "Death Mountain is a token-agnostic, no-code onchain
dungeon creator..." in AGENTS.md; also scan and update any other occurrences
(e.g., the phrasing referenced in CLAUDE.md) so all docs consistently use
"on-chain".
In @contracts/GEMINI.md:
- Line 7: Update the phrasing in the GEMINI.md description: replace the
standalone token "onchain" with the hyphenated form "on-chain" in the sentence
that begins "Death Mountain is a token-agnostic, no-code onchain dungeon
creator..." so it reads "no-code on-chain dungeon creator"; ensure only the
spelling is changed and surrounding punctuation/capitalization remains
unchanged.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
AGENTS.mdCLAUDE.mdGEMINI.mdclient/AGENTS.mdclient/CLAUDE.mdclient/GEMINI.mdcontracts/AGENTS.mdcontracts/CLAUDE.mdcontracts/GEMINI.md
🧰 Additional context used
🧠 Learnings (20)
📓 Common learnings
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Expose StarkNet entry points in systems/<module>/contracts.cairo
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Place #[starknet::interface] above the corresponding #[dojo::contract] module and group public interfaces there
Applied to files:
CLAUDE.mdcontracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Use dojo_cairo_test::spawn_test_world and starknet::testing utilities for deterministic contexts
Applied to files:
CLAUDE.mdcontracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Expose StarkNet entry points in systems/<module>/contracts.cairo
Applied to files:
CLAUDE.mdcontracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/models/**/*.cairo : Define packed structs and events under src/models/ (e.g., models/adventurer/*.cairo)
Applied to files:
CLAUDE.mdcontracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/{src,utils}/**/*.cairo : Run scarb fmt before pushing (max-line-length = 120; sort-module-level-items = true)
Applied to files:
CLAUDE.mdcontracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-12-17T13:20:17.126Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-17T13:20:17.126Z
Learning: Applies to client/.env : Configure environment variables for VITE_PUBLIC_NODE_URL, VITE_PUBLIC_TORII, and contract addresses (ETH, LORDS tokens, game contracts)
Applied to files:
CLAUDE.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/utils/setup_denshokan.cairo : Keep and update Dojo test scaffolding in utils/setup_denshokan.cairo
Applied to files:
CLAUDE.mdcontracts/CLAUDE.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Co-locate tests inside contracts.cairo with #[test] functions near the bottom
Applied to files:
CLAUDE.mdcontracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/{src,utils}/**/*.cairo : Follow Cairo 2 defaults: 4-space indentation; snake_case for functions/modules; UpperCamelCase for types; CONSTANT_CASE for constants
Applied to files:
CLAUDE.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: For PRs, describe gameplay/contract impact, migrations/manifest updates, manual test commands, and link the issue; include screenshots/logs when behavior changes
Applied to files:
CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Name tests with the test_* pattern and cover both success paths and guarded failures
Applied to files:
contracts/GEMINI.mdcontracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-12-17T13:20:17.126Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-17T13:20:17.126Z
Learning: React + TypeScript application using Vite as build tool for frontend development
Applied to files:
client/CLAUDE.md
📚 Learning: 2025-12-17T13:20:17.126Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-17T13:20:17.126Z
Learning: Death Mountain is a blockchain-based adventure RPG game built on StarkNet using the Dojo engine featuring adventurers battling beasts, collecting loot, and progressing through challenges
Applied to files:
client/CLAUDE.mdcontracts/CLAUDE.md
📚 Learning: 2025-12-17T13:20:17.126Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-17T13:20:17.126Z
Learning: Applies to client/src/**/*.tsx : Use Material-UI components and maintain consistent styling
Applied to files:
client/CLAUDE.md
📚 Learning: 2025-12-17T13:20:17.126Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-17T13:20:17.126Z
Learning: Applies to client/src/stores/**/*.ts : Use Zustand for global state management
Applied to files:
client/CLAUDE.md
📚 Learning: 2025-12-17T13:20:17.126Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-17T13:20:17.126Z
Learning: Applies to contracts/src/**/*.cairo : Use Cairo 2.10.1 syntax for smart contracts
Applied to files:
contracts/CLAUDE.mdcontracts/AGENTS.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/{src,utils}/**/*.cairo : Prefer explicit module imports over wildcard imports
Applied to files:
contracts/CLAUDE.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/utils/**/*.cairo : Place shared helpers in utils/ (including utils/setup_denshokan.cairo)
Applied to files:
contracts/CLAUDE.md
📚 Learning: 2025-09-27T04:41:07.357Z
Learnt from: CR
Repo: Provable-Games/death-mountain PR: 0
File: contracts/AGENTS.md:0-0
Timestamp: 2025-09-27T04:41:07.357Z
Learning: Applies to contracts/src/systems/**/contracts.cairo : Verify world permissions in tests using utils/setup_denshokan.cairo helpers
Applied to files:
contracts/CLAUDE.md
🪛 LanguageTool
CLAUDE.md
[grammar] ~84-~84: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet using...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
contracts/GEMINI.md
[grammar] ~7-~7: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
client/CLAUDE.md
[grammar] ~7-~7: Ensure spelling is correct
Context: ...nd for Death Mountain, a token-agnostic onchain dungeon creator on Starknet. The client...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
contracts/CLAUDE.md
[grammar] ~15-~15: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
contracts/AGENTS.md
[grammar] ~7-~7: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: sozo-test
- GitHub Check: Agent
- GitHub Check: claude-review
🔇 Additional comments (13)
CLAUDE.md (1)
1-184: Comprehensive architecture and development guide—well structured and technically sound.The CLAUDE.md document provides excellent end-to-end guidance spanning fullstack development patterns, Death Mountain architecture, Cairo/Dojo best practices, and deployment strategies. Content aligns with established project patterns and learnings (e.g., Dojo module structure, Cairo code style, testing with
dojo_cairo_test::spawn_test_world). The document is well-organized, actionable, and maintains appropriate technical depth throughout.client/AGENTS.md (1)
1-1: Agent routing file correctly references root CLAUDE.md.The minimal reference delegation allows frontend-specific agent contexts to inherit root fullstack and project guidance while maintaining a single source of truth for architectural patterns and development standards.
GEMINI.md (1)
1-1: Agent routing file correctly references root CLAUDE.md.Consistent with the client/AGENTS.md delegation pattern, this minimal reference enables the Gemini agent to inherit fullstack and project-specific guidance from the root CLAUDE.md while maintaining a single source of truth.
contracts/GEMINI.md (4)
21-44: No changes needed — all referenced scripts and paths are correct.The deployment scripts (
deploy_sepolia.sh,deploy_slot.sh) exist atcontracts/scripts/as documented, alongside configuration files for the deployment targets (dojo_sepolia.toml, dojo_slot.toml, etc.). Thetarget/devoutput path is a standard build artifact location and appropriate for the documentation.
46-75: Module structure and patterns match the actual codebase. All documented systems (game, adventurer, beast, loot, settings, game_token, objectives, renderer) have corresponding contracts.cairo files, models are properly organized in adventurer/ subdirectories and individual .cairo files, and lib.cairo exists at the specified location. The architecture description accurately reflects the current codebase structure.
75-75: Update path reference to correct location.The file exists and contains test setup helpers, but the path reference is incomplete. Update line 75 from
utils/setup_denshokan.cairotosrc/utils/setup_denshokan.cairo.Likely an incorrect or invalid review comment.
86-91: Verify version requirements against current project configuration.The specified versions (Cairo 2.10.1, Dojo 1.6.0, Scarb 2.10.1, sozo 1.6.2) appear significantly older than current stable releases as of January 2026 (Cairo ~2.12.0, Dojo 1.17.3, Scarb 2.15.0). However, these may be intentionally pinned for this project's compatibility. Verify against
Scarb.tomlto confirm whether these versions are outdated documentation or required for the death-mountain project's specific build configuration. Dojo and Scarb versions must be precisely matched per Dojo release notes.client/GEMINI.md (1)
1-1: No action required—reference syntax is correct.The
@CLAUDE.mdreference inclient/GEMINI.mdcorrectly resolves toclient/CLAUDE.mdfollowing a directory-scoped resolution pattern. This is consistent across the repository:root/AGENTS.mdandroot/GEMINI.mdboth use@CLAUDE.mdto referenceroot/CLAUDE.md, whileclient/AGENTS.mdandclient/GEMINI.mduse the same syntax to referenceclient/CLAUDE.md. Each directory maintains its own contextually appropriate CLAUDE.md file (with different content, as indicated by differing file sizes), and the unqualified@syntax resolves relative to the containing directory.AGENTS.md (1)
1-1: The@CLAUDE.mdreference syntax is valid and resolves correctly. This custom routing syntax is used consistently across the repository (root, client/, and contracts/ directories) to reference context files for different AI agents. AGENTS.md correctly references@CLAUDE.md.However, a broader multi-agent routing issue exists: All
GEMINI.mdfiles across the repository incorrectly contain@CLAUDE.mdinstead of@GEMINI.md, and contracts/GEMINI.md duplicates Claude's context instead of Gemini-specific guidance. These files should reference their respective agent contexts.contracts/CLAUDE.md (1)
1-120: Comprehensive contract development guide with strong alignment to project patterns.The documentation accurately reflects Cairo 2.10.1 syntax, Dojo 1.6.0 architecture, version requirements, code style conventions, and testing patterns. Architecture sections properly document module structure, key patterns, and namespace configurations consistent with learnings. Development commands and testing examples are well-structured and actionable.
client/CLAUDE.md (1)
1-118: Comprehensive frontend development guide with strong alignment to tech stack and patterns.The documentation accurately reflects React 18+, Vite 5+, TypeScript 5+, and specifies Zustand, MUI, and Dojo SDK integration patterns. Architecture sections clearly delineate state management, contexts, platform-specific code, and supporting directories. Version requirements and key dependencies are precise. Code style guidance is consistent with React best practices.
contracts/AGENTS.md (2)
1-3: Verify file intent: Reference @CLAUDE.md or standalone documentation?The PR description states AGENTS.md should "reference CLAUDE.md for multi-agent support," and the test plan requires confirming "@CLAUDE.md references work correctly." However, the provided content duplicates the full contracts/CLAUDE.md rather than referencing it. Additionally, the file title "# CLAUDE.md" is inconsistent with the filename
contracts/AGENTS.md.Clarify the intended design:
- Should this file contain a reference directive (e.g.,
@CLAUDE.md) pointing readers to shared guidance?- Or is full content duplication intentional for agent-specific routing?
1-124: Content alignment with contracts/CLAUDE.md is strong, pending reference pattern verification.Assuming the full-content approach is intentional, the documentation accurately mirrors contracts/CLAUDE.md with all Cairo style, version requirements, architecture patterns, and testing guidance properly specified. However, resolution of the file structure and reference syntax concern (above) is needed before approval.
| ## Project Overview | ||
|
|
||
| Death Mountain is a blockchain-based adventure RPG game built on StarkNet using the Dojo engine. The game features adventurers battling beasts, collecting loot, and progressing through various challenges. | ||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet using Cairo and the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
There was a problem hiding this comment.
Fix orthography: "onchain" → "on-chain".
Technical writing conventions prefer hyphenated "on-chain" for consistency with similar compound adjectives.
🔎 Proposed fix
-Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet using Cairo and the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system.
+Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet using Cairo and the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet using Cairo and the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | |
| Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet using Cairo and the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
🧰 Tools
🪛 LanguageTool
[grammar] ~84-~84: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet using...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In @CLAUDE.md at line 84, Replace the unhyphenated phrase "onchain" with the
hyphenated form "on-chain" in the sentence that currently reads "Death Mountain
is a token-agnostic, no-code onchain dungeon creator built on Starknet using
Cairo and the Dojo framework." so it becomes "no-code on-chain dungeon creator";
update only that token in the CLAUDE.md content to follow technical writing
conventions for compound adjectives.
|
|
||
| ## Project Overview | ||
|
|
||
| This is the React/TypeScript frontend for Death Mountain, a token-agnostic onchain dungeon creator on Starknet. The client integrates with Dojo smart contracts via the Dojo SDK and provides separate optimized experiences for desktop and mobile. |
There was a problem hiding this comment.
Standardize hyphenation: on-chain instead of onchain.
Use the standard English hyphenation "on-chain" for consistency with industry terminology and alignment with contracts/CLAUDE.md.
🔎 Proposed fix
-This is the React/TypeScript frontend for Death Mountain, a token-agnostic onchain dungeon creator on Starknet.
+This is the React/TypeScript frontend for Death Mountain, a token-agnostic on-chain dungeon creator on Starknet.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| This is the React/TypeScript frontend for Death Mountain, a token-agnostic onchain dungeon creator on Starknet. The client integrates with Dojo smart contracts via the Dojo SDK and provides separate optimized experiences for desktop and mobile. | |
| This is the React/TypeScript frontend for Death Mountain, a token-agnostic on-chain dungeon creator on Starknet. The client integrates with Dojo smart contracts via the Dojo SDK and provides separate optimized experiences for desktop and mobile. |
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: Ensure spelling is correct
Context: ...nd for Death Mountain, a token-agnostic onchain dungeon creator on Starknet. The client...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In @client/CLAUDE.md at line 7, Replace the nonstandard "onchain" token in the
CLAUDE.md description with the hyphenated form "on-chain" for consistency;
specifically update the sentence containing "token-agnostic onchain dungeon
creator" to read "token-agnostic on-chain dungeon creator" and ensure any other
occurrences of "onchain" in CLAUDE.md are similarly hyphenated to match project
and industry style.
|
|
||
| ## Coding Style & Naming Conventions | ||
| Follow Cairo 2 defaults: four-space indentation, `snake_case` for functions/modules, and `UpperCamelCase` for types. Constants stay in uppercase with underscores. Prefer explicit module imports over wildcards, and keep public interfaces grouped under `#[starknet::interface]` above their `#[dojo::contract]` modules. Always run `scarb fmt` before pushing to ensure consistent ordering (`sort-module-level-items = true`). | ||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
There was a problem hiding this comment.
Standardize hyphenation: on-chain instead of onchain.
Use the standard English hyphenation "on-chain" for consistency with industry terminology and alignment with contracts/CLAUDE.md.
🔎 Proposed fix
-Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework.
+Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework.Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In @contracts/AGENTS.md at line 7, Replace the non-standard "onchain" with the
hyphenated form "on-chain" in the sentence starting "Death Mountain is a
token-agnostic, no-code onchain dungeon creator..." in AGENTS.md; also scan and
update any other occurrences (e.g., the phrasing referenced in CLAUDE.md) so all
docs consistently use "on-chain".
|
|
||
| ## Project Overview | ||
|
|
||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
There was a problem hiding this comment.
Standardize hyphenation: on-chain instead of onchain.
Use the standard English hyphenation "on-chain" for consistency with industry terminology.
🔎 Proposed fix
-Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet.
+Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | |
| Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
🧰 Tools
🪛 LanguageTool
[grammar] ~15-~15: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
|
|
||
| ## Project Overview | ||
|
|
||
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
There was a problem hiding this comment.
Fix minor spelling: "onchain" → "on-chain".
Per modern conventions, this should use the hyphenated form.
🔎 Proposed fix
- Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system.
+ Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Death Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. | |
| Death Mountain is a token-agnostic, no-code on-chain dungeon creator built on Starknet. The contracts are written in Cairo using the Dojo framework. It features a complete RPG system with adventurers, beasts, items, obstacles, and a market system. |
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: Ensure spelling is correct
Context: ...h Mountain is a token-agnostic, no-code onchain dungeon creator built on Starknet. The ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In @contracts/GEMINI.md at line 7, Update the phrasing in the GEMINI.md
description: replace the standalone token "onchain" with the hyphenated form
"on-chain" in the sentence that begins "Death Mountain is a token-agnostic,
no-code onchain dungeon creator..." so it reads "no-code on-chain dungeon
creator"; ensure only the spelling is changed and surrounding
punctuation/capitalization remains unchanged.
Summary
CLAUDE.mdwith comprehensive fullstack development guidelines, architecture documentation, and code style guidanceclient/andcontracts/with tailored instructions for frontend and Cairo developmentAGENTS.mdandGEMINI.mdfiles that referenceCLAUDE.mdfor multi-agent supportTest plan
@CLAUDE.mdreferences work correctly in AGENTS.md and GEMINI.md files🤖 Generated with Claude Code
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.