Skip to content

Conversation

@MartianGreed
Copy link
Collaborator

@MartianGreed MartianGreed commented Jan 7, 2026

Closes #

Introduced changes

Checklist

  • Linked relevant issue
  • Updated relevant documentation
  • Added relevant tests
  • Add a dedicated CI job for new examples
  • Performed self-review of the code

Summary by CodeRabbit

  • Documentation
    • Added comprehensive Dojo.js skill docs: debugging, entities/queries, events, React patterns, setup, state management, transactions, and wallet workflows.
  • Chores
    • Updated ignore list and added a changeset noting the new skill documentation.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Jan 7, 2026

📝 Walkthrough

Walkthrough

Eight new Dojo.js skill documentation files were added under .claude/skills/ covering debugging, entities, events, React integration, setup, state, transactions, and wallets. A single .gitignore entry .claude-modified-files was also added.

Changes

Cohort / File(s) Summary
Dojo Skills Documentation
.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
Added eight comprehensive Markdown skill guides. Each file contains usage guidance, code examples (TypeScript/TSX), troubleshooting tips, patterns, and common pitfalls for its respective area. No runtime or API changes.
Git Configuration
.gitignore
Added entry: .claude-modified-files.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 In burrows of docs I quietly hop,
Eight new guides I tuck on the shelf,
Debug, transact, subscribe, and swap,
Wallets and state find their new home—myself,
A happy rabbit, knowledge in a hop!

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description check ⚠️ Warning The PR description is a bare template with no meaningful content—the 'Introduced changes' section contains only a dash and no checklist items are completed. Fill in the 'Introduced changes' section with details about the eight skills added, link to any related issue, and check off completed items in the checklist.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the main change: adding dojo.js skills for AI agents, which aligns with the eight new SKILL.md files added.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ 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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 2ac272e and 9bd9593.

📒 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-files to .gitignore is 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, and useEntityQuery are 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 useAtom with 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 waitForEntityChange pattern (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. The sdk.generateTypedData() and sdk.sendMessage() API signatures in the example match the actual SDK implementation. The parameter formats, return types, and Result pattern with .isOk(), .value, and .error are all correct.

@MartianGreed MartianGreed merged commit 1910f98 into main Jan 13, 2026
9 of 10 checks passed
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In @.claude/skills/dojo-entities/SKILL.md:
- Around line 23-77: The example incorrectly uses CompositeClause("And", [...])
which doesn't exist in @dojoengine/sdk; replace that usage with the exported
helper matching the intended logic—use AndComposeClause([clause1, clause2]) for
AND semantics or OrComposeClause([clause1, clause2]) for OR semantics, updating
the example text and any references to CompositeClause accordingly.
🧹 Nitpick comments (10)
.claude/skills/dojo-wallets/SKILL.md (2)

20-40: Add security warning to BurnerProvider configuration example.

The example shows masterAddress and masterPrivateKey without an immediate warning. While line 208 mentions funding concerns and the dojo-setup skill includes warnings, this section should also clearly state these credentials are for local development only.

📝 Suggested improvement

Add a note before or after the code block:

 ## BurnerProvider Setup
 
+> **Security Note**: `masterAddress` and `masterPrivateKey` shown below are for local development only. Never hardcode credentials in production code.
+
 ```tsx
 import { BurnerProvider, useBurner } from "@dojoengine/create-burner";

128-148: Clarify that PredeployedConnector is for development only.

The section title mentions "Dev Mode" but the example shows private keys without explicit warning. Make it clearer that this pattern should never be used in production.

📝 Suggested improvement
 ## PredeployedConnector (Dev Mode)
 
-For Katana predeployed accounts:
+For Katana predeployed accounts in local development:
+
+> **Dev Only**: This connector uses hardcoded private keys and should only be used with Katana in local development.
.claude/skills/dojo-setup/SKILL.md (1)

47-54: Consider using property shorthand for manifest.

Line 48 shows manifest: manifest which could use ES6 property shorthand.

♻️ Optional refactor
 const dojoConfig: DojoConfig = {
-    manifest: manifest, // From manifest.json
+    manifest, // From manifest.json
     rpcUrl: process.env.VITE_RPC_URL || "http://localhost:5050",
     toriiUrl: process.env.VITE_TORII_URL || "http://localhost:8080",
.claude/skills/dojo-debug/SKILL.md (7)

28-28: Clarify the command syntax.

The & operator backgrounds the first command, which may not be the intended behavior. If both services should run concurrently, consider using a process manager or separate terminal windows in the documentation.

📝 Suggested clarification
-katana & torii --world 0x... --rpc http://localhost:5050
+# Run in separate terminals:
+# Terminal 1:
+katana
+
+# Terminal 2:
+torii --world 0x... --rpc http://localhost:5050

39-46: Add language specifiers and security warning for CORS configuration.

The code block at line 39 lacks a language specifier. Additionally, the CORS configuration using "*" is insecure for production environments.

🔒 Proposed improvements
+```text
 Access to fetch blocked by CORS policy
+```

 **Solution:** Start Torii with CORS enabled:
 ```bash
-torii --world 0x... --allowed-origins "*"
+# Development only - restrict origins in production
+torii --world 0x... --allowed-origins "*"
+
+# Production example:
+# torii --world 0x... --allowed-origins "https://yourdomain.com"
</details>

---

`66-75`: **Add missing import statement.**

The code references `useDojoSDK` without importing it.



<details>
<summary>📦 Add import</summary>

```diff
 ```typescript
 // Debug: Check if entity exists
+import { useDojoSDK } from "@dojoengine/sdk/react";
+
 const { useDojoStore } = useDojoSDK();
 const allEntities = useDojoStore.getState().entities;
 console.log("All entities:", Object.keys(allEntities));

104-111: Add language specifier for error message block.

Markdown code blocks should specify a language for proper syntax highlighting and rendering.

✨ Suggested fix
+```text
 Type 'X' is not assignable to type 'Y'
+```

167-176: Add language specifier for error message block.

✨ Suggested fix
+```text
 Transaction reverted: insufficient balance
+```

180-187: Add language specifier for error message block.

✨ Suggested fix
+```text
 Invalid transaction nonce
+```

191-198: Add language specifier for error message block.

✨ Suggested fix
+```text
 Contract not found in manifest
+```
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9bd9593 and e334522.

📒 Files selected for processing (10)
  • .changeset/fancy-berries-post.md
  • .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
✅ Files skipped from review due to trivial changes (1)
  • .changeset/fancy-berries-post.md
🚧 Files skipped from review as they are similar to previous changes (4)
  • .gitignore
  • .claude/skills/dojo-transactions/SKILL.md
  • .claude/skills/dojo-state/SKILL.md
  • .claude/skills/dojo-react/SKILL.md
🧰 Additional context used
🪛 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)

