Skip to content

feat: enhance calendar event search and room finding#679

Open
hugang-lark wants to merge 5 commits intomainfrom
feat/room_and_search_event
Open

feat: enhance calendar event search and room finding#679
hugang-lark wants to merge 5 commits intomainfrom
feat/room_and_search_event

Conversation

@hugang-lark
Copy link
Copy Markdown
Collaborator

@hugang-lark hugang-lark commented Apr 27, 2026

Summary

This PR improves the calendar CLI capabilities by introducing event search support, enabling formatted output for event creation, and allowing users to query multiple meeting rooms at once.

Changes

  • Update calendar API documentation to replace search with search_event.
  • Add --format flag support for calendar +create shortcut to enable table output.
  • Support comma-separated multiple room names in calendar +room-find and update related documentation.

Test Plan

  • Run lark-cli calendar events search_event --params '{"calendar_id": "primary"}' --data '{"query": "会议"}' to verify event search functionality
  • Run lark-cli calendar +create with --format flag and verify the table output
  • Run lark-cli calendar +room-find --room-name "A,B" and verify the correct multi-room filtering

Related Issues

  • None

Summary by CodeRabbit

  • New Features

    • Room finder accepts multiple comma-separated names and numeric ranges (e.g., 16~20 → 16,17,18,19,20); CLI help updated.
    • Calendar creation output now shows results in a pretty formatted table and prints a success confirmation.
  • Documentation

    • Clarified recurring-event operations require instance-level event IDs; updated API and room-find guidance/examples.
  • Tests

    • Added tests for room-name normalization and formatted calendar-create output.

@hugang-lark hugang-lark added enhancement New feature or request feature labels Apr 27, 2026
@CLAassistant
Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ hugang-lark
❌ calendar-assistant
You have signed the CLA already but the status is still pending? Let us recheck it.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 27, 2026

📝 Walkthrough

Walkthrough

Adds pretty-formatted table output for calendar event creation and normalizes --room-name as comma-separated tokens with per-token validation. Adds unit tests for normalization and updates calendar skill docs to require recurring-instance event_id and to document events.search_event usage.

Changes

Cohort / File(s) Summary
Calendar Event Creation Output
shortcuts/calendar/calendar_create.go
Enabled HasFormat: true; replaced raw runtime.Out(...) with runtime.OutFormat(...) to render a one-row table of event_id, summary, start, end and print a success message via provided io.Writer.
Calendar Room Finding Input Handling
shortcuts/calendar/calendar_room_find.go
Introduced normalizeCommaSeparatedNames(raw string); treats --room-name as comma-separated list, trims entries, removes empties, validates each token individually with RejectDangerousChars, and updated flag help to document multiple names.
Room Name Normalization Tests
shortcuts/calendar/calendar_room_find_test.go
Added TestNormalizeCommaSeparatedNames covering passthrough, trimming, empty inputs, consecutive commas, and expected normalized outputs.
Calendar Skill Documentation
skills/lark-calendar/SKILL.md, skills/lark-calendar/references/lark-calendar-room-find.md
Reinforced requirement to resolve recurring-instance event_id before instance edits/deletes; replaced events.search references with events.search_event; added guidance and examples for comma-separated and range-expanded room-name queries.
Calendar Create Tests
shortcuts/calendar/calendar_test.go
Added test exercising --format pretty path; asserts stdout contains returned event_id and the "Event created successfully" confirmation.

Sequence Diagram(s)

(Skipped — changes are localized formatting, validation, tests, and documentation updates and do not introduce new multi-component control flows requiring sequencing.)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

Suggested reviewers

  • calendar-assistant
  • zhaoleibd

Poem

🐰 I hopped through code with nimble paws,
Trimmed commas, banished trailing flaws,
A pretty table now takes stage,
Tests sing truth, docs mark the page,
Rabbit cheers — commit applause! 🎉

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 12.50% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately reflects the main changes: calendar event search enhancement (search_event), formatted output for event creation, and multi-room finding support.
Description check ✅ Passed The description covers all required template sections: Summary, Changes, and Test Plan are present and adequately filled out with specific implementation details and manual verification steps.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/room_and_search_event

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.

