Send PR Message

Send a NAS frontend PR review request to Lark only after explicit user intent. Use when the user asks to send, post, or message a PR to Lark; if the user only asks to prepare or draft, draft the message and ask before sending.

Source: .agents/skills/send-pr-message/SKILL.md

Metadata

• name: send-pr-message
• version: 1.0.0
• bins: ["lark-cli"]

Content

Send PR Message

Prerequisite: Read installed lark-shared, lark-im, and lark-contact before sending, because this skill depends on auth state, chat membership, and open_id resolution.

Use this skill only when the user explicitly asks to send a PR review request to Lark. If the request is to prepare, draft, review, or format a message, do not send; return the draft and ask for confirmation.

Defaults

• Default target channel name: Pull Request Goes Here
• Default target channel ID: oc_e2e74c5a34b7c5b724cfcbb70b24933d
• Alternate target channel name: Frontend Squad
• Alternate target channel ID: oc_68f88c91774498eb3e36415b41b72437
• Preferred identity: choose the lower-risk sender that can send without changing chat membership:
  • use --as user when user send scope is already granted or the user explicitly authorizes it
  • use --as bot only when the bot is already able to send to the target chat
• User send scope: im:message.send_as_user

Frontend Reviewers

Current frontend people:

• yuchen@nas.com
• trent@nas.io
• nickvu@nas.io

Every FE PR review message should mention two frontend reviewers in addition to the requester/sender when possible. For Yuchen-sent PRs, default to Trent and Nick. If the requester names different reviewers, include the named reviewers and still ensure two frontend people are tagged unless the user explicitly says not to.

Required Skills

Read installed upstream skills before sending:

• lark-shared for auth and missing scopes.
• lark-im for message sending.
• lark-contact for reviewer resolution.

Permissions

Operation	Required scope
Resolve reviewer emails to open_id	contact:user:search
Check chat members or bot presence	im:chat.members:read
Send as user	im:message.send_as_user
Send as bot	im:message

Prefer the lark-cli shortcut im +messages-send. Do not use raw lark-cli api for message sending unless the shortcut cannot express the requested message type.

Preflight

Before resolving reviewers or sending:

command -v lark-cli
lark-cli auth status

Handle results:

• If lark-cli is missing, do not send. Return the drafted message and tell the user Lark CLI must be installed/configured.
• If user identity is unavailable, contact lookup and send-as-user cannot run. Use lark-shared split auth for contact:user:search and/or im:message.send_as_user.
• If bot identity is unavailable, do not use the bot path.
• If both user and bot send paths are unavailable, return the drafted message only.
• If user identity needs refresh, continue; retry auth only if the user API call fails.

Workflow

1. Confirm the user explicitly asked to send a Lark PR message. If they did not, draft the message, name the target chat, and ask for permission before sending.
2. Resolve the PR URL from the user request or current branch. If multiple PRs are possible, ask for the URL.
3. Collect PR metadata before drafting:
   • PR title and PR URL.
   • Source/head branch and target/base branch.
   • Total changed lines, ideally as +<additions> / -<deletions>.
   • Preview URL, if available.
   • Tech design or self-test links, if available.
4. Prefer GitHub CLI for PR metadata when available:

gh pr view "<PR URL or branch>" --json title,url,headRefName,baseRefName,additions,deletions

If GitHub CLI is unavailable, use the GitHub PR page or local git as a fallback:

git branch --show-current
git diff --shortstat origin/<base-branch>...HEAD

Do not guess the source branch, target branch, or changed line count. If any required PR metadata cannot be resolved, draft the message with Unknown for that field and call it out before sending.

5. Choose the target chat:
   • Default to Pull Request Goes Here (oc_e2e74c5a34b7c5b724cfcbb70b24933d).
   • Use Frontend Squad (oc_68f88c91774498eb3e36415b41b72437) only if the user asks for it or the PR process specifically requires the frontend squad chat.
   • Do not send to both chats unless the user explicitly asks for both.
6. Identify reviewers:
   • If the user named reviewers, include them.
   • If not, resolve and tag two frontend reviewers from the frontend people list, excluding the sender/requester when known.
   • If Yuchen is the requester/sender, default to trent@nas.io and nickvu@nas.io.
7. Resolve each reviewer by email or name with lark-cli contact +search-user --as user --query "<email-or-name>".
8. Choose send identity with the lowest-risk path:
   • Prefer user send when im:message.send_as_user is already granted or the user explicitly approves that auth.
   • If user send scope is missing, try a dry run with bot identity only if the bot is already in the target chat. Do not invite the bot or change membership.
9. Check user send permission when using --as user:

lark-cli auth check --scope "im:message.send_as_user"

10. If user scope is missing and bot send is not already available, use split auth:

lark-cli auth login --scope "im:message.send_as_user" --no-wait --json

Show the verification URL and QR code per lark-shared, then stop. Do not send until the user confirms authorization and the device-code flow completes.

11. Send only after permission is granted or bot dry-run confirms bot send is available:

lark-cli im +messages-send --as user --chat-id "<resolved_target_chat_id>" --text "<message>"

Use the chat ID selected in step 5. For example, use oc_68f88c91774498eb3e36415b41b72437 when the user requested Frontend Squad, and use oc_e2e74c5a34b7c5b724cfcbb70b24933d only when the selected target is Pull Request Goes Here.

12. Report channel name, target chat ID, sender identity, tagged reviewers, branch flow, changed line count, and returned message_id.

Message Content

Use concise plain text:

<at user_id="<open_id>">Reviewer 1</at> <at user_id="<open_id>">Reviewer 2</at> can you help review this pull request?

nas-fe: <PR title>
<PR URL>
Branch: <source/head branch> -> <target/base branch>
Changes: +<additions> / -<deletions>
Context: <one-sentence review context>
Preview: <preview URL>
Docs: <tech design/self-test links>

Omit the Preview: line when no preview URL is available. Omit the Docs: line when no tech design or self-test link is available. Do not send placeholder values such as N/A, None, or Not available for these optional lines.

Safety

• No implicit sends.
• Draft-only unless the user explicitly asked to send in this request or confirms the exact draft and target chat.
• No duplicate sends in the same task.
• Do not invite bots, add chat members, or alter chat membership just to send a PR message.
• Do not fabricate reviewer IDs, PR URLs, preview URLs, or message IDs.
• Do not expose auth device codes or tokens in the final report.