Univer Team Standup

univer-worklog core

Internal core skill. Do not call this skill directly from $; it is shared protocol loaded by the visible entry skills:

• univer-worklog-append
• univer-worklog-auto
• univer-worklog-report
• univer-worklog-report-team
• univer-worklog-help

Operate the worklog workbook through univer/unv only. Treat workbook-visible state as the source of truth; never inspect, unzip, patch, or directly edit .univer/.unv internals.

Required Skills

This workflow depends only on the Univer CLI toolchain:

1. the univer or unv executable from the npm package univer-cli
2. the univer-cli Codex skill installed from dream-num/skills

For workbook reads, writes, previews, synchronization, and verification, follow the univer-cli skill rules. Do not use ad hoc spreadsheet libraries, direct .univer package edits, or alternate workbook APIs for worklog state.

If univer-cli skill instructions are unavailable, use univer help and univer help <topic> before unfamiliar commands. Do not guess CLI syntax or bypass the CLI.

Dependency Bootstrap

The skill may bootstrap its own Univer dependencies when they are missing. Treat univer-cil as a typo for univer-cli.

Source for Univer skills:

https://github.com/dream-num/skills

Required local dependencies:

• univer or unv from univer-cli
• univer-cli skill from dream-num/skills
• no other workbook engine is required or allowed for normal worklog operation

Check dependencies only when:

1. first use
2. .univer-agent/dependency-check.json is missing
3. last dependency check is older than 7 days
4. the user asks to update
5. a univer/unv or univer-cli skill call fails in a way that suggests a missing or stale dependency

Install or repair flow:

command -v univer || command -v unv || npm install -g univer-cli@latest
npx skills add dream-num/skills

Verify after install:

univer --version || unv --version
test -f ~/.codex/skills/univer-cli/SKILL.md

After a successful check, write .univer-agent/dependency-check.json locally with checked time, CLI command, CLI version if available, skill source, and status. Never commit this file.

If install fails, show the exact failing command and continue only with operations that do not need the missing dependency.

Paths

Never commit .univer-agent/ files.

Team Remote

Mandatory team workbook unit id:

fYmh0HRyTUO6YECQGFScnA0

Default team workbook URL:

https://univer.ai/space/sheets/fYmh0HRyTUO6YECQGFScnA0

Default Univer CLI host:

https://univer.ai/

This remote is mandatory for every worklog write, append publish, auto-submit, commit, and sync. univer-worklog-append and univer-worklog-auto must never push worklog rows to any other unit id.

Remote override policy:

• profile.remote_workbook and UNIVER_WORKLOG_REMOTE may be read only to detect drift. They must not redirect append/auto writes away from fYmh0HRyTUO6YECQGFScnA0.
• If a local profile or environment variable points to a different unit id or URL, stop before writing or syncing, warn the user about the mismatch, and use the mandatory team remote only after the user confirms repairing local config.
• profile.univer_host and UNIVER_WORKLOG_HOST may not redirect append/auto writes away from https://univer.ai/. Before any write/sync, configure the CLI host back to https://univer.ai/.
• Reports may read a user-supplied workbook only when the user explicitly requests that separate read-only source. Append/auto/publish paths remain locked to the mandatory team remote.

Legacy local config fields that may exist:

UNIVER_WORKLOG_REMOTE=<remote-id-or-url>
profile.remote_workbook=<remote-id-or-url>
UNIVER_WORKLOG_HOST=<univer-host-base-url>
profile.univer_host=<univer-host-base-url>

When a workflow writes or syncs the team-visible workbook, resolve the remote as the mandatory team remote only:

fYmh0HRyTUO6YECQGFScnA0

Resolve the Univer host for writes/syncs as:

https://univer.ai/

Normalize remote values before running CLI commands:

• If the remote is a full URL like https://univer.ai/space/sheets/<unitID>, use <unitID> for univer clone --unit-id and keep the full URL as the user-facing access link.
• If the remote is only the mandatory unit id, build the access link as https://univer.ai/space/sheets/fYmh0HRyTUO6YECQGFScnA0.
• Configure the CLI with the base host, not the workbook URL path: univer config set univerHost https://univer.ai/.

Do not use guessed query URLs such as ?unit=<id>&type=2 for success links. Use the /space/sheets/<unitID> URL format above.

Do not print access-sensitive remote values in long logs. It is OK to show a short masked form such as fYmh...cnA0.

Mandatory remote enforcement checks:

1. Before clone/pull, confirm the target unit id is exactly fYmh0HRyTUO6YECQGFScnA0 and the CLI base host is https://univer.ai/.
2. After clone/pull, inspect the local workbook binding/status and confirm it is bound to fYmh0HRyTUO6YECQGFScnA0. If the binding is missing or different, stop before writing and clone the mandatory team workbook into a fresh package.
3. Immediately before writing rows, re-check the bound unit id. Do not write rows into a workbook bound to any other remote.
4. Immediately before commit/sync, run the Univer CLI status/binding check again and verify the destination unit id and access URL are still the mandatory values.
5. After sync, verify the success link or status points to https://univer.ai/space/sheets/fYmh0HRyTUO6YECQGFScnA0.
6. If the CLI output cannot prove the target unit id, stop before sync and ask the user to review; do not guess.

Business Goal Tracking

For report periods overlapping 2026-05-21 through 2026-06-18, load references/business-goals-2026-05-21-2026-06-18.md and track worklog evidence against the embedded Univer CLI next-stage OKR.

Source goal workbook:

https://univer.ai/space/sheets/iqf9frj6SACbbXMc06gZ8A3

Goal tracking applies to both personal and team reports. It should make the report better at remembering the business context over time:

• map worklog rows to O1 SpreadsheetBench, O2 Agent Builder, O3 Code as Spreadsheet, and O4 SDK-to-CLI/foundation delivery when evidence supports it
• distinguish strong, medium, and weak evidence; do not force a goal mapping when the evidence is vague
• call out missing evidence, owner gaps, blockers, risks, cadence risks, acceptance gaps, repeated stale next steps, and high-priority unmapped work
• do not invent progress percentages; use qualitative status unless a row contains measured proof such as ranking, coverage, migration rate, MVP closure, capability matrix completion, regression results, or formula Rust benchmark data proving 10x+ performance improvement
• keep the section concise enough for morning standup, with deeper details collapsed in HTML reports

When append or auto flows create rows during this goal window, prefer goal-aware 关联项 or WorkItems hints when the evidence clearly matches a goal, for example O2-KR1-worklog-dogfood, O4-KR1-sdk-cli-matrix, O4-KR3-formula-rust, O4-KR4-docs-export, or O4-KR5-slide-mvp. If uncertain, leave the row unmapped and let the report show it as possible focus drift rather than writing misleading metadata.

Route Intent

同步今天进展 means local append or auto worklog update, not remote sync. Manual append and report flows publish only when the user explicitly asks for commit/sync/publish. Auto flow may auto-submit when the Team Auto Submit policy allows it.

Team Auto Submit

univer-worklog-auto is allowed to commit/sync automatically to the team remote after it writes rows, because its purpose is automatic daily worklog submission.

Rules:

• --dry-run: never write and never submit.
• --confirm: ask before row writes; after confirmed writes, auto-submit if clean.
• --no-submit: write locally and preview, but do not commit/sync.
• default univer-worklog-auto: write allowed rows, verify by readback, append Audit, preview, then auto-submit if univer status is clean.
• manual append and report generation still do not auto-submit unless the user asks for commit/sync/publish.

Auto-submit steps:

1. Resolve the mandatory team unit id, access URL, and Univer host from Team Remote; the only allowed write/sync target is fYmh0HRyTUO6YECQGFScnA0 on https://univer.ai/.
2. Ensure univer config get univerHost matches https://univer.ai/; set it if needed before pull/write/sync.
3. Ensure the workbook is bound to fYmh0HRyTUO6YECQGFScnA0. If the local workbook is not bound to that exact unit id, clone the team workbook into a local working package with univer clone <path> --unit-id fYmh0HRyTUO6YECQGFScnA0 instead of syncing an unbound or wrong-bound workbook.
4. Run univer pull <bound-workbook>.
5. Re-read shared sheets and recompute local write ranges according to Shared Table Merge Policy.
6. Write and verify rows.
7. Run univer status <bound-workbook> and verify the destination is still fYmh0HRyTUO6YECQGFScnA0.
8. If clean, no conflict, and the target id is proven correct, run univer commit with a concise worklog message, then univer sync.
9. After sync, verify the success link or status points to https://univer.ai/space/sheets/fYmh0HRyTUO6YECQGFScnA0.
10. If status is unclear, conflict exists, or the target id cannot be proven, stop before sync, show review scope, and keep local changes.

Profile Contract

Required local profile:

{
  "schema_version": "univer-worklog/v0.1",
  "owner_id": "yangluoshen",
  "display_name": "洛神",
  "github_handle": "yangluoshen",
  "agent_id": "codex-yangluoshen-local",
  "personal_sheet": "log__yangluoshen",
  "timezone": "Asia/Shanghai",
  "default_repo": "dream-num/univer-cli"
}

Generate owner_id automatically, then ask the user to confirm once:

1. Prefer GitHub handle.
2. Else use email prefix if available.
3. Else slugify display name.
4. Else generate user-xxxx.

After confirmation, keep owner_id stable. personal_sheet must be exactly log__<owner_id>.

Workbook Contract

Template sheets: Dashboard, People, Audit, WorkItems, log__sample_member.

Runtime member sheets: onboarding creates log__<owner_id> for real members. Append and auto write only to the current profile's exact personal sheet.

Headers:

Dashboard: 成员ID,成员,更新状态,昨天完成,今天计划,阻塞,风险,下一步,最近日志,最近更新时间,预览状态
People: 成员ID,显示名称,GitHub账号,AgentID,个人日志表,默认仓库,默认项目,时区,是否启用,更新时间
Audit: 审计ID,创建时间,成员ID,AgentID,操作,工作表,范围,日志ID,操作摘要,状态
WorkItems: 关联项,工作项,默认优先级,默认仓库,负责人,状态,更新时间,备注
Personal Log: 日志ID,日期,成员ID,工作项,状态,优先级,昨天完成,今天计划,阻塞,风险,下一步,仓库,关联项,证据,来源,置信度,去重键,创建时间

People stores identity and display names. Personal logs use 成员ID; reports join to People to display names.

WorkItems is the shared memory for project priority and ownership. Before writing auto rows, read WorkItems and inherit priority for matching 关联项, 去重键, title, PR, issue, or repo signal. If the user corrects priority, update WorkItems before future auto runs.

Dashboard is presentation-only. It derives visible state from People and each active member's 个人日志表, falling back to log__<owner_id> only when 个人日志表 is blank. Its formulas must support both the canonical 18-column personal log schema and the extended 26-column evidence schema used by some manually imported logs.

Personal Log Date Field Policy

The Personal Log 日期 column is the canonical report date. Append, auto, personal report, and team report flows must treat it carefully so reports do not miss rows.

Write rules:

• Append and auto must write 日期 as the user's local work date, normalized to YYYY-MM-DD in profile.timezone.
• After writing rows, apply a date display format such as yyyy-mm-dd to the written 日期 cells, or to the whole personal log B:B data range when creating/repairing a sheet.
• It is acceptable for the workbook raw value to be a spreadsheet serial number if the display value is formatted as YYYY-MM-DD.
• It is not acceptable for the visible/display value to be a naked number such as 46163; if readback shows that, repair the number format before preview, commit, or sync.
• Read back both the written row and at least the 日期 cell display value after append/auto. The row is not verified until 日期 can be normalized to the intended YYYY-MM-DD.

Read/report rules:

• Reports must filter by normalized 日期, not by 创建时间, 最近更新时间, file modification time, or current conversation time.
• When reading existing rows, accept ISO strings, date-like display values, and spreadsheet serial numbers. Normalize all of them to local YYYY-MM-DD before period filtering.
• If a row has a valid serial raw value but numeric display, include it in the report after normalization and surface a compact data-quality warning: 日期格式需修复.
• If 日期 is missing or cannot be parsed, exclude it from date-bound report counts and list it under data-quality warnings with sheet name and 日志ID.
• Team reports must apply this normalization to every candidate log__* and legacy log_* sheet before deciding whether a member has filled the requested day/week/month.

Progress And Risk Prompting Policy

Append and auto rows should be useful for a morning standup, not only an evidence archive. Before writing rows, help the user fill the fields that make reports actionable.

Required review fields for every candidate row:

• 状态: 已完成, 进行中, 阻塞, or 待确认
• 优先级: resolved by Priority Policy
• 昨天完成: concrete progress or shipped outcome
• 今天计划: next checkpoint or planned follow-up
• 阻塞: blocker, dependency, owner, or 无
• 风险: schedule/product/quality/customer risk, severity hint, or 无风险
• 下一步: one concrete next action
• 关联项: objective, PR/issue, WorkItem, or blank only when genuinely unknown

Prompting rules:

• Manual append must show the candidate row before writing and explicitly remind the user to fill or confirm missing 风险, 阻塞, 今天计划, 下一步, and progress/status information.
• Auto must infer these fields from evidence when possible, then show a compact candidate review summary unless the user requested fully automatic submission and the evidence is clear.
• Do not silently write empty 风险, 阻塞, 今天计划, or 下一步 cells. Use 待确认 or 需补充 when the information is missing, and surface that in preview.
• Use 无风险 or 无 only when evidence or the user clearly indicates no risk/blocker. If unknown, prefer 待确认/需补充.
• If any candidate is 阻塞, P0/P1, high risk, or has missing next action, pause for confirmation unless --dry-run is being used.
• Keep the reminder short and operational: ask for missing risk/progress fields in one grouped prompt, not one question per cell.

Shared Table Merge Policy

Shared sheets such as People, WorkItems, and Audit are collaborative state. Every write workflow must treat the latest remote workbook as authoritative before editing shared rows.

Before any workflow writes People, WorkItems, Audit, or a personal log sheet:

1. Resolve the team remote and Univer host.
2. Clone the remote workbook into a fresh working package, or pull the already-bound package.
3. Inspect workbook sheet names and read the latest People, WorkItems, Audit, and the current user's personal log sheet.
4. Rebuild the local candidate write set from that latest read. Do not reuse row numbers, sequence ids, or shared table snapshots from before the pull.

Shared table write rules:

• People: identify rows by 成员ID. A member flow may insert or update only its own 成员ID row. It must preserve all other rows exactly as currently read from the workbook.
• People!个人日志表: if an existing row for the current 成员ID has a different non-empty personal sheet, stop and ask for review unless the user explicitly confirms the migration.
• WorkItems: identify rows by 关联项 first, then by stable repo/title key. Update only rows related to the current user's candidate evidence. If another row changed remotely, keep the remote value and recompute local priority inheritance.
• Audit: append new rows after the latest non-empty row. Never rewrite existing audit rows.
• Personal logs: identify rows by 日志ID and 去重键. Recompute the next 日志ID sequence after reading the latest remote sheet.

If a local candidate would overwrite a remotely changed shared row, do not write it as-is. Re-adjust the candidate against the latest workbook state, then show the user a concise conflict summary and either skip, append a new row, or ask for confirmation.

Before commit/sync, read back all changed ranges and run univer status. If status, readback, or sync indicates conflict/stale state, stop before sync and keep the workbook local for review.

Member Boundaries

Member flows may:

• create the current user's local profile during onboarding
• create or repair only the current user's log__<owner_id> sheet
• add or update only the current user's People row
• append rows only to profile.personal_sheet
• read WorkItems and write only priority/rule rows related to the current user's worklog evidence
• write Audit entries for their own actions

Member flows must not write another member's row, another member's sheet, team-level publish state, or Dashboard progress cells.

Priority Policy

Determine 优先级 in this order:

1. User explicitly provided priority in the current request.
2. Existing WorkItems row for the same 关联项, PR, issue, repo/title pattern, or 去重键.
3. GitHub issue/PR labels, milestone, title markers, or branch naming.
4. Skill rules and evidence strength.
5. Default to P2 and mark the row as review-needed in 证据 when uncertain.

Do not ask users to fill priority every time. Ask only when the priority changes the report meaning and no evidence can decide it.

Report Date Resolution

Personal and team report workflows must resolve both period and date anchor before reading logs.

Supported explicit forms:

univer-worklog-report --period day --date 2026-05-21
univer-worklog-report --period week --date 2026-05-21
univer-worklog-report --period month --date 2026-05
univer-worklog-report-team --period day --date yesterday
univer-worklog-report-team --period week --date last-week
univer-worklog-report-team --period month --date this-month

Supported natural-language aliases:

Date resolution rules:

• Resolve relative dates in profile.timezone; default to Asia/Shanghai when profile timezone is missing.
• --period day --date <YYYY-MM-DD> covers that natural day.
• --period week --date <YYYY-MM-DD|relative> covers Monday through Sunday for the week containing the resolved date.
• --period month --date <YYYY-MM|YYYY-MM-DD|relative> covers the whole natural month.
• If the user provides only day, week, or month, use today as the anchor in profile timezone.
• If the user says 今天, 昨天, 本周, 上周, 本月, or 上月 without flags, infer both period and date from the alias.
• Filter report rows by the Personal Log 日期 field, not by 创建时间, file modification time, sync time, or current conversation time.
• Accept spreadsheet serial dates and ISO/date-like display values, but normalize them to local YYYY-MM-DD before filtering.
• Report titles, filenames, and summaries must show the resolved absolute date range, for example 2026-05-20, 2026-05-18 to 2026-05-24, or 2026-05.
• If parsing is ambiguous, state the assumed absolute range before generating the report.