@github-actions github-actions Bot added domain/calendar PR touches the calendar domain size/M Single-domain feat or fix with limited business impact labels Apr 27, 2026
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 27, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.05%. Comparing base (f6f242e) to head (a610160).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #679      +/-   ##
==========================================
+ Coverage   63.04%   63.05%   +0.01%     
==========================================
  Files         437      437              
  Lines       38847    38866      +19     
==========================================
+ Hits        24491    24508      +17     
- Misses      12184    12185       +1     
- Partials     2172     2173       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Copy Markdown

@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

🧹 Nitpick comments (3)
shortcuts/calendar/calendar_room_find_test.go (1)

11-31: Solid coverage for normalizeCommaSeparatedNames.

The cases cover pass-through, whitespace trimming, empty/delimiter-only inputs, and consecutive-comma compaction. All expectations match the implementation in calendar_room_find.go.

Optional nit: consider adding a name field to the table for clearer failure output when a single case fails (e.g. via t.Run(tt.name, ...)), and a case asserting that full-width commas () are intentionally not treated as separators — the doc and CLI help both specify English commas, so locking that contract down with a test would prevent accidental drift.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_room_find_test.go` around lines 11 - 31, Add a
descriptive `name` field to each test case and use t.Run(tt.name, func(t
*testing.T){...}) when iterating so failures show which case failed (reference:
TestNormalizeCommaSeparatedNames and normalizeCommaSeparatedNames), and add an
explicit test case asserting that full-width commas (`,`) are NOT treated as
separators (e.g., input "a,b" expecting "a,b") to lock the documented contract
that only ASCII commas are separators.
shortcuts/calendar/calendar_room_find.go (1)

318-333: Per-segment validation is equivalent to validating the raw string — consider simplifying.

common.RejectDangerousChars iterates the entire input rune-by-rune (see shortcuts/common/validate.go:95-110), and , (U+002C) is not flagged as dangerous. Splitting the input and validating each non-empty segment therefore produces the same accept/reject set as validating the raw string once.

Two options to consider:

  • Add flagRoomName back to the simple loop at line 318 and drop the per-segment loop entirely.
  • Or, if you keep the split for clearer error provenance per segment, reuse normalizeCommaSeparatedNames to avoid duplicating split/trim logic across Validate and buildRoomFindBaseRequest.

Not a correctness issue — purely DRY/clarity.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_room_find.go` around lines 318 - 333, The
per-segment validation for flagRoomName is redundant because
common.RejectDangerousChars("--"+flagRoomName, ...) applied to the raw string
yields the same accept/reject result as validating each comma-separated segment;
update Validate to include flagRoomName in the initial flags loop (the loop over
flagCity, flagBuilding, flagFloor, flagEventRrule, flagTimezone) and remove the
subsequent per-segment loop, or alternatively if you want per-segment error
messages reuse normalizeCommaSeparatedNames to split/trim before calling
common.RejectDangerousChars to avoid duplicating split/trim logic between
Validate and buildRoomFindBaseRequest.
shortcuts/calendar/calendar_create.go (1)

291-296: Optional: simplify single-row table construction.

var rows []…; rows = append(rows, resultData) can be a one-liner; no behavior change.

♻️ Proposed simplification
 runtime.OutFormat(resultData, nil, func(w io.Writer) {
-    var rows []map[string]interface{}
-    rows = append(rows, resultData)
-    output.PrintTable(w, rows)
+    output.PrintTable(w, []map[string]interface{}{resultData})
     fmt.Fprintln(w, "\nEvent created successfully")
 })
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_create.go` around lines 291 - 296, In the
runtime.OutFormat(...) callback that builds a single-row table for output (the
block calling output.PrintTable), replace the two-step declaration and append of
rows (var rows []map[string]interface{}; rows = append(rows, resultData)) with a
single-line literal construction (e.g., rows :=
[]map[string]interface{}{resultData}) to simplify and clarify the creation of
the slice before calling output.PrintTable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@shortcuts/calendar/calendar_create.go`:
- Line 76: Add a unit/integration test that exercises the new formatted-output
path introduced by setting HasFormat: true in calendar_create (the
runtime.OutFormat rendering code around the OutFormat branch). Specifically, add
a test that runs the calendar +create command with the --format flag (e.g.,
--format pretty and/or --format json) and asserts the formatted output matches
expectations; follow existing tests for CalendarAgenda or CalendarRoomFind as a
template to verify both "pretty" table rendering and JSON output if applicable.

