feat(agent): add dojo.js skills #515
Conversation
📝 WalkthroughWalkthroughMultiple new skill documentation files for the Dojo.js framework have been added to the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Fix all issues with AI agents
In @.claude/skills/dojo-events/SKILL.md:
- Around line 64-99: Replace the placeholder values in the examples around
subscribeTokenBalance, getTokenBalances, and onTokenBalanceUpdated with clear
format rules and concrete examples: state that contractAddresses must be
0x-prefixed 20-byte hex Ethereum addresses (EIP-55 checksum recommended, e.g.,
"0x049d360..."), explain that for ERC-20 you typically provide the contract
address only (no tokenId) while for ERC-721/ERC-1155 tokenIds are either numeric
IDs or hex-strings (e.g., "1234" or "0x4d2"), and show one concrete example for
each case (ERC-20, ERC-721, ERC-1155) and for tokenIds (empty array means "all
tokens" vs explicit IDs). Update the examples using the function names
subscribeTokenBalance, getTokenBalances, and onTokenBalanceUpdated and the
parameters contractAddresses and tokenIds so readers see exact accepted formats
and sample values.
- Around line 23-46: The example is missing the import for ToriiQueryBuilder,
causing a runtime error when running the snippet; add an import for
ToriiQueryBuilder from the correct package (e.g. @dojoengine/sdk) at the top of
the example so the line new ToriiQueryBuilder<typeof schema>() resolves, or
explicitly state the correct package to import from; ensure the import sits
alongside the useDojoSDK import and keep references to ToriiQueryBuilder,
useDojoSDK, sdk, subscribeEventQuery, and schema consistent.
In @.claude/skills/dojo-setup/SKILL.md:
- Around line 45-51: Replace the insecure hardcoded keys in the dojoConfig
example: remove the literal masterPrivateKey value and instead reference a
server-side-only source (e.g., environment variable) and add an explicit
security warning above the example; mention that masterAddress/masterPrivateKey
must not be used in frontend code and should be loaded from process.env (or a
secrets manager) on the server, and add brief guidance that signing should occur
server-side or via secure wallet integrations (e.g., MetaMask or a backend HSM)
rather than embedding private keys in config.
- Around line 39-64: The example references an undefined createClient(provider)
in the DojoSdkProvider clientFn prop which will cause a runtime error; either
import/define a createClient function (e.g., a function that accepts the
provider and returns the client instance) and reference that here, or replace
the reference with an inline callback (clientFn={(provider) => /* return created
client */}) and add a short comment that clientFn must return a configured
client; ensure the symbol createClient is declared or removed and the
DojoSdkProvider usage documents that clientFn is a user-provided factory
callback.
In @.claude/skills/dojo-transactions/SKILL.md:
- Around line 174-182: The examples showing auto-generated action methods
(provider.spawn, provider.move, provider.get_stats) are vague—update the
SKILL.md to explain how and when those methods are generated from the contract
manifest, what in the manifest determines available method names and signatures,
how to discover them at runtime or via tooling (e.g., manifest introspection or
a CLI command), and what behavior to expect when a method is missing (error
thrown or undefined); either expand the existing example with these details and
a note linking to the manifest schema and discovery commands, or relocate the
examples to an "Advanced: auto-generated actions" section with clear caveats and
discovery instructions.
- Around line 64-81: The batch example in executeBatch uses provider.execute
with calldata: [structureType, x, y] but doesn't document required calldata
types/serialization; add a brief note or comment above the example (or a small
subsection) that specifies the expected formats for calldata items (e.g., which
values must be felts/uint256 parts/addresses, hex vs decimal, bigints or
string-encoded numbers) and the ordering expected by the contract, and mention
any helper/utility functions to serialize/encode values before passing them to
provider.execute (referencing executeBatch, provider.execute, calldata,
structureType, x, y so readers can map types to parameters).
- Around line 125-151: The optimistic update example in executeWithOptimism uses
store.applyOptimisticUpdate(transactionId, (draft) => { ... }) but doesn't
document the draft shape; update the SKILL.md example to show the draft's
structure and concrete mutations by describing the draft fields (e.g.,
draft.transactions: Transaction[], draft.balance: number, draft.items: Item[]),
and provide a short example mutation inside the callback (e.g., push a pending
transaction into draft.transactions and adjust draft.balance) so readers can see
available properties and typical updates; reference executeWithOptimism and the
applyOptimisticUpdate callback in the text to make it clear where the example
applies.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.claude/skills/dojo-debug/SKILL.md.claude/skills/dojo-entities/SKILL.md.claude/skills/dojo-events/SKILL.md.claude/skills/dojo-react/SKILL.md.claude/skills/dojo-setup/SKILL.md.claude/skills/dojo-state/SKILL.md.claude/skills/dojo-transactions/SKILL.md.claude/skills/dojo-wallets/SKILL.md.gitignore
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-26T13:27:46.736Z
Learnt from: CR
Repo: dojoengine/dojo.js PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-26T13:27:46.736Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : React hooks/components follow strict dependency arrays and early returns
Applied to files:
.claude/skills/dojo-react/SKILL.md
🪛 LanguageTool
.claude/skills/dojo-wallets/SKILL.md
[grammar] ~42-~42: Ensure spelling is correct
Context: ...rProvider> ); } ## useBurner Hook tsx import { useBurner } from "@dojoengine/create-burner"; function AccountManager() { const { account, // Current active account isDeploying, // True while creating new burner count, // Number of burners create, // Create new burner list, // List all burners select, // Select burner by address get, // Get burner by address clear, // Clear all burners listConnectors, // Get starknet-react connectors copyToClipboard, applyFromClipboard, generateAddressFromSeed, } = useBurner(); return (
Current: {account?.address}
<button onClick={() => create()} disabled={isDeploying}> {isDeploying ? "Creating..." : "New Burner"} # Creating Burners tsx const { create ...
(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: build-packages
- GitHub Check: build-examples
- GitHub Check: build
🔇 Additional comments (20)
.gitignore (1)
20-20: LGTM!Adding
.claude-modified-filesto.gitignoreis appropriate for excluding AI/IDE tooling artifacts from version control..claude/skills/dojo-entities/SKILL.md (2)
1-7: Frontmatter structure is solid.The YAML metadata is well-formatted with descriptive trigger keywords that should help with skill discovery. Triggers like
entity query,useModel,ToriiQueryBuilder, anduseEntityQueryare appropriately specific.
9-198: Documentation is comprehensive and well-organized.The skill file covers the entity query lifecycle clearly: from building queries with ToriiQueryBuilder, through pagination/filtering, to fetching/subscribing, and finally React hooks. The progression from basic to advanced examples is logical, and the "Common Pitfalls" section adds practical value (e.g., model name format, subscription cleanup).
Please verify that all Dojo.js SDK APIs referenced in the examples (e.g.,
ToriiQueryBuilder,useModel,useModels,useHistoricalModel,getEntityIdFromKeys) exist and match the current SDK version. If any APIs have changed or been deprecated, please update the examples accordingly..claude/skills/dojo-wallets/SKILL.md (2)
1-7: Frontmatter is well-crafted.The trigger keywords (
burner wallet,useBurner,BurnerProvider,account management,predeployed,session wallet) are specific and appropriate for skill discovery related to wallet/account operations.
9-211: Documentation provides solid coverage of wallet/account management patterns.The skill file covers the full workflow: setup via BurnerProvider, using the useBurner hook, creating burners (both random and deterministic), listing/selecting accounts, integrating with Starknet-React, managing predeployed accounts, import/export, and correct provider hierarchy. The common pitfalls section is especially valuable, addressing master account funding, class hash mismatches, provider ordering, and localStorage persistence.
Please verify that all SDK APIs referenced in the examples (e.g.,
BurnerProvider,useBurner,PredeployedConnector,WithAccount,usePredeployedAccounts) exist and match the current versions of@dojoengine/create-burner,@dojoengine/sdk, and@starknet-react/core. If any APIs have changed, renamed, or been removed, please update the examples to reflect the current API surface..claude/skills/dojo-react/SKILL.md (4)
1-40: Well-structured documentation front matter and provider setup.The YAML metadata is clearly defined, and the provider hierarchy example follows React best practices with proper nesting order. The code example is idiomatic.
42-142: Effect atoms and Result pattern properly implemented.The hook examples correctly handle all Result states (success, failure, initial). The infinite scroll implementation (line 123) properly uses
useAtomwith the destructured state and callback. Aligns well with the learning on dependency arrays and error handling.
144-204: Data transformation and custom hooks patterns are well-documented.The data formatter and custom subscription hook examples are clear and follow factory/hook composition patterns. Formatters at lines 171–182 properly separate model-level and field-level transforms.
206-265: Performance optimization and error handling patterns are solid.Zustand selectors with custom equality (line 217) correctly prevent unnecessary re-renders. The Error Boundary reset pattern and the pitfalls list reinforce best practices. The emphasis on always handling all Result.match cases (line 265) aligns with actual risk of incomplete pattern matching.
.claude/skills/dojo-debug/SKILL.md (4)
1-59: Connection troubleshooting guidance is practical and technically sound.The Torii health check (line 25) and CORS configuration are correct. The WebSocket guard check (line 52) and gRPC fallback pattern provide good defensive diagnostics. Commands and code examples are accurate.
61-122: Entity debugging and type troubleshooting patterns are well-explained.The entity ID computation pattern (line 73) and subscription callback logging (lines 90–92) are practical. The model name format section (lines 115–122) effectively shows both incorrect and correct usage, reducing common mistakes.
124-229: Error handling and performance patterns follow React best practices.Subscription cleanup (lines 155–159) with try-catch error handling is correctly implemented. Query optimization (line 207) and Zustand selector memoization (lines 225–228) demonstrate proper performance-conscious patterns with correct dependency arrays.
231-285: Debugging utilities and error reference are practical and implementable.The store subscription logging pattern (line 236), debug panel component (lines 273–285), and common error message table all provide actionable debugging guidance. Code examples are correct and can be readily implemented.
.claude/skills/dojo-state/SKILL.md (4)
1-64: Store interface design is comprehensive and well-documented.The GameState interface (lines 32–64) clearly defines entity operations, historical tracking, optimistic updates, queries, and subscriptions. Method signatures are properly typed with generics. The store setup pattern is idiomatic Zustand.
66-123: Optimistic update pattern is robust and complete.The optimistic update flow (lines 100–121) properly handles all three stages: immediate apply, transaction execution, and confirm/revert. Error handling with try-catch is correct. The draft mutation pattern (line 101) and transaction ID tracking prevent race conditions.
125-197: Subscription and entity change patterns follow React cleanup best practices.The useEffect cleanup (lines 136–138) properly unsubscribes. The
waitForEntityChangepattern (lines 149–153) includes timeout safety. Historical entity and subscription merge patterns are clean and well-integrated. Aligns with learnings on strict cleanup and early returns.
199-204: Common pitfalls section provides valuable guardrails.The pitfalls appropriately flag common mistakes: transaction confirmation/revert, stale closures, over-subscription, and cleanup. The recommendation to use
getState()for callbacks (line 202) prevents a frequent source of bugs. Practical and well-chosen..claude/skills/dojo-setup/SKILL.md (1)
1-17: Well-structured frontmatter and clear use-case guidance. Good job laying out when to use this skill..claude/skills/dojo-events/SKILL.md (1)
210-225: [Your rewritten review comment text here]
[Exactly ONE classification tag].claude/skills/dojo-transactions/SKILL.md (1)
88-109: No issues found. Thesdk.generateTypedData()andsdk.sendMessage()API signatures in the example match the actual SDK implementation. The parameter formats, return types, and Result pattern with.isOk(),.value, and.errorare all correct.
| ```tsx | ||
| const { sdk } = useDojoSDK(); | ||
|
|
||
| const [initialEvents, subscription] = await sdk.subscribeEventQuery({ | ||
| query: new ToriiQueryBuilder<typeof schema>() | ||
| .addEntityModel("game-GameEvent") | ||
| .withLimit(100), | ||
| callback: ({ data, error }) => { | ||
| if (error) { | ||
| console.error("Event error:", error); | ||
| return; | ||
| } | ||
| console.log("New event:", data); | ||
| } | ||
| }); | ||
|
|
||
| // Process initial events | ||
| initialEvents.items.forEach(event => { | ||
| console.log(event.models.game.GameEvent); | ||
| }); | ||
|
|
||
| // Cleanup | ||
| subscription.cancel(); | ||
| ``` |
There was a problem hiding this comment.
Missing import for ToriiQueryBuilder.
Line 28 uses new ToriiQueryBuilder<typeof schema>() but this class is never imported in the example. Developers copying this code will get a runtime error. Add the required import statement at the top of the example.
Suggested fix
```tsx
const { sdk } = useDojoSDK();
+import { ToriiQueryBuilder } from "@dojoengine/sdk"; // Add this import
const [initialEvents, subscription] = await sdk.subscribeEventQuery({
query: new ToriiQueryBuilder<typeof schema>()Or clarify whether ToriiQueryBuilder should be imported from a different package.
📝 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.
| ```tsx | |
| const { sdk } = useDojoSDK(); | |
| const [initialEvents, subscription] = await sdk.subscribeEventQuery({ | |
| query: new ToriiQueryBuilder<typeof schema>() | |
| .addEntityModel("game-GameEvent") | |
| .withLimit(100), | |
| callback: ({ data, error }) => { | |
| if (error) { | |
| console.error("Event error:", error); | |
| return; | |
| } | |
| console.log("New event:", data); | |
| } | |
| }); | |
| // Process initial events | |
| initialEvents.items.forEach(event => { | |
| console.log(event.models.game.GameEvent); | |
| }); | |
| // Cleanup | |
| subscription.cancel(); | |
| ``` |
🤖 Prompt for AI Agents
In @.claude/skills/dojo-events/SKILL.md around lines 23 - 46, The example is
missing the import for ToriiQueryBuilder, causing a runtime error when running
the snippet; add an import for ToriiQueryBuilder from the correct package (e.g.
@dojoengine/sdk) at the top of the example so the line new
ToriiQueryBuilder<typeof schema>() resolves, or explicitly state the correct
package to import from; ensure the import sits alongside the useDojoSDK import
and keep references to ToriiQueryBuilder, useDojoSDK, sdk, subscribeEventQuery,
and schema consistent.
| const [balances, subscription] = await sdk.subscribeTokenBalance({ | ||
| contractAddresses: ["0x049d36..."], // Token contract | ||
| accountAddresses: [playerAddress], | ||
| callback: (balance) => { | ||
| console.log("Balance updated:", balance.balance); | ||
| } | ||
| }); | ||
|
|
||
| // Initial balances | ||
| balances.items.forEach(b => { | ||
| console.log(`Token: ${b.token_id}, Balance: ${b.balance}`); | ||
| }); | ||
| ``` | ||
|
|
||
| ### Get Token Balances | ||
|
|
||
| ```tsx | ||
| const balances = await sdk.getTokenBalances({ | ||
| contractAddresses: ["0x..."], | ||
| accountAddresses: [playerAddress], | ||
| pagination: { limit: 100 } | ||
| }); | ||
| ``` | ||
|
|
||
| ### Track Balance Updates Only | ||
|
|
||
| ```tsx | ||
| const subscription = await sdk.onTokenBalanceUpdated({ | ||
| contractAddresses: ["0x..."], | ||
| accountAddresses: [playerAddress], | ||
| tokenIds: [], | ||
| callback: (balance) => { | ||
| updateUI(balance); | ||
| } | ||
| }); | ||
| ``` |
There was a problem hiding this comment.
Token ID format and contract address formatting lack documentation.
Lines 65 and 94 include placeholder values (0x049d36..., tokenIds: []) without explaining:
- The required format for contract addresses (padding, checksum, length)
- The expected format for token IDs (varies by ERC20 vs ERC721, integer vs string, etc.)
Add format specifications or examples to help developers avoid mistakes.
Suggested enhancement
const [balances, subscription] = await sdk.subscribeTokenBalance({
- contractAddresses: ["0x049d36..."], // Token contract
+ // Contract addresses must be full hex strings with 0x prefix, padded to 66 characters
+ contractAddresses: ["0x049d36570342e4e4a96c9f6666a64d4d67c3c5c5c5c5c5c5c5c5c5c5c5c5c5c"],
accountAddresses: [playerAddress],
callback: (balance) => {
console.log("Balance updated:", balance.balance);
}
});And for tokenIds:
- tokenIds: [],
+ tokenIds: [], // Leave empty for ERC20; for ERC721 use ['0x1', '0x2'] for specific token IDs🤖 Prompt for AI Agents
In @.claude/skills/dojo-events/SKILL.md around lines 64 - 99, Replace the
placeholder values in the examples around subscribeTokenBalance,
getTokenBalances, and onTokenBalanceUpdated with clear format rules and concrete
examples: state that contractAddresses must be 0x-prefixed 20-byte hex Ethereum
addresses (EIP-55 checksum recommended, e.g., "0x049d360..."), explain that for
ERC-20 you typically provide the contract address only (no tokenId) while for
ERC-721/ERC-1155 tokenIds are either numeric IDs or hex-strings (e.g., "1234" or
"0x4d2"), and show one concrete example for each case (ERC-20, ERC-721,
ERC-1155) and for tokenIds (empty array means "all tokens" vs explicit IDs).
Update the examples using the function names subscribeTokenBalance,
getTokenBalances, and onTokenBalanceUpdated and the parameters contractAddresses
and tokenIds so readers see exact accepted formats and sample values.
| ## React Provider Setup | ||
|
|
||
| ```tsx | ||
| import { DojoSdkProvider } from "@dojoengine/sdk/react"; | ||
| import { DojoConfig, DojoProvider } from "@dojoengine/core"; | ||
|
|
||
| const dojoConfig: DojoConfig = { | ||
| manifest: manifest, // From manifest.json | ||
| rpcUrl: "http://localhost:5050", | ||
| toriiUrl: "http://localhost:8080", | ||
| masterAddress: "0x...", | ||
| masterPrivateKey: "0x...", | ||
| }; | ||
|
|
||
| function App() { | ||
| return ( | ||
| <DojoSdkProvider | ||
| dojoConfig={dojoConfig} | ||
| sdk={sdk} | ||
| clientFn={(provider) => createClient(provider)} | ||
| > | ||
| {children} | ||
| </DojoSdkProvider> | ||
| ); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Undefined createClient function in React provider example.
Line 58 references createClient(provider) but this function is never imported or defined. Developers copying this example will encounter a runtime error. Either define the function (or import it) or clearly document that it's a user-provided callback.
Suggested clarification
function App() {
return (
<DojoSdkProvider
dojoConfig={dojoConfig}
sdk={sdk}
- clientFn={(provider) => createClient(provider)}
+ clientFn={(provider) => {
+ // User-provided function to initialize Dojo client
+ // Example: return new DojoClient(provider);
+ return createClient(provider);
+ }}
>
{children}
</DojoSdkProvider>
);
}Or add a clarifying note above the example explaining what createClient should be.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In @.claude/skills/dojo-setup/SKILL.md around lines 39 - 64, The example
references an undefined createClient(provider) in the DojoSdkProvider clientFn
prop which will cause a runtime error; either import/define a createClient
function (e.g., a function that accepts the provider and returns the client
instance) and reference that here, or replace the reference with an inline
callback (clientFn={(provider) => /* return created client */}) and add a short
comment that clientFn must return a configured client; ensure the symbol
createClient is declared or removed and the DojoSdkProvider usage documents that
clientFn is a user-provided factory callback.
| const dojoConfig: DojoConfig = { | ||
| manifest: manifest, // From manifest.json | ||
| rpcUrl: "http://localhost:5050", | ||
| toriiUrl: "http://localhost:8080", | ||
| masterAddress: "0x...", | ||
| masterPrivateKey: "0x...", | ||
| }; |
There was a problem hiding this comment.
Security vulnerability: Hardcoded private key in example code.
Line 50 shows masterPrivateKey: "0x..." hardcoded directly in component code. This is a critical security anti-pattern and will mislead developers into insecure practices. Private keys should never be hardcoded in frontend code or exposed in configuration files.
Provide secure alternatives:
- Load from environment variables (e.g.,
process.env.MASTER_PRIVATE_KEY) - Clarify that
masterAddress/masterPrivateKeyshould only be used in server-side contexts if at all - Document secure patterns for transaction signing
Suggested fix
const dojoConfig: DojoConfig = {
manifest: manifest,
rpcUrl: "http://localhost:5050",
toriiUrl: "http://localhost:8080",
masterAddress: process.env.VITE_MASTER_ADDRESS || "0x...",
- masterPrivateKey: "0x...",
+ // IMPORTANT: Never hardcode private keys in frontend code.
+ // For server-side use only, load from secure secret management.
+ masterPrivateKey: process.env.VITE_MASTER_PRIVATE_KEY || "",
};Add a warning callout before the example:
⚠️ **Security Warning**: `masterPrivateKey` should only be used in server-side contexts. Never expose private keys in frontend code or version control.
📝 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.
| const dojoConfig: DojoConfig = { | |
| manifest: manifest, // From manifest.json | |
| rpcUrl: "http://localhost:5050", | |
| toriiUrl: "http://localhost:8080", | |
| masterAddress: "0x...", | |
| masterPrivateKey: "0x...", | |
| }; | |
| const dojoConfig: DojoConfig = { | |
| manifest: manifest, // From manifest.json | |
| rpcUrl: "http://localhost:5050", | |
| toriiUrl: "http://localhost:8080", | |
| masterAddress: process.env.VITE_MASTER_ADDRESS || "0x...", | |
| // IMPORTANT: Never hardcode private keys in frontend code. | |
| // For server-side use only, load from secure secret management. | |
| masterPrivateKey: process.env.VITE_MASTER_PRIVATE_KEY || "", | |
| }; |
🤖 Prompt for AI Agents
In @.claude/skills/dojo-setup/SKILL.md around lines 45 - 51, Replace the
insecure hardcoded keys in the dojoConfig example: remove the literal
masterPrivateKey value and instead reference a server-side-only source (e.g.,
environment variable) and add an explicit security warning above the example;
mention that masterAddress/masterPrivateKey must not be used in frontend code
and should be loaded from process.env (or a secrets manager) on the server, and
add brief guidance that signing should occur server-side or via secure wallet
integrations (e.g., MetaMask or a backend HSM) rather than embedding private
keys in config.
| const executeBatch = async () => { | ||
| const tx = await provider.execute( | ||
| account, | ||
| [ | ||
| { | ||
| contractName: "actions", | ||
| entrypoint: "collect_resources", | ||
| calldata: [] | ||
| }, | ||
| { | ||
| contractName: "actions", | ||
| entrypoint: "build_structure", | ||
| calldata: [structureType, x, y] | ||
| } | ||
| ], | ||
| "game" | ||
| ); | ||
| }; |
There was a problem hiding this comment.
Batch transaction example lacks calldata type documentation.
Line 76 includes calldata: [structureType, x, y] without specifying data types or serialization format. In Starknet, calldata typically requires specific formatting (e.g., felts, addresses, numbers). Developers may not know how to properly serialize these values.
Consider adding a clarifying comment or separate subsection documenting calldata format requirements.
Suggested enhancement
{
contractName: "actions",
entrypoint: "build_structure",
- calldata: [structureType, x, y]
+ // calldata must match contract ABI types
+ // Example: [structureType (u32), x (u32), y (u32)]
+ calldata: [structureType, x, y]
}Or add a note section before the batch example explaining calldata format.
📝 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.
| const executeBatch = async () => { | |
| const tx = await provider.execute( | |
| account, | |
| [ | |
| { | |
| contractName: "actions", | |
| entrypoint: "collect_resources", | |
| calldata: [] | |
| }, | |
| { | |
| contractName: "actions", | |
| entrypoint: "build_structure", | |
| calldata: [structureType, x, y] | |
| } | |
| ], | |
| "game" | |
| ); | |
| }; | |
| const executeBatch = async () => { | |
| const tx = await provider.execute( | |
| account, | |
| [ | |
| { | |
| contractName: "actions", | |
| entrypoint: "collect_resources", | |
| calldata: [] | |
| }, | |
| { | |
| contractName: "actions", | |
| entrypoint: "build_structure", | |
| // calldata must match contract ABI types | |
| // Example: [structureType (u32), x (u32), y (u32)] | |
| calldata: [structureType, x, y] | |
| } | |
| ], | |
| "game" | |
| ); | |
| }; |
🤖 Prompt for AI Agents
In @.claude/skills/dojo-transactions/SKILL.md around lines 64 - 81, The batch
example in executeBatch uses provider.execute with calldata: [structureType, x,
y] but doesn't document required calldata types/serialization; add a brief note
or comment above the example (or a small subsection) that specifies the expected
formats for calldata items (e.g., which values must be felts/uint256
parts/addresses, hex vs decimal, bigints or string-encoded numbers) and the
ordering expected by the contract, and mention any helper/utility functions to
serialize/encode values before passing them to provider.execute (referencing
executeBatch, provider.execute, calldata, structureType, x, y so readers can map
types to parameters).
| ```tsx | ||
| async function executeWithOptimism(action: string, calldata: any[]) { | ||
| const { provider, useDojoStore } = useDojoSDK(); | ||
| const store = useDojoStore.getState(); | ||
| const transactionId = `${action}-${Date.now()}`; | ||
|
|
||
| // Apply optimistic update | ||
| store.applyOptimisticUpdate(transactionId, (draft) => { | ||
| // Update state optimistically | ||
| }); | ||
|
|
||
| try { | ||
| const tx = await provider.execute( | ||
| account, | ||
| { contractName: "actions", entrypoint: action, calldata }, | ||
| "game" | ||
| ); | ||
|
|
||
| // Wait for transaction to be accepted | ||
| await account.waitForTransaction(tx.transaction_hash); | ||
|
|
||
| store.confirmTransaction(transactionId); | ||
| } catch (error) { | ||
| store.revertOptimisticUpdate(transactionId); | ||
| throw error; | ||
| } | ||
| } |
There was a problem hiding this comment.
Incomplete optimistic update callback documentation.
Lines 132–134 show store.applyOptimisticUpdate(transactionId, (draft) => { ... }) but the callback receives a draft parameter whose shape is never explained. Developers won't know what fields/methods are available on draft, making the example unhelpful for implementation.
Document the draft object's structure or provide a concrete example showing actual state mutations.
Suggested enhancement
// Apply optimistic update
store.applyOptimisticUpdate(transactionId, (draft) => {
- // Update state optimistically
+ // draft is a mutable copy of the current state
+ // Example: draft.players[account.address].position = newPosition;
});🤖 Prompt for AI Agents
In @.claude/skills/dojo-transactions/SKILL.md around lines 125 - 151, The
optimistic update example in executeWithOptimism uses
store.applyOptimisticUpdate(transactionId, (draft) => { ... }) but doesn't
document the draft shape; update the SKILL.md example to show the draft's
structure and concrete mutations by describing the draft fields (e.g.,
draft.transactions: Transaction[], draft.balance: number, draft.items: Item[]),
and provide a short example mutation inside the callback (e.g., push a pending
transaction into draft.transactions and adjust draft.balance) so readers can see
available properties and typical updates; reference executeWithOptimism and the
applyOptimisticUpdate callback in the text to make it clear where the example
applies.
| ```tsx | ||
| // If your contract has a "spawn" system, you can call it directly: | ||
| const tx = await provider.spawn(account); | ||
|
|
||
| // For actions with arguments: | ||
| const tx = await provider.move(account, { direction: 1 }); | ||
|
|
||
| // For view functions (no account needed): | ||
| const stats = await provider.get_stats({ player: address }); |
There was a problem hiding this comment.
Auto-generated action methods example is vague.
Lines 176–182 claim that provider.spawn(account) and provider.move(account, { direction: 1 }) are "auto-generated" from the manifest but don't explain:
- How/when these methods are generated
- What determines which methods are available
- How to inspect or discover available methods
- What happens if a method doesn't exist
This is too vague for developers to know how to use the feature. Either provide clearer documentation or move this to an advanced section with caveats.
🤖 Prompt for AI Agents
In @.claude/skills/dojo-transactions/SKILL.md around lines 174 - 182, The
examples showing auto-generated action methods (provider.spawn, provider.move,
provider.get_stats) are vague—update the SKILL.md to explain how and when those
methods are generated from the contract manifest, what in the manifest
determines available method names and signatures, how to discover them at
runtime or via tooling (e.g., manifest introspection or a CLI command), and what
behavior to expect when a method is missing (error thrown or undefined); either
expand the existing example with these details and a note linking to the
manifest schema and discovery commands, or relocate the examples to an
"Advanced: auto-generated actions" section with clear caveats and discovery
instructions.
Closes #
Introduced changes
Checklist
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.