Update CHEK AI product enrichment skills

README.md

@@ -531,7 +531,8 @@ chek auth profile import dev-agent --file ./dev-agent.profile.json --activate
 ## 内置 Skills
 
 - [`skills/chek-setup/SKILL.md`](./skills/chek-setup/SKILL.md)：帮助 OpenClaw 完成 CHEK CLI setup、浏览器授权、token 兜底和健康检查。
-- [`skills/chek-ai-product-sourcing/SKILL.md`](./skills/chek-ai-product-sourcing/SKILL.md)：帮助 Agent 搜索、验证、分类、去重和整理 CHEK AI 产品候选，也能把用户录音、速记、截图和体验材料整理成评审房间内容。它只写本地文件或用户本轮指定的飞书/Lark 候选库，不硬编码默认候选库。
+- [`skills/formal-chinese-prd/SKILL.md`](./skills/formal-chinese-prd/SKILL.md)：将零散材料、现有文档或实现证据整理为正式、可评审、可验收的中文产品需求说明书，并提供结构、视觉布局与自动检查规范。
+- [`skills/chek-ai-product-sourcing/SKILL.md`](./skills/chek-ai-product-sourcing/SKILL.md)：帮助 Agent 搜索、验证、分类、去重和整理 CHEK AI 产品候选，也能把用户录音、速记、截图和体验材料整理成评审房间内容；用户明确指定 DEV 并授权执行时，还可按受控流程补充机器人、汽车、模型/方法、版本、封面和能力评测资料。它不硬编码默认候选库，也不会把候选整理静默升级成数据库写入。
 - [`skills/chek-prod-ai-product-ops/SKILL.md`](./skills/chek-prod-ai-product-ops/SKILL.md)：帮助 Agent 在生产环境执行正式 AI 产品评审房间提报、封面溯源、车型/机器人绑定、版本编辑提交、评测证据发布，以及长期智能汽车/机器人数据库维护；这个 skill 明确禁止 DEV/staging 操作。
 
 ## 前端和证据辅助
@@ -611,7 +612,8 @@ CI 也会运行 `scripts/check_registry_drift.py --allow-missing-optional`。如
 - `src/service.ts`：后台轮询、浏览器授权同步、mention task 处理、房间回复编排。
 - `src/render.ts`：房间上下文压缩、intent 识别、直接回复和本地 prompt 构造。
 - `skills/chek-setup/SKILL.md`：随仓库发布的 setup 和社区共建入口 skill。
-- `skills/chek-ai-product-sourcing/SKILL.md`：随仓库发布的 AI 产品候选 sourcing 和评测素材整理 skill。
+- `skills/formal-chinese-prd/SKILL.md`：随仓库发布的正式中文产品需求文档整理、评审与验收规范。
+- `skills/chek-ai-product-sourcing/SKILL.md`：随仓库发布的 AI 产品候选 sourcing、评测素材整理和显式授权 DEV 资料库增补 skill。
 - `skills/chek-prod-ai-product-ops/SKILL.md`：随仓库发布的 prod-only AI 产品提报、评测证据发布和车型/机器人库维护 skill。
 - `docs/bootstrap-message.md`：面向用户的一段式引导文案。
 - `docs/device-code-auth.md`：浏览器授权链路和 fallback 规则。

skills/chek-ai-product-sourcing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: chek-ai-product-sourcing
-description: Source, verify, classify, and package CHEK AI product candidates for either local output or a user-specified Feishu/Lark candidate base, including optional Zhihu Developer on-site search evidence and user review-material processing. Use when the user asks to search for AI products, fill or update a CHEK candidate pool, apply monthly or quarterly release windows, assess domestic availability/borrowability, prepare fields for AI product submission, check duplicate product candidates, use developer.zhihu.com/Zhihu site search, turn recordings/transcripts/notes into user-friendly AI product reviews, or decide which candidates/reviews should be submitted later through the CHEK CLI.
+description: Source, verify, classify, and package CHEK AI product candidates for local output, a user-specified Feishu/Lark candidate base, or an explicitly authorized CHEK DEV robot/vehicle/model enrichment run. Includes optional Zhihu Developer evidence and user review-material processing. Use when the user asks to search for AI products, maintain a candidate pool, enrich CHEK DEV robot/vehicle/model entries and versions, fill covers, deduplicate candidates, apply release windows, prepare formal submission fields, process review materials, or decide which candidates/reviews should be submitted later through the CHEK CLI.
 ---
 
 # CHEK AI Product Sourcing