---

Nitpick comments:
In `@shortcuts/calendar/calendar_create.go`:
- Around line 291-296: In the runtime.OutFormat(...) callback that builds a
single-row table for output (the block calling output.PrintTable), replace the
two-step declaration and append of rows (var rows []map[string]interface{}; rows
= append(rows, resultData)) with a single-line literal construction (e.g., rows
:= []map[string]interface{}{resultData}) to simplify and clarify the creation of
the slice before calling output.PrintTable.

In `@shortcuts/calendar/calendar_room_find_test.go`:
- Around line 11-31: Add a descriptive `name` field to each test case and use
t.Run(tt.name, func(t *testing.T){...}) when iterating so failures show which
case failed (reference: TestNormalizeCommaSeparatedNames and
normalizeCommaSeparatedNames), and add an explicit test case asserting that
full-width commas (`,`) are NOT treated as separators (e.g., input "a,b"
expecting "a,b") to lock the documented contract that only ASCII commas are
separators.

In `@shortcuts/calendar/calendar_room_find.go`:
- Around line 318-333: The per-segment validation for flagRoomName is redundant
because common.RejectDangerousChars("--"+flagRoomName, ...) applied to the raw
string yields the same accept/reject result as validating each comma-separated
segment; update Validate to include flagRoomName in the initial flags loop (the
loop over flagCity, flagBuilding, flagFloor, flagEventRrule, flagTimezone) and
remove the subsequent per-segment loop, or alternatively if you want per-segment
error messages reuse normalizeCommaSeparatedNames to split/trim before calling
common.RejectDangerousChars to avoid duplicating split/trim logic between
Validate and buildRoomFindBaseRequest.
🪄 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

Run ID: cdb6e74a-3269-4935-be16-9a5ff51bfb6f

📥 Commits

Reviewing files that changed from the base of the PR and between 78d92de and 83f3ff7.

📒 Files selected for processing (5)
  • shortcuts/calendar/calendar_create.go
  • shortcuts/calendar/calendar_room_find.go
  • shortcuts/calendar/calendar_room_find_test.go
  • skills/lark-calendar/SKILL.md
  • skills/lark-calendar/references/lark-calendar-room-find.md

Comment thread shortcuts/calendar/calendar_create.go
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 27, 2026

🚀 PR Preview Install Guide

🧰 CLI update

npm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@a61016095b513c99a412822cfe8c2409a3a1b19f

🧩 Skill update

npx skills add larksuite/cli#feat/room_and_search_event -y -g

@hugang-lark hugang-lark force-pushed the feat/room_and_search_event branch from 21f8f47 to a65158a Compare April 27, 2026 12:23
Copy link
Copy Markdown

@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

🧹 Nitpick comments (1)
shortcuts/calendar/calendar_room_find.go (1)

325-333: Reuse normalizeCommaSeparatedNames to avoid duplicated split/trim/skip logic.

The validation loop re-implements the split + TrimSpace + skip-empty behavior already encapsulated in normalizeCommaSeparatedNames. Consider extracting a slice-returning helper (e.g. splitCommaSeparatedNames) and have normalizeCommaSeparatedNames join its result, so both validation and request building share one source of truth.

♻️ Proposed refactor
+func splitCommaSeparatedNames(raw string) []string {
+	parts := strings.Split(raw, ",")
+	cleaned := make([]string, 0, len(parts))
+	for _, p := range parts {
+		if p = strings.TrimSpace(p); p != "" {
+			cleaned = append(cleaned, p)
+		}
+	}
+	return cleaned
+}
+
 func normalizeCommaSeparatedNames(raw string) string {
-	parts := strings.Split(raw, ",")
-	var cleaned []string
-	for _, p := range parts {
-		p = strings.TrimSpace(p)
-		if p != "" {
-			cleaned = append(cleaned, p)
-		}
-	}
-	return strings.Join(cleaned, ",")
+	return strings.Join(splitCommaSeparatedNames(raw), ",")
 }
