TongyiDai/feishu-okr-drafter

Feishu OKR Draft

Goals & Boundaries

Organize multi-source work facts into discussable, measurable, and aligned Feishu OKRs, and—after explicit user authorization—write them as drafts, @mention corresponding collaborators. Interfaces are used for acceleration; Feishu pages, historical documents, screenshots, user-pasted content, and work summaries are all valid inputs. Default to drafting and judgment first; do not create, publish, or modify existing OKRs.

Adhere to three bottom lines:

• Do not fabricate missing target values, baselines, deadlines, owners, business results, or alignment targets; write missing information as [To Be Confirmed].
• Report drafting, writing, saving, and publishing separately; do not claim completion without read-back evidence.
• For sensitive revenue, cost, customer, personnel, or strategic data, prioritize using confirmed ratios, ranges, completion rates, or anonymized expressions, and mark portions requiring separate communication.

Workflow

1. Determine Task Mode

Identify what the user wants to do:

1. Generate a new draft from work notes;
2. Revise existing O/KRs;
3. Review quality and alignment relationships;
4. Write the draft to Feishu;
5. Adjust objectives, KRs, weights, or deadlines during the cycle.

When there is no clear intent to write, remain in read-only and draft mode.

2. Establish Context & Data Source Paths

First, read the current version descriptions of lark-shared and lark-okr. When needing to read Feishu content, perform identity, tenant, and permission verification:

lark-cli auth status --json --verify
lark-cli contact +get-user --as user

Environments supporting auth status --json --verify must confirm identity=user and verified=true. If the current CLI build lacks the auth subcommand, fall back to contact +get-user --as user to resolve the current user; when still in draft mode, use task +get-my-tasks --as user to verify user-context readability. Before actually writing OKRs or @mentioning collaborators, still confirm the target user and tenant.

Select available data source paths in the following order; do not treat "interface unavailable" as a task endpoint:

1. Interface/CLI Path: When permissions allow, use interfaces to batch-read cycles, O/KRs, indicators, progress, and alignment relationships.
2. Feishu Page Path: When interfaces are missing, scope is insufficient, or page save status needs confirmation, use control-in-app-browser. Prioritize taking over the user's currently open OKR page; if no page is available, perform only one clear navigation to the Feishu OKR entry. Read based on visible pages; do not guess URLs, field order, or button meanings.
3. User Material Path: Read text, screenshots, documents, meeting minutes, performance summaries, H1 self-reviews, and work retrospectives provided by the user.
4. Feishu Document Path: Search for and read OKR formulation, writing, alignment, assistant, and role example documents accessible to the current tenant.

Even when interfaces succeed, cross-check key statuses with pages or original text; when pages succeed, retain page facts, and do not discard evidence because it cannot form an API ID.

Fetch as needed:

• Current user's target cycle: okr +cycle-list;
• O/KRs under the cycle: okr +cycle-detail;
• Indicators for O and KR: objective.indicators list, key_result.indicators list;
• Alignment relationships for O: objective.alignments list;
• Related progress records: okr +progress-list;
• Related Feishu documents: search for OKR, Formulation, Writing, Alignment, Assistant, prioritize reading specifications and examples accessible to the current tenant.

Cycle determination uses overlap between start/end dates and the current date as the primary condition, then references cycle status; when the user does not explicitly specify, do not treat the annual cycle as the default current cycle.

If the OKR-specific scope is missing, stop blind retries, explain the missing scope and its impact. Continue generating drafts based on user-provided work materials and Feishu documents that can be accessed with permissions, clearly marking context boundaries.

2.1 Use Historical Materials

Historical OKRs are a key reference. Check at least the most recently completed cycle; when conditions allow, also examine earlier cycles, progress records, scores, comments, performance summaries, and H1 self-reviews.

Categorize historical content into four types:

• Completed Facts: Use as baselines, proof of capability, or case evidence; do not copy verbatim as new KRs;
• Unfinished or Recurring High-Priority Items: Treat as candidate main lines for the current cycle, redefine phased results;
• Repeated Feedback from Superiors or Colleagues: Convert into quality, collaboration, or mechanism-oriented results;
• Capabilities Already Formed but Not Yet Replicated: Convert into scaled, standardized, independently runnable, or business results.

Establish a brief source ledger: Fact → Source → Time → Role in New O/KR → Confirmation Needed Yet. Separate past achievements from future commitments.

2.2 Read Four Types of OKR Relationship Context

Before writing the current cycle's OKRs, always check the following four types of relationships; when interfaces are missing, supplement via Feishu OKR pages, screenshots, user-pasted content, or accessible documents:

