360 Secure SkillHub
360 安全技能中心

tailor-cover-letter

该 Skill 接收可编辑的 Google Docs 求职信链接、配套简历和职位描述,直接修正拼写、语法、标点与表达流畅度,并在不改变原意的前提下调整措辞与段落顺序。涉及新增话题、经历或改变论证力度等实质性修改时,先列出建议并等待用户批准,避免编造或夸大资历。

tangentus
tangentus
热度 15.98
最近更新 2026-07-31 21:22:31
分类:效率依赖:MCP 服务应用场景:文案创作 / 校对润色

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add tailor-cover-letter
Metadata
name
tailor-cover-letter
description
Tailor and polish an existing cover letter in Google Docs for a specific role while keeping every claim consistent with the resume that will accompany it. Use when the user provides an editable Google Docs cover-letter link, the associated resume, and a role description as either pasted text or a direct link, and wants spelling, grammar, punctuation, style, clarity, persuasive focus, or organization improved without invented experience. Apply safe copyedits directly, but propose and obtain approval before adding topics, personal experiences, claims, or other substantive content.

Tailor Cover Letter

Improve a live Google Docs cover letter for a specific role. Make mechanical and meaning-preserving editorial corrections directly. Treat new facts, topics, examples, and material changes in emphasis as suggestions that require the user's approval before insertion.

Required inputs

Require all three:

  1. An editable Google Docs link to the cover letter.
  2. The resume that will accompany the cover letter, supplied as an accessible link, attachment, or pasted text.
  3. The role description, supplied as pasted text or a direct link.

Do not execute the editing workflow when any required input is absent or inaccessible. Ask only for the missing or inaccessible input. Do not substitute a generic job description, search snippet, inferred resume, or unrelated posting.

Confirm that the cover-letter link identifies a Google Doc and that write access is available before editing. If it cannot be opened or edited, stop and ask the user to correct access. Do not create a replacement document unless explicitly requested.

Evidence and honesty boundary

Treat the resume and the user's explicit factual confirmations as the only sources of candidate facts. Treat the role description as targeting guidance, not evidence that the candidate has a qualification.

Never invent, inflate, or imply unsupported:

  • employers, titles, dates, education, credentials, skills, responsibilities, scope, metrics, outcomes, or seniority;
  • personal motivations, relationships, hardships, anecdotes, values, or experiences;
  • familiarity, hands-on experience, ownership, or individual credit based only on adjacent or team experience;
  • enthusiasm for a company, product, mission, or industry that the user has not expressed.

Preserve meaningful qualifiers. If a potentially valuable claim is plausible but unsupported, ask the user to confirm it. If the user cannot confirm it, omit it.

Change boundary

Edit without confirmation

Directly make changes that preserve the existing meaning and factual scope:

  • correct spelling, grammar, punctuation, capitalization, and obvious typographical errors;
  • repair sentence fragments, agreement, tense, and parallel structure;
  • improve awkward syntax, transitions, concision, and readability without changing the claim;
  • remove accidental repetition and filler;
  • reorganize paragraphs or sentences only when the same ideas and emphasis remain intact;
  • normalize formatting to the document's established style.

When unsure whether a change is meaning-preserving, classify it as substantive and propose it instead.

Propose before editing

Do not make these changes until the user explicitly approves them:

  • add or remove a topic, anecdote, qualification, accomplishment, or personal experience;
  • introduce a new factual claim, metric, motivation, or degree of ownership;
  • materially strengthen, weaken, or redirect the letter's argument;
  • replace the opening, closing, or central narrative with a new approach;
  • remove content whose omission changes the candidate's intended message;
  • add role terminology that could imply unsupported proficiency;
  • make a substantial structural rewrite rather than a meaning-preserving reorganization.

Present suggestions as a short numbered list. For each suggestion, explain why it may help and identify the resume evidence that supports it, or ask a focused question needed to establish the experience honestly. Wait for approval before inserting any suggested content.

Workflow

1. Read all sources

Use the connected Google Docs or Google Drive capability to perform a trusted read of the cover letter and resume when supplied through Drive. Open the role-description link or analyze the pasted description.

Identify:

  • the role's core responsibilities, required qualifications, preferred qualifications, and repeated priorities;
  • the resume facts most relevant to those priorities;
  • the cover letter's current thesis, paragraph roles, tone, and factual claims.

Keep requirements separate from preferences. Do not overfit to generic company language.

2. Build an evidence map

For each important role priority and each material cover-letter claim, classify the resume evidence:

  • Supported: directly established by the resume or explicit user confirmation.
  • Adjacent: related experience exists, but the exact qualification or ownership is not established.
  • Unsupported: no evidence exists.

Use supported evidence accurately. Describe adjacent evidence without equating it to the target qualification. Flag unsupported existing claims to the user; do not silently rewrite them into a different factual claim.

3. Copyedit the live document

Apply the confirmation-free edits defined above while preserving:

  • the user's natural voice and level of formality;
  • names, dates, company names, links, salutations, and sign-off;
  • the document's native formatting, paragraph hierarchy, and intentional emphasis;
  • every supported factual distinction in the original.

Use fresh document state and revision controls when the connector supports them. Avoid broad text replacement when a precise edit is safer.

4. Develop suggestions

Assess whether the letter has:

  • a clear opening that names the role and establishes a truthful reason for interest;
  • a focused connection between role priorities and supported experience;
  • logical paragraph progression and clean transitions;
  • specific evidence rather than empty adjectives;
  • a concise closing with an appropriate next-step sentiment.

Suggest only high-value improvements. To surface honest personal material, ask narrow questions grounded in the role and resume, such as whether the user has a specific origin story, customer interaction, mentoring example, or motivation relevant to a named priority. Do not use the answer until the user approves the resulting wording or substantive edit.

5. Apply approved substantive edits

After explicit approval, update only the approved topics or passages. If the user's answer changes the factual basis, restate the proposed wording when needed before inserting it. Do not treat approval of one suggestion as approval of the entire list.

6. Verify and report

Re-read the live Google Doc after editing and verify:

  • spelling, grammar, punctuation, and formatting are clean;
  • each paragraph has a clear purpose and the progression is cohesive;
  • every factual claim is supported by the resume or explicit user confirmation;
  • role language does not overstate proficiency or ownership;
  • no unapproved substantive suggestion was inserted;
  • names, links, dates, greeting, and sign-off remain correct.

Report:

  • the direct copyedits and meaning-preserving improvements made;
  • the role priorities emphasized by existing supported content;
  • the numbered suggestions awaiting approval;
  • unsupported claims or factual questions requiring the user's attention.

Do not guarantee interviews, hiring outcomes, or claim the candidate is a perfect match.