@@
-		for _, name := range strings.Split(runtime.Str(flagRoomName), ",") {
-			name = strings.TrimSpace(name)
-			if name == "" {
-				continue
-			}
-			if err := common.RejectDangerousChars("--"+flagRoomName, name); err != nil {
-				return output.ErrValidation(err.Error())
-			}
-		}
+		for _, name := range splitCommaSeparatedNames(runtime.Str(flagRoomName)) {
+			if err := common.RejectDangerousChars("--"+flagRoomName, name); err != nil {
+				return output.ErrValidation(err.Error())
+			}
+		}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_room_find.go` around lines 325 - 333, The loop
that validates room names duplicates split/trim/skip logic; extract a helper
(e.g., splitCommaSeparatedNames) that takes runtime.Str(flagRoomName) and
returns a []string of non-empty, trimmed names, refactor
normalizeCommaSeparatedNames to call join on that slice, and then replace the
current validation loop with iteration over splitCommaSeparatedNames's result
while calling common.RejectDangerousChars("--"+flagRoomName, name) for each
entry so both validation and request building share the same parsing logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@shortcuts/calendar/calendar_room_find.go`:
- Around line 208-225: The room_name must be a single exact name, not a CSV;
update buildRoomFindBaseRequest to stop passing a comma-joined list from
normalizeCommaSeparatedNames and instead set roomFindRequest.RoomName to the
first non-empty trimmed token (or empty string) from runtime.Str(flagRoomName),
and remove or stop calling normalizeCommaSeparatedNames from this flow; if
multi-room search is required later, replace this flow with a call to the
meeting_room/freebusy/batch_get endpoint using room IDs rather than attempting
CSVs in roomFindRequest.

---

Nitpick comments:
In `@shortcuts/calendar/calendar_room_find.go`:
- Around line 325-333: The loop that validates room names duplicates
split/trim/skip logic; extract a helper (e.g., splitCommaSeparatedNames) that
takes runtime.Str(flagRoomName) and returns a []string of non-empty, trimmed
names, refactor normalizeCommaSeparatedNames to call join on that slice, and
then replace the current validation loop with iteration over
splitCommaSeparatedNames's result while calling
common.RejectDangerousChars("--"+flagRoomName, name) for each entry so both
validation and request building share the same parsing logic.
🪄 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

Run ID: 4cb61d36-2880-4f3e-9593-5b213624cd51

📥 Commits

Reviewing files that changed from the base of the PR and between 21f8f47 and a65158a.

📒 Files selected for processing (2)
  • shortcuts/calendar/calendar_room_find.go
  • shortcuts/calendar/calendar_test.go

Comment on lines +208 to +225
func normalizeCommaSeparatedNames(raw string) string {
parts := strings.Split(raw, ",")
var cleaned []string
for _, p := range parts {
p = strings.TrimSpace(p)
if p != "" {
cleaned = append(cleaned, p)
}
}
return strings.Join(cleaned, ",")
}