Workflow: Onboard

1. Check univer or unv.
2. Collect or infer display_name, github_handle, agent_id, timezone, and default_repo.
3. Generate owner_id and personal_sheet; ask the user to confirm once.
4. Write .univer-agent/profile.json; read it back.
5. Resolve the team unit id, access URL, and Univer host. If the local workbook is unbound, clone the team workbook by unit id into a local working package rather than syncing the template as a new remote. Otherwise say this is local template preview only.
6. Inspect People, WorkItems, Dashboard, and sheet names through public CLI reads.
7. Stop if People already has the same owner_id with a different personal sheet.
8. If the personal sheet is missing, create it with the Personal Log header.
9. Add/update only this owner's People row with 是否启用=是, preserving all other People rows from the latest remote read.
10. Append Audit with 操作=onboard.
11. Read back changed ranges and preview with univer view.
12. Stop. Do not commit or sync.

Workflow: Append

Use for manual rows.

1. Check univer/unv; avoid network dependency checks unless needed.
2. Read profile. If missing, run Onboard, then ask whether to continue.
3. Pull the workbook only from the mandatory team remote fYmh0HRyTUO6YECQGFScnA0; if local config points elsewhere, stop and repair before writing.
4. Inspect personal sheet, People, WorkItems, and Audit.
5. Build one or more candidate rows from the user's text.
6. Resolve priority through Priority Policy.
7. Apply Progress And Risk Prompting Policy: show candidate rows, remind the user to confirm or fill progress, risk, blocker, plan, and next-action fields, then wait for confirmation.
8. Generate 日志ID as YYYYMMDD-<owner_id>-<seq> in profile timezone, recomputing <seq> from the latest remote personal sheet.
9. Generate 去重键 from owner/date/repo/关联项/title/source when absent.
10. Re-check that the workbook is bound to fYmh0HRyTUO6YECQGFScnA0, then write only to profile.personal_sheet, following Personal Log Date Field Policy for the 日期 cell.
11. Read back and verify key fields, including that 日期 display can be normalized to the intended YYYY-MM-DD.
12. If 日期 displays as a naked serial number, repair the date number format before preview.
13. Append Audit, preview workbook, and stop without commit/sync.
14. If the user explicitly asks to publish/sync the append result, rerun Mandatory remote enforcement checks and sync only to fYmh0HRyTUO6YECQGFScnA0.

Workflow: Auto

Use for univer-worklog-auto. Auto means: collect evidence, summarize, dedupe, then write according to policy. It is allowed to write rows without asking per row unless --dry-run, --confirm, or uncertainty requires review.

Supported flags:

• --dry-run: collect, summarize, dedupe, and print candidate rows; do not write workbook.
• --confirm: show candidates and ask before writing each row.
• --no-submit: write locally but skip auto commit/sync.
• --period day|week|month: collection window; default day.

Evidence sources, in priority order:

1. Git and GitHub: commits, branches, PRs, issues, review comments, CI results.
2. Codex local sessions: ~/.codex/session_index.jsonl and ~/.codex/sessions/**/*.jsonl.
3. workbuddy local history: local history.json or equivalent path when available.
4. Current conversation and explicit user notes.

Collection rules:

• Use the user's timezone from profile.
• For day, read today's local window. Include active sessions whose events fall in the window, even if the JSONL file path is under the previous UTC date.
• For Codex, summarize by session: thread name, workspace, user requests, final outcomes, files changed, commands/tests run, and evidence path.
• For workbuddy, normalize to the same evidence shape: source, title, workspace, requests, outcomes, evidence path.
• For git/GitHub, prefer concrete evidence: commit SHA, PR number, issue number, changed files, CI status.
• Never infer another person's work as the current user's row unless the evidence is clearly authored by the current owner.

Deduping rules:

• Merge Codex/workbuddy/git/GitHub evidence into one row when repo, PR/issue, branch, title, or file cluster match.
• Prefer GitHub PR/issue as 关联项; else commit SHA or branch; else session id.
• Use 去重键 = <owner_id>:<date>:<repo>:<关联项-or-topic>.
• If a row with the same 去重键 already exists for the period, update only when the new evidence is materially better; otherwise skip and write an Audit row with 操作=auto-skip-duplicate.

