job-post-builder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Job Post Builder

职位发布文案生成工具

Produces a complete hiring packet — job post, interview guide, and offer letter — from a brief conversation about the role. Optionally routes the offer letter to DocuSign via Claude in Chrome.

通过关于职位的简短对话，生成完整的招聘数据包——职位发布文案、面试指南和录用信。可通过Chrome中的Claude将录用信同步至DocuSign。

Quick start

快速上手

Invoke when a user says they need to hire someone or produce any hiring document. The skill walks a 6-phase workflow: gather context → research the market → write the job post → draft the interview guide → assemble the offer letter → (optionally) route to DocuSign.

Example trigger:

"We're hiring a senior product manager. Can you put together the job post and interview questions?"

当用户表示需要招聘人员或生成任何招聘文档时调用该skill。该skill遵循6阶段工作流：收集信息→调研市场→撰写职位发布文案→起草面试指南→整理录用信→（可选）同步至DocuSign。

触发示例：

"我们正在招聘高级产品经理，能否帮我整理职位发布文案和面试问题？"

Workflow

工作流

Gather role context — Ask for role title, responsibilities, qualifications, location, comp, interview process, and offer delivery preference (Word doc vs. DocuSign). Source: conversation / AskUserQuestion.
Research comparable posts — Search Google Drive / Desktop for existing JDs and templates; run web search for 3–5 live postings for this role. Sources: file MCP, web search.
Write the job post — Draft a market-informed job description using
```
references/job-post-structure.md
```
. Output:
```
[Role]-Job-Post.docx
```
via docx skill.
Draft interview guide + scoring rubric — Build a stage-by-stage guide using
```
references/interview-guide-structure.md
```
. Output:
```
[Role]-Interview-Guide.docx
```
via docx skill.
Assemble offer letter — Build offer letter with bracketed placeholders using
```
references/offer-letter-template.md
```
. Output:
```
[Role]-Offer-Letter.docx
```
via docx skill.
Route to DocuSign (if requested) — Use Claude in Chrome to navigate DocuSign, upload the offer letter, configure the envelope, and save a draft. Requires explicit user approval before the envelope is sent.

收集职位信息 — 询问职位名称、职责、任职要求、工作地点、薪酬、面试流程以及录用信交付偏好（Word文档或DocuSign）。信息来源：对话 / AskUserQuestion功能。
调研同类职位信息 — 搜索Google Drive/本地桌面中已有的职位描述（JD）和模板；通过网络搜索该职位的3–5个有效招聘信息。信息来源：文件MCP、网络搜索。
撰写职位发布文案 — 参考
```
references/job-post-structure.md
```
生成符合市场情况的职位描述。输出：通过docx skill生成
```
[Role]-Job-Post.docx
```
文件。
起草面试指南+评分标准 — 参考
```
references/interview-guide-structure.md
```
构建分阶段面试指南。输出：通过docx skill生成
```
[Role]-Interview-Guide.docx
```
文件。
整理录用信 — 参考
```
references/offer-letter-template.md
```
生成带有占位符的录用信。输出：通过docx skill生成
```
[Role]-Offer-Letter.docx
```
文件。
同步至DocuSign（若用户要求） — 使用Chrome中的Claude访问DocuSign，上传录用信，配置信封并保存草稿。发送信封前需获得用户明确批准。

Approval gates

审批规则

This skill performs externally-visible actions in Phase 6. The following rules apply:

Never send a DocuSign envelope without approval. Save the envelope as a draft and return the URL. The user must review and confirm before Claude clicks Send.
Never send the Gmail fallback email without approval. If the DocuSign browser flow fails, draft the fallback email and show it to the user before sending.
Never publish the job post. Produce the .docx file only. Posting to any job board is the user's responsibility.

Phase 6 will not advance past "Save as draft" without the user explicitly confirming they have reviewed the envelope and want it sent.

该skill在第6阶段会执行外部可见操作，需遵循以下规则：

未经批准不得发送DocuSign信封。保存为草稿并返回URL，用户必须审核确认后，Claude才能点击发送。
未经批准不得发送Gmail备选邮件。若DocuSign浏览器流程失败，需起草备选邮件并展示给用户，获得批准后再发送。
不得发布职位发布文案。仅生成.docx文件，发布至招聘平台的工作由用户自行完成。