@@ -13,6 +13,8 @@ Read [references/candidate-base.md](references/candidate-base.md) before writing
 
 Read [references/zhihu-developer-search.md](references/zhihu-developer-search.md) before using `developer.zhihu.com`, the Zhihu search API, or Zhihu on-site search results as evidence.
 
+Read [references/dev-library-enrichment.md](references/dev-library-enrichment.md) before reading or mutating the CHEK DEV robot, vehicle, benchmark-method, version, cover, or capability-evaluation library.
+
 ## Operating Rules
 
 - Browse the web for current product facts, release dates, versions, prices, official pages, App Store listings, and availability. Prefer official product pages, App Store pages, manufacturer pages, store pages, and reputable media.
@@ -24,6 +26,8 @@ Read [references/zhihu-developer-search.md](references/zhihu-developer-search.md
 - Do not publish user review material to a CHEK room unless the user explicitly confirms the target room or exact product tuple and authorizes posting.
 - Keep the Base simple. Do not add columns unless the user explicitly asks.
 - Deduplicate before writing. Check existing product names and, for final submission, also check product name + hardware model + software version.
+- Treat a new main entity, a new hardware/config version, and an update to an existing entity as three different actions. Do not create a new main entity when the evidence only describes a version, SDK, delivery milestone, or configuration change.
+- A newly created DEV robot, vehicle, or benchmark-method entry is incomplete until it has a verified CHEK-hosted cover or an explicit blocked reason. Keep the original cover source URL in the audit trail.
 - Be honest about domestic access. Do not say a product can be borrowed or tested unless a source supports that. Use `待渠道确认` or `待实测材料` when access is plausible but unproven.
 - For pure software products, hardware model may be empty, but software version must be specific. For hardware, cars, robots, and glasses, capture both hardware model and software/firmware/app/vehicle version whenever possible.
 - For user recordings, transcripts, or rough notes, preserve the user's actual experience while removing private information, license plates, phone numbers, exact addresses, account identifiers, and unrelated personal details.
@@ -68,6 +72,12 @@ Read [references/zhihu-developer-search.md](references/zhihu-developer-search.md
    - For Feishu output, use `+data-query` for counts by `状态`, `类别`, and `统计时间窗口口径`.
    - State explicitly that CLI product submission has not been performed unless it actually has.
 
+## Explicit DEV Library Enrichment
+
+Candidate sourcing and DEV library enrichment are separate modes. Enter DEV library enrichment only when the user explicitly names DEV and asks to create, update, enrich, approve, or backfill library records. Follow [references/dev-library-enrichment.md](references/dev-library-enrichment.md) for environment checks, duplicate resolution, entity/version decisions, cover upload, governed edits, capability-benchmark admission, and readback.
+
+Do not silently turn a candidate-pool request into a DEV mutation. Do not use this DEV mode for production.
+
 ## Review Material To Room Workflow
 
 Use this workflow when the user wants Agent help turning a product test, voice memo, transcript, shorthand notes, screenshots, videos, or links into a CHEK review-room contribution.
@@ -144,7 +154,7 @@ Use this checklist when the user asks whether anything is missing:
 - AI 健康应用: search independent apps plus platform entrances and mini-programs: 百度健康, 支付宝健康, 微信生态, AI+真人, 家庭医生, 报告解读, 症状自查, 免责声明.
 - 其他消费级 AI 产品: search AI glasses, AI recorder cards, AI recorder pens, wearable assistants, cameras, creator tools, video/image apps, phone-vendor ecosystem hardware.
 
-## Final Submission Boundary
+## Production Formal Submission Boundary
 
 Candidate sourcing and formal product submission are separate phases.
 

skills/chek-ai-product-sourcing/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "CHEK AI Product Sourcing"
-  short_description: "维护 AI 产品候选、知乎证据、评测素材整理与本地/飞书输出"
-  default_prompt: "Use $chek-ai-product-sourcing to source AI product candidates, enrich them with official and Zhihu Developer evidence, process user recordings/transcripts into review-room drafts, and mark P0/P1 evidence-collection tasks in local or user-specified Feishu output."
+  short_description: "维护 AI 产品候选，并按授权丰富 CHEK DEV 机器人、汽车和模型资料库"
+  default_prompt: "Use $chek-ai-product-sourcing to source and deduplicate AI product candidates, enrich them with official evidence and verified covers, and, only when explicitly authorized for DEV, create or update CHEK robot, vehicle, model/method, version, and capability-evaluation records with governed readback."

skills/chek-ai-product-sourcing/references/dev-library-enrichment.md

@@ -0,0 +1,94 @@
+# CHEK DEV Library Enrichment
+
+## Scope And Environment
+
+Use this workflow only when the user explicitly asks to enrich the CHEK DEV robot, vehicle, model/method, version, cover, or capability-evaluation database.
+
+Before any read or write:
+
+```bash
+chek --json config show
+chek auth status --check
+```
+
+Require `env=dev` and `api_origin=https://api-dev.chekkk.com`. Stop if the target is production or ambiguous. Never print access tokens, cookies, Authorization headers, or used SMS codes.
+
+## Evidence Package
+
+For every proposed create or update, capture:
+
+- canonical name, brand/owner, category, entry type, and aliases;
+- event and date, with the change classified as main entity, hardware/config version, SDK/model/firmware version, delivery/production fact, or onsite showcase;
+- exact source-backed facts and precise missing evidence;
+- official product, release, paper, repository, or conference URLs;
+- domestic access status and confidence;
+- official cover page/image candidates;
+- suggested action: `create`, `update`, `create_version`, `link_method`, `pending`, or `skip`.
+
+Use discovery sites only to find leads. Resolve final fields and cover provenance to official pages, papers, conference organizers, regulatory sources, or reputable original reporting. Do not expose an intermediary discovery site as the factual source when primary evidence is available.
+
+## Mandatory Duplicate Resolution
+
+Before creating anything, query DEV by canonical name, normalized punctuation/case, brand, model code, and every known alias. Inspect the detail and version list of plausible matches.
+
+Use this decision order:
+
+1. Same real product and same generation: update the existing main entity.
+2. Same product family but a distinct SKU, hardware generation, or experimental configuration: create or update a version/variant under the existing main entity when the schema supports it.
+3. Same string but a different owner, embodiment, or method: keep separate entities and record disambiguating aliases/owner.
+4. SDK, firmware, foundation model, delivery milestone, or showcase only: update the related entity/version/fact; do not create a physical robot.
+5. Benchmark model/method with independent evaluation identity: use `entryType=benchmark_method`. It may appear as a robot-like leaderboard subject in the product UI, but must not be mislabeled as physical hardware.
+
+Record the matched entity ID for every update and the negative search evidence for every create. Re-run the duplicate lookup immediately before submission.
+
+## Main Entry And Version Completeness
+
+For a physical robot or vehicle, separate stable identity from versioned configuration:
+
+- Main entry: canonical name, aliases, brand, category, description, market status, official URL, cover.
+- Version/config: hardware SKU, dimensions/specs, controller/compute, firmware, SDK, model version, release date, source snapshot.
+- Market changes: production, delivery, preorder, or sales facts with exact scope; never assign company-wide totals to one model without evidence.
+- Onsite appearance: store as an event/evidence fact unless the event is the actual first public release.
+
+Enrich an existing record when new evidence fills previously empty parameters. Do not limit a run to creating missing entries.
+
+## Cover Completion Gate
+
+Every newly created main entry must finish with a verified cover. Existing entries with external-only or dead covers should be migrated when they are in scope.
+
+1. Prefer an official product hero, official announcement image, official conference exhibit image, paper/project visual for a benchmark method, or reputable original reporting when no official usable image exists.
+2. Visually confirm the exact model. Reject wrong-generation images, generic brand photos, group shots where the subject is unclear, unrelated robots, logos alone, watermarks, and synthetic replacements for a real product.
+3. Upload the local image with `chek media +upload-cover`, preserving the original source URL and a readable asset title.
+4. Store the returned `https://img.chekkk.com/...` URL through a governed edit. Keep the original source URL in the media metadata and edit description/evidence.
+5. Approve only when the user authorized approval. Read back the entity and verify the saved cover uses the CHEK media domain.
+6. Poll the media URL until it returns HTTP 200. Object storage may briefly return 404 after a successful upload; do not declare failure or success from the first request alone. If it never becomes available, re-upload and replace the edit.
+
+## Capability Evaluation Admission
+
+Do not put every discovered standard into the public capability leaderboard. Keep three states: candidate registry, governed definition, and formally published leaderboard.
+
+A definition may enter the governed library when it has a public protocol, stable version, task/dataset description, metric and ranking direction, environment/embodiment scope, aggregation rule, required trials, and evidence requirements.
+
+A definition may enter the formal capability leaderboard only when all of these gates pass:
+
+- at least 10 distinct comparable subjects from at least 5 independent organizations under the same protocol partition;
+- every ranked result identifies the exact method/robot configuration, protocol version, environment, metric, and source;
+- trial count or the protocol's required sample basis is present; do not infer counts from percentages;
+- one common primary metric with an explicit ascending/descending direction; no cross-project total score;
+- reproducible official, paper, or independently verifiable evidence, with fixtures and illustrative demos excluded;
+- no mixture of simulation and real-world results, seen and unseen settings, or materially different hardware scopes in one rank partition.
+
+Definitions below this threshold remain visible only in the evaluation library or candidate queue. Paper-specific real-robot protocols may be stored and shown on entity details as evidence without becoming a public cross-subject leaderboard.
+
+## Governed Write And Readback
+
+Prefer edit submissions over direct writes. Use CLI schema/route discovery and `--dry-run` before unfamiliar mutations. For each batch:
+
+1. submit the smallest entity/version/fact/cover diff;
+2. record submission IDs and status;
+3. approve only with explicit authority and after reading before/after snapshots;
+4. read back entity detail and versions;
+5. verify source URLs, cover HTTP status, entry type, identity, and changed fields;
+6. re-run duplicate search and report zero unintended duplicates.
+
+Final reporting must distinguish created main entries, created versions, enriched existing entries, pending evidence, skipped duplicates, covers completed, approvals performed, and failed readbacks.

skills/chek-prod-ai-product-ops/SKILL.md

@@ -57,6 +57,8 @@ Read [references/vehicle-database-maintenance.md](references/vehicle-database-ma
    - Maintain vehicle profile, model/trim identity, hardware/software version lists, raw parameters, intelligent-driving capability facts, and evidence quality.
    - Prefer edit submissions over direct writes unless the CLI command is explicitly a governed admin action.
    - Keep leaderboard support explainable: sales or delivery facts for sales ranking, community rooms for heat ranking, open-source resources plus room activity for open-source ranking, and source-backed vehicle metrics for car rankings.
+   - Treat duplicate resolution and cover completion as release gates for a new main entity. Preserve the original cover source and verify the CHEK-hosted asset after writeback.
+   - Do not publish every discovered evaluation standard as a capability leaderboard. Apply the formal admission gates in the robot maintenance reference; keep sub-threshold standards in the evaluation library or evidence queue.
 
 7. **User material extraction**
    - Accept user-supplied PDFs, screenshots, photos, spreadsheets, release notes, spec sheets, test notes, transcripts, or links.
@@ -115,6 +117,7 @@ Avoid titles like `资料整理`, `榜单支撑`, `开源材料`, `2026-xx-xx 
 - Use official pages, product pages, release notes, app stores, manufacturer media, store pages, GitHub repos, papers, trusted media, and first-hand test evidence.
 - Use Zhihu Developer search as Chinese discussion/evaluation evidence, not as the sole source for release date, version, availability, or sales facts.
 - For cover images, record both the CHEK media URL and the original web source URL.
+- Reject a cover if it shows the wrong model/generation, an unclear group scene, an unrelated robot/vehicle, a logo-only placeholder, or a method-to-hardware mismatch. Poll the CHEK media URL to HTTP 200 before closing the operation.
 - For sales facts, record month, units, confidence, source title, source URL, and whether the source is official, channel estimate, or media/reporting.
 - For open-source resources, record resource type, platform, URL, repo name if applicable, stars/forks if available, version linkage, confidence, and source date.
 

skills/chek-prod-ai-product-ops/references/prod-cli-runbook.md

@@ -86,6 +86,10 @@ Upload to CHEK prod media. If the generated `backend-app media images` command c
 - local downloaded file path until upload verification;
 - CHEK media URL returned by prod.
 
+After upload, poll the returned URL until it serves HTTP 200. Object storage/CDN propagation may briefly return 404. Do not approve or publish a record with a URL that has not passed readback, and do not mistake one early 404 for a permanent failure.
+
+For robot, vehicle, and benchmark-method covers, visually verify the exact identity. A paper/project figure is appropriate for a method; it must not be presented as a physical robot cover. Reject wrong generations, ambiguous group shots, logo-only placeholders, and unrelated product imagery.
+
 Do not use DEV media URLs for prod room covers.
 
 ## Robot And Vehicle Version Sync