func buildRoomFindBaseRequest(runtime *common.RuntimeContext) (*roomFindRequest, error) {
req := &roomFindRequest{
City: strings.TrimSpace(runtime.Str(flagCity)),
Building: strings.TrimSpace(runtime.Str(flagBuilding)),
Floor: strings.TrimSpace(runtime.Str(flagFloor)),
RoomName: strings.TrimSpace(runtime.Str(flagRoomName)),
RoomName: normalizeCommaSeparatedNames(runtime.Str(flagRoomName)),
Copy link
Copy Markdown

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:

Lark/Feishu open API calendar v4 freebusy room_find request body room_name field comma-separated multiple values

💡 Result:

No, the room_name field in the Lark/Feishu Open API calendar v4 freebusy/room_find request body does not support comma-separated multiple values. It is a single string field used for filtering by a specific room name keyword. The endpoint POST /open-apis/calendar/v4/freebusy/room_find is used to find available meeting rooms matching filters like city, building, floor, room_name, capacity, etc., for given time slots and attendees. From the request struct in larksuite/cli source code: type roomFindRequest struct { City string json:"city,omitempty" Building string json:"building,omitempty" Floor string json:"floor,omitempty" RoomName string json:"room_name,omitempty" // single string MinCapacity int json:"min_capacity,omitempty" MaxCapacity int json:"max_capacity,omitempty" EventStartTime string json:"event_start_time,omitempty" EventEndTime string json:"event_end_time,omitempty" AttendeeUserIDs []string json:"attendee_user_ids,omitempty" AttendeeChatIDs []string json:"attendee_chat_ids,omitempty" } room_name is defined as string, not an array or comma-separated list. Documentation emphasizes exact normalized room name matching (e.g., "木星" for "木星会议室"), with no mention of multiple values or comma separation. For multiple specific rooms, use room IDs in other freebusy endpoints like /meeting_room/freebusy/batch_get (up to 20 room_ids as query params).

Citations:


The room_name field does not support comma-separated values; the feature is broken.

The upstream Lark/Feishu /open-apis/calendar/v4/freebusy/room_find API treats room_name as a single string field for exact normalized room name matching (e.g., "木星" for "木星会议室"). It does not accept comma-separated lists.

Passing multiple room names as "A,B,C" causes the API to treat the entire string as a literal room name, resulting in zero matches. To search multiple rooms, use the /meeting_room/freebusy/batch_get endpoint with an array of room IDs. Either revert the multi-room input feature or refactor to use the correct endpoint.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_room_find.go` around lines 208 - 225, The
room_name must be a single exact name, not a CSV; update
buildRoomFindBaseRequest to stop passing a comma-joined list from
normalizeCommaSeparatedNames and instead set roomFindRequest.RoomName to the
first non-empty trimmed token (or empty string) from runtime.Str(flagRoomName),
and remove or stop calling normalizeCommaSeparatedNames from this flow; if
multi-room search is required later, replace this flow with a call to the
meeting_room/freebusy/batch_get endpoint using room IDs rather than attempting
CSVs in roomFindRequest.

@hugang-lark hugang-lark force-pushed the feat/room_and_search_event branch from a65158a to a610160 Compare April 27, 2026 12:58
Copy link
Copy Markdown

@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.

♻️ Duplicate comments (1)
shortcuts/calendar/calendar_room_find.go (1)

208-225: ⚠️ Potential issue | 🔴 Critical

Multi-room CSV --room-name is still broken — prior critical feedback unaddressed.

A previous review on this exact range already established (with web verification) that the upstream /open-apis/calendar/v4/freebusy/room_find API treats room_name as a single string for exact normalized matching. Joining tokens with , and sending "16,17,18,19,20" (or "木星,火星") makes the backend look for a single literal room named "16,17,18,19,20", which never matches anything. The CSV semantics this PR is trying to ship cannot work against the current endpoint.

This is the root cause; the following changes in this PR are downstream effects of the same defect and should be reverted/redesigned together:

  • --room-name help text at line 287 advertising comma-separated multiple names.
  • Per-token validation loop at lines 325–333 (only meaningful if CSV is supported).
  • The new "批量会议室名称查询" section and rules in skills/lark-calendar/references/lark-calendar-room-find.md, plus the XX~YY range expansion guidance — all instruct the agent to produce inputs the API will reject.

Two viable directions:

  1. Drop the multi-room feature: keep RoomName as a single trimmed value, restore the original whole-string validation, and revert the doc additions.
  2. Implement true multi-room search by issuing one room_find call per token and merging results client-side (similar to the existing per-slot fan-out via collectRoomFindResults / roomFindWorkers), or by switching to meeting_room/freebusy/batch_get with room IDs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_room_find.go` around lines 208 - 225, The code
currently splits --room-name into a comma-joined string via
normalizeCommaSeparatedNames and sets roomFindRequest.RoomName to a CSV which
the upstream room_find API treats as a single literal name; fix by choosing one
of two approaches: (A) revert to single-name behavior by removing
normalizeCommaSeparatedNames usage in buildRoomFindBaseRequest and pass the raw
trimmed runtime.Str(flagRoomName) (and revert the per-token validation and CSV
help/docs), or (B) implement true multi-room queries by treating
runtime.Str(flagRoomName) as a list of tokens, issuing one room_find call per
token and merging results client-side (reusing collectRoomFindResults /
roomFindWorkers fan-out pattern or switching to the batch_get
meeting_room/freebusy endpoint), updating validation/docs accordingly; apply the
chosen approach consistently across buildRoomFindBaseRequest, the validation
loop, help text, and docs.
🧹 Nitpick comments (1)
shortcuts/calendar/calendar_test.go (1)

151-194: Optional: deduplicate with TestCreate_CreateEventOnly via a table-driven test.

TestCreate_CreateEventOnly_PrettyFormat reuses the exact same stub fixture and args as TestCreate_CreateEventOnly, differing only by adding --format pretty and one extra assertion. Consider folding both into a single subtest table to share the stub registration and reduce drift if the fixture changes.

Note: if the trailing "Event created successfully" hint is routed to stderr (see comment in calendar_create.go), the assertion at lines 191–193 will need to read from stderr instead of stdout, and mountAndRun may need to expose the stderr buffer.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@shortcuts/calendar/calendar_test.go` around lines 151 - 194, Two tests
(TestCreate_CreateEventOnly_PrettyFormat and TestCreate_CreateEventOnly)
duplicate the same HTTP stub and args; refactor into a table-driven test with
subtests that share the stub registration and only vary the extra "--format
pretty" arg and the additional assertion. Update the test wrapper (mountAndRun)
or test invocation to accept and return both stdout and stderr buffers so the
subtest that expects the "Event created successfully" hint can assert against
stderr if calendar_create.go writes that message to stderr; keep unique
identifiers like TestCreate_CreateEventOnly_PrettyFormat,
TestCreate_CreateEventOnly, mountAndRun, and calendar_create.go when locating
and changing the code.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@shortcuts/calendar/calendar_room_find.go`:
- Around line 208-225: The code currently splits --room-name into a comma-joined
string via normalizeCommaSeparatedNames and sets roomFindRequest.RoomName to a
CSV which the upstream room_find API treats as a single literal name; fix by
choosing one of two approaches: (A) revert to single-name behavior by removing
normalizeCommaSeparatedNames usage in buildRoomFindBaseRequest and pass the raw
trimmed runtime.Str(flagRoomName) (and revert the per-token validation and CSV
help/docs), or (B) implement true multi-room queries by treating
runtime.Str(flagRoomName) as a list of tokens, issuing one room_find call per
token and merging results client-side (reusing collectRoomFindResults /
roomFindWorkers fan-out pattern or switching to the batch_get
meeting_room/freebusy endpoint), updating validation/docs accordingly; apply the
chosen approach consistently across buildRoomFindBaseRequest, the validation
loop, help text, and docs.

---

Nitpick comments:
In `@shortcuts/calendar/calendar_test.go`:
- Around line 151-194: Two tests (TestCreate_CreateEventOnly_PrettyFormat and
TestCreate_CreateEventOnly) duplicate the same HTTP stub and args; refactor into
a table-driven test with subtests that share the stub registration and only vary
the extra "--format pretty" arg and the additional assertion. Update the test
wrapper (mountAndRun) or test invocation to accept and return both stdout and
stderr buffers so the subtest that expects the "Event created successfully" hint
can assert against stderr if calendar_create.go writes that message to stderr;
keep unique identifiers like TestCreate_CreateEventOnly_PrettyFormat,
TestCreate_CreateEventOnly, mountAndRun, and calendar_create.go when locating
and changing the code.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d3193b5e-b79c-4e09-a64e-695e331ee4cf

📥 Commits

Reviewing files that changed from the base of the PR and between a65158a and a610160.

📒 Files selected for processing (6)
  • shortcuts/calendar/calendar_create.go
  • shortcuts/calendar/calendar_room_find.go
  • shortcuts/calendar/calendar_room_find_test.go
  • shortcuts/calendar/calendar_test.go
  • skills/lark-calendar/SKILL.md
  • skills/lark-calendar/references/lark-calendar-room-find.md
✅ Files skipped from review due to trivial changes (1)
  • shortcuts/calendar/calendar_room_find_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • skills/lark-calendar/SKILL.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain/calendar PR touches the calendar domain enhancement New feature or request feature size/M Single-domain feat or fix with limited business impact

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants