Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
📝 WalkthroughWalkthroughIntroduces comprehensive developer guidance documentation to the repository, including developer onboarding (CLAUDE.md), API patterns, ENS referrals rules, ponder indexing guidelines, and SDK development standards. Also removes CLAUDE.md from the gitignore file to track the documentation. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive Claude Code setup documentation to guide AI-assisted development. The documentation includes general codebase overview, development commands, architecture patterns, and path-specific rules for different parts of the monorepo. The setup is primarily auto-generated by Claude itself with manual verification, designed to reduce token usage by providing concise pattern descriptions rather than requiring the AI to analyze the entire codebase.
Changes:
- Added
.claude/directory with four rule files covering SDK development, Ponder indexing, ENS referrals, and API patterns - Added root
CLAUDE.mdfile with comprehensive repository overview, technology stack, development commands, and coding conventions - Removed CLAUDE.md from
.gitignoreto commit the documentation
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
.gitignore |
Removed CLAUDE.md ignore entry to allow committing AI assistant documentation |
.claude/rules/sdk-development.md |
Documents serialization patterns, internal module pattern, builder pattern, and SDK package structure |
.claude/rules/ponder-indexing.md |
Describes plugin architecture, directory layout, and key patterns for ENSIndexer |
.claude/rules/ens-referrals.md |
Details v0/v1 stability rules and domain types hierarchy for referral system |
.claude/rules/api-patterns.md |
Covers SWR cache, Hono factory, response codes, and API endpoint patterns |
.claude/CLAUDE.md |
Comprehensive 511-line overview covering repository structure, tech stack, commands, architecture, conventions, and workflows |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/CLAUDE.md:
- Line 211: The README entry incorrectly lists the package scope as
"@ensnode/ens-referrals"; update that string to the correct published package
scope "@namehash/ens-referrals" wherever it appears (e.g., the list item
currently reading "**@ensnode/ens-referrals** - ENS referral program logic.") so
imports generated from this doc use the correct package name.
- Around line 492-493: Tips 2 and 3 are duplicate (both instruct to use
`satisfies`); remove or merge them into a single tip that mentions "Follow the
builder pattern when creating domain objects — use `satisfies` for type safety
and to preserve type inference" and then renumber all subsequent tips
accordingly; update the content where `satisfies` is referenced to point to the
merged tip.
- Line 195: Update the documentation entry for "ensindexer" to point to the
actual handler implementation directory: change the reference from
`apps/ensindexer/ponder/src/` to `apps/ensindexer/src/plugins/`; note that
`apps/ensindexer/ponder/src/register-handlers.ts` only orchestrates imports
while the real event handlers live under the plugin folders (see
`ponder-indexing.md` for the correct pattern), so ensure the single-line
description for ensindexer names `apps/ensindexer/src/plugins/` as the handler
location.
In @.claude/rules/api-patterns.md:
- Around line 114-143: Update the markdown fenced code blocks in this section to
explicitly declare the TypeScript language (change every ``` to ```typescript)
so the linter MD040 passes; specifically ensure the block surrounding the
example that uses describeRoute, factory.createApp, validate, and
paginationQuerySchema is opened with ```typescript and check adjacent fenced
blocks in the same section for missing language specifiers and fix them as well.
In @.claude/rules/ens-referrals.md:
- Around line 42-49: Add a language tag to the fenced code block containing the
domain type hierarchy (the block that starts with "ReferrerMetrics" and lists
ScoredReferrerMetrics, RankedReferrerMetrics, AwardedReferrerMetrics, and
UnrankedReferrerMetrics) so the linter MD040 is satisfied; change the opening
fence from ``` to ```text and keep the closing fence as ``` so the diagram
remains unchanged but is explicitly marked as plain text.
- Around line 6-9: The glob patterns "referr*" already match any path beginning
with "referr", so the explicit "referral*" entries are redundant; remove the
duplicate patterns "apps/ensapi/src/cache/referral*" and
"apps/ensapi/src/middleware/referral*" from the rules so only the broader
"apps/ensapi/src/cache/referr*" and "apps/ensapi/src/middleware/referr*" remain
(update the list in .claude/rules/ens-referrals.md accordingly).
In @.claude/rules/ponder-indexing.md:
- Line 72: Update the incorrect example path that uses `src/` to use `handlers/`
instead: change any occurrences like
`apps/ensindexer/src/plugins/subgraph/plugins/subgraph/src/` to
`apps/ensindexer/src/plugins/subgraph/plugins/subgraph/handlers/`, and similarly
update the subgraph-sharing plugin examples to
`apps/ensindexer/src/plugins/subgraph/plugins/basenames/handlers/` (and
lineanames/threedns variants); ensure the docs consistently reference the
`handlers/` directory for plugin handler registration.
In @.claude/rules/sdk-development.md:
- Around line 37-46: The deserialize example for deserializeReferrerMetrics is
misleading: replace the simple "deserialize → safeParse" guidance with explicit
instruction to use z.preprocess (not z.transform) so preprocessing runs before
validation; update the documentation and the schema construction in the
deserialize flow to use z.preprocess(buildUnvalidated, finalSchema) and ensure
the preprocess function returns unknown, then safeParse/parse against the final
schema (reference symbols: deserializeReferrerMetrics, buildUnvalidated,
finalSchema, z.preprocess).
|
|
||
| ### Apps Structure | ||
|
|
||
| - **ensindexer** - Ponder-based blockchain indexer. Event handlers in `apps/ensindexer/ponder/src/`. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, check if the files mentioned exist and view the specific line
echo "=== Checking CLAUDE.md line 195 ==="
if [ -f ".claude/CLAUDE.md" ]; then
sed -n '190,200p' ".claude/CLAUDE.md"
else
echo "File not found"
fi
echo ""
echo "=== Looking for ponder-indexing.md ==="
find . -name "ponder-indexing.md" -type f 2>/dev/nullRepository: namehash/ensnode
Length of output: 817
🏁 Script executed:
#!/bin/bash
# Verify which paths contain actual event handler implementations
echo "=== Files in apps/ensindexer/ponder/src/ ==="
fd --type f "\.ts$" apps/ensindexer/ponder/src/ 2>/dev/null | head -20
echo ""
echo "=== Files in apps/ensindexer/src/plugins/ ==="
fd --type f "\.ts$" apps/ensindexer/src/plugins/ 2>/dev/null | head -20Repository: namehash/ensnode
Length of output: 1667
🏁 Script executed:
#!/bin/bash
# Check the overall structure of apps/ensindexer
echo "=== Directory structure of apps/ensindexer ==="
tree -L 3 apps/ensindexer/ 2>/dev/null || find apps/ensindexer/ -maxdepth 3 -type d | head -30Repository: namehash/ensnode
Length of output: 2186
🏁 Script executed:
#!/bin/bash
# Now let's examine ponder-indexing.md to see the conflicting information
echo "=== Content of ponder-indexing.md ==="
cat "./.claude/rules/ponder-indexing.md"Repository: namehash/ensnode
Length of output: 2777
🏁 Script executed:
#!/bin/bash
# Let's also check what's inside the register-handlers.ts to understand the relationship
echo "=== Content of register-handlers.ts ==="
cat "apps/ensindexer/ponder/src/register-handlers.ts"Repository: namehash/ensnode
Length of output: 2292
Correct handler location in documentation.
Line 195 directs event handlers to apps/ensindexer/ponder/src/, but actual handler implementations are in apps/ensindexer/src/plugins/. The ponder/src/ directory contains only orchestration (like register-handlers.ts which imports handlers from plugins). The ponder-indexing.md documentation correctly identifies handlers in plugin directories. Update line 195 to reference apps/ensindexer/src/plugins/ to match the actual codebase structure and prevent developer confusion.
🧰 Tools
🪛 LanguageTool
[typographical] ~195-~195: To join two clauses or introduce examples, consider using an em dash.
Context: ...s) ### Apps Structure - ensindexer - Ponder-based blockchain indexer. Event h...
(DASH_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/CLAUDE.md at line 195, Update the documentation entry for
"ensindexer" to point to the actual handler implementation directory: change the
reference from `apps/ensindexer/ponder/src/` to `apps/ensindexer/src/plugins/`;
note that `apps/ensindexer/ponder/src/register-handlers.ts` only orchestrates
imports while the real event handlers live under the plugin folders (see
`ponder-indexing.md` for the correct pattern), so ensure the single-line
description for ensindexer names `apps/ensindexer/src/plugins/` as the handler
location.
| - **@ensnode/ponder-subgraph** - Subgraph-compatible GraphQL API implementation. | ||
| - **@ensnode/ponder-metadata** - Metadata utilities for Ponder. | ||
| - **@ensnode/ensrainbow-sdk** - TypeScript client for ENSRainbow API. | ||
| - **@ensnode/ens-referrals** - ENS referral program logic. |
There was a problem hiding this comment.
Wrong package scope for ens-referrals — causes incorrect import path.
Line 211 lists @ensnode/ens-referrals, but the actual published package name is @namehash/ens-referrals — confirmed by the Package Naming section at line 66 ("Published packages: @namehash/*"), the Gotchas section at line 429 ("v0 of @namehash/ens-referrals"), and ens-referrals.md. An AI following this list would generate imports against the wrong package.
🐛 Proposed fix
-- **@ensnode/ens-referrals** - ENS referral program logic.
+- **@namehash/ens-referrals** - ENS referral program logic.📝 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.
| - **@ensnode/ens-referrals** - ENS referral program logic. | |
| - **@namehash/ens-referrals** - ENS referral program logic. |
🧰 Tools
🪛 LanguageTool
[style] ~211-~211: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...peScript client for ENSRainbow API. - @ensnode/ens-referrals - ENS referral program ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[typographical] ~211-~211: To join two clauses or introduce examples, consider using an em dash.
Context: ...ainbow API. - @ensnode/ens-referrals - ENS referral program logic. - **@namehas...
(DASH_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/CLAUDE.md at line 211, The README entry incorrectly lists the
package scope as "@ensnode/ens-referrals"; update that string to the correct
published package scope "@namehash/ens-referrals" wherever it appears (e.g., the
list item currently reading "**@ensnode/ens-referrals** - ENS referral program
logic.") so imports generated from this doc use the correct package name.
| 2. **Follow the builder pattern** when creating domain objects - use `satisfies` for type safety | ||
| 3. **Use `satisfies`** for type validation while preserving type inference |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Tips 2 and 3 are duplicates — both advise using satisfies.
Tip 2 already says "Follow the builder pattern when creating domain objects — use satisfies for type safety." Tip 3 restates "Use satisfies for type validation while preserving type inference." Merge or drop one.
🔧 Proposed fix
2. **Follow the builder pattern** when creating domain objects - use `satisfies` for type safety
-3. **Use `satisfies`** for type validation while preserving type inference
-4. **Match import ordering** defined in `biome.jsonc` - Biome will auto-fix on save
+3. **Match import ordering** defined in `biome.jsonc` - Biome will auto-fix on save
...(Renumber subsequent tips accordingly.)
🧰 Tools
🪛 LanguageTool
[typographical] ~492-~492: To join two clauses or introduce examples, consider using an em dash.
Context: ...r pattern** when creating domain objects - use satisfies for type safety 3. **Use...
(DASH_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/CLAUDE.md around lines 492 - 493, Tips 2 and 3 are duplicate (both
instruct to use `satisfies`); remove or merge them into a single tip that
mentions "Follow the builder pattern when creating domain objects — use
`satisfies` for type safety and to preserve type inference" and then renumber
all subsequent tips accordingly; update the content where `satisfies` is
referenced to point to the merged tip.
| ```typescript | ||
| import { describeRoute } from "hono-openapi"; | ||
| import { z } from "zod/v4"; | ||
|
|
||
| const app = factory | ||
| .createApp() | ||
| .use(someMiddleware) | ||
| .get( | ||
| "/referral-leaderboard", | ||
| describeRoute({ | ||
| tags: ["ENSAwards"], | ||
| summary: "Get Referrer Leaderboard", | ||
| description: "Returns paginated leaderboard data", | ||
| responses: { | ||
| 200: { description: "Success" }, | ||
| 500: { description: "Internal server error" }, | ||
| }, | ||
| }), | ||
| validate("query", paginationQuerySchema), | ||
| async (c) => { | ||
| try { | ||
| const { page, recordsPerPage } = c.req.valid("query"); | ||
| // ... handler logic | ||
| return c.json(serializeResponse(response)); | ||
| } catch (error) { | ||
| logger.error({ error }, "Error in endpoint"); | ||
| return c.json(errorResponse, 500); | ||
| } | ||
| }, | ||
| ); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Verify the fenced code block language specifier (MD040).
Static analysis flags a missing language specifier at line 42 in the file (which falls within or adjacent to one of the code blocks in this section). Ensure all fenced blocks in this section explicitly declare typescript.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/rules/api-patterns.md around lines 114 - 143, Update the markdown
fenced code blocks in this section to explicitly declare the TypeScript language
(change every ``` to ```typescript) so the linter MD040 passes; specifically
ensure the block surrounding the example that uses describeRoute,
factory.createApp, validate, and paginationQuerySchema is opened with
```typescript and check adjacent fenced blocks in the same section for missing
language specifiers and fix them as well.
| - "apps/ensapi/src/cache/referr*" | ||
| - "apps/ensapi/src/cache/referral*" | ||
| - "apps/ensapi/src/middleware/referr*" | ||
| - "apps/ensapi/src/middleware/referral*" |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Redundant glob patterns — referr* subsumes referral*.
referr* matches any path starting with referr, which already includes referral* patterns. The referral* entries at lines 7 and 9 are unreachable duplicates.
🔧 Proposed fix
- "apps/ensapi/src/cache/referr*"
- - "apps/ensapi/src/cache/referral*"
- "apps/ensapi/src/middleware/referr*"
- - "apps/ensapi/src/middleware/referral*"📝 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.
| - "apps/ensapi/src/cache/referr*" | |
| - "apps/ensapi/src/cache/referral*" | |
| - "apps/ensapi/src/middleware/referr*" | |
| - "apps/ensapi/src/middleware/referral*" | |
| - "apps/ensapi/src/cache/referr*" | |
| - "apps/ensapi/src/middleware/referr*" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/rules/ens-referrals.md around lines 6 - 9, The glob patterns
"referr*" already match any path beginning with "referr", so the explicit
"referral*" entries are redundant; remove the duplicate patterns
"apps/ensapi/src/cache/referral*" and "apps/ensapi/src/middleware/referral*"
from the rules so only the broader "apps/ensapi/src/cache/referr*" and
"apps/ensapi/src/middleware/referr*" remain (update the list in
.claude/rules/ens-referrals.md accordingly).
| ``` | ||
| ReferrerMetrics | ||
| └── ScoredReferrerMetrics (+ score calculation) | ||
| └── RankedReferrerMetrics (+ rank, isQualified, finalScore) | ||
| └── AwardedReferrerMetrics (+ awardPoolShare) | ||
|
|
||
| UnrankedReferrerMetrics (for addresses not on leaderboard) | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add language specifier to fenced code blocks.
The domain type hierarchy diagrams at lines 42–49 use bare ``` fences without a language tag, triggering MD040. Use ```text to silence the linter and convey intent.
🔧 Proposed fix
-```
+```text
ReferrerMetrics
└── ScoredReferrerMetrics (+ score calculation)
└── RankedReferrerMetrics (+ rank, isQualified, finalScore)
└── AwardedReferrerMetrics (+ awardPoolShare)
UnrankedReferrerMetrics (for addresses not on leaderboard)
-```
+```🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/rules/ens-referrals.md around lines 42 - 49, Add a language tag to
the fenced code block containing the domain type hierarchy (the block that
starts with "ReferrerMetrics" and lists ScoredReferrerMetrics,
RankedReferrerMetrics, AwardedReferrerMetrics, and UnrankedReferrerMetrics) so
the linter MD040 is satisfied; change the opening fence from ``` to ```text and
keep the closing fence as ``` so the diagram remains unchanged but is explicitly
marked as plain text.
|
|
||
| ## Working with Ponder Event Handlers | ||
|
|
||
| - Handlers are registered in plugin directories under `src/` (e.g., `apps/ensindexer/src/plugins/subgraph/plugins/subgraph/src/`) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check the actual structure of plugins directory
find apps/ensindexer/src/plugins -type d -name "src" | sortRepository: namehash/ensnode
Length of output: 42
🏁 Script executed:
# Read the specific line from the file to confirm content
sed -n '72p' .claude/rules/ponder-indexing.mdRepository: namehash/ensnode
Length of output: 189
🏁 Script executed:
# Get broader context around line 72
sed -n '70,75p' .claude/rules/ponder-indexing.mdRepository: namehash/ensnode
Length of output: 378
🏁 Script executed:
# List the actual structure of plugins directory
find apps/ensindexer/src/plugins -type f -o -type d | head -50Repository: namehash/ensnode
Length of output: 3228
🏁 Script executed:
# Get a tree view to understand the structure
ls -lR apps/ensindexer/src/plugins/ 2>/dev/null | head -100Repository: namehash/ensnode
Length of output: 4361
🏁 Script executed:
# Get complete subgraph structure
find apps/ensindexer/src/plugins/subgraph -type f -o -type d | sortRepository: namehash/ensnode
Length of output: 2605
🏁 Script executed:
# Also check if there's any nested structure in subgraph
ls -lR apps/ensindexer/src/plugins/subgraph/Repository: namehash/ensnode
Length of output: 3138
The path example uses src/ but handlers are actually organized in handlers/ directories.
The documentation claims handlers are at apps/ensindexer/src/plugins/subgraph/plugins/subgraph/src/, but the actual structure uses handlers/ instead of src/. All plugins across the codebase follow this pattern: handlers are in handlers/ subdirectories. The nested subgraph/plugins/subgraph/ path is correct (the subgraph plugin does have subgraph-sharing child plugins beneath it), but the directory name is wrong.
Correct paths:
- Core subgraph plugin:
apps/ensindexer/src/plugins/subgraph/plugins/subgraph/handlers/ - Subgraph-sharing plugins:
apps/ensindexer/src/plugins/subgraph/plugins/basenames/handlers/(and lineanames, threedns similarly)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/rules/ponder-indexing.md at line 72, Update the incorrect example
path that uses `src/` to use `handlers/` instead: change any occurrences like
`apps/ensindexer/src/plugins/subgraph/plugins/subgraph/src/` to
`apps/ensindexer/src/plugins/subgraph/plugins/subgraph/handlers/`, and similarly
update the subgraph-sharing plugin examples to
`apps/ensindexer/src/plugins/subgraph/plugins/basenames/handlers/` (and
lineanames/threedns variants); ensure the docs consistently reference the
`handlers/` directory for plugin handler registration.
| // 4. Create deserialize function with Zod validation | ||
| function deserializeReferrerMetrics( | ||
| serialized: SerializedReferrerMetrics | ||
| ): ReferrerMetrics { | ||
| // First deserialize, then validate with Zod | ||
| const deserialized = { ... }; | ||
| const parsed = schema.safeParse(deserialized); | ||
| if (parsed.error) throw new Error(...); | ||
| return parsed.data; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Deserialize example omits the z.preprocess() pattern actually used in the codebase.
The pseudocode implies a simple deserialize → safeParse flow, but the actual pattern in packages/ensnode-sdk/src/api/indexing-status/deserialize.ts uses z.preprocess() (not .transform()) precisely because preprocessing must run before validation against the final schema. An AI following this doc might reach for .transform() or a plain parse call and break the intended parse serialized → preprocess to unvalidated → validate pipeline.
Consider adding a note:
// ⚠️ Use z.preprocess(), NOT .transform()
// z.preprocess runs before validation (correct for the unvalidated→validated flow)
// z.transform runs after parsing and receives a typed input (incorrect here)
const schema = z.preprocess(buildUnvalidated, finalSchema);Based on learnings: the pattern of using z.preprocess() with a function returning unknown is intentional, enforcing the "parse serialized → preprocess to unvalidated → validate final schema" flow. Using .transform() would be incorrect here as it runs after parsing.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/rules/sdk-development.md around lines 37 - 46, The deserialize
example for deserializeReferrerMetrics is misleading: replace the simple
"deserialize → safeParse" guidance with explicit instruction to use z.preprocess
(not z.transform) so preprocessing runs before validation; update the
documentation and the schema construction in the deserialize flow to use
z.preprocess(buildUnvalidated, finalSchema) and ensure the preprocess function
returns unknown, then safeParse/parse against the final schema (reference
symbols: deserializeReferrerMetrics, buildUnvalidated, finalSchema,
z.preprocess).
| ### ENSRainbow (apps/ensrainbow) | ||
|
|
||
| Label hash recovery service. | ||
|
|
| - **@ensnode/ponder-subgraph** - Subgraph-compatible GraphQL API implementation. | ||
| - **@ensnode/ponder-metadata** - Metadata utilities for Ponder. | ||
| - **@ensnode/ensrainbow-sdk** - TypeScript client for ENSRainbow API. | ||
| - **@ensnode/ens-referrals** - ENS referral program logic. |
| ): ReferrerMetrics { | ||
| // First deserialize, then validate with Zod | ||
| const deserialized = { ... }; | ||
| const parsed = schema.safeParse(deserialized); |
Claude Code Setup
Sharing my Claude Code setup. It is mostly automatically generated by Claude itself, but with my instructions on what should be covered and quickly verified. Note that some statements may be incorrect; the main purpose is to reduce token usage so that Claude can infer the patterns we use from a simple description rather than manually reading and analyzing the entire codebase.
Besides that, I'm using:
claude-code-setup- general helpers to set up everythingclaude-md-management- updating, improving CLAUDE.mdcode-review- self-explanatory (haven't tried it yet)context7- MCP for documentationtypescript-lsp- language serverAll of those are official plugins. Haven't explored other plugins yet, and haven't set up any skills for manual testing and whatnot.
Not included, but I'm also using a few hooks, like running a linter after Claude edits the code.