# Moka Headcount

> Moka 招聘需求查询。查询招聘系统的招聘需求清单、各状态数量、名额（HC）进度与单个需求详情，以及人事系统内的招聘需求业务单据列表与详情。两者是完全独立的两套业务数据。当用户问招聘需求进度、剩余 HC、各状态需求数量，或要查人事侧的招聘需求单据时使用。

- Skill: `ahang1598/moka-headcount` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ahang1598/moka-headcount`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/moka-headcount/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/moka-headcount

---


# 招聘需求查询

查招聘需求的名额（HC）进度与状态分布，以及人事系统内的招聘需求业务单据。只编排以下两个工具：

- `mcp__moka__list_hiring_requirements`
- `mcp__moka__get_recruit_requirements`

## 选择工具

**最重要的一条：两个工具查的是两套完全独立的业务数据，标识互不关联、不能互查。**`mcp__moka__list_hiring_requirements` 查询招聘系统的招聘需求；`mcp__moka__get_recruit_requirements` 查询人事系统内的招聘需求业务单据——它与 `mcp__moka__list_hiring_requirements` 查询的招聘需求是两套完全独立的数据，标识互不关联、不能混用。具体来说：

- 一边的需求 ID 绝不能传给另一边查详情——即使名称、编号看起来像同一件事。
- 两边的数量不要相加，也不要拿一边的数字去「核对」另一边；数字对不上是正常的，因为本来就是两套数据。
- 回答里同时出现两边时，各自说清数据来源（招聘系统的需求 / 人事系统的业务单据），不要合并陈述。

分流规则：

- 「我有哪些进行中的招聘需求」「需求都在什么状态、各有多少个」「这个需求招到几个了、还剩几个名额」：招聘视角，用 `mcp__moka__list_hiring_requirements`。
- 「人事里的招聘需求业务单据有哪些」「打开这条业务单据看详情」「哪些单据同步失败了」：人事单据视角，用 `mcp__moka__get_recruit_requirements`。
- 用户没说清是哪一边时，默认按招聘视角理解（问进度、HC、招聘状态的都是招聘侧）；只有明确提到人事系统、业务单据或同步结果时才走人事侧。

概念辨析：**职位 vs 招聘需求**——需求是「要招几个人（HC 名额）、招得怎么样了」，职位是对外发布的岗位与要求。问职责要求、JD、发布情况是职位问题，这些问题应由当前可用的其他 Moka 工具处理；统计候选人在流程各阶段的人数同理。

## 常见问题速查

- 「我有哪些进行中的招聘需求」→ `mcp__moka__list_hiring_requirements`（status 过滤）
- 「需求各状态各有多少个」→ `mcp__moka__list_hiring_requirements`，直接读 counts
- 「这个需求招到几个了、还剩几个名额」→ `mcp__moka__list_hiring_requirements`（列表定位后 `action="detail"`）
- 「人事里的招聘需求单据有哪些」→ `mcp__moka__get_recruit_requirements`（列表模式）
- 「这条业务单据的详情/同步结果」→ `mcp__moka__get_recruit_requirements`（传本工具列表返回的 id）

## 调用规范

1. 通过当前平台的工具发现能力读取实时 description 与参数 Schema，以它们为入参事实源。
2. `mcp__moka__list_hiring_requirements` 的详情走两段式：先 `action="list"`（缺省）查清单拿到返回项的 requirementId，再用同一工具 `action="detail"` 带 requirementId 查单个需求详情（进度、负责人、汇报对象、关联职位、学历要求与需求描述）。
3. `mcp__moka__get_recruit_requirements` 是自己的双模式：不传 id 分页查列表，传 id 查详情——id 只能来自**本工具**列表返回的 requirementId，不能拿招聘侧的需求 ID 来传；id 与列表筛选参数不能同时传。
4. 读 `mcp__moka__list_hiring_requirements` 的数字要分清口径：counts 是七个状态（进行中/未开始/已完成/已暂停/已取消/已超时/草稿）各自的数量、不受 status 入参影响；total 是当前筛选条件（含 status）下的总数。
5. 回答「某状态有几个」直接读 counts 里对应的数字，不必为每个状态各查一次；回答「一共有多少个需求」用不传 status 时的 total。
6. `mcp__moka__list_hiring_requirements` 不传招聘模式时统计的是全部模式（社招+校招）。用户没有明确说「社招」「校招」时不要自行加模式过滤——那会静默缩小口径。
7. 只传用户明确给出的条件（状态、关键词、日期、部门等），不自行扩展；相对日期按用户所在时区换算成绝对日期再调用，回答里说明实际查询口径。
8. 需要翻很深的清单时优先用状态、关键词或招聘模式缩小范围，而不是逐页翻到底。

## 结果与权限

- 空列表一律按「未返回数据」如实说明，不据此反推权限，也不断言「没有需求/单据」。
- 招聘侧的统计范围是当前账号有权限查看的需求，不等于「你创建的」或「你负责的」；不同账号看到的数字可能不同。
- 招聘侧某个状态计数为 0，表示该状态下没有当前账号有权限查看的需求，转述时保留这一层含义。
- 草稿状态的可见范围与其余六个状态不同，两边数字对不上时以 total 为准。
- 人事侧部分字段（职务名称、招聘方式、员工类型等）的具体业务语义未经业务侧确认，转述时按返回文本原意表达，不做引申解读。
- 人事侧详情返回的是经过敏感字段过滤的可读字段与同步结果；同步失败时如实转达失败原因文本，不自行归因。
- 工具返回的 notices 与 message 是数据解读须知，先读再组织回答，如实转达，不自行改写归因。
- 两边都只读：不支持新建、修改、审批、导出、同步重试或状态变更，这些操作需要用户在 Moka 页面完成。

## 安全边界

- 不向用户展示访问令牌、内部标识符或原始技术响应；需求 ID、页码只用于串联工具，不出现在回答里。
- 只使用工具返回的字段组织回答，不虚构需求进度、负责人或同步结果。
- 需求数据按当前账号权限范围返回，不扩散与提问无关的部门或负责人信息。
- 隐私字段与内部标识不会出现在结果中，不要向用户许诺提供。
- 面向用户的回答只用业务语言：没数据说「没有查到」，不引用参数名、状态值或字段名。
- 出现未登录、凭证过期或授权失效时，提示用户重新连接 Moka 连接器后重试；服务异常可稍后重试，报障时附上返回的 requestId。