feat(mail): support scheduled send via --send-time#449
Open
Conversation
github-actions
bot
added
domain/mail
📝 WalkthroughWalkthroughThis PR adds scheduled email sending capability by extending the mail service with a Changes
Sequence DiagramsequenceDiagram
actor User
participant CLI as CLI Command
participant Service as draft.Send()
participant API as Backend API
User->>CLI: Execute with --send-time flag
CLI->>CLI: Parse --send-time value
CLI->>Service: Send(runtime, mailboxID, draftID, sendTime)
Service->>Service: Build request body with send_time
Service->>API: POST /drafts/{draftID}/send<br/>(with {"send_time": timestamp})
API->>API: Schedule message for future delivery
API-->>Service: Return scheduled send result
Service-->>CLI: Return response
CLI-->>User: Confirm scheduled send time
Estimated code review effort🎯 2 (Simple) | ⏱️ ~18 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Greptile SummaryThis PR adds Two bugs need to be fixed before merging:
Confidence Score: 4/5Two P1 bugs prevent the scheduled-send feature from working correctly; existing (non-scheduled) send paths are unaffected. The
Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant Shortcut as +send / +reply / +reply-all / +forward
participant DraftSvc as draft.Send()
participant LarkAPI as Lark Mail API
User->>Shortcut: --confirm-send --send-time <timestamp>
Shortcut->>Shortcut: CreateWithRaw() → draft_id
Shortcut->>DraftSvc: Send(mailboxID, draftID, sendTime string)
Note over DraftSvc: ⚠ bodyParams["send_time"] = sendTime (string)<br/>API expects integer
DraftSvc->>LarkAPI: POST .../drafts/{id}/send<br/>{"send_time": "1744608000"}
LarkAPI-->>DraftSvc: Error / ignores field (type mismatch)
DraftSvc-->>Shortcut: error or unscheduled send
Note over User,Shortcut: If --send-time used WITHOUT --confirm-send:<br/>sendTime is read but silently discarded → plain draft saved
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+64
to
+65
| if sendTime != "" { | ||
| bodyParams["send_time"] = sendTime |
There was a problem hiding this comment.
send_time serialized as string, API expects integer
sendTime is a string, so bodyParams["send_time"] = sendTime will be marshaled to JSON as {"send_time": "1744608000"}. The Lark API and all documentation examples use an unquoted integer ({"send_time": 1744608000}). Sending the wrong type will cause the API to reject or silently ignore the scheduled-send request, making the entire --send-time feature non-functional via the shortcut.
Suggested change
| if sendTime != "" { | |
| bodyParams["send_time"] = sendTime | |
| if sendTime != "" { | |
| ts, err := strconv.ParseInt(sendTime, 10, 64) | |
| if err != nil { | |
| return nil, fmt.Errorf("invalid --send-time value %q: must be a Unix timestamp in seconds", sendTime) | |
| } | |
| bodyParams["send_time"] = ts | |
| } |
strconv will need to be added to the import block.
Comment on lines
+62
to
68
| func Send(runtime *common.RuntimeContext, mailboxID, draftID, sendTime string) (map[string]interface{}, error) { | ||
| bodyParams := map[string]interface{}{} | ||
| if sendTime != "" { | ||
| bodyParams["send_time"] = sendTime | ||
| } | ||
| return runtime.CallAPI("POST", mailboxPath(mailboxID, "drafts", draftID, "send"), nil, bodyParams) | ||
| } |
There was a problem hiding this comment.
Previously, CallAPI received nil as the body for plain (non-scheduled) sends. After this change, an empty map[string]interface{}{} is always passed, which serializes to {} in JSON. If CallAPI encodes nil as no-body / omitted Content-Type, the change in the empty-map case is a subtle behavioral difference for all existing Send calls, not just the new scheduled path. Consider passing nil when sendTime is empty:
Suggested change
| func Send(runtime *common.RuntimeContext, mailboxID, draftID, sendTime string) (map[string]interface{}, error) { | |
| bodyParams := map[string]interface{}{} | |
| if sendTime != "" { | |
| bodyParams["send_time"] = sendTime | |
| } | |
| return runtime.CallAPI("POST", mailboxPath(mailboxID, "drafts", draftID, "send"), nil, bodyParams) | |
| } | |
| func Send(runtime *common.RuntimeContext, mailboxID, draftID, sendTime string) (map[string]interface{}, error) { | |
| var bodyParams map[string]interface{} | |
| if sendTime != "" { | |
| bodyParams = map[string]interface{}{"send_time": sendTime} | |
| } | |
| return runtime.CallAPI("POST", mailboxPath(mailboxID, "drafts", draftID, "send"), nil, bodyParams) | |
| } |
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@13d67af45e8c8c560e6073b17a0673b45efcf759🧩 Skill updatenpx skills add larksuite/cli#feat/mail-scheduled-send -y -g |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 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/mail/mail_reply.go`:
- Line 35: Validate the "--send-time" flag locally before proceeding to send: in
the mail send/reply/forward handlers in shortcuts/mail/mail_reply.go (the code
paths around the existing send handling and the locations referenced by the
review: ~line 35, ~72, ~186), ensure you check that if a send-time value is
provided then "--confirm-send" is also set and the timestamp is at least 5
minutes in the future; if either check fails, return a clear user-facing error
instead of proceeding (apply the same validation pattern to the +send,
+reply-all and +forward handlers).
In `@skill-template/domains/mail.md`:
- Line 75: The example Unix timestamp `1744608000` in the note about scheduled
sends is stale and violates the "now + 5 minutes" requirement; update the
example to a future timestamp (e.g., pick a value at least 5 minutes ahead of
the current time) and ensure the text around `--send-time`, `--confirm-send`,
and `send_time` still clearly states the requirement that `--send-time` must be
used with `--confirm-send` and represent a Unix timestamp in seconds (now + 5
minutes minimum).
In `@skills/lark-mail/references/lark-mail-forward.md`:
- Line 70: The example Unix timestamp for `--send-time <timestamp>` is wrong and
in the past (uses 1744608000); update the example to the correct Unix timestamp
for "2026-04-14 15:00" (1776178800) or replace examples with a clear placeholder
like `<unix_timestamp>`; apply the same change to the other occurrences
referenced (the block around the current example and the instances noted at
lines 123-127) so the narrative time and example timestamps are consistent.
In `@skills/lark-mail/references/lark-mail-reply-all.md`:
- Around line 161-164: The paragraph about scheduled sending with `--send-time`
is self-contradictory: it first says there will be no `message_id` immediately
and then implies `send_status` can be queried immediately; change the text to
consistently instruct callers not to call `send_status` when `message_id` is
absent (i.e., for scheduled sends), and instead state they should either wait
until the scheduled send time or wait until a `message_id` is returned before
calling `send_status`; keep references to `--send-time`, `message_id`, and
`send_status` to make the behavior clear.
- Around line 127-131: The human-readable send time "2026-04-14 15:00" and the
example Unix timestamp (1744608000) are inconsistent; update the example in the
lark-cli mail user_mailbox.drafts send snippet so the send_time matches the
displayed time (e.g., replace the incorrect 1744608000 with the correct Unix
seconds for 2026-04-14 15:00 UTC: 1776178800) and add a brief note that
send_time should be in seconds and at least current_time + 5 minutes; target the
send_time field and the lark-cli mail user_mailbox.drafts send example to make
this change.
In `@skills/lark-mail/references/lark-mail-reply.md`:
- Line 77: Update the inconsistent example for the `--send-time <timestamp>`
option: either replace the hardcoded Unix timestamp `1744608000` with one that
matches the displayed datetime "2026-04-14 15:00" (or vice versa), or swap both
to a clear placeholder like `<unix_timestamp>`; apply the same fix to the other
occurrences referencing `--send-time <timestamp>` (the block around the
additional examples mentioned) so the human-readable datetime and Unix timestamp
are consistent throughout.
In `@skills/lark-mail/references/lark-mail-send.md`:
- Around line 129-133: The example uses a human-readable send time "2026-04-14
15:00" but supplies a mismatched Unix timestamp 1744608000 for send_time; update
the send_time value in the lark-cli example (the JSON --data
'{"send_time":...}') to the correct Unix timestamp that corresponds to
"2026-04-14 15:00" (or change the human-readable text to match the existing
timestamp), ensuring the --data send_time matches the displayed time and still
satisfies the "current time + 5 minutes" requirement; refer to the lark-cli mail
user_mailbox.drafts send command and the send_time field/draft_id placeholder
when making the correction.
- Around line 156-157: Clarify the documentation to remove the logical conflict
between "message_id is not generated immediately" and "`send_status` returns
'pending'": state explicitly that send_status can only be queried when a
message_id is available, and for scheduled sends the system may return a
'pending' send_status without a message_id until the scheduled job is
created/executed; update the paragraph to say: for scheduled sends, do not query
send_status immediately—wait until a message_id is returned (or until after the
scheduled send time), then use that message_id to query send_status.
In `@skills/lark-mail/SKILL.md`:
- Line 89: Update the example for `--send-time` in SKILL.md so the sample Unix
timestamp matches the 2026 example date used elsewhere (or replace the hardcoded
`1744608000` with a note to compute the Unix seconds dynamically), and ensure
the surrounding text referencing `--send-time`, `--confirm-send`, and
`send_time` still states that the timestamp is in seconds and must be at least
current time + 5 minutes.
- Around line 136-137: The scheduled-send paragraph mentioning "--send-time",
"message_id", and "send_status" is ambiguous; update the SKILL.md paragraph to
explicitly state that when a scheduled send does not immediately return a
message_id you must not query send_status (i.e., wait until you have a
message_id or until the scheduled send time has passed), and add a clear
sentence such as "If no message_id is returned for a scheduled send, do not
query send_status until a message_id is obtained or the scheduled time has
passed" to close the loop.
🪄 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: f900c828-6446-4983-b946-3307d21f0c2e
📒 Files selected for processing (11)
shortcuts/mail/draft/service.goshortcuts/mail/mail_forward.goshortcuts/mail/mail_reply.goshortcuts/mail/mail_reply_all.goshortcuts/mail/mail_send.goskill-template/domains/mail.mdskills/lark-mail/SKILL.mdskills/lark-mail/references/lark-mail-forward.mdskills/lark-mail/references/lark-mail-reply-all.mdskills/lark-mail/references/lark-mail-reply.mdskills/lark-mail/references/lark-mail-send.md
| {Name: "attach", Desc: "Attachment file path(s), comma-separated (relative path only)"}, | ||
| {Name: "inline", Desc: "Inline images as a JSON array. Each entry: {\"cid\":\"<unique-id>\",\"file_path\":\"<relative-path>\"}. All file_path values must be relative paths. Cannot be used with --plain-text. CID images are embedded via <img src=\"cid:...\"> in the HTML body. CID is a unique identifier, e.g. a random hex string like \"a1b2c3d4e5f6a7b8c9d0\"."}, | ||
| {Name: "confirm-send", Type: "bool", Desc: "Send the reply immediately instead of saving as draft. Only use after the user has explicitly confirmed recipients and content."}, | ||
| {Name: "send-time", Desc: "Scheduled send time as a Unix timestamp in seconds (e.g. 1744608000). Must be at least 5 minutes in the future. Use with --confirm-send to schedule the email."}, |
There was a problem hiding this comment.
Enforce --send-time constraints before sending.
--send-time is documented as requiring --confirm-send and being at least 5 minutes in the future, but this path currently performs no local validation. That leads to silent ignore (when not confirming send) or opaque backend errors (invalid/past timestamp).
💡 Proposed fix (apply same pattern to +send / +reply-all / +forward)
import (
"context"
"fmt"
+ "strconv"
"strings"
+ "time"
@@
Validate: func(ctx context.Context, runtime *common.RuntimeContext) error {
if err := validateConfirmSendScope(runtime); err != nil {
return err
}
+ if ts := strings.TrimSpace(runtime.Str("send-time")); ts != "" {
+ if !runtime.Bool("confirm-send") {
+ return fmt.Errorf("--send-time requires --confirm-send")
+ }
+ sec, err := strconv.ParseInt(ts, 10, 64)
+ if err != nil {
+ return fmt.Errorf("--send-time must be a Unix timestamp in seconds: %w", err)
+ }
+ if time.Unix(sec, 0).Before(time.Now().Add(5 * time.Minute)) {
+ return fmt.Errorf("--send-time must be at least 5 minutes in the future")
+ }
+ }
return validateComposeInlineAndAttachments(runtime.FileIO(), runtime.Str("attach"), runtime.Str("inline"), runtime.Bool("plain-text"), "")
},Also applies to: 72-72, 186-186
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@shortcuts/mail/mail_reply.go` at line 35, Validate the "--send-time" flag
locally before proceeding to send: in the mail send/reply/forward handlers in
shortcuts/mail/mail_reply.go (the code paths around the existing send handling
and the locations referenced by the review: ~line 35, ~72, ~186), ensure you
check that if a send-time value is provided then "--confirm-send" is also set
and the timestamp is at least 5 minutes in the future; if either check fails,
return a clear user-facing error instead of proceeding (apply the same
validation pattern to the +send, +reply-all and +forward handlers).
| - **发送后必须调用 `send_status` 确认投递状态**（详见下方说明） | ||
| - **立即发送后必须调用 `send_status` 确认投递状态**；定时发送（`--send-time`）在预定发送时间后再查询，取消定时发送用 `cancel_scheduled_send`（详见下方说明） | ||
|
|
||
| > **定时发送注意事项**：`--send-time` 必须与 `--confirm-send` 配合使用，不能单独使用。`send_time` 为 Unix 时间戳（秒），如 `1744608000`，需至少为当前时间 + 5 分钟。 |
There was a problem hiding this comment.
Scheduled-send timestamp example is stale.
The sample 1744608000 maps to April 14, 2025 (UTC), which is in the past relative to April 13, 2026 and conflicts with the “now + 5 minutes” requirement.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skill-template/domains/mail.md` at line 75, The example Unix timestamp
`1744608000` in the note about scheduled sends is stale and violates the "now +
5 minutes" requirement; update the example to a future timestamp (e.g., pick a
value at least 5 minutes ahead of the current time) and ensure the text around
`--send-time`, `--confirm-send`, and `send_time` still clearly states the
requirement that `--send-time` must be used with `--confirm-send` and represent
a Unix timestamp in seconds (now + 5 minutes minimum).
| | `--attach <paths>` | 否 | 附件文件路径，多个用逗号分隔，追加在原邮件附件之后。相对路径 | | ||
| | `--inline <json>` | 否 | 高级用法：手动指定内嵌图片 CID 映射。推荐直接在 `--body` 中使用 `<img src="./path" />`（自动解析）。仅在需要精确控制 CID 命名时使用此参数。格式：`'[{"cid":"mycid","file_path":"./logo.png"}]'`，在 body 中用 `<img src="cid:mycid">` 引用。不可与 `--plain-text` 同时使用 | | ||
| | `--confirm-send` | 否 | 确认发送转发（默认只保存草稿）。仅在用户明确确认后使用 | | ||
| | `--send-time <timestamp>` | 否 | 定时发送时间，Unix 时间戳（秒），如 `1744608000`。需至少为当前时间 + 5 分钟。配合 `--confirm-send` 使用可定时发送邮件 | |
There was a problem hiding this comment.
Timestamp examples are inconsistent and currently in the past.
1744608000 is April 14, 2025 (UTC), but the scenario states “2026-04-14 15:00”. Please make the Unix timestamp consistent with the narrative time (or use <unix_timestamp> placeholders).
Also applies to: 123-127
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/references/lark-mail-forward.md` at line 70, The example
Unix timestamp for `--send-time <timestamp>` is wrong and in the past (uses
1744608000); update the example to the correct Unix timestamp for "2026-04-14
15:00" (1776178800) or replace examples with a clear placeholder like
`<unix_timestamp>`; apply the same change to the other occurrences referenced
(the block around the current example and the instances noted at lines 123-127)
so the narrative time and example timestamps are consistent.
Comment on lines
+127
to
+131
| # Step 2: 向用户确认 "回复全部草稿已创建：收件人 alice@, bob@, carol@，内容「已确认。」定时 2026-04-14 15:00 发送。确认吗？" | ||
|
|
||
| # Step 3: 用户确认后定时发送（send_time 为 Unix 时间戳，需至少当前时间 + 5 分钟） | ||
| lark-cli mail user_mailbox.drafts send --params '{"user_mailbox_id":"me","draft_id":"<draft_id>"}' --data '{"send_time":1744608000}' | ||
| ``` |
There was a problem hiding this comment.
send_time 示例与展示时间不一致（会误导实际定时时间）
Line 127 写的是 2026-04-14 15:00，但 Line 130 的 1744608000 对应的不是这个时间（也不是 2026 年）。请统一“人类可读时间”和 Unix 秒级时间戳，避免用户按错时间发送。
Suggested doc fix
-# Step 2: 向用户确认 "回复全部草稿已创建：收件人 alice@, bob@, carol@，内容「已确认。」定时 2026-04-14 15:00 发送。确认吗？"
+# Step 2: 向用户确认 "回复全部草稿已创建：收件人 alice@, bob@, carol@，内容「已确认。」定时 2026-04-14 15:00 发送。确认吗？"
-# Step 3: 用户确认后定时发送（send_time 为 Unix 时间戳，需至少当前时间 + 5 分钟）
-lark-cli mail user_mailbox.drafts send --params '{"user_mailbox_id":"me","draft_id":"<draft_id>"}' --data '{"send_time":1744608000}'
+# Step 3: 用户确认后定时发送（send_time 为 Unix 时间戳，需至少当前时间 + 5 分钟）
+# 示例时间戳请按目标时区实时换算，确保与上面的“2026-04-14 15:00”一致
+lark-cli mail user_mailbox.drafts send --params '{"user_mailbox_id":"me","draft_id":"<draft_id>"}' --data '{"send_time":<与确认时间一致的unix秒级时间戳>}'📝 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.
Suggested change
| # Step 2: 向用户确认 "回复全部草稿已创建：收件人 alice@, bob@, carol@，内容「已确认。」定时 2026-04-14 15:00 发送。确认吗？" | |
| # Step 3: 用户确认后定时发送（send_time 为 Unix 时间戳，需至少当前时间 + 5 分钟） | |
| lark-cli mail user_mailbox.drafts send --params '{"user_mailbox_id":"me","draft_id":"<draft_id>"}' --data '{"send_time":1744608000}' | |
| ``` | |
| # Step 2: 向用户确认 "回复全部草稿已创建：收件人 alice@, bob@, carol@，内容「已确认。」定时 2026-04-14 15:00 发送。确认吗？" | |
| # Step 3: 用户确认后定时发送（send_time 为 Unix 时间戳，需至少当前时间 + 5 分钟） | |
| # 示例时间戳请按目标时区实时换算，确保与上面的"2026-04-14 15:00"一致 | |
| lark-cli mail user_mailbox.drafts send --params '{"user_mailbox_id":"me","draft_id":"<draft_id>"}' --data '{"send_time":<与确认时间一致的unix秒级时间戳>}' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/references/lark-mail-reply-all.md` around lines 127 - 131,
The human-readable send time "2026-04-14 15:00" and the example Unix timestamp
(1744608000) are inconsistent; update the example in the lark-cli mail
user_mailbox.drafts send snippet so the send_time matches the displayed time
(e.g., replace the incorrect 1744608000 with the correct Unix seconds for
2026-04-14 15:00 UTC: 1776178800) and add a brief note that send_time should be
in seconds and at least current_time + 5 minutes; target the send_time field and
the lark-cli mail user_mailbox.drafts send example to make this change.
Comment on lines
+161
to
+164
| **1b. 定时发送（指定了 `--send-time`）** | ||
|
|
||
| 定时发送不会立即产生 `message_id`，因此 `send_status` 在定时发送成功后会返回"待发送"状态，**不建议在定时发送后立即查询**。可在预定发送时间后再查询。 | ||
|
|
There was a problem hiding this comment.
“无 message_id”与“立即查 send_status 返回待发送”表述冲突
Line 163 前半句说定时发送不会立即有 message_id，后半句又描述 send_status 的即时返回，这在操作上是自相矛盾的。建议改成：无 message_id 时不要查询；拿到 message_id 后再查。
Suggested doc fix
-定时发送不会立即产生 `message_id`，因此 `send_status` 在定时发送成功后会返回"待发送"状态，**不建议在定时发送后立即查询**。可在预定发送时间后再查询。
+定时发送通常不会立即产生 `message_id`，**不建议在定时发送后立即查询 `send_status`**。建议在预定发送时间后、且拿到 `message_id` 后再查询投递状态。📝 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.
Suggested change
| **1b. 定时发送（指定了 `--send-time`）** | |
| 定时发送不会立即产生 `message_id`，因此 `send_status` 在定时发送成功后会返回"待发送"状态，**不建议在定时发送后立即查询**。可在预定发送时间后再查询。 | |
| **1b. 定时发送（指定了 `--send-time`）** | |
| 定时发送通常不会立即产生 `message_id`，**不建议在定时发送后立即查询 `send_status`**。建议在预定发送时间后、且拿到 `message_id` 后再查询投递状态。 | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/references/lark-mail-reply-all.md` around lines 161 - 164,
The paragraph about scheduled sending with `--send-time` is self-contradictory:
it first says there will be no `message_id` immediately and then implies
`send_status` can be queried immediately; change the text to consistently
instruct callers not to call `send_status` when `message_id` is absent (i.e.,
for scheduled sends), and instead state they should either wait until the
scheduled send time or wait until a `message_id` is returned before calling
`send_status`; keep references to `--send-time`, `message_id`, and `send_status`
to make the behavior clear.
| | `--attach <paths>` | 否 | 附件文件路径，多个用逗号分隔。相对路径 | | ||
| | `--inline <json>` | 否 | 高级用法：手动指定内嵌图片 CID 映射。推荐直接在 `--body` 中使用 `<img src="./path" />`（自动解析）。仅在需要精确控制 CID 命名时使用此参数。格式：`'[{"cid":"mycid","file_path":"./logo.png"}]'`，在 body 中用 `<img src="cid:mycid">` 引用。不可与 `--plain-text` 同时使用 | | ||
| | `--confirm-send` | 否 | 确认发送回复（默认只保存草稿）。仅在用户明确确认后使用 | | ||
| | `--send-time <timestamp>` | 否 | 定时发送时间，Unix 时间戳（秒），如 `1744608000`。需至少为当前时间 + 5 分钟。配合 `--confirm-send` 使用可定时发送邮件 | |
There was a problem hiding this comment.
Timestamp examples are inconsistent with the stated schedule time.
The text says “2026-04-14 15:00”, but 1744608000 corresponds to April 14, 2025 (UTC). Please align the displayed datetime and Unix timestamp (or use a placeholder like <unix_timestamp>).
Also applies to: 130-134
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/references/lark-mail-reply.md` at line 77, Update the
inconsistent example for the `--send-time <timestamp>` option: either replace
the hardcoded Unix timestamp `1744608000` with one that matches the displayed
datetime "2026-04-14 15:00" (or vice versa), or swap both to a clear placeholder
like `<unix_timestamp>`; apply the same fix to the other occurrences referencing
`--send-time <timestamp>` (the block around the additional examples mentioned)
so the human-readable datetime and Unix timestamp are consistent throughout.
Comment on lines
+129
to
+133
| # Step 2: 向用户确认 "邮件草稿已创建：收件人 alice@example.com，主题「周报」，定时 2026-04-14 15:00 发送。确认吗？" | ||
|
|
||
| # Step 3: 用户确认后定时发送（send_time 为 Unix 时间戳，需至少当前时间 + 5 分钟） | ||
| lark-cli mail user_mailbox.drafts send --params '{"user_mailbox_id":"me","draft_id":"<draft_id>"}' --data '{"send_time":1744608000}' | ||
| ``` |
There was a problem hiding this comment.
定时发送示例时间与时间戳不匹配
Line 129 的 2026-04-14 15:00 与 Line 132 的 1744608000 不一致。这个示例会直接导致用户设置到错误时间。
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/references/lark-mail-send.md` around lines 129 - 133, The
example uses a human-readable send time "2026-04-14 15:00" but supplies a
mismatched Unix timestamp 1744608000 for send_time; update the send_time value
in the lark-cli example (the JSON --data '{"send_time":...}') to the correct
Unix timestamp that corresponds to "2026-04-14 15:00" (or change the
human-readable text to match the existing timestamp), ensuring the --data
send_time matches the displayed time and still satisfies the "current time + 5
minutes" requirement; refer to the lark-cli mail user_mailbox.drafts send
command and the send_time field/draft_id placeholder when making the correction.
Comment on lines
+156
to
+157
| 定时发送不会立即产生 `message_id`，因此 `send_status` 在定时发送成功后会返回"待发送"状态，**不建议在定时发送后立即查询**。可在预定发送时间后再查询投递状态。 | ||
|
|
There was a problem hiding this comment.
定时发送后的 send_status 说明存在逻辑冲突
这里同时说“不会立即产生 message_id”和“send_status 会返回待发送”，会让执行路径不清晰。建议明确前置条件：只有拿到 message_id 才能查 send_status。
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/references/lark-mail-send.md` around lines 156 - 157,
Clarify the documentation to remove the logical conflict between "message_id is
not generated immediately" and "`send_status` returns 'pending'": state
explicitly that send_status can only be queried when a message_id is available,
and for scheduled sends the system may return a 'pending' send_status without a
message_id until the scheduled job is created/executed; update the paragraph to
say: for scheduled sends, do not query send_status immediately—wait until a
message_id is returned (or until after the scheduled send time), then use that
message_id to query send_status.
| - **发送后必须调用 `send_status` 确认投递状态**（详见下方说明） | ||
| - **立即发送后必须调用 `send_status` 确认投递状态**；定时发送（`--send-time`）在预定发送时间后再查询，取消定时发送用 `cancel_scheduled_send`（详见下方说明） | ||
|
|
||
| > **定时发送注意事项**：`--send-time` 必须与 `--confirm-send` 配合使用，不能单独使用。`send_time` 为 Unix 时间戳（秒），如 `1744608000`，需至少为当前时间 + 5 分钟。 |
There was a problem hiding this comment.
--send-time 示例时间戳建议更新为“与示例日期一致”
当前示例 1744608000 与本 PR 文档里的 2026 年示例时间不一致，建议统一替换为“按目标时间实时换算的 Unix 秒级时间戳”。
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/SKILL.md` at line 89, Update the example for `--send-time`
in SKILL.md so the sample Unix timestamp matches the 2026 example date used
elsewhere (or replace the hardcoded `1744608000` with a note to compute the Unix
seconds dynamically), and ensure the surrounding text referencing `--send-time`,
`--confirm-send`, and `send_time` still states that the timestamp is in seconds
and must be at least current time + 5 minutes.
Comment on lines
+136
to
+137
| **定时发送（指定了 `--send-time`）**：定时发送不会立即产生 `message_id`，`send_status` 在定时发送成功后会返回"待发送"状态，**不建议在定时发送后立即查询**。可在预定发送时间后再查询。如需取消定时发送： | ||
|
|
There was a problem hiding this comment.
定时发送段落需明确 send_status 的可查询前提
Line 136 同时描述“无立即 message_id”和 send_status 返回，执行上不闭环。建议补一句：未拿到 message_id 时不应查询 send_status。
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/lark-mail/SKILL.md` around lines 136 - 137, The scheduled-send
paragraph mentioning "--send-time", "message_id", and "send_status" is
ambiguous; update the SKILL.md paragraph to explicitly state that when a
scheduled send does not immediately return a message_id you must not query
send_status (i.e., wait until you have a message_id or until the scheduled send
time has passed), and add a clear sentence such as "If no message_id is returned
for a scheduled send, do not query send_status until a message_id is obtained or
the scheduled time has passed" to close the loop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
+send、+reply、+reply-all、+forward四个 shortcut 新增--send-time参数，支持定时发送邮件draft.Send函数增加sendTime参数，透传至 API 请求体Test plan
+send --confirm-send --send-time <timestamp>定时发送新邮件+reply --confirm-send --send-time <timestamp>定时发送回复+reply-all --confirm-send --send-time <timestamp>定时发送回复全部+forward --confirm-send --send-time <timestamp>定时发送转发cancel_scheduled_send取消定时发送后邮件恢复为草稿状态Summary by CodeRabbit
New Features
--send-timeflag (Unix timestamp, minimum 5 minutes in future)--confirm-sendDocumentation