dmlin7777777/resume-tailor/resume-tailor

包公.skill v3

Pseudo Multi-Agent + Blackboard Architecture

Analyze a job description and tailor the source resume to match, using isolated expert nodes for writing and auditing.

📖 Progressive Loading Protocol（分段加载协议）

本文件只保留路由、门控和铁律。各阶段详细执行指令在 `references/` 中——进入对应阶段时必读，未进入不预读。

🔴 规则：

1. 进入阶段前未读对应文件 → 不得开始执行该阶段
2. 只读当前阶段的文件——一次性预读全部 references 违反本协议（上下文膨胀）
3. 本文件中的 🔴 STOP / 🛑 CHECKPOINT / Anti-Patterns 全程有效，不依赖 references

Trigger Phrases

⚠️ 优先级规则：所有触发词（含 Mode A / Mode B）先执行 Onboarding Check。 resume_master.md 不存在 → 无论用户说的是 Mode A/B 还是 Init，先进入 Init-A。 resume_master.md 已存在 → 按下方分类判断 Mode。

Init（新用户初始化）：

• "帮我创建简历" / "我还没有简历" / "从头做简历"
• "建一个故事库" / "帮我整理经历" / "我想记录项目经历"
• "create resume from scratch" / "build my resume"
• 所有触发词，如果检测不到 resume_master.md → 自动进入 Init-A

Mode A (JD-Targeted):

• "帮我针对这个 JD 调简历" / "tailor my resume for this JD"
• "优化简历给这个岗位" / "optimize resume for this role"
• Any JD text or URL provided with resume adjustment intent

Mode A2 (Multi-JD Batch):

• "帮我针对这几个 JD 分别做简历" / "我有多个岗位要投"
• "这两个岗位帮我比较一下，分别做简历"
• "还有一个 JD 也帮我做"（Mode A 完成后追加）
• "batch tailor for these JDs" / "compare these roles"

Scenario C (JD-Only):

• 用户提供 JD 但没有简历 → 自动检测（resume_master.md 不存在 + 有 JD 输入）
• "帮我分析一下这个 JD 要什么" / "这个岗位需要什么能力"
• "analyze this JD" / "what does this role require"

Scenario D (信息不足):

• 自动检测（输入 < 20 字且不含关键词）
• 不需要触发词——由 Mode Detection 自动路由

Scenario E (造假阻断):

• 自动检测（用户意图包含编造/虚构/捏造关键词）
• 🔴 硬门控，优先级最高，先于所有 Mode 判断

Mode B (General-Purpose):

• "帮我针对产品岗位生成一个通用性的简历"
• "做个通用版简历" / "生成XX方向的简历"
• "make a general resume" / "create a role-oriented resume"
• "简历定制" / "简历优化"

Onboarding Check（所有流程的前置门卫）

在执行任何 Mode A / Mode B 流程之前，必须先检查两个资产是否存在：

检查 resume_master.md
    ├─ Glob **/resume_master.md 找到 → 记录路径，进入 Mode Detection
    └─ 未找到 → 🔴 STOP，进入 【Init-A：创建 Master 简历】
 
检查故事库（仅 Mode B 需要，或 Mode A 的 CP3 量化备援需要）
    ├─ Glob **/项目故事库.md 或 **/story-library.md 或 **/project-story-library.md 找到 → 记录路径
    └─ 未找到 → 在 Mode B 入口 或 CP3 量化追问失败时触发 【Init-B：创建故事库】

🔴 STOP 规则：

• resume_master.md 不存在 → 不论用户要做什么，先完成 Init-A，再继续
• 故事库不存在且用户选择 Mode B → 先完成 Init-B，再进入 Phase G1
• 故事库不存在但用户选择 Mode A → 进入 Mode A，CP3 量化追问如用户无法回答则跳过，不强制先建故事库

Init-A / Init-B（详细流程 → references/onboarding_init.md）

• Init-A（创建 Master 简历）：从任意格式简历生成结构化 resume_master.md。🔴 STOP：结构化结果必须用户确认后才写入；🔴 严禁在此阶段修改数字或添加原文没有的描述。
• Init-B（创建故事库）：引导录入 STAR + 量化数据 + 追问准备，生成 project-story-library.md。🔴 STOP：预览确认后才写入；🔴 严禁推断填充用户没提供的数字。
• Mode A 故事库接入（CP3 量化备援）：优先级 = 故事库已有数字 > 用户对话提供 > 追问 2 轮无果写过程描述（并建议顺便录入故事库）。

🔴 执行 Init 前必读 references/onboarding_init.md。

Resume Input

On first run, try auto-detection first:

1. Glob **/resume_master.md in workspace — if found, use it directly
2. If workspace has resume_master.md or .workbuddy/memory/MEMORY.md with a resume path, follow that
3. Auto-detect fails → 不是直接报错，而是触发 【Init-A：创建 Master 简历】

Story library path (for Mode B capability matching): {vault}/project-story-library.md

• Use Glob **/项目故事库.md or Glob **/story-library.md or Glob **/project-story-library.md to auto-locate
• Auto-detect fails → 在 Mode B 入口触发 【Init-B：创建故事库】

Store the resolved paths in workspace memory. Never modify the original.

Mode Detection Protocol（先于 Operating Modes 执行）

执行以下决策树判断路由。优先检测 E（造假阻断）和 D（信息不足），再判断 A/A2/B/C。

用户输入到达
    │
    ├─ 🔴 E-Check：用户意图包含造假请求（见下方 Scenario E 定义）
    │    → 立即进入 Scenario E 阻断流程，不进入任何 Mode
    │
    ├─ 🟡 D-Check：输入信息严重不足（< 20 字且无 JD/简历/方向词）
    │    → 进入 Scenario D 信息收集流程
    │
    ├─ 有 JD + 有简历（resume_master.md 存在）
    │    ├─ 单份 JD → Mode A
    │    └─ 多份 JD（≥2 份或用户说「帮我比较」）→ Mode A2
    │
    ├─ 有 JD + 无简历（resume_master.md 不存在）
    │    → Scenario C（JD 分析 + 引导建简历）
    │
    ├─ 包含 URL（http/https 开头）
    │    → WebFetch 获取内容；字数 ≥ 50 字 → 按上方「有 JD」分支判断；失败 → 走「输入模糊」分支
    │
    ├─ 只有职位名称或方向词（< 50 字）
    │    → 输出「我检测到的是职位方向，没有具体 JD。
    │         有 JD 可以粘贴，或者直接告诉我你想做哪个方向，我用 Mode B 帮你生成通用简历。」
    │         → 等待用户回复后再判断 Mode
    │
    └─ 用户明确说「不需要 JD」或「通用简历」
         → 直接进入 Mode B，跳过确认问询

🔴 STOP — 歧义输入不允许自行判断 Mode，必须问用户一次。每个 session 最多触发一次此确认。

Mode A → A2 升级路径：用户在 Mode A 完成第一份简历后说「还有一个 JD 也帮我做」→ 自动切换到 A2 流程，复用已有事实底稿。

Scenario C: JD-Only（有 JD 无简历）

JD 需求分析（复用 Phase 1 Scout）→ 输出岗位需求清单，用户逐项标注 ✅/❌/🤔（🔴 STOP 等待标注）→ 命中率 ≥50% 进 Init-A→Mode A；<50% 诚实告知差距，用户选择继续或换方向。详细流程见 references/modes_playbook.md。

Scenario D: 信息不足（输入模糊或极度不足）

触发：输入 < 20 字且无 JD/简历/方向关键词。输出信息收集问卷 → 等用户回复后重新进入 Mode Detection。最多触发一次，第二次仍模糊 → 默认进 Init-A，不再追问。问卷模板见 references/modes_playbook.md。

Scenario E: 造假阻断（用户要求编造内容）

🔴 硬门控 — 在 Mode Detection 阶段拦截，不进入任何工作流程。

触发关键词（中/英）：

• "帮我编一些经历" / "帮我捏造" / "没做过但帮我写上" / "虚构一段实习"
• "fabricate experience" / "make up work history" / "fake internship"
• "帮我把数字夸大一点" / "编几个数据" / "随便写个数字"
• 任何明确要求添加用户未经历过的工作、项目、技能、证书的意图

阻断响应：

🔴 我无法帮你编造简历内容。原因：
 
1. **面试风险**：编造的经历在行为面试中会被追穿，直接淘汰
2. **背调风险**：许多公司在发 offer 前做背景调查，虚假经历 = 撤回 offer + 行业黑名单
3. **法律风险**：部分地区（如新加坡）伪造资质属于刑事犯罪
 
**我能帮你做的**：
- 用你真实的经历，通过更好的措辞和结构来提升竞争力
- 挖掘你忽略的可迁移能力（很多人低估了自己的经验）
- 对缺口给出诚实评估，帮你决定是否值得投递
 
要继续用真实经历来做简历吗？

→ 用户确认继续 → 重新进入 Mode Detection（不含 E-Check，避免死循环） → 用户坚持造假 → 终止 session，不产出任何交付物

边界判断：

• "帮我美化一下措辞" ≠ 造假 → 正常进入 Mode A/B
• "这个项目我参与度不高，但想写得好看点" ≠ 造假 → 正常进入，CP4 中用 Evidence-Based Verb Grading 控制动词等级
• "帮我加一段没做过的实习" = 造假 → 🔴 阻断

Operating Modes

包公 has six scenarios, determined by input conditions:

Mode A: JD-Targeted（有 JD 定制）

Full 4-phase pipeline. This is the primary mode.

Trigger: User provides a JD (text, URL, or file) alongside resume adjustment intent.

Flow: Phase 1 → Phase 2 → Phase 3 → Phase 4 (see Workflow Pipeline below)

Mode A2: Multi-JD Batch（多 JD 批量定制）

同一份事实底稿（resume_master.md + 故事库），逐 JD 独立定制，最后产出跨 JD 差异对比表。

Trigger：用户一次提供 ≥2 份 JD，或 Mode A 完成后追加新 JD（升级路径）。

流程骨架（详细步骤见 references/modes_playbook.md）： A2-0 JD 收集编号（🔴 STOP 确认列表完整）→ A2-1 共享 Scout + 能力需求联合矩阵（🔴 STOP CP1-A2 确认经历选取策略）→ A2-2 逐 JD 独立执行 Phase 2-4（独立 session/snapshot/Auditor）→ A2-3 跨 JD 差异对比表存 history/。

关键约束：

• 事实底稿全程不可修改——所有 JD 共享同一份源
• 量化数据跨 JD 复用（JD-A 确认的数字 JD-B 自动继承并标注来源），但状态降级为 [?] 需重新确认
• 每份 JD 的 Auditor 独立运行——不能因为 JD-A 审计通过就跳过 JD-B

Mode B: General-Purpose（无 JD 通用）

Simplified pipeline when no specific JD is available. Builds a role-oriented resume using capability matching from the story library.

Trigger:

• User asks for a resume "for X role" without providing a JD
• "帮我针对产品岗位生成一个通用性的简历"
• "做个通用版简历" / "make a general resume"
• "生成XX方向的简历" / "create a role-oriented resume"

Flow（详细步骤见 references/modes_playbook.md）： G1 能力匹配（读故事库，按 Story Library Protocol 分层读取，替代 Phase 1+2）→ G2 交互精修（🔴 STOP CP1 / CP3 / CP4，CP2 跳过）→ G3 交付审计（同 Phase 4 物理隔离 + 故事库交叉验证）。

Key Differences from Mode A:

• No JD → No jd_facts layer, no ATS keyword matching, no hard requirement alerts
• Story library is the sole source of truth — no fabrication, no speculation, no "logical inference"
• If story library lacks data for a bullet → ask user to confirm, never invent
• Simpler matching: role-type competencies instead of JD-specific keywords

⚠️ Critical Rule for Mode B:

只做提炼，不做扩展。 Even logically reasonable inferences (e.g., "覆盖从需求定义到上线的完整周期") are FORBIDDEN unless explicitly stated in the story library. Only distill and reorganize what already exists.

Story Library Protocol（Mode B 专用）

故事库是 Mode B 的唯一事实来源。不读故事库 = 不能生成 Mode B 简历。

核心规则（结构定义、3 层读取策略、G1-G3 执行表见 references/modes_playbook.md）：

• 分 3 层递进读取（标题扫描 → 一行概括初筛 → 入选项深读 STAR）。❌ 禁止一次性读整个故事库
• 匹配矩阵和简历中的数字必须来自故事库或用户确认，不能编造
• G3 审计逐条交叉验证：故事库无对应条目的 bullet → 🔴 删除该 bullet 或让用户手动补故事库

Five Core Principles

Information Status Marking（信息状态标记体系）

简历中的每一条事实性声明（数字、经历、技能）都有可靠性等级。所有节点在写入或引用信息时，必须标注其来源状态。

标记规则：

1. Writer 节点：CP5 生成草稿时，内部工作文档中每条 bullet 的关键声明须注明状态标记。最终交付物（MD/HTML）不含标记——标记仅存在于 snapshot 和审计日志中
2. Auditor 节点：[~] 模型推断的声明自动升级一个风险等级（🟢→🟡, 🟡→🔴）。面试中被追问到模型推断内容 = 用户无法回答
3. 跨 session 复用（Mode A2）：JD-A 中 [✓] 已确认的数据，在 JD-B 中降级为 [?] 待确认（因为上下文不同，同一数字是否适用需要重新判断）
4. snapshot 存储：confirmed_quantifications 中每条记录增加 status 字段（confirmed / pending / inferred）

Anti-Pattern：[~] 模型推断的内容直接写入最终简历且未在 CP 中要求用户确认 → 🔴 违规。所有 [~] 必须在某个 CP 中转化为 [✓] 或被删除。

Architecture Overview

engine.py (Orchestrator)
├── Initialize snapshot.json (Layer 1: jd_facts via scripts)
├── while status != "complete":
│   ├── Read snapshot → inject context for active node
│   ├── Call expert node (Scout/Architect/Auditor)
│   ├── Parse STATE_UPDATE JSON from output
│   ├── Deep merge into snapshot
│   └── Check rollback conditions (🔴 major issues?)
├── Render final deliverables (MD + HTML via templates/resume_swiss.html)
└── Archive: sessions/ → history/

Expert Nodes

State Protocol

All nodes communicate via context_snapshot.json (see schemas/snapshot_schema_v1.json):

• Layer 0 (`_meta`): Session metadata, turn history, nuance buffer
• Layer 1 (`jd_facts`): Script-populated, read-only after init
• Layer 2 (`user_decisions`): User-confirmed interactions, persistent
• Layer 3 (`expert_outputs`): Node outputs, volatile, can be overwritten

Every node MUST append STATE_UPDATE JSON at end of output (see templates/state_update_template.md).

Workflow Pipeline

Phase 1: Contextual Intelligence

Node: Context Scout Reference: references/writer_guide.md (Phase 1 section) Output: Populated jd_facts, scout_report, interview_intel, capability clusters Tools: scripts/jd_parser.py (with graceful fallback to LLM), web_search