Auto row writing:

1. Read profile, enforce the mandatory team remote fYmh0HRyTUO6YECQGFScnA0, pull workbook from that remote, and inspect People, WorkItems, personal log, and Audit.
2. Collect evidence from enabled sources.
3. Summarize evidence into candidate rows using the Personal Log schema.
4. Resolve priority from the latest WorkItems, GitHub labels, explicit user data, then fallback rules.
5. Set 状态 to 已完成, 进行中, 阻塞, or 待确认; use 待确认 if evidence is unclear.
6. Keep 昨天完成 and 今天计划 human-readable enough for report generation. Do not dump raw logs.
7. Keep 证据 compact: include session id/path, commit/PR/issue links, and test command summaries.
8. Apply Progress And Risk Prompting Policy: infer progress/risk/blocker/next-action fields when evidence supports them, mark missing items as 需补充 or 待确认, and pause for review when uncertainty affects the report.
9. Respect --dry-run and --confirm.
10. Before writing, re-check latest personal log 去重键/日志ID, latest shared People/WorkItems, and the workbook binding to fYmh0HRyTUO6YECQGFScnA0; adjust candidate rows if the remote changed during collection.
11. Write candidate rows only into the workbook bound to fYmh0HRyTUO6YECQGFScnA0, following Personal Log Date Field Policy for all 日期 cells.
12. Read back candidate rows, verify date display/normalization, repair naked serial number display if needed, append Audit, and preview workbook.
13. Unless --no-submit is present, follow Team Auto Submit.

Workflow: Personal Report

Use for univer-worklog-report [day|week|month], natural-language date aliases such as 今天, 昨天, 本周, 上周, 本月, 上月, or --period day|week|month --date <anchor>. Default period is day with today's date anchor.

Before reading rows, resolve the exact date range according to Report Date Resolution.

Read only the current user's log__<owner_id> plus People and WorkItems. Generate a self-contained AI-written HTML report under the matching report directory. Use Markdown only when the user explicitly asks for Markdown.

If the report period overlaps the Business Goal Tracking window, load the business goals reference and include goal-aware analysis from the current user's rows. Do not show every objective by default; show touched objectives plus warnings where the user's missing or unmapped work creates risk.

Personal report output:

• file: ops/reports/<daily|weekly|monthly>/<period>-<owner_id>.html
• format: standalone HTML with inline CSS and minimal inline JS; no external network assets
• opening view: executive header with member name, period, generated time, team workbook link, and 3-5 sentence AI-written summary
• top metrics: total rows, completed, in progress, blocked, risk count, P0/P1 count
• business goal contribution: for overlapping periods, a compact 业务目标贡献 section after top metrics with touched O1-O4 objectives, evidence strength, next checkpoint, and relevant warnings
• main body: visual project cards grouped by repo/work item, with status and priority chips, progress narrative, next action, blockers/risks, and compact evidence links
• interactions: filter chips for status/priority/repo, collapsible evidence/details sections, copy-summary button, and print-friendly styling
• visual style: calm operational dashboard, dense but readable, 8px-or-less card radius, not a marketing landing page, no decorative gradient/orb background
• accessibility: semantic headings, keyboard-friendly buttons, readable contrast, responsive layout

Weekly and monthly HTML reports must add a trend section: repeated themes, shipped work, lingering risks, suggested next focus, and whether the member's evidence is converging on or drifting from the business goals.

Workflow: Team Report

Use for univer-worklog-report-team [day|week|month], natural-language date aliases such as 今天, 昨天, 本周, 上周, 本月, 上月, or --period day|week|month --date <anchor>. Default period is day with today's date anchor.

Before reading rows, resolve the exact date range according to Report Date Resolution.

Read team logs from both the member registry and the workbook's actual log sheets. People is the roster, but it is not the only evidence source; any non-sample personal log sheet with period rows must be included in the report even when the member is missing from People.

Team report read order:

1. Inspect the workbook and collect all sheet names.
2. Read People and build a member registry keyed by 成员ID; treat 是否启用 values 是, yes, true, TRUE, and boolean true as active.
3. Read WorkItems for priority/repo ownership hints.
4. Build the candidate log sheet set as the union of:
   • People!个人日志表 for active people rows
   • fallback log__<成员ID> for active people rows when 个人日志表 is blank
   • every workbook sheet matching log__* or legacy log_*, excluding log__sample_member
