agentleFS
Sign inStart free
manuelschurrmanuelschurr/professional-twin/skills/tailor-application/SKILL.md

tailor-application

Skill0 starsChanged 7 months agoMITView on GitHub

Use when the user wants to draft application materials (cover letter, CV emphasis, answers to specific application questions) for a specific job, using their professional twin repository as the source of truth. Commonly chained from review-job-offer.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. CodesWhat/careerrat★ 4same name
    2. mayankasthana/applymate★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository5 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 11 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before doing anything else, verify the cwd is a twin repo.

    line 20
  2. Distinctive:

    If any are missing, bail out:

    line 26
  3. Distinctive:

    Locate the job description: If passed in via subagent context, use that.

    line 34
  4. Very specific:

    Optionally save: Ask if the user wants the final drafts saved to applications/<company>-<role>/ in the twin repo.

    line 40
  5. Distinctive:

    Ask the user which of these they want:

    line 44
  6. Very specific:

    Read ALL .md files in the twin repo before drafting:

    line 53
  7. Distinctive:

    Do not selectively read. The repo is small.

    line 60
  8. Distinctive:

    Flag honesty problems: If the JD asks for something the user doesn't have, do not invent it.

    line 67
  9. Very specific:

    Reuse existing answers: If common-questions.md has a pre-existing answer that fits the role's question, adapt it rather than starting from …

    line 68
  10. Distinctive:

    Match the language of the JD: If the JD is in German, draft in German.

    line 69
  11. Distinctive:

    Don't dump everything at once and ask "what do you think?" — present one material, get feedback, refine, then move to the next.

    line 77
  12. Distinctive:

    After all materials are approved by the user, ask:

    line 81
  13. Very specific:

    Create applications/<company>-<role>/ if it doesn't exist

    line 86
  14. Distinctive:

    Commit if the repo has git

    line 89
  15. Distinctive:

    If no, end without writing anything.

    line 91

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Tailor Application

Overview

Draft tailored application materials for a specific job, using the professional twin repository as the source of truth. The output is a working draft the user can edit — not a final, polished submission.

When to use

  • The user has a specific job description and wants help writing application materials.
  • This skill was dispatched as a subagent by review-job-offer.
  • The user explicitly asks "tailor my application for this role."

Pre-flight check

Before doing anything else, verify the cwd is a twin repo. Check for:

  • A CLAUDE.md referencing professional-twin
  • A core-profile/ directory
  • An application-materials/ directory

If any are missing, bail out:

This doesn't look like a professional twin repository. cd into your twin repo before invoking tailor-application, or run setup to create one.

Checklist

Complete in order:

  1. Locate the job description. If passed in via subagent context, use that. If invoked standalone, ask the user for the JD (paste, file, or URL — do not auto-fetch).
  2. Locate the fit assessment (if passed in by review-job-offer). If absent, run a brief inline fit check first — read direction/target-roles-and-criteria.md and direction/industries-and-domains.md and confirm there's no dealbreaker. If there is, surface it and confirm with the user before continuing.
  3. Ask which materials to draft. See "Materials menu" below.
  4. Read the relevant twin files. See "Required reading" below.
  5. Draft each requested material. Present in sections, get user feedback after each.
  6. Iterate. Apply feedback. Re-present.
  7. Optionally save. Ask if the user wants the final drafts saved to applications/<company>-<role>/ in the twin repo. Default is no — only save if asked.

Materials menu

Ask the user which of these they want:

  • Cover letter — A drafted cover letter / motivation letter
  • CV emphasis — Notes on what to emphasize, reorder, or add to the base CV for this specific role (the actual CV file is the user's to edit; this skill produces a tailoring brief)
  • Answers to specific questions — Drafted answers for application form questions or screening prompts the user mentions
  • All of the above

Required reading

Read ALL .md files in the twin repo before drafting:

  • Everything in core-profile/ — positioning, career overview, skills, side projects
  • Everything in direction/ — the user's preferences, values, and criteria should inform framing even though they don't appear directly in materials
  • Everything in companies/ — not just "relevant" ones; adjacent experience from unexpected roles is often the strongest differentiator
  • Everything in application-materials/ — base CV, existing answers, writing voice, portfolio

Do not selectively read. The repo is small; the cost of reading everything is lower than the cost of missing a relevant fact.

Drafting principles

  • Be specific, not generic. Pull real examples and metrics from the repo. Generic claims ("strong leader," "results-driven") are forbidden — every claim must be backed by something concrete.
  • Match tone to the company. Startup vs. corporate, German vs. English, formal vs. casual. Read the JD for cues.
  • Don't oversell. The honest, well-framed version is more compelling than a hyped one.
  • Flag honesty problems. If the JD asks for something the user doesn't have, do not invent it. Tell the user, in the draft, where the honest answer is "I don't have that, but here's adjacent experience."
  • Reuse existing answers. If common-questions.md has a pre-existing answer that fits the role's question, adapt it rather than starting from scratch.
  • Match the language of the JD. If the JD is in German, draft in German. If English, English. Ask if unclear.

Output format

Present each requested material as its own section, with a heading. After each, ask:

Does this work, or want me to revise [X]?

Don't dump everything at once and ask "what do you think?" — present one material, get feedback, refine, then move to the next.

Saving (optional)

After all materials are approved by the user, ask:

Save these drafts to applications/<company>-<role>/ in the twin repo? (yes/no)

If yes:

  • Create applications/<company>-<role>/ if it doesn't exist
  • Save each material as a separate file (cover-letter.md, cv-emphasis.md, answers.md)
  • Also save the original JD as job-description.md for reference
  • Commit if the repo has git

If no, end without writing anything.

What this skill does NOT do

  • It does NOT modify any existing file in core-profile/, direction/, companies/, or application-materials/. Those are sources, not outputs.
  • It does NOT fetch URLs unless the user tells you to.
  • It does NOT invent experience or skills.
  • It does NOT submit applications. Drafting only.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free