1. Previous Cycle's Personal Completion: Item-by-item comparison of O/KR target values, progress, scores, comments, and actual results. Distinguish between completed, partially completed, uncompleted, changed goals, and missing evidence; only bring forward unclosed items or new phased results that are still meaningful for the current cycle.
2. Current Cycle's Personal @Mentions: Collect which O/KRs you were @mentioned in, by whom, the corresponding collaboration expectations, delivery milestones, and responsibility boundaries. Categorize them as primary responsibility candidates, collaborators, items to confirm, or informational @mentions; do not automatically interpret being @mentioned as a commitment.
3. Previous Cycle's @Mentions of Others: Review who the user @mentioned, corresponding O/KRs, collaboration content, and whether closure occurred. Identify persistent dependencies, repeated contacts, collaboration mismatches, and relationships that can be codified into mechanisms; only retain collaboration relationships that are still valid for the current cycle.
4. Direct Supervisor's OKRs: Confirm the direct supervisor's identity, current cycle, O/KR order, key results, indicator definitions, and collaboration boundaries. Determine whether personal O is for alignment, support, horizontal collaboration, or an independent main line; when the supervisor's OKR is missing, the cycle is unclear, or identity cannot be verified, mark boundaries without inferring.

Establish a relationship ledger: Relationship Type → Source Object → O/KR → Counterparty/Collaborator → Fact or Expectation → Current Cycle Handling → Confirmed Yet. Use the four types of information as "historical results," "collaboration input," "collaboration traceback," and "vertical alignment," respectively; avoid mixing them into a single to-do list.

3. Collect Minimum Necessary Input

At a minimum, confirm: cycle, role or scope of responsibility, business results to be achieved, known baselines, target values or judgment criteria, main collaborators, constraints, and sensitive information.

When supervisor's or team OKRs are already available, first identify:

• Which O's need alignment;
• Which KRs involve peer collaboration;
• Which work is the user's primary responsibility vs. assistance;
• Whether the user's proposed work duplicates or conflicts with existing O's.

If a direct supervisor exists, the supervisor's current cycle OKR is the primary reference for vertical alignment; team OKRs, peer OKRs, and @mention content supplement the scope of alignment and collaboration boundaries. Being @mentioned, @mentioning others, and "seemingly relevant" can only form candidate relationships; alignment is only reported as confirmed when content, primary responsibility, cycle, and mutual confirmation are all established.

When key inputs are missing, use the fewest questions to fill gaps; if still unable to confirm, continue outputting, but explicitly place uncertainties into [To Be Confirmed].

4. Generate Draft

O Writing Guidelines

• Focus on high-priority, high-value work; exclude routine duty stacking; recommend 3–5 O's, allow fewer when scope is narrow.
• Clearly state direction, expected value, and time range; keep granularity moderate, avoid sloganeering or task listing.
• Maintain some challenge; avoid treating "continue doing" as a goal.
• For long-term items, break down into phased results for the current cycle.
• Use business vocabulary understandable on first reading; use already confirmed organizational proper nouns.

When a user lists multiple projects or campaigns at once, first cluster by business result, then decide the number of O's. Project names usually go into KR, implementation paths, or evidence columns; only when they represent an independent result storyline should they become a separate O. Common clustering directions include customer/business results, end-to-end process efficiency, productization and replication, and organizational mechanisms and influence.

KR Writing Guidelines

• Each O: recommend 3–5 KRs, covering different key support dimensions.
• Write results and status first, then add necessary implementation paths; avoid simply writing "complete, responsible, drive, follow up."
• Provide objectively observable qualitative or quantitative judgment criteria; after "improve, optimize, enhance," supplement the starting point, endpoint, or acceptance criteria.
• Specify time milestones within the cycle; when target values are unknown, retain [Target Value To Be Confirmed].
• When collaboration is needed, indicate primary responsibility, collaborators, and responsibility boundaries; generally no more than 4 main collaborators.
• If an explanation of KR's direction is needed, use short subtitles, e.g., [Customer Value], [Process Efficiency], avoid merging multiple main lines into one.

Prefer the following structure for a single KR:

[Key Aspect] Through [necessary path], by [time milestone], achieve [observable result/target value], with [primary owner] responsible, @ [collaborators] in collaboration.

Shorten overly long paths; results, time, and acceptance criteria must be retained.

5. Perform Quality Check

Check each O and KR individually, categorize issues into "blocking publication" and "suggested optimization." Detailed rules are in references/okr-writing-principles.md.

Key checks:

• Is O high-priority, clear, moderately challenging, and corresponding to the current cycle?
• Does KR directly support O, describe a result, and be measurable, achievable, and time-bound?
• Are KRs duplicative, missing key support dimensions, or conflicting with each other?
• Do target values, baselines, dates, and owners have sources?
• Are vertical alignment, horizontal collaboration, clear primary responsibility, and actual alignment targets present?
• Have previous cycle completion, this cycle's @mentions, previous cycle's @mentions of others, and direct supervisor's OKRs been checked?
• Is consistency maintained for target order, proper nouns, privacy, and sensitive information?
• Are scores, progress, weights, and target values not conflated?

6. Output Draft

Deliver in the following order:

1. Cycle & Context: Which cycles, supervisor O's, documents, and user inputs were used; explain reading boundaries.
2. OKR Draft: Under each O, list KRs, result criteria, time, primary responsibility, collaborators, and evidence sources.
3. Historical Continuity: Which historical facts became baselines, which items continue, which achievements are elevated to replication or scaling results.
4. Relations & Continuity Checklist: Previous cycle completion, this cycle's @mentions, previous cycle's @mentions of others, direct supervisor alignment, suggested @mention targets, conflicts, and items to discuss.
5. Quality Diagnosis: Blocking items, suggested optimizations, unverified assumptions.
6. To Be Confirmed: List only items that would change objective meaning, result criteria, or system writes.

Do not use seemingly complete numbers to mask uncertainty. Quality judgments should explain "why this KR proves the O is achieved."

7. Write to Feishu

Only perform write operations when the user explicitly requests writing or saving. Before writing:

1. Confirm the current user, tenant, cycle, target ownership, and complete draft again;
2. Establish a "Write & @Mention Checklist": for each O/KR, list collaborators, @mention reasons, primary responsibility boundaries, sources, and verification status;
3. Resolve each name or email to open_id one by one using lark-cli contact +search-user. If multiple candidates, cross-tenant, or insufficient identity information, pause @mention for that item, request confirmation, do not guess;
4. First use --dry-run to check the request;
5. For plain text and @mention, prioritize the simple style; when precise control over @mention position is needed, use the mention element in richtext;
6. For creating multiple O/KRs, prioritize okr +batch-create; for a single O or KR, use okr +create; write the mention on the corresponding O/KR, avoid centralizing @mention of all collaborators in one target;
7. Do not automatically set scores due to "draft"; only handle scores when the user explicitly requests grading;
8. After writing, re-read the cycle details, verify O/KR count, content, order, weights, deadlines, mentions, and save/publish status;
9. If read-back is incomplete, mentions are not materialized, or system semantics may directly publish, stop and explain to the user; do not proceed.

Write & @Mention Decision

• When the user only says "draft, generate, optimize," output only the local draft and @mention suggestion list.
• When the user explicitly says "write, save to Feishu, fill in for me," drafts can be created; only when the user simultaneously explicitly says "@mention someone" or the relationship ledger has a verified collaborator, then write the mention.
• mention is a real user ID, not a @Name string in the body. Use the interface path to put mention: ["ou_xxx"] into the corresponding O/KR; use the page user picker for the page path and read back the actual user tag in the page.
• Explain reasons for @mentioning primary responsible persons, collaborators, and direct supervisors separately; for candidate relationships formed solely by "relevant" or "being @mentioned," first enter the to-be-confirmed list.
• Report write results separately: Created/Saved, @Mentioned, Not @Mentioned + Reason, Not Published. If any item lacks read-back evidence, retain as to be verified.

When the interface cannot write, you may use the "Batch Paste OKRs" or page editing controls on the logged-in Feishu OKR page to save the draft. The page path must follow this order:

1. Confirm the current user, cycle, and page title first;
2. After pasting O/KRs, check the parsing preview to confirm O/KR count and hierarchy; when batch paste cannot generate real @mentions, switch to page editing controls to select collaborators one by one;
3. For each O/KR requiring @mention, use the page user picker, verify the displayed name and department; avoid only entering plain text @Name;
4. Only perform save confirmation; do not click publish;
5. Return to the final page to verify "Saved," O/KR content, and real user tags, and confirm that each target still has the "Publish" button;
6. When the page popup closes, save prompt is missing, @mention tag does not appear, or field count is abnormal, re-read the page; do not claim save success.

Alignment relationships only affect Objectives. Before creating an alignment, confirm that the two targets belong to different objectives, have overlapping cycle time, and indeed have a alignment or collaboration relationship; do not write "relevant" directly as "aligned." Full process is in references/feishu-okr-alignment-review.md.

Reference Routing

• Writing principles, O/KR diagnostics, and counterexamples: read references/okr-writing-principles.md.
• Pre-meeting, during-meeting, post-meeting alignment and conflict resolution: read references/feishu-okr-alignment-review.md.
• Feishu OKR entities, reading, writing, permissions, and read-back: read references/feishu-okr-operations.md.