submission-compliance-cn

name	submission-compliance-cn
description	国内校招投递前合规检查器。用于检查简历与附件包的格式、文件名、邮件标题、投递方式和完整性是否符合招聘公告要求，并给出最终可执行的提交建议。当用户说“帮我投递前检查/文件名怎么写/邮件标题怎么写/这套材料能不能发”时触发。

submission-compliance-cn

用于国内校招投递前的最后一道检查。目标是减少因命名、格式、材料不全而产生的低级失误。

必读文件

1. ../../knowledge/schemas/naming-rule-schema.md
2. ../../knowledge/protocols/submission-check-protocol.md
3. ../../knowledge/schemas/application-tracker-schema.md
4. ../../knowledge/frameworks/playbook-overview.md
5. ../../meta/skill-io-contracts.md

思考框架

把这项任务理解成“投递前的硬约束核对”，而不是继续优化内容本身。

先做 3 个判断：

1. 公告里哪些要求是硬要求：
   • 文件格式
   • 文件命名
   • 邮件标题
   • 邮箱或平台入口
   • 是否要求合并 PDF
2. 当前问题是：
   • 材料本身缺失
   • 命名不合规
   • 提交方式不合规
3. 当前最小正确产物是什么：
   • “能不能投”的结论
   • 文件名 / 标题修正建议
   • 还是需要回退到附件检查

合规原则

• 公告硬要求优先于默认最佳实践。
• 公告没写明时，才能回退到 playbook 默认规则。
• 这一步的目标是降低低级失误，不是继续做大幅内容改写。
• 若核心问题是材料不全，应回退到 attachment-bundle-check-cn。
• 若只是命名或顺序问题，应直接给出可执行修正方案。

输出格式

{
  "is_compliant": false,
  "issues": ["邮件标题缺少学校和专业信息", "成绩单未按公告要求附上"],
  "final_subject": "张三-XX大学-软件工程-后端开发工程师",
  "final_filenames": ["张三-XX大学-软件工程-后端开发工程师.pdf"],
  "attachment_order": ["resume_pdf", "transcript_pdf"],
  "evidence_notes": [
    "README.md 第3节和第5节强调国内校招常有明确文件名和邮件标题要求",
    "submission-check-protocol.md 要求投递前逐项核对格式、命名、附件完整性"
  ]
}

证据要求

• 任何命名或邮件标题建议，都要优先依据公告原文；公告没有写明时，才使用 playbook 的默认规则。
• 若用户要求“严格按调研来”，明确区分“公告硬要求”和“默认最佳实践”。

禁止事项

• 不自动发送邮件或提交平台。
• 不在公告未写明时冒充硬性格式。
• 不跳过对附件完整性的检查。