메뉴
生成 HTML 仪表盘，让开发者用户可视化核查结果、系统进度、质量指标。在测试轮次完成、生产批次跑完、开发者用户想看可视化报告，或他们明确要求时使用。仪表盘是自包含的 HTML 文件。**仅在确实有"值得可视化的东西"时使用** —— 不要当成默认交付物。日常状态汇报用 KC 的 TUI 即可。HTML 仪表盘是对直接汇报的补充，不是替代。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use Context7 CLI for up-to-date model facts (size, API format, context window) and the guidance below for "what kind of models are good for what part of a doc verification app". Consult whenever you need to pick a model for a tier slot, decide between provider alternatives, or sanity-check an existing tier assignment. Context7 gives you fresh facts; this skill gives you the heuristic that maps those facts onto KC's pipeline. Optional plugin (Context7 install: npm i -g context7).
Determine whether extracted entities comply with verification rules. Use after entity extraction to make the pass/fail judgment for each rule on each document. Covers translating natural language rules into executable logic, choosing between Python calculation and LLM semantic judgment, and producing actionable comments on failures. Also use when designing the judgment step of a workflow or when a rule's judgment logic needs debugging.
Design and calibrate confidence scoring for extraction and verification results. Use when building any workflow that needs to quantify trust in its output, when setting up quality control sampling thresholds, or when calibrating existing confidence scores against actual accuracy. Confidence is the bridge between workflows and quality control — high confidence means less review, low confidence means more review. Also use when the quality control skill reports that confidence scores do not correlate with actual correctness.
Identify, catalog, and handle corner cases that do not fit the mainstream verification workflow. Use AFTER several rounds of skill/workflow iteration have surfaced documents that genuinely don't fit and can't be accommodated by reasonable changes to the standard flow. Covers when something is a corner case vs. a systemic fix needed, how to register it, how to wire detection-and-resolve so the corner case stays out of the hot path until a similar document appears again, and when to promote a corner case to a regular rule.
Build cross-document verification rule-skills and workflows — i.e., rules where the verdict depends on facts that appear in MORE than one document. Use when authoring or distilling a rule that requires comparing entities/values across documents in a case (main contract + appendices, loan application + income certificate + bank statement, etc.). Covers what the rule definition must specify (source-doc → entity → target-doc → entity → consistency level), how the resulting check.py/workflow walks the case, contradiction types to handle, and severity classification. Distinct from `compliance-judgment` (within-doc rules); KC is the builder, not the executor.
Generate HTML dashboards for developer users to visualize verification results, system progress, and quality metrics. Use when a testing round completes, when production batches finish processing, when the developer user wants visual reporting, or when they explicitly ask for it. Dashboards are self-contained HTML files. Use this skill **when there's something visual worth showing** — not as a default deliverable. For routine status updates use KC's TUI. The dashboard is a complement to direct reporting, not a substitute.
| name | dashboard-reporting |
| tier | meta-meta |
| description | 生成 HTML 仪表盘，让开发者用户可视化核查结果、系统进度、质量指标。在测试轮次完成、生产批次跑完、开发者用户想看可视化报告，或他们明确要求时使用。仪表盘是自包含的 HTML 文件。**仅在确实有"值得可视化的东西"时使用** —— 不要当成默认交付物。日常状态汇报用 KC 的 TUI 即可。HTML 仪表盘是对直接汇报的补充，不是替代。 |
仪表盘只是众多渠道之一 —— 而且并不总是最经济的那个 —— 让开发者用户了解情况。KC 在 TUI 里已经能直接汇报状态；HTML 仪表盘存在的理由是值得可视化看的东西：分布、时间线、热力图、并列对比、可钻取的表格。
不要把生成仪表盘当成"满足这条 skill"的打卡项。把它当成开发者用户真要的交付物，或者一张图确实比读 TUI 输出 / JSON 更省时间的场景。
开发者用户要仪表盘时，先做到最低限，能真带来价值再扩展。
一份够用的仪表盘的底线：
够发了。开发者用户能在 3 秒内回答"这一批健不健康，哪些规则出了问题"，最低限就达成。
下面这些只在数据或用户需求确实证明合理时才加：
不要为了显得周到而加一节。一张空的"置信度分布"图（背后根本没有校准过的数据）比没有图更糟。
处理完一批文档后。上面的最低限通常就够了。
按需生成，展示系统跨阶段演化。每条规则的生命周期状态、规则目录表、演化时间线。多在开发者用户想要"现在到哪了"的中段快照时有用。
QC 复核周期结束后。准确率趋势、抽样率走势、待处理标记、成本。在 QC 已经跑了足够多周期、能画出趋势时才有用。
如果当下只有一种对开发者用户真正有帮助，就只做那一种。不要默认三种都生成。
当仪表盘要给会真去复核结果的人看时（开发者用户、终端用户、领域专家），加上反馈控件。当仪表盘只是开发者用户构建过程中的自查工具时，反馈控件通常多余 —— 它假装存在一个用户根本不打算走的流程。
能看到完整结果细节。有用的控件：
只能看到简化结果。有用的控件：
用户报错就是 ground truth，覆盖 agent 判定和 worker LLM 的输出。流转：
{result_id, trace_id, reporter_role, feedback_type, original_result, corrected_value, comment, timestamp}。evolution-loop 作为已确认的失败。自包含的 HTML，内嵌 CSS / JavaScript。
图表用内联 SVG，或把轻量图表库以 <script> 标签内联。
仪表盘读取：
Output/ 的核查结果。logs/ 的演化与测试历史。versions.json（或 git log）的当前系统状态。Output/ 并列存放）。生成脚本应接收输入路径，输出单个 HTML 文件。
什么时候生成：
不要在每个小事件后都自动生成 —— 仪表盘会迅速堆积，用户大部分都不会打开。不确定时，问一下用户（"要不要我生成一份仪表盘？"），而不是不问就生成。
生成的仪表盘存到 Output/dashboards/，文件名带时间戳留作历史。
scripts/generate_dashboard.py 是一个起步脚本。按具体场景改写 —— 当一半 section 都没有内容可放时，删掉那一半。一份能回答用户问题的小仪表盘，胜过一份用户不需要的"全面"仪表盘。
KC 的 TUI 本身就支持在运行时做丰富的状态汇报。TUI 用来：
HTML 仪表盘用来：
不确定时优先用 TUI。一条用户已经在读的简短状态消息，胜过一份还要他去打开的仪表盘。