docs: document OKR block XML guidance#1648
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (2)
📝 WalkthroughWalkthroughUpdates ChangesOKR Block XML Documentation
Estimated code review effort: 2 (Simple) | ~5 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
github-actions
Bot
added
domain/ccm
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
skills/lark-doc/references/lark-doc-xml.md (2)
127-128: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueClarify inclusivity of
percent/scorerange bounds.The constraint "取值 0-100" could be interpreted as
[0, 100]or(0, 100). Specify inclusive bounds (e.g.,0–100（含）) if the API accepts both endpoints, reducing ambiguity for agent-generated values.🤖 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 `@skills/lark-doc/references/lark-doc-xml.md` around lines 127 - 128, Clarify the `percent` and `score` bounds in the Lark doc reference by updating the range description in the XML docs to explicitly state whether 0 and 100 are included; adjust the wording around the existing `status`/`percent`/`score` bullet so it says the accepted values are inclusive if that is the intended API behavior.
104-104: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueClarify the prohibition on create-time child tree construction.
The guidance states "创建时只写 root-only
<okr cycle-id="..."/>挂载已有 OKR，不构造 Objective/KR/Progress 子树." Consider explicitly stating that providing child elements (<okr-objective>,<okr-key-result>,<okr-progress>) during create will be ignored or rejected, to prevent agent confusion about whether partial child trees are accepted.🤖 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 `@skills/lark-doc/references/lark-doc-xml.md` at line 104, The OKR XML guidance in the lark-doc reference needs to explicitly forbid create-time child tree construction: update the instructions around the root-only `okr` usage so it is clear that `create` must only mount an existing OKR with `<okr cycle-id="..."/>`, and that any child elements such as `okr-objective`, `okr-key-result`, or `okr-progress` are not accepted there and should be treated as ignored or rejected. Use the `OKR block` guidance in the lark-doc XML reference to make this distinction unambiguous for agents.
🤖 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.
Nitpick comments:
In `@skills/lark-doc/references/lark-doc-xml.md`:
- Around line 127-128: Clarify the `percent` and `score` bounds in the Lark doc
reference by updating the range description in the XML docs to explicitly state
whether 0 and 100 are included; adjust the wording around the existing
`status`/`percent`/`score` bullet so it says the accepted values are inclusive
if that is the intended API behavior.
- Line 104: The OKR XML guidance in the lark-doc reference needs to explicitly
forbid create-time child tree construction: update the instructions around the
root-only `okr` usage so it is clear that `create` must only mount an existing
OKR with `<okr cycle-id="..."/>`, and that any child elements such as
`okr-objective`, `okr-key-result`, or `okr-progress` are not accepted there and
should be treated as ignored or rejected. Use the `OKR block` guidance in the
lark-doc XML reference to make this distinction unambiguous for agents.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 16737c44-e952-4578-9457-2b489a8c267e
📒 Files selected for processing (1)
skills/lark-doc/references/lark-doc-xml.md
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@f363a1b88bb97236590070e857b784a51f89f8bc🧩 Skill updatenpx skills add ZEden0/cli#feat/okr-block-export-new-format -y -g |
github-actions
Bot
added
size/L
2 participants
Summary
Document the
lark-docXML guidance for OKR blocks so agents can use the supported OKR XML shape consistently across fetch, create, and update flows.Changes
<okr>out of the move-only block list and point it to dedicated supplemental rules.cycle-id.status,percent,score, andokr-progresscontent.lark-okrskill before creating OKR blocks so they can confirm an available OKR cycle.Test Plan
git diff --check upstream/main...HEADskills/lark-doc/references/lark-doc-xml.md.Related Issues
Summary by CodeRabbit
<okr>entry, while keeping existing related blocks’ create/move behavior unchanged.<okr cycle-id="..."/>), sample retrieval XML, and per-field read-only vs updatable rules.okr-progresscontent is structured and how nested progress elements can be represented.