大易招聘技能

概述

Dayee ATS

当前版本号见本目录 VERSION 文件（勿凭本文档猜测版本）。本包基于 v1.0.1

逐业务重建并逐条实测：11 条业务路径全部端到端验证；测试/生产环境可切换

（config.json）；命中速查表之外的需求走「统一 MCP 调用入口」兜底；

支持在线自更新（见「技能自更新」章节）。

Use this skill as the main fastpath operating manual for known Dayee ATS recruiting reports. It coordinates the all-in-one local runner, Dayee report fetchers, answer-first analysis, and lightweight ECharts display planning. Do not use it for non-Dayee systems or non-recruiting data.

发布回归口令（精确输入 445566）

当用户消息去除首尾空白后恰好等于 445566，不要把它当作普通数字或业务查询，也不要再次确认。执行完整发布回归：

1. 先告知用户：将依次验证全部已发布路径，写操作只做演练，完成后交付一份

Markdown 总报告。运行：

   node <skill_dir>/scripts/regression/run-regression-suite.mjs --mode live

即使命令因某个 runner 用例失败而返回非零，也要从 stdout 的 JSON 中取得run_dir、report 和 agent_worklist，继续处理剩余用例，不要丢失本次运行。

1. 读取本次运行目录的 agent-worklist.md。对每个 pending_agent 用例，把其中

的提示词当作独立用户请求，完整走对应快速路径，不能只记录model_driven、manual_mcp_fallback 或 next_action。同一时间只执行一个重取数或 OAuth 流程。

1. 把每个用例原本要回复给用户的完整 Markdown 写入工作清单指定的

answer.md。有 HTML 时保留绝对路径，然后运行工作清单给出的record-regression-case.mjs 命令；失败也要以 --status fail --error <安全错误>记录，再继续下一条。

1. 全部用例完成后重新读取 run.json。只要还有 pending_agent，就继续执行；

不得把未执行用例标成通过。一键催办等 side_effect: write 用例永远只做dry-run，445566 不构成真实写操作授权。

1. 最终向用户返回总体结论和本次 report.md 的 Markdown 链接。报告已包含

每条提示词、Agent 输出、检查结果及所有 HTML 相对链接；不要在对话中重新粘贴整份报告。

意图速查表（先查这里，再看详情章节）

表中 … = node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs。速查表覆盖不了的说法，再读 references/business-paths.yaml 用语言理解匹配；仍匹配不上则走「统一 MCP 调用入口」的兜底规则。日期类路径先把用户说的时间规整成起止日期；启动前按「长任务预期告知」先说一句预计耗时。

First Step

Match the user's request against the 意图速查表 above (fall back to references/business-paths.yaml for uncovered utterances), then call the runner with the resolved path:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --path <path_id>

For paths that require a date range, normalize it from the user's request and pass it directly:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --path <path_id> 
  --start 2025-01-01 
  --end 2025-03-31

Do not pass --request as the primary invocation. The built-in substring matcher is a debug/fallback tool; it cannot handle natural-language variation. Use --path so routing is done by language understanding, not keyword lookup.

Failure-First Race Mode

For an explicit authorize/login request, run scripts/setup.mjs --env prod before OAuth; use --env test only when the user explicitly names the test environment. An already selected business run keeps its configured environment.

Default Dayee report runs must assume auth, source fetch, cache reuse, and rendering may fail. Do not wait for a heavy report query to fail before entering diagnostics. The top-level runner now performs auth preflight before live fetch:

1. Identify the business path from references/business-paths.yaml and normalize the date range if required.
2. Probe the selected token cache with

<skill_dir>/scripts/auth/inspect-dayee-token-cache.mjs --probe-refresh true.

1. If refresh is rejected, use local browser OAuth when a graphical session is

available; otherwise the runner returns auth.browser_handoff_required.

1. Only after auth is verified, run the report fetch/render fastpath.

For auth.browser_handoff_required, open authorization_url with the same sandbox browser tool, call browser_take_over when login is required, then retry the original path after the success page. If that browser cannot reach localhost, stop: it does not share loopback networking with the Skill worker. For debugging, --auto-reauth false stops after auth inspection. OAuth and live fetch remain single-flight; never start parallel authorization or duplicate report queries.

Safe probes that may be run early or in parallel: business-path match, date normalization, token-cache inspection, refresh-token probe, existing artifact lookup, renderer syntax/static asset checks, and lightweight MCP reachability. Heavy report queries, token refresh writes, browser OAuth, and HTML writes must remain single-flight.

<skill_dir> means this skill's install directory; all scripts resolve their own paths via import.meta, so the working directory does not matter (outputs default to <cwd>/output). Requires Node.js >= 20.11 (uses import.meta.dirname); no npm install is needed — the package is fully self-contained, ECharts asset included.

The runner is non-interactive by default. Auth policy for every data fetch (channel-effect and funnel alike): prefer the skill's own scripts/auth/ token-first browser OAuth flow and its local token cache under ~/.dayee-mcp-auth. DAYEE_MCP_ACCESS_TOKEN is honored only when explicitly set for a one-off run. Do not ask the user for enterprise code, username, or password in chat, and do not use password OAuth as the normal report path. If the cache is missing or cannot refresh, stop quickly or run the fixed browser OAuth helper <skill_dir>/scripts/auth/reauth-dayee-oauth.mjs; never improvise a password flow. Never write credentials, tokens, OAuth codes, callback URLs, or raw secrets into this skill, project files, generated reports, timing records, or chat-visible commands. Use --dry-run true to verify matching and routing without fetching. Use --allow-prompts true only for isolated manual debugging of legacy scripts, not during a normal user-facing report answer.

On success, read only the answer path from the runner JSON and return that answer, plus the HTML path and timing path. Do not re-read raw MCP JSON, raw CSV rows, generated HTML, or embedded report data unless debugging a concrete failure. If the runner returns status: needs_clarification, ask only for the missing slot it names. If it returns status: unsupported_path, use the manual MCP fallback below while preserving the same answer-first and compact-artifact discipline.

Critical Entry Rule

Always identify the business path and call the runner with --path <path_id> before touching MCP, cached artifacts, or display code. ECharts/Evidence are only renderers. They are never the business path and never decide which ATS report to call.

Path matching is your responsibility, not the script's. Read references/business-paths.yaml, match the user's request to the right path_id using language understanding, then pass it to the runner. If the request is ambiguous between two paths, pick the closest one and proceed; ask only if a required slot (date range for date-dependent paths) is genuinely missing.

match-business-path.mjs is a debug tool only — use it to inspect the substring matcher's output or verify catalog entries, not as the routing step:

node <skill_dir>/scripts/match-business-path.mjs 
  "<user request>"

Keep user-facing progress updates business-focused. Say what report subject, date range, and source you are checking; do not mention unrelated report paths, special-case fastpaths, or internal routing unless they affect accuracy, permissions, auth, timing, or a blocker.

Hard Rules

• Never store credentials, tokens, OAuth codes, callback URLs, or raw secrets in

project files, docs, screenshots, or timing records.

• Never start by calling MCP tools directly. First run

scripts/run-dayee-fast-report-fastpath.mjs, or, for debugging, read references/business-paths.json / run scripts/match-business-path.mjs.

• Never diagnose auth from a generic exited 1 alone. Read the structured

failure class and safe tail log. Expected classes include auth.cache_missing, auth.refresh_token_missing_local, auth.refresh_token_rejected_by_server, auth.access_token_rejected, mcp.network_or_timeout, report.query_failed, and render.failed.

• Never let a newer but wrong ~/.mcp-auth cache silently override the

skill's local token cache at ~/.dayee-mcp-auth. Fetchers must print the selected cache path and safe token-field presence (has_access_token, has_refresh_token, has_client_id), never token values.

• Never use shell history, old agent session logs, generated reports, or broad

repository searches to discover routine report fields after a business path has matched. Use the matched path's field_mapping_id, the corresponding references/field-mappings.yaml entry, or the live MCP report field resource such as report://report_post/fields. Historical investigation is allowed only when the user explicitly asks to debug a past run or when the registry and live field resource are both missing or contradictory; record that as a blocked fastpath, not as the default path.

• Never describe this skill as "pointing to Evidence/ECharts"; it points to a

Dayee ATS recruiting business-path registry. Display tools are downstream adapters.

• Enforce permissions at fetch time. Do not fetch unauthorized data and remove

it later.

• Show only cleaned, permission-filtered data previews to users. Once the

cleaned dataset is ready, emit an answer-first summary first, then continue with a lightweight visualization by default for analytical report requests.

• ECharts/static HTML is a required deliverable for Dayee ATS analytical report

requests, including funnel, channel-effect, resume-source, volume, offer, interview, and hire-conversion analysis. A report turn is not complete until it returns an ECharts preview path/URL or explicitly states that the user asked for text only or that rendering was blocked after a concrete attempt.

• Use lightweight verification by default after report generation: confirm the

script syntax/checks, generation status, core tests when available, and key visible wording with scoped text checks. Do not run a full browser QA pass (desktop, mobile, DOM extraction, console logs, screenshots) unless the user explicitly asks for it, the page appears broken, charts may be blank, console errors are suspected, or the task specifically changed layout/responsiveness. Business readability and visual acceptance are normally user-reviewed in the browser; if the user reports an issue, fix that specific issue and verify it narrowly.

• Do not block the first user-facing answer on Evidence build, ECharts page

rendering, browser QA, or delivery probes. For analytical requests, keep working after the summary and hand off a lightweight ECharts/static HTML preview when it is ready. Use Evidence build only when the user explicitly asks for a formal/static Evidence report.

• Every full fastpath run should write an ExecutionTimingRecord. Append a

FastPathMemoryRecord only after the reusable path is verified; failed or unchecked runs must not update fastpath memory.

• If auth or source-system fetch fails, stop live fetching quickly and report

the source-system error without exposing secrets.

• Never dump large raw MCP JSON, full HTML, or embedded window.__REPORT_DATA__

into the model context for routine analysis. Read compact artifacts such as answer_summary.json, metrics.json, or a short answer.md instead.

• Never run unbounded rg / find over generated outputs, node_modules,

agent session directories, or project history during a normal report answer. If search is unavoidable, scope it to the specific registry/reference file or current report artifact and exclude generated directories.

• Treat repeated OAuth inside report-fetch scripts as technical debt once the

user is already logged in to MCP. Prefer a packaged runner that uses the current MCP token/session or non-interactive env auth, fails fast when auth is missing, and records OAuth time separately so it does not hide source-system performance.

MCP 认证失败处理（强制，不得向用户询问凭证）

遇到 Token expired / 401 / auth failed 时：

1. 运行 node <skill_dir>/scripts/auth/inspect-dayee-token-cache.mjs --probe-refresh true
2. auth.refresh_ok 直接重试；其他分类交给顶层 runner 的单次 OAuth 恢复。
3. auth.browser_handoff_required：用同一沙箱浏览器打开返回的授权页，需要登录时调用 browser_take_over；成功页出现后重试原路径。
4. 浏览器无法访问 localhost 或回调超时就停止，报告“平台浏览器与 Skill 回环网络不通”；没有服务端证据时，不得向账号或网络故障归因。

❌ 禁止在任何步骤前向用户询问凭证。

统一 MCP 调用入口（mcp-call）

所有对大易 MCP 的调用一律经 skill 内部客户端完成，不依赖、也不要求在 Agent 侧注册大易 MCP 服务器。业务路径各自的取数脚本内置了调用逻辑；业务路径之外的临时需求使用统一入口：

• 查看服务端当前全部工具：node <skill_dir>/scripts/mcp-call.mjs --list --brief
• 调用任意工具：node <skill_dir>/scripts/mcp-call.mjs --call <tool> --args '<JSON参数>'

兜底规则：用户需求匹配不上任何已迁入的业务路径时，先 --list 查看服务端是否有能覆盖该需求的工具，再用 --call 调用。职位 create/update 必须走run-dayee-job-action-link.mjs，拿到链接只表示交接，executed=false；其他写操作（上传简历、添加备注、联系候选人、创建画像等）必须先复述操作并获得确认。

技能自更新（用户说「更新技能 / 升级技能 / 有没有新版本」时）

本技能自带在线更新能力，不需要 GitHub 仓库或人工传包。按以下步骤执行：

1. 查当前版本：读本目录 VERSION 文件。
2. 查有无新版：node <skill_dir>/scripts/update.mjs --check

（更新源地址已内置在 config.json 的 updateManifestUrl）。

1. 返回 update_available → 把新版本号与更新说明告诉用户，用户确认后执行：

node <skill_dir>/scripts/update.mjs（自动下载、SHA-256 校验、整目录备份、原地升级，用户的 config.json 保留；运行中会输出【更新进度】）。

1. 返回 up_to_date → 告知用户已是最新版本。

返回 not_configured → 告知用户该安装未配置更新源，需联系供应商获取清单地址填入 config.json 的 updateManifestUrl。

1. 升级完成后提醒用户：新会话生效更稳妥；如需回滚，用备份目录整体替换回来。

环境冲突自检（自动）

runner 每次启动会自动检测环境冲突（已被本包替代的旧技能、本包的重复安装、Agent 侧多余的大易 MCP 注册），环境干净时零输出；发现冲突时 stderr 会出现「【环境冲突】…」行。看到冲突行必须把内容与处理建议转告用户，等用户处理或明确表示忽略后再继续业务。也可手动运行完整报告：node <skill_dir>/scripts/preflight-conflicts.mjs

报告展示规范（所有路径通用）

统一视觉规范：所有 HTML 报告样式遵循用友 HR SaaS 浅色规范，单一实现源为scripts/lib/hrsaas-style.mjs，规则说明见 references/report-style-guide.md。脚本已内置；模型需要手写 HTML 片段时按该文件取色取字号，禁止自造样式、禁止阴影/渐变/侧边彩条。

生成 HTML 报告后，必须立刻向用户展示，按以下顺序，成功一种即止：

1. 平台工具列表里存在 open_local_file（YonClaw 侧边预览，传 HTML 绝对路径）

或 present_files（Codex 桌面端，传 files=["<HTML绝对路径>"]）任一 →必须立即调用它，侧边栏会自动打开预览，不要只贴路径。两个工具名对应不同平台版本，逐一在工具列表里找，找到哪个用哪个；

1. 没有此类工具或展示失败 → 在对话里输出指向报告文件的 Markdown 链接：

[查看完整报告](HTML绝对路径)。不要主动替用户拉起浏览器——那超出用户预期地跳出了当前平台；scripts/open-report.mjs 仅在用户明确说「帮我打开」时使用。

跳转真实系统的操作一律放在对话里，不放在报告里：内嵌预览的沙盒容器通常禁止跳转外部网站，报告里的操作按钮点不动；对话里的 Markdown 链接则总能在系统浏览器打开。例如深入分析完成后，在对话末尾输出固定话术：「如果您对此候选人满意，也可以直接对Ta[安排面试](操作链接)；」

长任务预期告知（所有路径通用）

启动任何取数命令之前，先用一句话告诉用户将要做什么、大约要等多久，再执行。各路径的典型耗时（已登录状态下实测）：

运行中脚本会向终端实时输出阶段进度（如「【漏斗进度】4/6 正在做候选人流向桑基的31 组状态组合计数…」）；在能看到命令输出的环境里用户可自行观察，不必重复播报。命令结束后按各路径的 next_action 返回结果即可。

授权状态查询与授权（用户问「检查大易招聘系统授权 / 授权状态」或说「授权 / 重新授权招聘系统」时）

这不是业务报表路径，不走 runner，也不需要日期或任何槽位。完整执行细节（六项报告字段、追问话术、验证清单、旧授权处理的保证级别措辞）在references/auth-status-and-reauth.md，执行前先读它。骨架：

• 查状态（「检查大易招聘系统授权」「授权状态」等）：运行

node <skill_dir>/scripts/auth/check-dayee-auth-status.mjs（只读，不弹授权页），按 reference 报告六项：是否授权 / 环境 / 是否生效 / 企业代码 / 账号 /有效期；然后必须追问——生效时问「是否需要重新授权？」，不可用时问「是否进行授权？」，用户确认后再发起。

• 直接要求授权（「授权招聘系统」「重新授权」，含首次会话）：不必先查

状态，直接发起授权调起授权页。

• 发起授权：默认生产环境，只有用户明确说测试环境才

setup.mjs --env test；然后 scripts/auth/reauth-dayee-oauth.mjs（无图形界面时按「Failure-First Race Mode」browser handoff）。

• 验证换新（重新授权必做）：授权前后各跑一次 check 脚本，核对

effective: true、authorized_at_ms 晚于发起时间、账号符合预期，三项齐备才宣布成功；不满足则如实报告，不得凭退出码 0 宣布完成。旧授权的处理按 reference 的保证级别措辞转述，不许诺「旧授权立即失效」。

测试/生产环境切换（config.json）

大易 MCP 分测试与生产两套环境，本 skill 的所有取数、登录、工具清单获取都从同一处配置读取地址，改一处即全局生效：

• 测试环境：https://claw-dayee.wintalent.cn/mcp
• 生产环境：https://claw.wintalent.cn/mcp

配置文件为 skill 根目录 config.json（标准 mcpServers 模版格式），把mcpServers.ats-recruit-mcp.url 改成目标环境地址即可。临时切换可用环境变量 DAYEE_MCP_BASE_URL 覆盖，仅对当次运行生效。config.json 缺失时默认生产环境。用户直接请求授权但未说明环境时，默认使用生产环境发起授权；只有用户明确说要在测试环境授权时，才选择测试环境。

每个环境的登录凭据缓存相互独立（缓存文件名含地址哈希），互不干扰；切到新环境后第一次使用需要完成一次浏览器授权，之后照常静默续期。

Channel-Effect Default Fastpath

For recruiting.channel_effect_analysis.v1, use the local answer fastpath as the default execution path after business-path matching. This is a fixed 经营诊断 recipe, not an open-ended agent analysis: one deterministic route fetches report_channel_post, calculates the channel portfolio, sufficient-sample hire conversion, channel × post-type fit, monthly channel movement, per-channel profiles, data caveats, and evidence-backed follow-up research paths, then renders the approved light SaaS HTML. Recruitment-type breakdowns are no longer shown in the default channel report because they make the page harder to read; only pass --recruittype-* for explicit debugging or a separately requested analysis. Do not first probe the agent-side MCP tool surface, because that surface has repeatedly shown invalid_client while the local wrapper can fetch the report successfully; all MCP calls go through the skill's own client.

Default channel-effect order:

1. Run scripts/run-dayee-fast-report-fastpath.mjs --request "<user request>".
2. The runner performs failure-first auth preflight. If the refresh token is

rejected by the server, it opens browser OAuth via reauth-dayee-oauth.mjs, writes the token cache into ~/.dayee-mcp-auth, verifies it, then continues.

1. If the matched path is recruiting.channel_effect_analysis.v1, the runner

normalizes the requested date range and calls scripts/run-dayee-channel-answer-fastpath.mjs.

1. The primary fetch groups by channelType,channelName and uses the fixed 20-field

column set: B1,B2,B11,B92,B93,B94,B98,B100,B105,B109,B17,B22,B23,B24,B26,B35,B36,B47,B49,B574.

1. Live runs also fetch a second fixed aggregation for the post-type fit:

groupColumn=postType,channelType,channelName, with B1,B2,B11,B22,B23,B26,B36,B47,B49,B574. Offline validation should pass --posttype-csv (or legacy --adaptation-csv); use --renderer legacy only for old single-CSV debug output. For date ranges spanning 2 to 6 calendar months, the channel answer fastpath also fetches one channel-level monthly CSV per month and passes those files to the strategy renderer for the trend section. Longer ranges skip automatic monthly expansion by default to avoid excessive source-system requests. Parse live report rows by titleList.column, not fixed array offsets. postType returns hierarchy columns plus current position category; use the current postType column for the matrix. Interview fields such as B92, B98, B105, and B109 may return as -1...-14 interview-round columns; the channel fastpath uses round 1 for candidate-level stage leakage.

1. Read only compact artifacts: summary JSON, answer Markdown, timing JSON, and

metrics JSON.

1. Default HTML structure is fixed: 渠道效果概览 → left-side

"渠道入职转化图（简历数充足）" and right-side "渠道来源结构图" dual bars → cost-data note → "按职位类别看渠道表现" post-type tables only → "渠道变化趋势" with separate resume-volume and hire-conversion trend tables plus a focused recent-change line chart when month CSVs are present → per-channel detailed appendix → final follow-up research list. Do not restore the removed top KPI cards, first-screen detail tables, same-post-type waterfall/diagnostic charts, or recruitment-type analysis as the default channel report. The approved visual style is the local yonyou-hrsaas-ui-spec skill. Any chart, KPI card, table, candidate card, or report component generated by this skill must load/follow that spec: white/light background, #0055FF primary, series palette #0055FF/#07E09D/#57709E/#FFBA00/#7666FA/#49CDFD/#009B99/#FF90C8/#FF9202/#FF573E, PingFang text, #E9ECF0 1px borders/gridlines, no gradients/shadows, 8px cards, 652×400 chart canvas where practical, top-centered rectangular legends, 60% square bars, and spec table/data-card styling. Do not invent a parallel "light SaaS" palette.

1. Return the answer as soon as the strategy summary artifact exists. For normal

iterative edits, prefer static text/JSON checks over browser QA and let the user perform browser acceptance unless a concrete browser failure is in scope.

When the user asks to deep-dive one channel from an existing channel report, route to recruiting.channel_followup_deep_dive.v1. The runner reuses the latest channel metrics before the auth gate; it must not call get_job_list, get_report_details, or retry by changing report parameters. Return its answer directly. For needs_source_report, needs_clarification, channel_not_found, or ambiguous_channel, follow next_action and stop instead of changing tools.

Only use an agent-side MCP tool-surface preflight for channel-effect requests when the user explicitly asks to test MCP login/tool status, debug OAuth, compare MCP clients, or validate server compatibility. In those cases, keep the result separate from the business report path.

招聘进展 Pipeline 概览 Fastpath

For recruiting.pipeline_overview.v1（招聘进展、Pipeline 概览、岗位完成率、月底完成率、招聘进度）, no date range needed:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --path recruiting.pipeline_overview.v1

The runner calls scripts/run-dayee-pipeline-overview-fastpath.mjs, which:

1. Fetches per-post pipeline data via get_report_post

(groupColumn="A2", columnCode="A2,A17,REAL_211,REAL_201,A148,REAL_197,REAL_7" ——职位名称/招聘人数 HC/已入职/待入职/进入 offer/接受 offer/面试中), excluding未对应职位 and 合计 rows. 统计范围与待办看板、催办同口径：只统计「我负责的 + 招聘中」岗位。

1. Computes 完成率 = 已入职/HC；预计月底入职 = 已入职 + 待入职×90% + Offer×75% +

面试中×20%，逐岗封顶到 HC，所有人数四舍五入取整。

1. Renders the fixed three-part HTML panel (652px): KPI cards（总 HC/已入职/

Offer 中/面试中）+ 岗位明细表（完成率 0% 标红，合计行浅灰）+ 完成率进度条，底部固定文案「预计月底完成率基于历史同类职位测算转化率：待入职→入职 90%，Offer→入职 75%，面试→入职 20%。」不得改动措辞与样式。

1. Writes HTML + _data.json + _answer.md + _timing.json; returns compact

JSON. Read the answer file and return it with the HTML path; do not inspect raw MCP JSON.

Recruitment Funnel Default Fastpath

For recruiting.funnel.v1（招聘漏斗/流程漏斗分析）, the default is the fixed leader-report headcount fastpath. One command does everything; do not improvise MCP calls:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --request "2024下半年校招漏斗分析"

The router matches recruiting.funnel.v1, normalizes the date range, infers 招聘类型 from wording (校招/社招/实习…; unspecified defaults to 校园招聘 and the answer says so), and routes to scripts/run-dayee-funnel-answer-fastpath.mjs, which drives scripts/funnel/run-funnel-leader-report.mjs:

1. Local token cache at ~/.dayee-mcp-auth first, with OAuth refresh when the cache contains

a refresh token; DAYEE_MCP_ACCESS_TOKEN is only an explicit one-off override.

1. Fetch report_details by the same headcount denominator for every stage:

投递、测评、面试、Offer、入职. The implementation uses dimension filters plus hisApplyStatus count queries; do not use independent report_post action counters to subtract or divide stages into a funnel.

1. Fetch the approved leader dimensions: 职位类别、人头流向桑基、部门、招聘负责人

data-quality distribution, and 同期对比. Departments with no Offer and no hire must not appear in the Offer/hire analysis.

1. Build the approved leader HTML: KPI cards → draggable decision Sankey with

测评 restored and edgeLabel hidden → 职位类别 funnel table with in-cellconversion bars normalized to the column maximum → 部门漏斗 → 同期对比 (no 环比panel) → 分招聘负责人.

1. The report keeps user-accepted safeguards: Sankey nodes have explicit depths,

layoutIterations:0, draggable:true, and hidden edge labels to avoid text overlap; +/- percentage deltas use styled tags; the separate old conversion chart below the 职位类别 table is removed.

Output paths: --out-dir (default <cwd>/output), per-run files <period><recruitType>漏斗分析-领导版.html and funnel-headcount_<label>.json. Read only the runner JSON answer, html, and timing; do not re-read raw MCP JSON or the generated HTML.

唯一正确的取数方法就是上面第 2–3 步的「状态码计数 + 桑基状态码组合容斥」。旧的 report_post 单次聚合漏斗(靠各环节计数器相减/相除凑漏斗)已彻底废弃——它无法还原跳步路径、会让桑基失真,不要再用,也不要参照它的字段口径。

候选人深入分析 Fastpath

For recruiting.resume_deep_analysis.v1（深入分析 {姓名} / 深度分析 / 详细分析）。取数与版式全部由脚本固定，模型只负责评分与评语。下游动作「安排面试」的操作链接由脚本自动获取并渲染为报告底部按钮（点击后在 ATS 页面完成实际安排）。

Step 1：数据采集（脚本）

优先从当前对话 context 中查找候选人的 resumeCode 和 jobId（上一轮若是招聘待办看板或搜索结果，候选人信息可能已在 context 中）：

# 已有编码（推荐；有 jobId 一并传入，报告会结合岗位 JD 评分）
node <skill_dir>/scripts/run-dayee-deep-analysis-step1.mjs 
  --resume-code <resumeCode> [--job-id <jobId>] --original-prompt "<用户原话>"

# 只有姓名（脚本自动定位；重名会返回列表，向用户确认后用 --resume-code 重调）
node <skill_dir>/scripts/run-dayee-deep-analysis-step1.mjs 
  --name "<姓名>" --original-prompt "<用户原话>"

脚本并行拉取完整简历、HR 标签与操作记录、AI 历史评估、岗位 JD（有 jobId 时）、安排面试链接，写入一个数据包文件并返回其路径。

Step 2：评分与评语（模型）

读取数据包文件，产出评估 JSON 文件，格式如下：

{
  "score": 7.5,
  "position": "应聘岗位名（无则省略）",
  "recommendation": "推荐理由一句话",
  "info": { "education": "最高学历", "workYears": "N年", "age": "N岁", "source": "简历来源" },
  "tags": [ { "text": "标签文本", "type": "company|skill|arch|edu|risk" } ],
  "dimensions": { "基本信息": 4, "行业相关性": 3, "技能相关性": 2, "个性特征": 3, "价值观": 3, "稳定性": 4 },
  "strengths": ["核心优势 3-5 条"],
  "concerns": ["待考察点 2-3 条"],
  "verdict": "整体评语（是否推荐及理由）"
}

评分与措辞规范（沿用已验收标准）：

• 6 个维度各 0-5 星：基本信息 / 行业相关性 / 技能相关性 / 个性特征 / 价值观 / 稳定性

（有 jobId 时结合 JD 评分，无 jobId 时基于简历独立评估）

• 待考察点用柔和语气，不以"缺少/缺失/不满足"定性
• 标签最多 10 个，类型对应配色：公司/大厂背景→company、技术技能→skill、

架构/平台→arch、学历/学校→edu、风险/待考察→risk

Step 3：渲染报告（脚本，版式固定不可改）

node <skill_dir>/scripts/run-dayee-deep-analysis-step2.mjs 
  --bundle <数据包路径> --assessment <评估JSON路径>

版式由脚本按已验收规格固定输出（顶部简历卡片含分数段配色与星级、评分概要表、综合评估、HR 标签、招聘操作记录时间线、底部「📅 安排面试」按钮），生成{姓名}_深入分析报告.html。

Step 4：展示结果

按「报告展示规范」展示生成的 HTML 文件，对话中简短确认：「已生成 {姓名} 的深入分析报告。」并在对话末尾用 step2 输出的 action_url 输出固定话术：「如果您对此候选人满意，也可以直接对Ta[安排面试](action_url)；」

招聘待办与简历筛选 Fastpath

For recruiting.todo_resume_screen_lite.v1（招聘待办、今日待办、筛选简历）, route through the packaged fastpath — no date range needed, the script uses today's date internally:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --path recruiting.todo_resume_screen_lite.v1

The runner calls scripts/run-dayee-todo-resume-screen-fastpath.mjs, which:

1. Phase 1 (parallel): fetches apply-status counts and the P1 data from the

standard 候选人明细表 interface（get_report_details，每个账套默认可用，不依赖任何私有保存的报表模板）: groupColumn="name", columnCode="postName,workYears,C268,C269,smallApplyStatus,interviewerName", operType="C268" + conDate=<14-days-ago>,<today>.

1. P1 filter: keeps rows where 应聘状态-明细（报表实际列名 smallApplyStatus）

contains "待评价" (substring, not exact match); calculates overdue days from the latest interview round (C268-N/C269-N columns); keeps ≥ 2 days.统计范围为最近两周安排的面试，两周之前的面试不计入统计。同一报表还产出【已有面试结果-待流转】：最新面试轮次 C274-N（面试结果）为明确结论（通过/不通过；「待定」不算），且应聘状态「-」前的大环节仍是面试类（初试/复试/终试/面试）——已流转的「企业人才库-面试」等不算。不通过在前、按等待天数降序，提示用户在 ATS 完成流转。

1. Phase 3: fetches my active jobs (get_job_list, status="招聘中",

isMyCharge="我负责的"), then calls search_resumes(applyStatus="待处理", jobIdStr=<jobId>) per job（本租户无「收件箱」环节，待筛选简历对应「待处理」）;fetches per-job match scores via talent_discovery（matchDegree 即简历在所投职位下的匹配分数）; filters score > 7, groups by job, sorts descending,top 8 per group（评分全部缺失时按工作年限降序兜底）; 简历详情链接从search_resumes 返回的姓名字段中拆取（⚠️ 不要调用 resumes_jump_link 取链接，该接口是「把候选人跳转到指定环节」的写操作）.

1. Renders the exact HTML template from the original SKILL.md (CSS/colors/layout

unchanged): P0 (red border) + 已有面试结果-待流转（P1 上方，通过/不通过彩色标签）+ P1 (orange border) + 🏆 candidate sections (blue border), with P0 backlog rows in count-descending order and P1 overdue rows in days-descending order.

1. Writes todo_resume_screen_{date}.html, _data.json, _answer.md,

_timing.json to the output directory.

1. Returns compact JSON; read answer for the summary, then show the HTML

dashboard to the user per「报告展示规范」.

On-demand deep analysis (not auto-triggered): when the user explicitly requests"深入分析 {姓名}" / "分析一下 {姓名}"，按本文档「候选人深入分析 Fastpath」章节执行（本包已内置该流程，无需加载任何外部技能）。

一键催办面试官 Fastpath

For recruiting.urge_interview_feedback.v1（一键催办面试官、催促面试官提交反馈）:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --path recruiting.urge_interview_feedback.v1

The runner calls scripts/run-dayee-urge-interviewers-fastpath.mjs, which:

1. Re-fetches the latest P1 report data (same params as the main dashboard)

to capture any changes since the dashboard was shown.

1. Filters 待评价 + overdue ≥ 2 days; 明细表不输出简历编码，按「姓名+应聘职位」

通过 search_resumes 反查每人的 resumeCode。统计范围为最近两周安排的面试，两周之前的面试不计入统计。

1. Calls urge_biz(type="interview_eval", resumeCodeStr="<all codes comma-joined>")

once to batch-urge all overdue candidates.

1. Returns JSON with message (ready-to-display result text) and overdue list.

Pass result.message verbatim to the user.

If urge_count === 0, all evaluations are on time — return the "✅ 无需催办" message.

用人经理需求变更处理 Fastpath

For recruiting.requirement_change_orchestration.v1（用人经理修改岗位要求、需求变更后重新评估候选人、面试和猎头沟通），先读取并严格执行 references/requirement-change-orchestration.md。

固定边界：step1 只读取数（含自动按新要求回搜人才库补充候选人），模型只生成 assessment（含从 bundle.talent_pool 挑选的 Top 3~5 人才库推荐），step2 只生成报告和待确认动作；修改职位、调整流程、安排面试、联系候选人、催办、外部发送或把人才库候选人加入流程，都必须在报告展示后获得用户明确确认。MCP 没有对应写工具时，才按 reference 的 Playwright 兜底规则操作 trunk。

本地工作台联动（免确认、随报告自动执行）：step2 成功后立即运行node <skill_dir>/scripts/sync-local-workspace.mjs --mode add --actions <actions路径> --summary "<一句话工作记录>"，把待确认动作写成用户本地待办（状态「待完成」），并在当天日报与本周周报的「工作记录」追加处理摘要。工作台目录由 config.json 的 localWorkspace 决定（缺省 ~/Desktop，即用户桌面），只写该目录内的 待办.txt、日报-<日期>.txt、周报-<ISO周>.txt 三个文件。用户确认执行某动作成功后，运行 --mode complete --seq <报告中的动作序号> 把对应待办勾成已完成并补「已执行」记录。

回复格式：分析完成后的对话回复必须按 reference 的「对话回复模板」输出（step2 的 next_action 内含同款模板）——变更要点、影响全景（五类逐项）、已为您准备好、已自动记入您的工作台、待确认动作编号清单，禁止自创结构或只贴报告路径。

候选人智能搜索 Fastpath

For recruiting.candidate_smart_search.v1（搜简历、推荐候选人、帮我找、有 XX 经验的、和 XX 类似的、对比这几个、比较一下、找相似、以人找人）。

统一替代 ai-resume-match 与 smart-recruit（人才智搜）两个旧技能。

调用时必须把用户原话通过 --request 传给 runner（搜索词就是用户原话，不传会直接报错）：

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --path recruiting.candidate_smart_search.v1 
  --request "<用户原话>"

搜索意图由脚本端到端执行；对比/找相似意图 runner 会返回 status: model_driven 并指明子路径，按下方对应小节执行。

路由（先判断意图和上下文，再决定子路径）

用户请求
├── 含"对比/比较" + 上下文已有候选人      → 子路径 C：对比
├── 含"相似/类似" + 指定参照候选人        → 子路径 S：找相似
├── 含搜索意图（推荐/找/搜/筛选）         → 子路径 A：搜索
└── 含"对比/比较" 但上下文无候选人        → 先走子路径 A，再走子路径 C

子路径 A：搜索候选人

Step 1 — 构建搜索参数：

必填：embeddingText（用户原话）、embeddingText2（语义扩展一句话）、embeddingTextArray（核心关键词数组）、embeddingWeightArray（权重数组，总和 1.0）

选填（按用户描述）：postNameArray（含同义词扩展）、workYearRange（如"3年以上"→"3-100"）、workPlaceArray、educationArray、ageRange、schoolLabelArray、corpLabelArray、skillArray、industryArray

postNameArray 同义词扩展规则：

• "产品经理" → ["产品经理","高级产品经理","产品总监","产品负责人"]
• "后端开发" → ["后端开发工程师","Java开发","Python开发","Go开发","服务端开发"]
• "算法工程师" → ["算法工程师","AI算法工程师","机器学习工程师","深度学习工程师"]
• "前端开发" → ["前端开发工程师","Web前端","React开发","Vue开发"]
• "项目经理" → ["项目经理","项目总监","IT项目经理","技术项目经理"]

Step 2 — 调用接口：

唯一接口：ai_search_resume_recommend(embeddingText, embeddingText2, embeddingTextArray, embeddingWeightArray, [选填参数...])

接口特性（已实测）：resumeNum 参数无效（传 10/20/30 不影响结果，禁止传 resumeNum=50，会报错）；返回条数由服务端按语义匹配决定，不是固定值——不要假设固定 10 条，有几条用几条；返回 { _raw: "..." }。

Step 3 — 解析 _raw：

从 _raw 文本中提取每个候选人的 简历名称、简历id、简历信息。ATS 详情链接从 _raw 内嵌模板构建（将 {简历id} 替换为实际 resumeId）。

Step 4 — 清洗（按顺序，命中即剔除）：

• R0：name 长度 > 8 汉字 AND 含"汇总/报告/推荐/沟通情况" → 剔除
• R1：age == 0 OR age >= 60 → 剔除
• R2：name 含 测试/test/勿动/画像/预览/Copy（不区分大小写）→ 剔除
• R3：name 匹配 ^.{1,2}d{4,}$ → 剔除
• R4：name 精确匹配具名测试账号黑名单（陈味/陈倒/陈拖/陈递/陈刃/陈恨/陈更/陈添/陈急/邹测试/邹彤彤/邹墨菲/邹内推/李测试/李横一/李卡三/李云六/李海264/韩天一/韩立92/钱宝儿/罗小黑/杨诗诗/王嘻嘻/测繁体/你剋一/尼克二/秤路一）→ 剔除
• R5：position 含 测试职位/HC新建/副本/验证/勿动 → 剔除
• R5b：position 精确匹配（手动创建0918/hui软件测试/测试审核123/画像验证0001/画像验证0002/Annie职位推送一下/Annie测试工作年限和薪资/20251110HC新建/HC新建（无新增职位权限）/西安test创建/陈辉测试职位/金桔子职位【报表】/秋儿群翁群二/侧的四四/xms111/123测试）→ 剔除
• 去重：按"姓名+工作年限+最近公司"组合，保留第一条

清洗后 0 条 → 输出"未找到符合条件的候选人，建议调整搜索条件后重试。"；≥ 1 条继续。

Step 5 — 评分（五维，每维 0-2 分，总分 0-10）：

星级：9-10→⭐⭐⭐⭐⭐，7-8→⭐⭐⭐⭐☆，5-6→⭐⭐⭐☆☆，3-4→⭐⭐☆☆☆，0-2→⭐☆☆☆☆

排序：星级高→低；同星级按可到岗（离职优先）→ 年限（长优先）

Step 6 — 展示（Markdown，Top 10，格式写死不可自创）：

开头一行交代数量：搜到 N 条，清洗后 M 位。按五维评分排序：

每位候选人独立一段，段与段之间用 --- 分隔：

### 序号. [姓名](ATS详情链接) ⭐评级
`→ 职位方向`

**最近公司 · X年经验 · X岁 · 学历 · 城市**　状态标签

1. **强匹配**：匹配点1（量化数据优先，能引用简历自述原文更好）
2. 匹配点2（教育/工作/项目经历优势）
3. 匹配点3（期望薪资/到岗状态；风险或待核实点中性表述；值得推进的加粗"建议优先联系"）

评分偏弱的尾部候选人（⭐⭐及以下）不逐人分段，合并为一张表：

### N–M（偏弱，供参考）
| 候选人 | 经验 | 问题 |

（候选人列保留 ATS 链接和星级）

结尾一段加粗结论：一两句总结整体供给情况，给出下一步建议（如扩大地域、放宽条件再搜）。

禁止：把多位候选人压成一行列表；用星级当分组小标题（如"⭐⭐⭐⭐⭐ 强烈推荐"下挂一串人）；省略每人的三条匹配点。

多职位交叉搜索展示 Top 5。生成 HTML 时遵循 hrsaas-ui-spec 规范，标签用彩色线框（background:transparent），不硬编码色值。

子路径 S：找相似候选人（以人找人）

触发条件：用户说"和 XX 类似/相似"/"以这个人为参照"/"以人找人"。

本质：以参照人为样板，把其简历读成搜索词，复用子路径 A 搜一批相似的人。是子路径 A 的特殊入口——区别只是搜索词由参照人简历自动生成，而非用户口述。

Step 1 — 定位参照人（复用子路径 C 的定位逻辑）：

• 上文已提到该参照人 → 直接取其简历信息（上一轮 _raw 已含全文，零接口调用）
• 上文未提到 → 告知"之前没有提到过[姓名]，是否要从人才库里搜索这位候选人？"，用户确认后经统一入口定位：

node <skill_dir>/scripts/mcp-call.mjs --call search_resumes --args '{"originalPrompt":"<用户原话>","name":"<姓名>","pageSize":10,"page":1}'（重名则列出岗位/来源让用户选），再node <skill_dir>/scripts/mcp-call.mjs --call resumes_detail --args '{"originalPrompt":"<用户原话>","resumeCodeStr":"<resumeCode>"}'取简历全文

Step 2 — 提取参照人特征： 技术栈/核心技能、行业、公司背景、学历、项目类型、年限、岗位方向。

Step 3 — 构建子路径 A 搜索参数： 以参照人特征组织 embeddingText（"找和[姓名]类似的人：[特征描述]"）+ embeddingText2/embeddingTextArray/权重；能从特征推出的结构化筛选（postNameArray/workYearRange 等）一并带上。

• ⚠️ 禁止传 resumeId / resumeCode：已实测——带 resumeId 会把结果锁成参照人本人一个（接口将其当作"按 ID 精确查单份简历"，而非相似度增强），带 resumeCode 接口不识别返回空。以人找人只走纯搜索词。

Step 4 — 执行： 复用子路径 A 的 Step 2~6（调接口 → 解析 _raw → 清洗 → 五维评分 → 展示）。展示格式与 Step 6 完全同款，仅两处不同：开头一行改为"20条原始，清洗后N位（已排除XX本人）。按与XX的相似度评分："；每人第 1 条匹配点写"和参照人哪里像"（最像的加粗"最像XX"）。结尾小结点名最值得联系的 1-2 位。

Step 5 — 排除参照人本人： 展示时按 resumeId/姓名剔除参照人自己。

子路径 C：对比候选人

触发条件：用户说"对比/比较"+ 指定 2 个以上候选人。

Step 1 — 定位候选人：

• 命中（上下文有）→ 取其 简历信息 和已有五维评分
• 部分命中 → 命中的照常处理；未命中的告知："之前没有提到过[姓名]，是否要从人才库里搜索这位候选人？" 等用户回复后合并，再继续
• 全未命中 → 告知上下文无候选人记录，询问是否先搜索

Step 2 — 自适应对比模式：

• 模式 A（有五维评分，来自本次搜索）：直接取已有评分横向并列，维度：岗位匹配/行业经验/年限匹配/专业能力/可到岗
• 模式 B（无评分，用户直接指名）：从简历信息提取客观字段互比——工作年限/最高学历/最近公司/核心技能/亮点（1句）/风险（1句），缺失字段标"—"，不强制打分
• 混合情况：优先模式 A，无评分的格子填"未评分"附简要描述

Step 3 — 输出（格式写死不可自创）：

• 开头一行交代来源：如"上下文里已有两位的完整简历信息，直接做对比，不需要再调 MCP。"
• 2-3 人 → Markdown 横向表：维度为行、候选人各占一列，表头姓名带 ATS 链接；五维行的维度名后标本行满分星（如 **岗位匹配** ★★），每格以该人得分星开头再接一句依据（如 ★★ 明确 toB SaaS PM，赛道对口）；五维之后补客观行：可到岗/期望薪资/学历/城市
• 4 人以上 → HTML 表格（遵循 hrsaas-ui-spec），同样结构
• 表后一段加粗综合推荐：先一句点出核心差异，再每人一条"更适合什么方向"的要点，最后给出明确的优先推进建议（如"优先约XX；岗位偏XX方向再考虑XX"）

人才地图 Fastpath

For recruiting.talent_map.v1（人才地图、给我做一个人才地图、xxx的人才地图）:

三步固化流程，步骤间有模型分析环节。

已知数据格式：search_resumes 返回的 name 字段是 Markdown 超链接格式，例如 [文先生](https://trunknew.wintalent.cn/wt/mailResponse/...) — 这是 ATS 系统的正常返回，不是异常。step1 脚本已用 stripMarkdownLink 提取纯姓名，模型无需处理原始格式。

第一步：数据采集（脚本）

node <skill_dir>/scripts/run-dayee-talent-map-step1.mjs --company <公司名>

• 调用 search_resumes(companyName=<公司名>) 全量分页（pageSize=50，并行取所有页）
• 规则清洗：姓名含"测试"/"test"/"Test"、职位含"测试"/"画像"/"勿动"/"勿用"的一律剔除
• 批量调 resumes_detail（每批≤5个 resumeCode）获取简历全文
• 从简历全文中提取：companyExperience（目标公司工作经历块＝标题行＋职责描述，部门推断的主要依据）、sourceCompany/destCompany（入职前/离职后相邻公司，已解析为纯公司名）、city（现居住地）
• companyExperience 为 null 的候选人不过滤，保留在数据中并由模型归入 uncategorized
• 不保存简历全文，只保存提取后的结构化字段，控制文件体积
• 输出 <当前目录>/output/talent-map/talent_map_<公司名>_<日期>_candidates.json

第二步：语义分析（模型）

读取 step1 输出的 candidates JSON 和 references/org_structures.md，按照 step1 输出的 Schema 规格产出 analysis JSON，写入 <当前目录>/output/talent-map/talent_map_<公司名>_<日期>_analysis.json。

写文件方式（必须遵守）：analysis JSON 用文件写入工具（Write）直接写入，禁止用 shell 的 echo/heredoc 拼 JSON——中文引号和特殊字符会造成语法错误；后续命令里的路径一律加双引号（技能目录路径可能含空格）。

analysis JSON 包含：

• org_tree：将每个候选人映射到事业群 → 部门层级。组织架构是本报告的主体，必须结合 org_structures.md 主动推断，优先级：明确部门名 > 产品/团队名 > 职位上下文 > 地点线索。凡 companyExperience 非 null 的候选人都必须归入某个事业群（部门不明时放该事业群下"未细分"），只有 companyExperience 为 null 的才进 uncategorized；推断占比在 data_notes 说明
• flow_analysis：直接聚合 step1 给出的 sourceCompany/destCompany（已是纯公司名），同一公司不同写法要归并；公司名里禁止出现日期、序号、职级残片
• regions：按城市统计，取前6个，每个城市列2-3位代表性候选人
• business_context / recruitment_context：基于公开知识对目标公司的业务背景和招聘动态判断
• data_notes：标注数据局限（如"部门归属为推断"）

超过50%为测试数据时在 data_notes 中标记。

status 枚举：pool（人才池/待跟进）、active（仍在该公司在职）、hired（已入职新公司）、offer（拟录用/待面试）

第三步：生成 HTML（脚本）

node <skill_dir>/scripts/run-dayee-talent-map-step2.mjs --company <公司名> --date <YYYY-MM-DD>

• 读取 candidates JSON + analysis JSON + references/talent_map_template.html
• 所有占位符替换均由脚本完成，无需模型参与
• 输出 <当前目录>/output/talent-map/talent_map_<公司名>_<日期>.html
• 按「报告展示规范」向用户展示 HTML

目标公司人才画像 Fastpath

For recruiting.target_company_talent_portrait.v1（分析人才库中来自某目标公司/对标公司/竞品公司的候选人画像，如"分析人才库中来自京东的候选人画像"、"看一下阿里背景的人才特点"）:

三步固化流程，步骤间有模型分析环节。区别于人才地图（看组织架构/人才流动），本路径关注"曾在这家公司待过的人才有什么共性"，输出四维画像：履历完整性 + 业务广度 + 跳槽链 + 上下游对标。

前置依赖：生成 HTML 前由 step3 脚本套用 references/portrait_template.html，模板已内置 hrsaas-ui-spec 风格，模型不需手写样式。

第一步：数据采集（脚本）

node <skill_dir>/scripts/run-dayee-portrait-step1.mjs --company <公司名>

• 按 8 个职类桶（开发/产品/销售/算法/运营/测试/设计/职能）分别调 search_resumes(companyName=<公司名>) 采集，规则清洗（姓名含测试/test、职位含画像/勿动等剔除）、去重
• 批量调 resumes_detail 拉简历全文，提取 companyExperience（目标公司经历块）、city、workHistory、targetTenure，并按 workYears 推断 tier（A/B/C）
• 不保存简历全文，只存提取后的结构化字段
• 输出 <当前目录>/output/portrait/portrait_<公司名>_<日期>_candidates.json
• 脚本 stdout 末尾会打印完整的 Analysis JSON Schema、tier 分层规则、tag_color 枚举 —— 第二步严格以该输出为准

第二步：语义分析（模型）

读取 step1 输出的 candidates JSON，按 step1 stdout 打印的 Analysis JSON Schema 严格输出，写入 <当前目录>/output/portrait/portrait_<公司名>_<日期>_analysis.json。

analysis JSON 含 5 章节（schema 字段以 step1 输出为准，此处只列章节意图）：

• chapter1 画像群体：样本规模/平均在职/高价值占比数据卡片 + tier 分布（A 战略级 / B 主力中坚 / C 初级跨岗）+ BU 分布
• chapter2 人才剖面：按 tier 给 persona（代表人物、核心能力、业务方向、跳槽模式、发展建议）+ callout 观察
• chapter3 知识技能特征：按职类（研发/销售/产品/运营）拆 tech_stack / 方法论 / 客户类型等 + 稀缺加分技能（每条标注来自哪位候选人）
• chapter4 跳槽链总结：common_stats + 5 类跳槽模式（internal_multi / simple_1seg / bigco_serial / traditional / short_label，固定枚举与 tag_color）+ 上下游对标（sources / destinations / benchmark_summary）
• chapter5 候选人名录：按职类分桶列出候选人明细

tier 分层规则（以 step1 输出为准）：A 战略级 = workYears≥10年 或 position 含总监/VP/负责人/架构师/专家；B 主力中坚 = 5-9年；C 初级跨岗 = <5年。

tag_color 枚举：blue / green / orange / purple / cyan。

数据局限（如"部门归属为推断""测试数据占比高"）写入 data_notes，不猜测。

第三步：生成 HTML（脚本）

node <skill_dir>/scripts/run-dayee-portrait-step3.mjs --company <公司名> --date <YYYY-MM-DD>

• --date 用 step1 的 fetched_at（即 step1 运行当天日期）
• 读取 analysis JSON + references/portrait_template.html，所有占位符替换由脚本完成，无需模型参与
• 输出 <当前目录>/output/portrait/portrait_<公司名>_<日期>.html
• 按「报告展示规范」向用户展示 HTML

人才情报与竞争 Mapping Fastpath

For recruiting.competitor_talent_intelligence.v1（人才情报与竞争Mapping）,runner 返回 model_driven，模型按本章节执行。覆盖五个子场景：竞品动态（谁在大招）、竞品分析（深度情报报告）、人才流向、组织还原、浓度探测。详细步骤、数据收集清单、报告结构逐场景固化在references/talent-intelligence-scenarios.md，先读它再动手。

路由边界（先判再做）：带"人才地图"字样 → talent_map.v1；带"画像 /背景候选人特点 / 群体共性" → target_company_talent_portrait.v1；"情报 / 竞品报告 / 竞品分析 / 谁在大招 / 人才流向 / 组织架构还原 / 分布浓度"→ 本路径。典型演示问法「帮我看一下<公司>的人才情报分析」对应子场景二（竞品深度报告：KPI 指标卡 + 财务对比 + 薪酬对标 + 人才流动 + AI 人才竞争 +SWOT + HR 建议）。

执行纪律：

1. ATS 优先：ATS 取数一律经统一入口

node <skill_dir>/scripts/mcp-call.mjs --call search_resumes --args '<JSON>'（分页克制：前 2-3 页做分析，其余只记数量），resumes_detail 只抽 3-5 个关键样本；与 WebSearch 并行发起，不串行等待。

1. 外部信息用 WebSearch/WebFetch，财务只取营收/净利润/员工数三个核心指标并

标注来源（"年报"/"财经网站摘要"）；不准确的数据宁可不展示。

1. 产出用 references/talent_intelligence_template.html（占位符

REPORT_TITLE / REPORT_SUBTITLE / CORE_JUDGMENT / METRICS_HTML /MAIN_CONTENT / ADVICE_HTML / WEB_SOURCES / GEN_DATE 等，模型填槽生成最终 HTML）。模板内嵌本 skill 同一套 HRSaas Design Tokens，禁止改色彩/字体/间距参数、禁止引入外部 UI 依赖或 Chart.js 等外部库。

1. 每份报告结尾必有「对 HR 的建议」段落，给出可执行动作（挖谁/防谁/

薪酬动作/跟踪目标）。

1. 候选人姓名在 HTML 呈现时脱敏（姓+*）；search_resumes 的 name 字段是

Markdown 超链接格式，分析用纯姓名。ATS 跳转链接保持原样。

1. 数据纪律沿用全局 Hard Rules：不编数字、样本不足只报计数不报率、

周期/口径在报告里写明。

Personal Weekly Report Fastpath

For recruiting.personal_weekly_report.v1（招聘个人周报）, route through the packaged fast-report runner:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --request "个人周报"
# 指定周窗口/操作人（缺省 = Asia/Shanghai 当前自然周（周一~周日）+ 当前登录账号。
# 账号识别：首选本地解码登录令牌（JWT 载荷 sub = 企业代码_登录名_序号，零请求）；
# 解不出时用「我负责的岗位」负责人字段推断；都不行返回 needs_clarification
# 要求补 --user。不写死任何默认账号）：
node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --request "个人周报" --start 2026-06-15 --end 2026-06-21 --user <账号>
# 默认只生成个人周报；用户明确要求团队周报时加 --include-team true（个人+团队一起出）

This route is LIVE: the orchestrator run-dayee-personal-weekly-answer-fastpath.mjs runs the weekly five-script chain under scripts/weekly/ against real ATS data — fetch-weekly-data.mjs (本周全量 userName 维度 + 基线 4 周合计, report_user_post) → fetch-weekly-stage-c.mjs ∥ fetch-weekly-details.mjs (个人基线行+职位分布 ∥ 行级明细 report_details: 入职/面试/offer 宽窗) →analyze-weekly.mjs (聚合出 output/weekly_report_<weekId>_<user>.json, 含caliber_notes 与 sentinels 口径哨兵) → render-weekly-html.mjs (默认仅个人周报HTML；--include-team true 时同时生成团队周报, 周标签按真实周起点生成).团队周报聚合口径：取本周操作人维度报表的全部账号 → 保留周内有任意操作动作的账号（10 个动作字段之和 > 0）→ 其中「批量操作账号」（推荐面试 ≥150 次且初筛动作 < 推面 15%，机器/导入行为指纹）单独列出，不混入真人工作量对比。Expect roughly 90–120s live end-to-end; each phase reports its own timing in phases. On any fetch failure the runner returns a structured status: failed with the failing phase — never fall back to static demo artifacts.

目标人本周没有任何操作动作是正常业务情形：链路按全零行继续生成「本周无操作」口径的周报（meta.sentinels 里会带 S0 哨兵说明），不会中断报错。

Data caliber (inherited from the verified weekly chain): userName 操作人口径（周内发生的操作动作，非按应聘时间归属）; 各环节计数是动作量不是同批转化;率类指标分母不足 10 只报计数; D8 报表值不可靠已由哨兵弃用、全部用计数实算。

This route preserves the weekly-report product rules: userName 操作人口径, professional report wording, no visible process words such as 辅助, 洞见/猜想/方向, 该区域用于, or demo/version labels, and no repeated metric blocks that restate the same numbers in multiple places.

Presentation rule: Never expose data origin in any user-visible output. Do not add notes such as "静态报告", "演示数据", "预生成", "固定路由", "若需实时数据请配置", or any equivalent disclaimer — regardless of context. Present report numbers and conclusions directly. The data source is an internal implementation detail and must never appear in the answer text, chat replies, or any accompanying summary.

Quick Start

For a user request, first run the packaged report fastpath:

node <skill_dir>/scripts/run-dayee-fast-report-fastpath.mjs 
  --request "<user request>"

Then read the answer artifact named in the JSON result and return it with the HTML/timing paths. Follow the matched path's execution definition, field mapping, permission policy, and display template only when the runner reports an unsupported path or a concrete debug task requires manual execution. Use the current MCP login/session or non-interactive env auth when the report tool is callable, and keep user updates focused on the requested business report.

Channel-Effect Matched Path

Only when debugging the channel runner directly, or when the top-level runner is temporarily unavailable, run this single answer fastpath. It fetches the fixed channel and post-type aggregations, renders the current channel diagnostic HTML, and writes summary/answer/timing artifacts:

node <skill_dir>/scripts/run-dayee-channel-answer-fastpath.mjs 
  --start 2025-01-01 
  --end 2025-03-31

The wrapper is non-interactive by default. The channel fetcher is local token-cache first (~/.dayee-mcp-auth); if the cache is missing or cannot refresh, re-authorize through the skill's own scripts/auth/ browser OAuth flow and rerun. Use DAYEE_MCP_ACCESS_TOKEN only as an explicit one-off override. Do not put credentials, tokens, OAuth codes, or callback URLs in command arguments, project files, generated reports, timing records, or final responses. Use --allow-prompts true only for isolated manual debugging of legacy scripts.

Read only the generated compact artifacts:

• artifacts/channel_answer_<range>_summary.json
• artifacts/channel_answer_<range>_answer.md
• artifacts/channel_answer_<range>_timing.json

The HTML path defaults to ../agent-html-channel-strategy-<label>/index.html. The default page is the current accepted channel diagnostic: overview charts, post-type-only channel performance, separated monthly volume/conversion trends, per-channel appendix, and final follow-up list. Use --renderer legacy only when explicitly debugging the old lightweight renderer.

If the packaged helper is unavailable or has diverged, stop with the concrete error and repair that fixed path; do not improvise a second MCP route.