Repository navigation
Clarify capability execute snippets - #447
Conversation
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR adds an ChangesCapability execution examples in search output
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
|
🔎 Preview deployed: https://kody-pr-447.kentcdodds.workers.dev Worker: Mocks:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/worker/src/mcp/tools/search-format.node.test.ts (1)
165-234: ⚡ Quick winAdd one capability-detail test for non-identifier capability IDs.
The new accessor builder has a branch for bracket notation, but current additions only assert dot-notation IDs. Please add one test (e.g.
foo-bar) asserting bothusageandexecuteExampleusecodemode["foo-bar"](...).Also applies to: 251-262
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/worker/src/mcp/tools/search-format.node.test.ts` around lines 165 - 234, Add a new test that calls formatEntityDetailMarkdown with a capability whose id contains a non-identifier character (e.g., 'foo-bar') and assert that the returned structured.usage and structured.executeExample use bracket notation (codemode["foo-bar"]) rather than dot notation; mirror the existing capability test (the test around formatEntityDetailMarkdown) but set id to 'foo-bar' and assert usage === 'execute with codemode["foo-bar"](args)' (or stringContaining) and that executeExample contains 'return await codemode["foo-bar"](input)'; also duplicate the same assertion pattern for the second similar test block referenced (lines ~251-262) so both code paths (dot vs bracket) are covered.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/worker/src/mcp/tools/execute.ts`:
- Line 50: The guidance text only documents dot notation for calling discovered
capabilities; update the wording to explain both dot notation for valid
identifier names and bracket notation for non-identifier names (e.g.,
codemode.capability_id(input) and codemode["capability-id"](input)) to match how
buildCodemodeCapabilityAccessor generates accessors. Edit the guidance line in
packages/worker/src/mcp/tools/execute.ts (and mirror the change in
packages/worker/src/mcp/server-instructions.ts, docs/use/execute.md, and
docs/use/search.md) so it mentions both patterns and includes the two short
examples; reference buildCodemodeCapabilityAccessor and the codemode accessor
examples in the updated text.
---
Nitpick comments:
In `@packages/worker/src/mcp/tools/search-format.node.test.ts`:
- Around line 165-234: Add a new test that calls formatEntityDetailMarkdown with
a capability whose id contains a non-identifier character (e.g., 'foo-bar') and
assert that the returned structured.usage and structured.executeExample use
bracket notation (codemode["foo-bar"]) rather than dot notation; mirror the
existing capability test (the test around formatEntityDetailMarkdown) but set id
to 'foo-bar' and assert usage === 'execute with codemode["foo-bar"](args)' (or
stringContaining) and that executeExample contains 'return await
codemode["foo-bar"](input)'; also duplicate the same assertion pattern for the
second similar test block referenced (lines ~251-262) so both code paths (dot vs
bracket) are covered.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f677a188-25cd-47d5-98e7-9783a1ad3cd2
📒 Files selected for processing (7)
docs/use/execute.mddocs/use/search.mdpackages/worker/src/mcp/server-instructions.tspackages/worker/src/mcp/tools/execute.tspackages/worker/src/mcp/tools/search-format.node.test.tspackages/worker/src/mcp/tools/search-format.tspackages/worker/src/mcp/tools/search.ts
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a7547f3. Configure here.
Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>

Summary
executemodule snippet to capability detail responses fromsearch.codemode.<capability_id>(input)pattern in search/execute tool descriptions, MCP server instructions, and usage docs.Testing
npm test -- --run packages/worker/src/mcp/tools/search-format.node.test.ts packages/worker/src/mcp/tools/search-handler.node.test.ts packages/worker/src/mcp/server-instructions.node.test.tsnpm run format:checknpm test -- --run packages/worker/src/mcp/tools/search-format.node.test.ts packages/worker/src/mcp/server-instructions.node.test.tsnpm run validateSummary by CodeRabbit
New Features
Documentation
Tests