🪛 markdownlint-cli2 (0.18.1)
.claude/skills/dojo-debug/SKILL.md

39-39: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


104-104: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


167-167: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


180-180: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


191-191: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

⏰ 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-examples
  • GitHub Check: build-packages
  • GitHub Check: build
🔇 Additional comments (11)
.claude/skills/dojo-entities/SKILL.md (2)

105-126: Good demonstration of subscription patterns and cleanup.

The examples correctly show:

  • Error handling in subscription callbacks
  • Proper cleanup with subscription.cancel()
  • Pagination handling with cursors

193-198: Excellent common pitfalls section.

The pitfalls listed are practical and address common developer mistakes:

  • Namespace format requirements
  • Type expectations for entity IDs
  • Subscription lifecycle management
  • Performance considerations with query limits
.claude/skills/dojo-wallets/SKILL.md (2)

190-204: Provider hierarchy is correctly structured.

The example demonstrates the proper nesting order, which aligns with the guidance in the Common Pitfalls section (line 210). The hierarchy correctly shows BurnerProvider wrapping DojoSdkProvider.


206-212: Comprehensive common pitfalls coverage.

The pitfalls address practical deployment and configuration issues that developers commonly encounter. The warnings about master account funding, class hash compatibility, and network configuration are particularly valuable.

.claude/skills/dojo-setup/SKILL.md (4)

41-41: Excellent security warning placement.

The prominent note about development-only credentials is well-positioned and clearly stated. This is better than the equivalent section in dojo-wallets/SKILL.md.


70-88: Clear configuration reference.

The environment variables section and configuration table provide a helpful quick reference for developers setting up the SDK.


103-108: Practical common pitfalls for SDK setup.

The pitfalls address key setup issues developers encounter: type generation, CORS configuration, chain ID matching, and provider hierarchy. These are valuable troubleshooting tips.


19-37: SDK initialization code is correct and matches the @dojoengine/sdk API.

The example accurately reflects the current init function signature, configuration structure (client and domain nesting), chainId values (SN_MAIN, SN_SEPOLIA), and generic type parameter usage with generated schema.

.claude/skills/dojo-events/SKILL.md (2)

1-238: Excellent comprehensive documentation!

This skill document provides thorough coverage of event subscriptions, token tracking, and related features. The code examples are well-structured with:

  • Clear use cases and triggers
  • Practical examples for each feature
  • Helpful inline comments (e.g., contract address format, token ID handling)
  • Cleanup patterns for subscriptions
  • Common pitfalls section

220-230: The import path @dojoengine/react/effect is correctly configured in the package exports and all three functions (createEventQueryAtom, createEventUpdatesAtom, createEventQueryWithUpdatesAtom) are properly exported. No changes needed.

.claude/skills/dojo-debug/SKILL.md (1)

