Compensation Repo
做定薪判断,也先把申报前风险挑出来 / Price offers and catch filing risks Skill: Compensation Repo Owner: ashley-aihr Summary: 做定薪判断,也先把申报前风险挑出来 / Price offers and catch filing risks Tags: china:0.2.0, compensation:0.2.0, hr:0.2.0, latest:0.5.0, payroll:0.2.0 Version history: v0.5.0 | 2026-05-18T20:34:48.346Z | auto **Summary:** Introduces dynamic market data handling, clearer output protocols, and improved decision logic for compensation and payroll checks. - Added support for dynamic mar
Rank
62
Safety
84
Downloads
1.4k
Updated
Oct 10, 2026
Version
0.5.0
Source
CLAWHUB
About
What it does, and when to use it.
Capability contract not published. No trust telemetry is available yet. 1.4K downloads reported by the source. Last updated 10/10/2026.
Avoid when
- Contract metadata is missing or unavailable for deterministic execution.
Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing
Public facts
Every fact links back to the source it came from.
- Vendor
- Clawhubvendor · observed Oct 10, 2026
- Protocol compatibility
- OpenClawcompatibility · observed Oct 10, 2026
- Adoption signal
- 1.4K downloadsadoption · observed Oct 10, 2026
- Latest release
- 0.5.0release · observed May 18, 2026
- Handshake status
- UNKNOWNsecurity
Install and run
Setup complexity: low.
clawhub skill install s1709qwt8f7axz6nyace1xk5s5840gbe:hr-compensation-checks- Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
- Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.
Contract: missing
curl -s "https://www.xpersona.co/api/v1/agents/clawhub-ashley-aihr-hr-compensation-checks/snapshot"
Documentation
CLAWHUB
55,298 characters of source documentation, loaded on request.
Extracted files
5 files captured from the source.
SKILL.md
---
name: hr-compensation-checks
description: 帮 HR 做定薪判断、band 对标、市场调研摘要,以及个税社保公积金申报前检查,先看值不值,再看会不会出风险。 / Help HR teams with compensation review, band and market checks, and payroll filing prechecks.
version: 0.5.0
metadata:
openclaw:
homepage: https://github.com/Ashley-AIHR/hrskill-compensation-module
envVars:
- name: COMP_EXPORT_PATH
required: false
description: Optional local export path for filing check outputs.
---
# 定薪与申报检查助手 / Compensation Decision Assistant
当用户在处理两类薪酬工作时使用这个 skill:
1. 定薪判断:band、市场调研、内部公平、offer 建议
2. 申报检查:个税、社保、公积金申报前排雷
目标不是手算工资,而是输出:
1. 结论
2. 依据
3. 风险
4. 待办
5. 可直接发给内部协作方的说明
如果用户第一次使用或输入很乱,先读 [references/real-user-scenario.md](references/real-user-scenario.md)。
如果需要工作流背景,读 [references/compensation-workflows.md](references/compensation-workflows.md)。
如果需要最新政策、城市口径和系统操作依据,读 [references/china-compensation-policy-kb-2026.md](references/china-compensation-policy-kb-2026.md)。
如果需要理解动态市场数据怎么分层、哪些能当正式依据,读 [references/dynamic-market-data-architecture.md](references/dynamic-market-data-architecture.md)。
## 路由规则
根据输入内容路由到下面动作之一:
1. `review_compensation_band_and_offer`
触发条件:输入里有 band、市场分位、候选人期望、内部参考、预算中的任意组合。
2. `precheck_payroll_filing`
触发条件:输入里有个税、社保、公积金申报字段,或月度申报名单、员工状态、主体信息。
如果用户不知道该选哪个动作:
1. 有申报名单、基数、主体、缴纳地,就走 `precheck_payroll_filing`
2. 有 band、市场分位、候选人期望,就走 `review_compensation_band_and_offer`
对 `review_compensation_band_and_offer`,必须区分:
1. `official_policy`
2. `public_market_signal`
3. `paid_survey_data`
4. `internal_company_data`
如果只有 `public_market_signal`,不允许把结论写成正式定薪建议。
## 输出协议
处理任意薪酬场景时,始终输出:
```text
normalized_data
decision_summary
decision_basis
missing_information
risk_summary
priority_issues
next_action
message_draft
record_update
human_confirmation_needed
compliance_warning_if_any
```
要求:
1. `decision_summary` 必须先回答“怎么定”或“能不能报”。
2. `decision_basis` 必须把 band、市场、内部参考或申报依据讲清楚。
3. `missing_information` 只写真正影响判断或申报的缺口。
4. `risk_summary` 优先写申报失败风险、内部公平风险、预算风险。
5. `priority_issues` 必须按高、中、低排序。
6. `next_action` 必须是 HR 今天能做的动作。
7. `message_draft` 默认写给业务负责人、薪酬同事或数据提供方。
8. `human_confirmation_needed` 必须写清楚还要谁确认什么。
9. 对定薪场景,必须标明本次结论属于 `正式建议`、`弱建议` 还是 `仅市场信号判断`。
## 动作要求
### `review_compensation_band_and_offer`
至少抽取:
```text
job_family
job_level
band_min
band_mid
band_max
market_p25
market_p50
market_p75
candidate_current_pay
candidate_expected_pay
internal_peer_reference
budget_range
```
并优先识别:
```text
official_policy
public_market_signal
paid_survey_data
internal_company_data
candidate_total_comp_context
```
结果优先顺序:
1. 建议怎么定
2. 为什么这么定
3. 内部公平或预算风险
4. 怎么和业务解释
5. 还需要谁确认
判断规则:
1. 同时具备 `internal_company_data + paid_survey_data + candidate_current_pay_or_total_comp + budget_range` 时,才可给 `正式建议`
2. 只有 `public_market_signal` 时,只能给 `市场信号判断`
3. 缺少 `band` 或 `internal_company_data` 时,不得假装能完成内部公平判断
4. 缺少 `budget_range` 时,不得假装能完成审批级建议
5. 缺少 `candidate_current_pay` 或总包口径时,要主动降低结论强度
如果需要文件产出,运行:
```text
node scripts/generate_band_offer_packet.js <input.json> <output-dir>
```
示_meta.json
{
"ownerId": "kn7cfgqtq1167ctj7rfp8cg3yn840js9",
"slug": "hr-compensation-checks",
"version": "0.5.0",
"publishedAt": 1779136488346
}references/china-compensation-policy-kb-2026.md
# 中国薪酬申报与定薪知识库 更新时间:2026-05-19 这份文件只收录两类内容: 1. 会随着时间、城市、系统流程变化的动态资料 2. 可以直接支撑薪酬 skill 判断的政策与操作依据 它不是完整政策汇编,而是给 skill 用的最小知识库。 ## 先给结论 截至 2026-05-19,当前 repo 里原本并没有真正把这些动态资料接进去。 最明显的缺口有 4 个: 1. 没有按城市维护社保、公积金口径 2. 没有按年度维护社保缴费工资申报周期 3. 没有把个税扣缴端和 WEB 端的真实操作限制接进去 4. 没有把“哪些数据能公开动态获取、哪些不能”说清楚 所以如果这个 skill 要从 prototype 变成 professional-grade,至少要从这份知识库起步。 ## 一、社保年度缴费工资申报:这是真正会变的动态资料 ### 上海:2026 社保年度申报已经变化 官方来源: 1. 国家税务总局上海市税务局 [关于开展2026社保年度用人单位社会保险缴费工资申报工作的通告](https://shanghai.chinatax.gov.cn/zcfw/zcfgk/sbf/202604/t480144.html) 2. 国家税务总局上海市税务局 [一图了解:上海市2026社保年度用人单位社会保险缴费工资申报](https://shanghai.chinatax.gov.cn/zcfw/tjss/202605/t480288.html) 截至 2026-05-19,关键动态口径是: 1. 申报时间:2026-05-01 至 2026-06-25 2. 对应社保年度:2026-07 至 2027-06 3. 用人单位要按 2025-01-01 至 2025-12-31 的上一自然年度月平均工资申报 4. 上一年工作不满一年的职工,按工资总额除以实际工作月数计算 5. 2026 年新招录职工,以起薪当月全月工资收入申报 6. 申报渠道至少包括上海电子税务局、社保费管理客户端、办税服务厅 这意味着: 1. `precheck_payroll_filing` 不能只做“当月申报前检查” 2. 还必须知道当前是不是处在“年度缴费工资申报窗口” 3. 对上海场景,必须区分“月度申报前检查”和“年度基数申报检查” ## 二、公积金:北京、深圳都不是静态规则 ### 北京:社保工资与公积金基数已经开始联动 官方来源: 1. 北京住房公积金管理中心 [2025住房公积金年度缴存基数申报常见问题解答](https://gjj.beijing.gov.cn/web/zwfw5/1747335/1747336/743669918/index.html) 2. 北京住房公积金管理中心 [《关于2025住房公积金年度缴存有关问题的通知》政策解读](https://gjj.beijing.gov.cn/web/zwgk61/2024zcjd/743765478/index.html) 3. 北京住房公积金管理中心 [《关于用人单位和灵活就业人员申报2025年度社会保险费缴费工资(缴费基数)有关事项的通告》(住房公积金部分)政策解读](https://gjj.beijing.gov.cn/web/zwgk61/2024zcjd/743660449/) 截至 2026-05-19,关键口径是: 1. 2025 公积金年度为 2025-07-01 至 2026-06-30 2. 缴存比例仍是 5% 至 12% 3. 月缴存基数上限为 35811 元 4. 自 2025-09-01 起,月缴存基数下限为 2540 元 5. 领取基本生活费职工的下限为 1778 元 6. 单位可授权公积金中心获取已向税务部门申报的社保缴费工资,作为核定公积金缴存基数的“上年月均工资” 这意味着: 1. 北京场景下,公积金不能完全当成一套独立口径 2. skill 需要知道“社保年度申报数据是否已经可供授权获取” 3. 如果企业是在 6 月到 7 月切换窗口期,系统要提醒“缴存基数申报”和“7 月汇缴名单确认”的顺序风险 ### 深圳:2026 年公积金规则也在变 官方来源: 1. 深圳政府在线 [深圳新版住房公积金管理办法下月起施行](https://www.sz.gov.cn/cn/xxgk/zfxxgj/zwdt/content/post_12687780.html) 2. 深圳市住房和建设局 [缴存基数调整有什么要求?](https://zjj.sz.gov.cn/zcjzts/content/post_12322480.html) 3. 深圳市住房公积金管理中心问答 [个人缴存比例从2026年4月1日起就能申请调整,还是要等到7月1日才能调整?](https://zjj.sz.gov.cn/szszfhjsjwzgkml/szszfhjsjwzgkml/seztfw/zfly/wyw/ywzsk/content/post_12703688.html) 截至 2026-05-19,关键口径是: 1. 深圳新版《住房公积金管理办法》在 2026-04 起进入新阶段 2. 每个住房公积金年度为当年 7 月 1 日至次年 6 月 30 日 3. 职工可在单位缴存比例基础上,自愿申请提高个人缴存比例 4. 调整后的个人缴存比例最高不超过 12% 5. 在每个住房公积金年度内,职工可调整一次个人缴存比例 这意味着: 1. 深圳场景不只要检查缴存基数,还要检查“个人缴存比例是否已在年度内调整过” 2. 如果把深圳用户当成和北京、上海完全同一套逻辑,会误判 ## 三、个税扣缴:真实工作不是“算税”,而是“系统约束 + 数据恢复 + 更正逻辑” 官方来源: 1. 国家税务总局上海市税务局 [自然人扣缴端热点操作问答](https://shanghai.chinatax.gov.cn/jstax/ztzl/yshj/sycz/202512/t478537.html) 2. 国家税务总局广东省税务局转发 [自然人电子税务局WEB端扣缴业务等相关功能操作指南](https://guangdong.chinatax.gov.cn/gdsw/zqsw_tzgg/2020-11/18/content_75df0d6a19634d9596f0bffd81492a5c.shtml) 截至 2026-05-19,对 skill 最有用的不是税率本身,而是这些操作型事实: 1. 扣缴端数据丢失时,不是所有企业都能直接恢复 2. 办税人员可能需要先申请开通“扣缴端数据下载”权限 3. 上海税务口径下,开通后可在 72 小时内下载数据 4. 分部门申报的企业,数据下载存在限制 5. WEB 端和扣缴端都支持人员信息、专项附加扣除信息、扣缴申报、查询统计等模块 这意味着: 1. `precheck_payroll_filing` 不能只假设数据永远齐全 2. 要把“系统数据恢复能力”和“历史申报数据可追溯性”纳入风险提示 3.
references/compensation-workflows.md
# 中国 HR 薪酬高频工作流 这个 skill 当前只先做一个场景,但背后的工作流语境来自中国 HR 常见的薪酬操作链路。 ## 常见月度链路 1. 人员异动确认 2. 考勤、绩效、补发补扣等数据收集 3. 算薪 4. 差异复核 5. 个税申报 6. 社保申报 7. 公积金汇缴 8. 发薪与留痕 ## 当前最适合 AI 的两个切入点 ### 1. 薪酬判断 包括: 1. 薪酬 band 校验 2. 市场调研摘要 3. 定薪建议 这类工作适合做“高阶判断型 Skill”,因为它很像资深 HR 脑子里的隐性判断。 ### 2. 申报前检查 第一版不做完整算薪,而做: 1. `band / 调研 / 定薪建议` 2. `申报前检查` 原因: 1. 一个负责专业感与判断感 2. 一个负责落地感与风险感 3. 两者合在一起,才更像真实中国薪酬模块 ## 当前最应该优先识别的问题 1. 人员漏报 2. 离职人员仍在申报名单 3. 申报主体错误 4. 缴纳地错误 5. 社保、公积金基数异常 6. 专项附加扣除信息缺失或异常 7. 银行卡或身份证号缺失
references/dynamic-market-data-architecture.md
# 薪酬市场动态数据架构 更新时间:2026-05-19 这份文件回答 3 个问题: 1. 薪酬市场调研数据从哪里来 2. 哪些数据可以动态拿,哪些不能 3. skill 应该如何区分“市场信号”和“正式定薪依据” ## 一、核心原则 薪酬 skill 不能把所有数据都当成同一种证据。 至少要区分 4 层: 1. `official_policy` 官方动态资料,例如国家统计局、税务局、公积金中心、地方人社口径 2. `public_market_signal` 公网职位薪资、招聘平台公开区间、景气和招聘热度 3. `paid_survey_data` 企业采购的薪酬调研结果,例如 Mercer、智联企业薪酬调研等 4. `internal_company_data` 企业自己的 band、内部同岗参考、预算、历史 offer、接受率 ## 二、每一层能做什么 ### `official_policy` 能支持: 1. 合规边界 2. 城市年度口径 3. 社保、公积金、个税相关约束 4. 宏观工资趋势 不能直接支持: 1. 某一岗位的精准定薪 2. 某一级别的 P50/P75 报价 ### `public_market_signal` 能支持: 1. 当前市场招聘热度 2. 公开薪资区间趋势 3. 城市、行业、岗位的招聘侧价格信号 不能直接支持: 1. 最终成交薪资 2. 企业内部公平 3. 可审计的正式定薪依据 所以它最多只能作为: `market signal only` ### `paid_survey_data` 能支持: 1. 分城市、分岗位、分级别的市场分位点 2. 定薪、调薪、band 校准 3. 对业务或老板的正式解释材料 这是最接近真实薪酬 benchmark 的外部数据。 ### `internal_company_data` 能支持: 1. band 判断 2. 内部公平判断 3. 预算约束 4. 历史 offer 一致性 5. 真正的审批建议 这是最终定薪最关键的一层。 ## 三、skill 的判断权重 对于 `review_compensation_band_and_offer`,建议使用下面的判断优先级: 1. `internal_company_data` 2. `paid_survey_data` 3. `public_market_signal` 4. `official_policy` ## 四、什么时候允许 skill 给出强结论 ### 可以给“正式建议” 至少满足: 1. 有 `band` 2. 有 `internal_company_data` 3. 有 `paid_survey_data` 或高质量市场分位点 4. 有候选人当前薪资或总包口径 5. 有预算范围 ### 只能给“弱建议”或“仅市场信号判断” 如果出现这些情况: 1. 只有公网职位薪资,没有正式调研 2. 没有内部 band 3. 没有内部同岗同级参考 4. 没有预算 5. 候选人只有期望薪资,没有当前薪资或总包口径 这时 skill 必须主动说: 1. 当前只能给市场信号判断 2. 不能作为正式定薪依据 3. 还缺哪些数据 ## 五、建议的输入结构 建议每次定薪判断输入都显式区分来源: ```text policy_context public_market_signal paid_survey_data internal_company_data candidate_compensation_context ``` 不要把所有东西都混在一个 `market_benchmark` 里。 ## 六、最小可行动态方案 如果现在就要做一个“动态版薪酬 skill”,最实际的路线是: 1. 官方动态口径:由 skill 内置并定期更新 2. 公网市场信号:允许用户补充或人工抓取摘要 3. 正式调研数据:由用户上传最新报告或 Excel 4. 企业内部数据:由用户上传 band、预算、内部参考 也就是说: `动态` 不等于 `全靠 skill 自己上网抓` 而是: `skill 能持续消费会变化的数据,并且知道每种数据能撑起多强的判断`
AionUi
Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!
activepieces
AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents
cherry-studio
AI productivity studio with smart chat, autonomous agents, and 300+ assistants.
CopilotKit
The Frontend for Agents & Generative UI. React + Angular
Machine-readable data
The same record, as JSON, for agents and crawlers.
{
"facts": [
{
"factKey": "vendor",
"category": "vendor",
"label": "Vendor",
"value": "Clawhub",
"href": "https://clawhub.ai/ashley-aihr/skills/hr-compensation-checks",
"sourceUrl": "https://clawhub.ai/ashley-aihr/skills/hr-compensation-checks",
"sourceType": "profile",
"confidence": "medium",
"observedAt": "2026-10-10T15:34:19.600Z",
"isPublic": true
},
{
"factKey": "protocols",
"category": "compatibility",
"label": "Protocol compatibility",
"value": "OpenClaw",
"href": "https://www.xpersona.co/api/v1/agents/clawhub-ashley-aihr-hr-compensation-checks/contract",
"sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-ashley-aihr-hr-compensation-checks/contract",
"sourceType": "contract",
"confidence": "medium",
"observedAt": "2026-10-10T15:34:19.600Z",
"isPublic": true
},
{
"factKey": "traction",
"category": "adoption",
"label": "Adoption signal",
"value": "1.4K downloads",
"href": "https://clawhub.ai/ashley-aihr/hr-compensation-checks",
"sourceUrl": "https://clawhub.ai/ashley-aihr/hr-compensation-checks",
"sourceType": "profile",
"confidence": "medium",
"observedAt": "2026-10-10T15:34:19.600Z",
"isPublic": true
},
{
"factKey": "latest_release",
"category": "release",
"label": "Latest release",
"value": "0.5.0",
"href": "https://clawhub.ai/ashley-aihr/hr-compensation-checks",
"sourceUrl": "https://clawhub.ai/ashley-aihr/hr-compensation-checks",
"sourceType": "release",
"confidence": "medium",
"observedAt": "2026-05-18T20:34:48.346Z",
"isPublic": true
},
{
"factKey": "handshake_status",
"category": "security",
"label": "Handshake status",
"value": "UNKNOWN",
"href": "https://www.xpersona.co/api/v1/agents/clawhub-ashley-aihr-hr-compensation-checks/trust",
"sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-ashley-aihr-hr-compensation-checks/trust",
"sourceType": "trust",
"confidence": "medium",
"observedAt": null,
"isPublic": true
}
],
"events": [
{
"eventType": "release",
"title": "Release 0.5.0",
"description": "**Summary:** Introduces dynamic market data handling, clearer output protocols, and improved decision logic for compensation and payroll checks. - Added support for dynamic market data input and output with new sample assets. - Refined workflow routing based on input content; now distinguishes between official, market, survey, and internal data sources. - Updated output structure to require explicit decision summaries, bases, risk levels, and human confirmation steps. - Improved clarity of documentation and protocols, including updated SKILL.md with new requirements and principles. - Expanded references and sample scenarios, including latest China compensation policy and market data architecture guides.",
"href": "https://clawhub.ai/ashley-aihr/hr-compensation-checks",
"sourceUrl": "https://clawhub.ai/ashley-aihr/hr-compensation-checks",
"sourceType": "release",
"confidence": "medium",
"observedAt": "2026-05-18T20:34:48.346Z",
"isPublic": true
}
]
}Record generated Oct 10, 2026.