5. For every candidate sheet, read rows for the requested period. If the sheet is not present in People, infer 成员ID from the row 成员ID column first, then from the sheet name, and mark the member as 未注册填报人.
6. Include registered members with no period rows as 未填报, but include unregistered log sheets only when they have period rows.
7. Join display names from People when available; otherwise use the inferred member id or sheet name and show a compact warning badge such as 未注册.
8. Never rely on Dashboard as the report source; Dashboard is presentation-only and can miss rows that are not represented in People.

Generate a self-contained AI-written HTML report under the matching report directory. Use Markdown only when the user explicitly asks for Markdown.

If the report period overlaps the Business Goal Tracking window, load the business goals reference and include 业务目标追踪 — OKR 进度 as the first sub-section inside 晨会聚焦. This section must be AI-written from worklog evidence, not a static copy of the OKR table. Do not create a separate generic 业务目标概览 block.

PMO OKR focus requirements:

• Priority: treat this as P1 presentation-layer behavior for team reports. Do not change data collection, workbook schema, storage, append, or auto write logic for this requirement.
• Replace, do not duplicate: remove 晨会聚焦 -> 业务目标概览; promote the former standalone 业务目标追踪 card area into 晨会聚焦 as 业务目标追踪 — OKR 进度.
• 晨会聚焦 must contain these four sub-sections in order: 业务目标追踪 — OKR 进度, 重大进展同步, 重要风险点, 需沟通事项.
• 业务目标追踪 — OKR 进度 must keep the compact one-card-per-objective layout for O1-O4 and show progress percentage, status (正常/滞后/风险), "到了哪里", and "还差什么".
• 重大进展同步 must be visually clustered by objective so the reader can quickly answer "O3 今天有哪些产出" and "O4 今天推进了什么".
• Use exactly these progress group headings, in order: O1 SpreadsheetBench, O2 Agent Builder, O3 Code as Spreadsheet, O4 SDK→CLI, 基建 & 其他.
• Omit objective groups with no progress for the selected period; do not render empty placeholder sections.
• Within one objective group, preserve the existing item ordering rule: delivered/shipped outcomes first, then in-progress items, then weaker signals. Avoid repeating the project name on every item when the group heading already provides the context.

Team report presentation order:

1. Team summary and update coverage.
2. 晨会聚焦: the meeting-first block. It must contain only 业务目标追踪 — OKR 进度, 重大进展同步, 重要风险点, and 需沟通事项. A host should be able to run the morning meeting from this block alone.
3. Inside 晨会聚焦, render 业务目标追踪 — OKR 进度 first. Use one compact card per O1-O4 with evidence-based progress percentage, status (正常/滞后/风险), and "到了哪里 / 还差什么". Keep progress and risks visually separate, such as left/right columns or stacked progress/risk areas. Do not expand raw evidence in this block. Do not also render a separate 业务目标概览.
4. Inside 晨会聚焦, render 重大进展同步 as meeting-worthy progress grouped strictly by business objective in this order: O1 SpreadsheetBench, O2 Agent Builder, O3 Code as Spreadsheet, O4 SDK→CLI, 基建 & 其他. Omit empty groups. Within each group, place delivered outcomes before in-progress items, merge duplicate rows, and do not repeat the project name on every item when the group title already names the objective.
5. Inside 晨会聚焦, render 重要风险点 as an independent section separate from progress. List O1-O4 goal risks first, then other project/team/infrastructure risks. Group by project/category, show owner when known, and mark severity as P0/P1 or 高/中/低.
6. Inside 晨会聚焦, render 需沟通事项 as an independent section for alignment topics in today's standup. Each item must name responsible owner(s), for example @name, and state the question or decision needed.
7. After 晨会聚焦, render 每人晨会要点: one compact row or list item per active or log-only contributor, optimized for a quick verbal round. Each person should have status, 1 highlight, 1 next action, and blocker/risk/help signal. Keep it to 1-2 short lines per person; detailed rows come later.
8. Then render member detail cards and collapsed row details for after-meeting follow-up.

Team report output:

• file: ops/reports/<daily|weekly|monthly>/<period>-team.html
• format: standalone HTML with inline CSS and minimal inline JS; no external network assets
• opening view: team-level summary with date/period, generated time, workbook link, update coverage, and key delivery/risk narrative
• coverage accounting: show registered active members, registered updated members, unregistered log-only contributors, and missing registered members separately
• morning focus block: place 晨会聚焦 after the overview and before member details; include only 业务目标追踪 — OKR 进度, 重大进展同步, 重要风险点, and 需沟通事项
• business goal tracking: render 业务目标追踪 — OKR 进度 as the first sub-section of 晨会聚焦; for overlapping periods, show one compact card per objective O1-O4 with an evidence-based progress percentage, status (正常/滞后/风险), "到了哪里 / 还差什么", missing proof, and a separate risk area; label uncertain percentages as estimated and avoid false precision; never render a separate generic 业务目标概览
• major progress sync: a visually prominent but compact 重大进展同步 section grouped strictly by O1 SpreadsheetBench, O2 Agent Builder, O3 Code as Spreadsheet, O4 SDK→CLI, and 基建 & 其他; omit empty objective groups; inside each group, sort delivered outcomes before in-progress items, merge duplicates, avoid repeating the project name, and show owner badges where useful
• important risks: a separate 重要风险点 section, grouped first by O1-O4 goal risks, then by other project/team/infrastructure risks; include severity and owner
• communication items: a 需沟通事项 section for today's discussion/alignment items, each with owner, topic, and desired outcome
• per-person standup points: a 每人晨会要点 table or dense list before personal details, with columns such as member, status, highlight, next action, and help/risk; this is the meeting script, not the raw detail log
• default density: optimized for a 10-15 person team; the first viewport must be readable in a morning meeting without scrolling through every detail
• opening summary: 3-5 short sentences or bullets, no raw row-by-row narration
• member sections: each active member gets a compact summary card with one-line status, top 1-2 highlights, next action, and risk/help signal; detailed rows are collapsed by default
• member delay risk: every member card must show a delay-risk tag, such as 红/黄/绿 or 高/中/无风险, plus one short reason. Members without risk should still show 无风险 for contrast.
• member detail rows: include status/priority chips, next actions, blockers/risks, and evidence links; show at most 3 most important rows per member before an expandable "more" detail area
• team views: filter by member/status/priority/repo, show/hide details, copy standup summary, and print-friendly mode
• visual style: morning-standup dashboard, scannable on projector, restrained operational UI, no decorative gradient/orb background
• accessibility: semantic headings, keyboard-friendly controls, readable contrast, responsive layout

Team reports must include the team-level summary, morning focus block, per-person standup points, and each person's section. The default reading path is: team summary -> 晨会聚焦 with 业务目标追踪 — OKR 进度, grouped major progress, risks, and communication items -> per-person standup points -> compact member cards. The detailed list is for after-meeting follow-up and must not dominate the main view.

Workflow: Help

Return this concise command list:

$univer-worklog-append
$univer-worklog-auto [--dry-run] [--confirm] [--no-submit] [--period day|week|month]
$univer-worklog-report [day|week|month] [--date today|yesterday|YYYY-MM-DD|YYYY-MM]
$univer-worklog-report-team [day|week|month] [--date today|yesterday|this-week|last-week|this-month|last-month|YYYY-MM-DD|YYYY-MM]
$univer-worklog-help

Also mention natural-language aliases such as 生成我的日报, 生成团队周报, 自动总结今天工作, 今天, 昨天, 本周, 上周, 本月, and 上月.

Also mention the only required Univer dependencies:

npm install -g univer-cli@latest
npx skills add dream-num/skills

Also mention the default team workbook:

https://univer.ai/space/sheets/fYmh0HRyTUO6YECQGFScnA0

Also mention that reports covering 2026-05-21 through 2026-06-18 include Univer CLI next-stage OKR tracking from:

https://univer.ai/space/sheets/iqf9frj6SACbbXMc06gZ8A3

Workflow: Publish

Run for explicit commit/sync/publish requests, or when Team Auto Submit is reached by univer-worklog-auto.

1. Enforce Team Remote before doing anything: the publish target must be fYmh0HRyTUO6YECQGFScnA0 on https://univer.ai/.
2. Run univer status ops/team-ops.univer and verify the workbook binding/status proves that exact unit id.
3. Summarize workbook changes, target unit id, target URL, and conflict state.
4. If conflict, status needs review, or the target id cannot be proven, stop before commit/sync and explain review scope.
5. If clean and the mandatory target is proven, run univer commit and univer sync with a concise message.
6. After sync, verify the success link or status points to https://univer.ai/space/sheets/fYmh0HRyTUO6YECQGFScnA0.

Success Messages

After appen

…(truncated)