Apply Prefill

Fills the form. Never sends it.

HARD RULE

Never click Submit, Apply, Send, or Postuler. Ever.

This skill fills forms, prepares everything, and then stops with the completed form on screen for the human to review and send. No exceptions, even when asked to "just submit them all".

This protects against terms-of-service bans, corrupted CAPTCHAs, and burned relationships with schools and partners that took years to build. An auto-submit path was added to an earlier version of this system once and removed the following day. It stays removed.

Why halting matters more than filling

An agent that guesses on a form field is worse than no agent. A wrong self-assessed language level, a fabricated salary expectation, or a fuzzy-matched dropdown becomes a written claim on a real application, under a real person's name.

So this skill is built around the halts, not the fills.

Load first

• facts.md — identity, education, experience. Never invent a metric.
• profile.yml — target roles, work authorisation wording, comp expectations
• The human-voice skill — any free-text the human "writes" must sound like them
• The jd-analyser positioning brief for this specific role

Steps

1. Confirm the posting is live

Open the apply page in the user's real browser session, so their existing logins are used. A page with only a navbar and footer means the role is closed. Stop and mark it discarded.

2. Read the whole form before typing anything

Enumerate every field, its type, whether it is required, and what would satisfy it. Produce a plan. Show the plan before filling. A form read end-to-end first produces far fewer halts than one filled top to bottom.

3. Fill what you can answer from verified facts

Standard fields come from profile.yml: name, email, phone, location, work authorisation, languages, school. Attach the tailored CV built by cv-tailor.

Write screening answers and any motivation field in the human's voice, per human-voice Part 1. Surface every drafted answer to the user inline before typing it into the form.

4. Halt on anything you cannot answer honestly

These halts exist to prevent fabrication. Do not weaken them.

On a halt: stop, name the halt, say exactly what you need, and wait.

5. Stop and hand over

Leave the completed form on screen. Tell the user precisely what is filled, what is not, and what needs their input. They review. They send.

6. Log only after they confirm

Add the tracker row with status Applied only after the human confirms they sent it. Never mark something applied because the form was filled.

Credentials

Never create a credentials file. Use the user's existing logged-in browser profile. A YAML of portal passwords sitting in a project directory is a worse answer than typing a password once, and a far worse answer if that directory is ever committed.

If a persistent browser profile directory is used to keep sessions alive between runs, it must be in .gitignore before the first run, not after.

Honest limits

• Anti-bot protection on major boards can block automated fill entirely. Fall back to guiding the user click by click rather than forcing it.
• CAPTCHAs mean immediate hand-off. Do not attempt them.
• Quality beats volume. Five sharp applications beat fifty generic ones, and the part that converts is the fit narrative, which is the human's job.