若用户未明确确认已审核信封并同意发送，第6阶段不得推进至“发送”环节，仅停留在“保存为草稿”阶段。

Phase 1 — Understand the Role

阶段1 — 了解职位详情

Before researching or writing anything, gather enough context to do it well. Ask the user (via conversation or AskUserQuestion) for:

Role title — exact title they want to post
Team / function — who this person reports to and works with
Key responsibilities — 3–5 things this person will own day-to-day
Must-have qualifications — hard requirements (years of experience, specific skills, credentials)
Nice-to-have qualifications — preferred but not required
Location / remote policy — on-site, hybrid, or fully remote; location if relevant
Compensation range — salary band if they have one (flag that this needs HR/legal sign-off)
Existing JD or template? — ask if there's a prior version in Google Drive or on their Desktop to use as a starting point
Offer letter delivery preference — ask how they'd like the offer letter delivered:
- Send directly via DocuSign — skill opens DocuSign in Chrome, uploads the letter, sets up the envelope, and saves a draft for review before sending
- Just the Word doc — skill saves the offer letter as a .docx and stops there; the user handles routing themselves

Interview process — ask how their hiring process is structured:

How many rounds/stages are there?
Who conducts each stage? (e.g. recruiter, hiring manager, peer, skip-level, panel)
What is each stage meant to assess? (e.g. culture fit, technical depth, cross-functional collaboration)
Is there a take-home exercise or work sample at any stage?

This is critical — the interview guide will be organized by stage, and each stage gets its own question set. If the user doesn't know yet, suggest a sensible default based on the role level and company size, and confirm before proceeding.

Example default for a mid-senior IC role:

Stage	Interviewer	Focus
Phone screen	Recruiter	Communication, baseline fit, logistics
Hiring manager interview	HM	Scope, ownership, role-specific depth
Peer interview	Team member	Collaboration, working style
Skills/case exercise	Senior IC	Relevant technical or domain depth
Final / culture interview	Skip-level or exec	Values, long-term trajectory

Capture the delivery preference in Phase 1 so the right Phase 5/6 path is clear before any writing starts. If the user already indicated a preference (e.g. "send it to DocuSign"), extract it from their message rather than asking again.

If the user has already provided most of this in their message, extract it and confirm before moving on rather than asking redundant questions. One focused clarifying question is better than a long form.

在调研或撰写任何内容前，需收集足够的信息以确保质量。通过对话或AskUserQuestion功能询问用户：

职位名称 — 用户希望发布的准确职位名称
团队/职能 — 该职位的汇报对象及协作团队
核心职责 — 该职位日常需负责的3–5项核心工作
必备任职要求 — 硬性要求（工作年限、特定技能、资质证书）
优先任职要求 — 偏好但非必需的要求
工作地点/远程政策 — 现场办公、混合办公或完全远程；若相关需明确地点
薪酬范围 — 若用户有薪资区间需提供（需提示该内容需经HR/法务审批）
是否有现有职位描述或模板？ — 询问用户Google Drive或本地桌面中是否有可作为基础的过往版本
录用信交付偏好 — 询问用户希望的录用信交付方式：
- 直接通过DocuSign发送 — skill在Chrome中打开DocuSign，上传录用信，配置信封并保存草稿供审核，之后再发送
- 仅生成Word文档 — skill将录用信保存为.docx文件后即停止，由用户自行处理后续流程

面试流程 — 询问用户的招聘流程结构：

共有几轮/几个阶段？
每个阶段的面试官是谁？（例如：招聘专员、招聘经理、同事、上级领导、面试小组）
每个阶段的考察重点是什么？（例如：文化适配度、技术深度、跨职能协作能力）
是否有任何阶段包含实操任务或工作样本测试？

这一点至关重要——面试指南将按阶段划分，每个阶段对应专属问题集。若用户暂不明确，可根据职位级别和公司规模建议合理的默认流程，并在推进前获得用户确认。

中高级独立贡献者（IC）职位的默认流程示例：

阶段	面试官	考察重点
电话初面	招聘专员	沟通能力、基础匹配度、入职相关事宜
招聘经理面试	招聘经理	工作范围、职责权限、职位相关深度能力
同事面试	团队成员	协作能力、工作风格
技能/案例测试	资深员工	相关技术或领域深度能力
终面/文化面试	上级领导或高管	价值观契合度、长期发展潜力

在阶段1即明确交付偏好，以便在开始撰写前确定阶段5/6的正确流程。若用户已在消息中表明偏好（例如：“同步至DocuSign”），则直接从消息中提取，无需再次询问。

若用户已在消息中提供大部分信息，需先提取并确认，再推进流程，避免重复提问。一次聚焦的澄清提问好过冗长的表单。

Phase 2 — Research Comparable Posts

阶段2 — 调研同类职位信息

Good job posts are grounded in what the market actually says for this role. Do both of the following in parallel:

A. Check existing files first Search Google Drive and Desktop for prior JDs, offer letter templates, or interview guides the user may already have. Use file search tools with terms like the role title, "job description", "JD", "offer letter", "interview". If found, read them and use them as the baseline — preserving any existing language, structure, or requirements the user has established.

B. Web search for comparable posts Search for current job postings for this role at comparable companies. Good sources include LinkedIn, Greenhouse, Lever, Workday, and company career pages. Look for 3–5 real postings and note:

Common responsibilities listed for this role
Qualifications that appear consistently (these are table stakes)
How companies describe the role's impact/scope
Any language patterns that make postings feel compelling vs. generic

Use this research to pressure-test the user's requirements (are they missing something standard? asking for something unusual?) and to make the job post feel current and market-aware.

优质的职位发布文案需贴合市场实际情况。需同时完成以下两项工作：

A. 优先检查现有文件 搜索Google Drive和本地桌面中用户可能已有的过往职位描述、录用信模板或面试指南。使用文件搜索工具，关键词包括职位名称、“job description”、“JD”、“offer letter”、“interview”。若找到相关文件，需阅读并将其作为基础——保留用户已确立的任何现有表述、结构或要求。

B. 网络搜索同类职位信息 搜索同类公司当前发布的该职位招聘信息。优质来源包括LinkedIn、Greenhouse、Lever、Workday以及公司官网招聘页面。寻找3–5个真实招聘信息，并记录：

该职位的常见职责
频繁出现的任职要求（这些是必备条件）
公司如何描述该职位的影响力/工作范围
让招聘文案更具吸引力而非通用化的语言模式

利用调研结果验证用户的要求（是否遗漏了标准内容？是否要求了非常规内容？），并使职位发布文案符合当前市场情况。

Phase 3 — Write the Job Post

阶段3 — 撰写职位发布文案

Read

references/job-post-structure.md

for the full recommended structure and writing guidance.

If an existing job post or JD was found in Phase 2: Use it as the structural template — mirror its section names, tone, ordering, and any boilerplate the user has established (e.g. company description, benefits blurb, how-to-apply language). The user's format is the source of truth.

Compare it against

references/job-post-structure.md

and surface any missing components in a single question before writing:

"Your existing JD has a responsibilities section and requirements list, but I didn't see an opening hook or a description of what success looks like in year one. Want me to add those, or keep it to your current format?"

Only add the missing components if the user confirms.

If no existing job post was found: Build from scratch using

references/job-post-structure.md

as the full template.

Either way:

Lead with impact, not just tasks
Be honest about what's hard — candidates who self-select in are better fits
Use inclusive language; avoid jargon that implicitly filters for in-group candidates
Keep the required qualifications list tight — every line is a reason someone doesn't apply
If compensation isn't provided, omit the range rather than invent one

Save as

[Role]-Job-Post.docx

using the docx skill. Read

docx/SKILL.md

before generating the file.

阅读

references/job-post-structure.md

获取完整推荐结构和撰写指导。

若阶段2中找到现有职位发布文案或职位描述： 将其作为结构模板——镜像其章节名称、语气、顺序以及用户已确立的任何通用内容（例如：公司介绍、福利说明、申请方式说明）。用户的格式为最终标准。

将其与

references/job-post-structure.md

对比，在撰写前以单个问题的形式指出缺失的内容：

“您现有的职位描述包含职责部分和要求列表，但未包含开篇吸引点或入职第一年的成功标准描述。需要我补充这些内容，还是保持现有格式？”

仅在用户确认后补充缺失内容。

若未找到现有职位发布文案： 以

references/job-post-structure.md

为完整模板从头构建。

无论哪种情况：

以职位影响力开篇，而非仅罗列任务
如实说明工作难点——主动选择该职位的候选人更适配
使用包容性语言；避免使用隐含筛选内部候选人的行话
必备任职要求列表需精简——每一条都会成为候选人放弃申请的理由
若未提供薪酬信息，请勿编造范围，直接省略

使用docx skill保存为

[Role]-Job-Post.docx

文件。生成文件前请阅读

docx/SKILL.md

。

Phase 4 — Draft Interview Questions + Scoring Rubric

阶段4 — 起草面试问题+评分标准

Read

references/interview-guide-structure.md

for the full recommended format.

If an existing interview guide was found in Phase 2: Use the user's existing guide as the structural template — mirror its section names, ordering, and formatting conventions. The user's format is the source of truth; the reference file is a checklist, not an override.

After mapping the existing guide's sections against the reference, surface any components present in the reference but missing from the user's guide. Present these as a short, friendly question before writing — for example:

"Your existing guide has a question bank and scoring rubric, but I noticed it doesn't include an interview stage map or a debrief guide. Want me to add those, or keep it to your current structure?"

Only add the missing components if the user confirms. Don't silently expand their format without asking.

If no existing guide was found: Build the guide from scratch using

references/interview-guide-structure.md

as the full template. The reference defines the recommended sections, question format, rubric anchors, and debrief guidance — follow it completely.

Either way, organize the guide by interview stage using the process captured in Phase 1.

Structure the document so each stage is its own section:

Each stage gets its own section with the stage name and interviewer as the heading, followed by: the focus area this stage assesses, 4-6 behavioral questions specific to that focus, 2-3 follow-up probes per question, and a 1/3/5 scoring rubric with anchors for each competency the stage owns.

Key principles for multi-stage guides:

Each competency should be owned by one stage — avoid two interviewers asking the same thing. If there's overlap, assign different angles.
For panel interviews, split questions across panelists explicitly so each person knows what they're covering.
If there's a take-home exercise, include a structured debrief section for reviewing it — what to look for, how to score it, follow-up questions.
The debrief guide goes at the end, after all stage sections.
1/3/5 scoring anchors should be written for this specific role, not generic.

Save as

[Role]-Interview-Guide.docx

using the docx skill.

阅读

references/interview-guide-structure.md

获取完整推荐格式。

若阶段2中找到现有面试指南： 将用户现有的指南作为结构模板——镜像其章节名称、顺序和格式规范。用户的格式为最终标准；参考文件仅作为检查清单，不得覆盖用户格式。

将现有指南的章节与参考文件对比后，以简短友好的问题形式指出参考文件中有但用户指南缺失的内容，例如：

“您现有的指南包含问题库和评分标准，但未包含面试阶段地图或复盘指导。需要我补充这些内容，还是保持现有结构？”

仅在用户确认后补充缺失内容。请勿未经询问擅自扩展用户格式。

若未找到现有面试指南： 以

references/interview-guide-structure.md

为完整模板从头构建。参考文件定义了推荐章节、问题格式、评分标准锚点和复盘指导——需完全遵循。

无论哪种情况，需按照阶段1收集的面试流程按阶段组织指南。

文档结构需确保每个阶段为独立章节：

每个阶段的章节标题为阶段名称和面试官，随后包含：该阶段的考察重点、4-6个针对该重点的行为面试问题、每个问题对应的2-3个跟进追问，以及该阶段负责考察的每项能力对应的1/3/5分制评分标准及锚点。

多阶段指南的核心原则：

每项能力应由一个阶段负责考察——避免两位面试官重复提问同一内容。若有重叠，需分配不同的考察角度。
若为小组面试，需明确将问题分配给每位小组成员，确保每个人清楚自己的考察内容。
若包含实操任务，需添加结构化复盘部分——明确考察要点、评分方式及跟进问题。
复盘指导需放在所有阶段章节之后。
1/3/5分制评分标准锚点需针对该特定职位撰写，而非通用模板。

使用docx skill保存为

[Role]-Interview-Guide.docx

文件。

Phase 5 — Assemble the Offer Letter Template

阶段5 — 整理录用信模板

Read

references/offer-letter-template.md

for the full base template and field definitions.

If an existing offer letter or template was found in Phase 2: Use it as the structural template — preserve the user's formatting, clause ordering, signature blocks, and any legal language they've already established. Their version is the source of truth.

Compare it against

references/offer-letter-template.md

and surface any missing components in a single question before writing:

"Your existing offer letter has compensation and position details, but I noticed it doesn't include an at-will employment clause or a legal review disclaimer. Want me to add those, or keep it to your current format?"

Only add the missing components if the user confirms.

If no existing offer letter was found: Build from scratch using

references/offer-letter-template.md

as the full template.

Either way:

Use clearly marked
```
[BRACKETED]
```
placeholder fields for all candidate-specific values
Include: at-will clause (if applicable), contingency conditions, legal review disclaimer
Don't invent compensation figures — leave them as placeholders if not provided

Save as

[Role]-Offer-Letter.docx

using the docx skill.

Then branch based on the delivery preference captured in Phase 1:

If the user chose DocuSign → proceed to Phase 6
If the user chose Word doc only → skip Phase 6, deliver the .docx and close out

阅读

references/offer-letter-template.md

获取完整基础模板和字段定义。

若阶段2中找到现有录用信或模板： 将其作为结构模板——保留用户的格式、条款顺序、签名栏以及已确立的任何法律表述。用户的版本为最终标准。

将其与

references/offer-letter-template.md

对比，在撰写前以单个问题的形式指出缺失的内容：

“您现有的录用信包含薪酬和职位详情，但未包含自愿雇佣条款或法务审核声明。需要我补充这些内容，还是保持现有格式？”

仅在用户确认后补充缺失内容。

若未找到现有录用信： 以

references/offer-letter-template.md

为完整模板从头构建。

无论哪种情况：

所有候选人专属信息需使用清晰标记的
```
[BRACKETED]
```
占位符
需包含：自愿雇佣条款（如适用）、录用条件、法务审核声明
请勿编造薪酬数据——若未提供则保留为占位符

使用docx skill保存为

[Role]-Offer-Letter.docx

文件。

随后根据阶段1收集的交付偏好分支处理：

若用户选择DocuSign → 推进至阶段6
若用户选择仅生成Word文档 → 跳过阶段6，交付.docx文件后结束流程

Phase 6 — Route the Offer Letter Directly to DocuSign

阶段6 — 将录用信同步至DocuSign

Use Claude in Chrome to upload the offer letter into DocuSign and set up the envelope, so the user doesn't have to touch DocuSign manually.

Step-by-step browser flow:

Navigate to
```
https://app.docusign.com
```
— the user should already be logged in. If a login screen appears, pause and ask the user to log in, then continue.
Click "Start" → "Send an Envelope" (or the equivalent "New" / "Use a Template" button depending on the UI version).
Upload the offer letter: Click "Upload Documents" and upload the
```
[Role]-Offer-Letter.docx
```
file that was just created.
Add the signer: In the Recipients section, add the candidate as a signer. Ask the user for the candidate's name and email if not already provided. Set their role to "Signer".
Add the sender as a CC recipient if the user wants a copy (ask if unsure).

Set the subject line:

Offer of Employment — [Role Title] at [Company Name]

Add a message:

"Hi [Candidate First Name], we're thrilled to extend this offer and look forward to having you join the team. Please review and sign at your earliest convenience. Don't hesitate to reach out if you have any questions."
Place signature fields: On the document, place a Signature field and a Date Signed field on the candidate acceptance line at the bottom of the letter.
Save as draft — do NOT send. Return the envelope URL to the user so they can review before sending.

Tell the user:

"The DocuSign envelope has been set up with the offer letter and candidate details. Here's the draft link: [ENVELOPE URL]. Review the signature placement, then confirm here when you're ready to send."

Fallback: If DocuSign is unavailable or the browser flow fails at any step, fall back to the Gmail draft approach: draft an email via the Gmail MCP with the offer letter attached and a note to upload it to DocuSign manually. Show the draft to the user before sending.

使用Chrome中的Claude将录用信上传至DocuSign并配置信封，无需用户手动操作DocuSign。

浏览器分步流程：

访问
```
https://app.docusign.com
```
——用户应已登录。若出现登录界面，需暂停并请用户登录，之后继续。
点击**“Start”→“Send an Envelope”**（或根据UI版本选择等效的“New”/“Use a Template”按钮）。
上传录用信： 点击“Upload Documents”并上传刚生成的
```
[Role]-Offer-Letter.docx
```
文件。
添加签署人： 在收件人部分，添加候选人作为签署人。若未提供候选人姓名和邮箱，需询问用户。将其角色设置为“Signer”。
若用户需要副本，添加发送方为CC收件人（若不确定需询问用户）。

设置主题：

Offer of Employment — [Role Title] at [Company Name]

添加消息：

"Hi [Candidate First Name], we're thrilled to extend this offer and look forward to having you join the team. Please review and sign at your earliest convenience. Don't hesitate to reach out if you have any questions."
放置签名字段： 在文档中，在录用信底部的候选人接受栏放置签名字段和签署日期字段。
保存为草稿 — 请勿发送。将信封URL返回给用户，以便其审核后再发送。

告知用户：

“DocuSign信封已配置完成，包含录用信和候选人信息。以下是草稿链接：[ENVELOPE URL]。请审核签名位置，确认后告知我即可发送。”

备选方案： 若DocuSign不可用或浏览器流程在任何步骤失败， fallback至Gmail草稿方案：通过Gmail MCP起草邮件，附上录用信，并提示用户手动上传至DocuSign。发送前需将草稿展示给用户。

Delivering the Packet

交付数据包

Once all three files are created, present them together:

Present a summary listing the three deliverables by role title: the job post docx (ready to post), the interview guide docx (share with interviewers), and the offer letter docx (routed to DocuSign draft or ready for manual upload).

Remind the user:

The offer letter template needs legal review before use in any jurisdiction
Compensation ranges should be confirmed with HR before publishing the job post
This skill does not screen or rank applicants

生成所有三个文件后，统一交付：

按职位名称列出三个交付成果：职位发布文案docx（可直接发布）、面试指南docx（可分享给面试官）、录用信docx（已同步至DocuSign草稿或可手动上传）。

提醒用户：

录用信模板在任何地区使用前需经法务审核
薪酬范围在发布职位前需经HR确认
该skill不负责筛选或排名候选人

Reference Files

参考文件

Load these when reaching the relevant phase — don't load all upfront:

File	Load when
`references/job-post-structure.md`	Phase 3 — before writing the job post
`references/interview-guide-structure.md`	Phase 4 — before writing the interview guide
`references/offer-letter-template.md`	Phase 5 — before writing the offer letter
`references/gotchas.md`	Any phase — non-obvious edge cases
`references/examples/worked-example.md`	For reference on expected output shape

到达对应阶段时再加载这些文件——无需提前全部加载：

文件	加载时机
`references/job-post-structure.md`	阶段3 — 撰写职位发布文案前
`references/interview-guide-structure.md`	阶段4 — 撰写面试指南前
`references/offer-letter-template.md`	阶段5 — 撰写录用信前
`references/gotchas.md`	任何阶段 — 处理非明显边缘情况时
`references/examples/worked-example.md`	参考预期输出格式时

Tests

测试

See

tests/triggers.md

for must-trigger, must-NOT-trigger, and ambiguous routing cases.

See

tests/scenarios.md

for end-to-end scenario walkthroughs covering the happy path, missing connector, and approval gate flows.

请查看

tests/triggers.md

获取必须触发、必须不触发以及模糊路由的案例。

请查看

tests/scenarios.md

获取端到端场景演练，涵盖正常流程、缺失连接器以及审批规则流程。