Skip to main content
A skill is a markdown file an assistant reads before you ask it anything. Without one, every conversation starts by re-explaining that backgrounds are raw material, that update_role overwrites, and that nothing goes on a resume Me cannot back. With one, that is already known. Three ship with every instance. Find them under Settings → Connections, where each comes two ways: the raw SKILL.md to drop into a folder, and a zip for the upload box in Claude’s apps, which wants a folder rather than a loose file.

Open Settings in your instance

The downloads are on the Connections tab, served by your own deployment — so what you install is byte for byte the copy it is running.

​
Where they go

~/.claude/skills/<name>/SKILL.md makes it available in every project. .claude/skills/<name>/SKILL.md inside a repository scopes it to that one.
Settings → Capabilities → Skills → upload the zip. The upload wants a folder rather than a loose file, which is exactly what the zip already is.
Paste the contents in at the start of a conversation. Less tidy, same effect. Some clients also support project-level instruction files — a skill’s body works there unchanged.

​
The three

​
hired — orientation

The one to install if you install only one. It is what an assistant reads before its first tool call rather than after its first mistake. It carries:
  • The four areas and which tool is the fastest way into each, plus the two things that cut across them — tags, and the archive that deleting sends things to.
  • The rule that matters most — never invent experience, employers, dates or metrics — with the specific failure it exists to prevent, which is quiet upgrading during tailoring rather than invention from nothing.
  • The replace-versus-append table. update_role, update_resume, update_company and update_contact all replace what you send; append_role_background adds, and so do the bulk tools. Getting this wrong silently deletes work, so it is written out as a table — the row that earns its place is the one saying “tag these nine as fintech” written as nine update_company calls strips the size and location off all nine.
  • The order of operations before writing anything: search Me, snapshot it for profile and dates, read the company record, then draft.
  • A reminder to read your notes and look for the ones marked GUARDRAIL, because your own standing rules override anything an assistant would otherwise infer. list_notes takes no arguments and returns all of them, so the picking-out happens on the way back.
  • What is reversible and what is not. Deleting a company, a person or an application archives it; everything else is gone when it goes. The two acts that really destroy something get read back to you before they run.
  • Saying what you did. You cannot see tool calls; a resume that changed without explanation is one you have to re-read from scratch.

​
tailor-a-resume — the tailoring craft

How to read a posting for what it actually rewards, and how to write a bullet that survives the follow-up question.
  • A posting has three layers and only one is worth optimising for: boilerplate, stated requirements, and the actual problem they are hiring someone to fix. The last one is usually in the first paragraph or in one oddly specific requirement.
  • Mine Me one requirement at a time, searching for the concept rather than the posting’s phrasing — a background says “cut the nightly job from 6h to 20m”, not “experience with performance optimisation”.
  • Three honest outcomes per requirement: strong evidence, weak evidence used as what it is, or nothing. All three are fine. Upgrading the second into the first is not.
  • The shape of a bullet that holds up: what changed, by how much, because of what you did. The number goes in the bullet, not the summary. One idea per bullet. Never a metric that is not in Me.

​
run-the-search — the day to day

Capturing a posting, logging what happened, researching a company, chasing follow-ups, and the weekly review.
  • Paste the whole posting into jobDescription. It is what a resume gets tailored against later, and postings vanish from the web the moment a role is filled.
  • Do not set nextFollowUpAt unless asked — follow-up dates schedule themselves from the stage.
  • Write the timeline entry the way you said it. “Recruiter said the team is six people and they want someone to own billing end to end” is worth more in three months than “had a call”.
  • Read before writing research. update_company replaces the notes field. Losing someone’s research by writing over it is the worst outcome available in the tool.
  • An ending is a stage, not a deletion. REJECTED and GHOSTED keep an application in the funnel, which is the only thing that can say where the search is losing people. Deleting takes it out — and archives it, so it is recoverable for thirty days.
  • Working a list rather than a record. Both CRM lists filter and sort the same way the list tools do, acts that cover a selection have their own add-and-remove tools, and export_csv hands back the whole list as a spreadsheet.
  • What not to do: do not log the same thing twice, do not move a stage nobody told you about, do not create a company record just to have one, and do not empty the archive without reading it back first.

​
Do you need them?

No. Everything works without them — the server sends its own briefing on connect, and every tool description carries its own warnings. The skills are the difference between an assistant that is told the rules once per connection and one that has read the manual. If your client does not support skills at all, the workflows cover the same ground from the other direction: they are step-by-step plans you invoke by name, and they arrive as ordinary tools in every client.