Hire

Hire an AI Employee

An AI Employee is a folder of plain markdown instructions and a few small Node scripts that covers one business role. Each routine in the folder runs on a schedule, on the user's own machine, through the agent they already use, and each weekday it leaves a short brief. The folder is the product. There is no service, no account and no runtime behind it.

Your job here is narrow and the same every time: put one employee folder in the right place, prove it runs, and hand over the install prompt with the path filled in. The install prompt then does the setup, in a fresh session opened in that folder. You do not run the install prompt yourself, you do not register any scheduled job, and you send nothing anywhere.

If the user is asking a question rather than hiring (which one first, how the schedule works, how it improves), answer from sections 1 and 8, then offer to hire.

1. Pick the employee

If the request names one loosely, pick the obvious slug and say which you picked. If it names none, show this table and ask which. If they ask where to start:

• Launching or growing something: the GTM Engineer. It has the longest production record of the eight.
• Traffic is the bottleneck: the SEO/AEO Employee.
• A live site that breaks quietly: the Web Dev Employee.
• Already running two or more: add the Chief of Staff. It supervises the others and has nothing to read until they have run for a few days.

Hire one, let it run for a week, then hire the next. Each employee is its own folder with its own schedule, and their routine ids carry a prefix so they sit side by side without colliding.

2. Choose the folder

The user chooses. If they did not say, ask once and suggest D:\AgentOps\<slug> on Windows or ~/ai-employees/<slug> on macOS and Linux. One folder per employee.

Refuse any path under OneDrive, Dropbox, Google Drive or iCloud, including one that only resolves into it. On Windows the Desktop and Documents folders are often redirected into OneDrive, so check the resolved absolute path, not the spelling. Say why in one sentence: the routines write their state and run log mid run, and a sync client can corrupt exactly the file that tells tomorrow's run what already happened. Then ask for another folder.

If the folder exists and is not empty, stop. Never copy over an existing install: its strategy/, state/, ledgers and ## Corrections sections are the user's work. To update one, use the upgrade in section 8.

3. Copy it into place

Node 18 or newer is required. Check with node --version first; if it is missing or older, stop and point the user at https://nodejs.org and docs/PREREQUISITES.md.

Use the first route that works:

1. The installer bundled with this skill. When this skill loads you are told its base directory. The repository root is two levels up from it. If <base directory>/../../installer/cli.mjs and <base directory>/../../employees/<slug>/CONTRACT.md both exist, run, through the shell:

   node "<base directory>/../../installer/cli.mjs" hire <slug> --to "<folder>"

   It copies the kit from the bundled files with no network, refuses a synced or non empty folder, writes .installed.json (the record that lets a later upgrade tell the user's edits from ours), runs every kit script's self tests, checks the login, and prints the install prompt with the path filled in.

2. The published installer. Inside the plugin route 1 always works, so this is for the skill used on its own. Tell the user it will fetch the ai-employees package from npm and wait for a yes, then run npx ai-employees hire <slug> --to "<folder>". Same behaviour, fetched from npm.

3. Only if neither can run: tell the user you need to download https://github.com/markfulton/ai-employees/archive/refs/heads/main.zip and wait for a yes. Then extract only employees/<slug>/ into the folder, and tell the user that this route writes no .installed.json, so an upgrade later will treat every file as edited by them.

Never rename anything inside the kit. A routine's folder name, its YAML name and the name of its scheduled job are the same string, and a rename breaks the install.

4. Read the result

The installer prints three self test lines and a login line. Every self test must say ok. If one says FAIL, stop and point at docs/PREREQUISITES.md; nothing else is worth doing until it passes.

If the login line says NOT logged in, say so in one plain sentence: no scheduled run can work until the user signs in themselves, by running claude in a terminal and completing /login. Never try to sign in for them. unknown is normal on the desktop app, which has its own login.

5. Hand over

Keep the printed install prompt out of your reply unless the user asks for it; it is long, and the file already has it. Tell them three things:

1. Open a fresh session in that folder. In the Claude Code desktop app, open the folder and trust it. In a terminal, cd into it and run claude. The folder must be the working folder, because the routines, their permissions and their schedule are all resolved from it.
2. Say "install the <Employee name> from this folder". It reads INSTALL-PROMPT.md itself. Anything they want it to know up front, such as a channel that is off limits or a claim it must never make, goes in the optional line at the top of that file.
3. Let it work, about an hour. It researches the business from the user's own public pages instead of interviewing them, writes a strategy folder, seeds a work board, builds a local dashboard, proves one routine by hand, registers its own schedule, and stops once to show its first drafts. If the session ends early, a new session in the same folder with the same line picks up where it stopped.