257-258: Verify the DojoProvider constructor signature against official documentation.

The third parameter ("debug") requires verification against the @dojo package documentation to confirm whether it's a log level, configuration option, or other parameter type.

Comment on lines +23 to +77
```typescript
import { ToriiQueryBuilder, KeysClause, MemberClause } from "@dojoengine/sdk";

// Basic query with limit
const query = new ToriiQueryBuilder<typeof schema>()
.withLimit(100)
.build();

// Query with clause filter
const query = new ToriiQueryBuilder<typeof schema>()
.withClause(
KeysClause(["game-Player"], [playerAddress], "VariableLen").build()
)
.withLimit(50)
.build();

// Query with ordering
const query = new ToriiQueryBuilder<typeof schema>()
.addOrderBy("game-Player.score", "Desc")
.withLimit(10)
.build();

// Query specific models
const query = new ToriiQueryBuilder<typeof schema>()
.addEntityModel("game-Player")
.addEntityModel("game-Position")
.withLimit(100)
.build();
```

## Query Methods

### Pagination

```typescript
const query = new ToriiQueryBuilder<typeof schema>()
.withLimit(50) // Max results
.withCursor(nextCursor) // Pagination cursor
.withDirection("Forward") // "Forward" | "Backward"
.build();
```

### Clause Types

```typescript
// Keys clause - filter by entity keys
KeysClause(["namespace-Model"], [key1, key2], "VariableLen")

// Member clause - filter by field value
MemberClause("namespace-Model", "fieldName", "Eq", value)

// Composite clause - combine clauses
CompositeClause("And", [clause1, clause2])
```

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

@dojoengine/sdk ToriiQueryBuilder API documentation

💡 Result:

Here are the official API docs and examples for ToriiQueryBuilder in the @dojoengine/sdk:

  • Dojo SDK (ToriiQueryBuilder usage, examples, operators): Dojo docs — Client SDK (JavaScript). [1]
  • dojo.js package docs with init/getEntities examples using ToriiQueryBuilder. [2]
  • Dojo SDK overview (querying, Clause examples, advanced queries). [3]

If you want, I can open the exact page and copy the ToriiQueryBuilder TypeScript API/signature or provide sample code for your use case.

Sources:
[1] https://dojoengine.org/client/sdk/javascript
[2] https://dojoengine.github.io/dojo.js/
[3] https://dojoengine.org/client/sdk/javascript/overview


🌐 Web query:

@dojoengine/sdk KeysClause MemberClause operators "VariableLen" API signature

💡 Result:

Short answer — common API signatures and operator options:

  • KeysClause (JS/TS): KeysClause(models: string[] | string, keys: string[] | string, pattern: "FixedLen" | "VariableLen") — matches entities by model + key pattern. [1]

  • MemberClause (JS/TS): MemberClause(model: string, member: string, operator: "Eq" | "Neq" | "Gt" | "Gte" | "Lt" | "Lte" | "In" | "NotIn", value: any) — filter on a model field with the listed operators. [1]

  • VariableLen (pattern) — used for flexible key matching (e.g., match variable-length composite keys). Shown in Rust SDK as PatternMatching::VariableLen for KeysClause-style filters. [2]

Sources: Dojo JS/TS SDK docs (query/clause examples). [1] Dojo Rust SDK (KeysClause + PatternMatching::VariableLen example). [2]


🌐 Web query:

@dojoengine/sdk CompositeClause "Forward" "Backward" pagination direction API

💡 Result:

Short answer: CompositeClause in @dojoengine/sdk is for composing logical query clauses (And/Or); it does not define pagination direction. Pagination/direction is handled by the query transport (Torii / GraphQL) — use forward pagination with first/after and backward pagination with last/before (cursor-based) or offset/limit for offset-style paging. See the SDK docs and Torii GraphQL pagination notes.

Sources:

  • @dojoengine/sdk / dojo.js overview and examples (Clause/ClauseBuilder usage). [1]
  • Dojo SDK / Torii query examples showing Composite clause JSON structure. [2]
  • Torii GraphQL docs — pagination: use first/after for forward and last/before for backward. [3]

References:
[1] https://github.com/dojoengine/packages
[2] https://dojoengine.org/client/sdk/javascript/overview
[3] https://dojoengine.org/toolchain/torii/graphql

If you want, tell me which SDK call or code snippet you’re using and I’ll show the exact code to page forward/backward.


🌐 Web query:

ToriiQueryBuilder withDirection withLimit withCursor pagination methods JavaScript

💡 Result:

Short answer: Torii uses cursor-based queries in the JavaScript SDK's ToriiQueryBuilder. Use withLimit(size), withCursor(cursor) to page forward, and withDirection / withOrderBy (direction = "Asc" | "Desc") to control sort order. The API returns a nextCursor (or next_cursor) which you pass into withCursor for the next page.

Example (JS SDK):
import { ToriiQueryBuilder } from "@dojoengine/sdk";

// first page
const q1 = new ToriiQueryBuilder()
  .withClause(/* your clause */)
  .withLimit(50)
  .withOrderBy([{ field: "createdAt", direction: "Desc" }]) // or .withDirection("Desc") if available
  .build();

const res1 = await sdk.getEntities({ query: q1 });
const nextCursor = res1.nextCursor || res1.next_cursor;

// next page
if (nextCursor) {
  const q2 = new ToriiQueryBuilder()
    .withClause(/* same clause */)
    .withLimit(50)
    .withCursor(nextCursor)
    .build();

  const res2 = await sdk.getEntities({ query: q2 });
}

References: Torii pagination docs and SDK query examples. [1][2]

Sources:
[1] Torii pagination reference (cursor/size/nextCursor).
[2] Dojo / Torii JS SDK docs (ToriiQueryBuilder, withLimit/withOffset/withOrderBy examples).


🌐 Web query:

site:github.com dojoengine/dojo ToriiQueryBuilder TypeScript definitions source code

💡 Result:

The TypeScript source/definitions for ToriiQueryBuilder live in the Dojo JavaScript packages (the @dojoengine/sdk package) on the dojoengine GitHub; the package and docs show ToriiQueryBuilder is exported/used there. See the repository and SDK docs for the source files. [1][2]

Sources:
[1] dojoengine/packages (Dojo.js GitHub repository). [2] Dojo SDK documentation showing ToriiQueryBuilder usage.


🏁 Script executed:

#!/bin/bash
# Search for @dojoengine/sdk imports or package references
find . -type f \( -name "package.json" -o -name "*.ts" -o -name "*.tsx" -o -name "*.js" \) | head -20

Repository: dojoengine/dojo.js

Length of output: 923


🏁 Script executed:

#!/bin/bash
# Search for ToriiQueryBuilder class definition and implementation
rg -A 20 "class ToriiQueryBuilder" --type ts --type tsx

Repository: dojoengine/dojo.js

Length of output: 89


🏁 Script executed:

#!/bin/bash
# Search for ToriiQueryBuilder class definition
rg -A 20 "class ToriiQueryBuilder" --type ts

Repository: dojoengine/dojo.js

Length of output: 1533


🏁 Script executed:

#!/bin/bash
# Search for more methods in ToriiQueryBuilder including withCursor and withDirection
rg "withCursor|withDirection|addOrderBy|addEntityModel" packages/internal/src/toriiQueryBuilder.ts -A 5

Repository: dojoengine/dojo.js

Length of output: 965


🏁 Script executed:

#!/bin/bash
# Search for PaginationDirection type definition
rg "type PaginationDirection|enum PaginationDirection" packages/internal/src/

Repository: dojoengine/dojo.js

Length of output: 44


🏁 Script executed:

#!/bin/bash
# Search for PaginationDirection definition in all source files
rg "PaginationDirection" packages/internal/src/ -B 2 -A 2

Repository: dojoengine/dojo.js

Length of output: 2206


🏁 Script executed:

#!/bin/bash
# Search for CompositeClause implementation
rg "CompositeClause|export.*Clause" packages/internal/src/ -B 1 -A 3 | head -50

Repository: dojoengine/dojo.js

Length of output: 2431


🏁 Script executed:

#!/bin/bash
# Search for all exported clause functions and CompositeClause references
rg "export (function|class).*Clause|CompositeClause" packages/internal/src/clauseBuilder.ts

Repository: dojoengine/dojo.js

Length of output: 425


Fix CompositeClause API usage — use AndComposeClause or OrComposeClause instead.

The code example at line 75 shows CompositeClause("And", [clause1, clause2]), but the @dojoengine/sdk API exports separate functions: AndComposeClause([clause1, clause2]) for AND logic and OrComposeClause([clause1, clause2]) for OR logic. Update the example to use one of these functions instead.

All other APIs are correct:

  • KeysClause, MemberClause signatures and parameter types match
  • ToriiQueryBuilder methods (.withLimit(), .withCursor(), .withDirection(), .addOrderBy(), .addEntityModel()) and their parameters match
  • Direction values "Forward" and "Backward" are valid
🤖 Prompt for AI Agents
In @.claude/skills/dojo-entities/SKILL.md around lines 23 - 77, The example
incorrectly uses CompositeClause("And", [...]) which doesn't exist in
@dojoengine/sdk; replace that usage with the exported helper matching the
intended logic—use AndComposeClause([clause1, clause2]) for AND semantics or
OrComposeClause([clause1, clause2]) for OR semantics, updating the example text
and any references to CompositeClause accordingly.

@MartianGreed MartianGreed deleted the feat/skills branch January 13, 2026 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants