Career & LinkedIn

Personal site on GitHub Pages

Goal: a fast, accessible personal site at https://<account>.github.io/, built from one content file the user can edit, published by GitHub Actions on every push to main. No framework and no npm dependencies, so it builds anywhere.

Works for anyone, in any field. Write the site in the user's language.

Hard rules

• The repository must be named exactly <account>.github.io, where <account> is the GitHub username (or organization) that owns it, in lowercase. Only that name publishes at the root (https://<account>.github.io/). Any other name publishes under a subpath (https://<account>.github.io/<repo>/), and a typo or a different owner means the root URL stays a 404. Each account has one such site.
• Never invent content. No made-up employers, dates, titles, metrics, projects or links. Missing facts become a visible placeholder like [year you started] and a question to the user.
• Personal data is public once pushed, including in git history. Ask before publishing a phone number, home address, personal email or birth date; prefer city/region, a contact link and LinkedIn. Never commit secrets or .env files.
• Run commands that create or change things on GitHub (create repo, enable Pages, push) only after showing the user what they will do, the first time. Everything else can go ahead.

Prerequisites

The GitHub CLI, installed and logged in. Check first and fix what fails:

gh --version                        # install: https://cli.github.com
gh auth status                      # logged in? which account? which scopes?
gh auth login -h github.com -p https -w          # if not logged in (browser flow)
gh auth refresh -h github.com -s workflow        # pushing .github/workflows/* needs the workflow scope
gh api user --jq .login             # the account name: the repo is <this>.github.io
git --version
node --version                      # 18+; only needed to run the build locally

If the site belongs to an organization, <account> is the organization name and the user needs permission to create repos in it (gh repo create <org>/<org>.github.io).

Step 1: check the starting point

ACCOUNT=$(gh api user --jq .login | tr '[:upper:]' '[:lower:]')
REPO="$ACCOUNT.github.io"
gh repo view "$ACCOUNT/$REPO" --json name,visibility,url 2>/dev/null || echo "repo does not exist yet"
gh api "repos/$ACCOUNT/$REPO/pages" 2>/dev/null || echo "Pages not enabled"

• Repo exists with a site in it: ask whether to replace it, keep it, or migrate its content. Never overwrite without a yes.
• Repo exists under a different name (e.g. portfolio, MyName.github.io under another account): offer to rename it (gh repo rename <account>.github.io -R <owner>/<old>) instead of creating a second one.
• On a free plan the repo must be public for Pages to work.

Step 2: gather content (ask only what's missing, in one message)

1. Name, role or headline, city/region (optional), and the site language.
2. Two or three sentences on what they do and for whom, then a longer "about" if they want one.
3. Experience or projects: title, organization, period, one or two lines each. A CV, LinkedIn export or existing page is the fastest source.
4. Links: GitHub (filled in automatically), LinkedIn, email or contact form, other profiles.
5. Look and feel in a few words, and anything to avoid. Without a preference, use the sober default in assets/style.css.

Put the answers in content/profile.json (shape in assets/profile.example.json). Show the user the JSON before building, and mark every placeholder.

Step 3: create the project

Recommended structure (same layout works for any static generator):

<account>.github.io/
  AGENTS.md                    instructions for any coding agent (template: assets/AGENTS.md)
  CLAUDE.md -> AGENTS.md       optional symlink, so Claude Code reads the same file
  README.md                    how to edit, build and publish
  content/profile.json         all text on the site
  build.mjs                    generator, Node only, no dependencies (assets/build.mjs)
  static/style.css             tokens on :root, dark mode via prefers-color-scheme
  .github/workflows/deploy.yml build + deploy to Pages (assets/deploy.yml)
  .gitignore                   dist/ and node_modules/

Copy the files from this skill's assets/ folder, then adapt them. scripts/ has the repo setup used in step 4. Keep AGENTS.md agent-neutral: it describes the project, the commands and the design rules, not one specific tool.

mkdir "$REPO" && cd "$REPO" && git init -b main
mkdir -p content static .github/workflows
# copy assets/: build.mjs, style.css -> static/, deploy.yml -> .github/workflows/,
#               AGENTS.md, profile.example.json -> content/profile.json
ln -s AGENTS.md CLAUDE.md          # optional
printf 'dist/\nnode_modules/\n' > .gitignore
node build.mjs && python3 -m http.server 4321 -d dist   # preview at http://localhost:4321

Optional extras, only if the user asks: a projects page, a blog (Markdown files rendered at build time), a custom domain, or a plugin/skill marketplace in the same repo (.claude-plugin/marketplace.json + plugins/<plugin>/, with the site listing them; validate with claude plugin validate . when Claude Code is installed).

Step 4: create the repository and enable Pages

Always create the repo with gh, never by typing the name in the web UI: scripts/create-site-repo.sh takes the name from the logged-in account, so it is always exactly <account>.github.io. Run it from the site folder, with --dry-run first and show the user the output:

bash <skill-dir>/scripts/create-site-repo.sh --dry-run      # checks gh, login, scopes; prints what it will do
bash <skill-dir>/scripts/create-site-repo.sh                # creates the public repo, enables Pages (Actions), sets origin
# organization site:       ... --org <org>
# repo already exists:     ... --existing   (only after checking with the user what's in it)

It stops if gh is missing or not logged in, warns when the token lacks the workflow scope, and refuses to touch an existing repo without --existing. The same steps by hand:

gh repo create "$ACCOUNT/$REPO" --public --description "Personal site"
gh api -X POST "repos/$ACCOUNT/$REPO/pages" -f build_type=workflow   # PUT if Pages already exists
git remote add origin "https://github.com/$ACCOUNT/$REPO.git"
gh api "repos/$ACCOUNT/$REPO/pages" --jq '{url: .html_url, source: .build_type}'

The Pages setting also lives in the web UI under Settings → Pages → Build and deployment → Source: GitHub Actions.

Step 5: deploy

git add -A && git commit -m "Personal site"
git push -u origin main
gh run watch "$(gh run list --workflow deploy.yml --limit 1 --json databaseId --jq '.[0].databaseId')" --exit-status
curl -sI "https://$REPO/" | head -1      # expect HTTP/2 200; the first deploy can take a minute or two

From then on, every push to main rebuilds and publishes. gh workflow run deploy.yml redeploys without a commit.

Step 6: check before calling it done

• Open the live URL, not only the local preview. Links work, no 404 on CSS or pages.
• Take screenshots at 1280px and 390px wide, light and dark mode. No horizontal scroll at 390px.
• Keyboard: Tab reaches every link with a visible focus ring. Text contrast meets WCAG AA in both themes.
• <title>, meta description and lang are set; images have alt.
• No placeholder like [year] left in the published page, unless the user chose to keep it for now (then list them).

Troubleshooting

Custom domain (optional)

gh api -X PUT "repos/$ACCOUNT/$REPO/pages" -f cname=www.example.com
# DNS: CNAME www -> <account>.github.io ; apex: A records to GitHub Pages IPs (see GitHub docs)
gh api -X PUT "repos/$ACCOUNT/$REPO/pages" -F https_enforced=true   # once the certificate is issued

Output

End with: the live URL, the repo URL, which file to edit for each kind of change (content/profile.json for text, static/style.css for look), the list of placeholders still open, and the one command to preview locally.

Job application

Goal: help the user spend applications where they have a real chance, and send applications that are accurate. Works for any field; base every judgment on the user's own CV and profile.

Hard rules

• Never invent facts. Any question whose answer depends on the user (language level, salary expectation, notice period, visa or work authorisation, whether they use the company's product, years with a tool, phone number) is asked, not guessed. Write open answers only from what the CV, profile or user said.
• Never submit without an explicit ok for that specific application. An application usually can't be edited after it's sent.
• Answers must be true even when a "yes" would score better. If the user hasn't used the product, say so honestly and write about what they know of it publicly.
• Don't create accounts, solve captchas or type passwords for the user.

Step 1: get the inputs

• The posting: a link (read it) or the pasted text. If the page doesn't load fully, scroll or ask for the text.
• The user's current CV and profile. If they were just updated, use the new versions.
• Anything not in the CV that the posting will ask about: target salary, language levels, availability, work model and contract preferences.

Step 2: fit evaluation (fixed format)

1. The role in one line: title, company, seniority, location / remote, employment type, salary if shown, and how many applicants if visible.
2. What matches: requirements the user meets, each tied to concrete evidence from their CV ("asks for 3+ years of X: you have 8").
3. Gaps: requirements the user doesn't meet or meets only partly. Separate must-haves from nice-to-haves.
4. Risks: what is most likely to stop the process. Common ones: a required language level above the user's; a different tool or platform ecosystem; a role that is a step down or a different job family (e.g. people management vs. individual contributor); a contract model the user may not want; on-site requirements.
5. Rough fit (e.g. strong / partial ~50% / weak) and a recommendation: apply, apply with caveats, or skip, with the reason in two sentences. When skipping, suggest what to look for at the same company instead, if it's a good employer for the user.

When the user sends several postings, rank them by fit.

Step 3: filling in the application

• Open the form and list every field and page before filling, so you can ask all the user-dependent questions in one message instead of one per page.
• Attach the user's current CV, never an old file stored on the site. Check which file is selected.
• Flag divergent data before using it: a phone or email that the site pre-filled differently from the CV, a language level in the CV that is lower than the posting requires. Ask which one is right.
• Open questions ("Why do you want to work here?", "Describe a relevant project"): tie 2–3 real facts from the user's experience to what the posting describes. Write in the language of the posting. Keep it short and specific, no flattery. Show the text to the user.
• Mandatory consent checkboxes (privacy, data processing) can be accepted when the user has asked to apply; mention that you did.
• External sites may block automation (captcha, bot checks, account creation). Say so as soon as it happens, leave the page open for the user to clear it, and continue after.

Step 4: before submitting

Show a summary of everything that will be sent: CV file, contact data, each answer (short open answers in full) and any choice you made on the user's behalf. Then ask "Can I submit?". After submitting, confirm that the site shows the application as sent.

End of every turn

If an application is left unfinished, end with a pending checklist per application: where it stopped (e.g. "page 6 of 12"), what's already filled, and exactly what the user needs to answer or do to continue.

LinkedIn profile for recruiters

Goal: a profile that a recruiter for the user's target role finds in search, understands in 10 seconds and wants to contact. Specific beats impressive. When a CV exists, profile and CV must tell the same story: recruiters who receive a referral open both and compare.

Works for any field and seniority. The examples below come from different areas on purpose; adapt them to the user's own field, market and language.

Hard rules

• Never invent facts. No made-up metrics, employers, titles, dates, tools, certifications or results. When a bullet needs a number the user didn't give, write a placeholder like [X% reduction in onboarding time] and ask for it. If the user has no number, write the bullet without one.
• No hype words ("top 1%", "ninja", "rockstar", "guru", "passionate about", "exceptional results", and their equivalents in other languages). Show it with specifics instead.
• Write in the language of the profile (default: the user's language). Keep the terms the user's market uses as-is, even when they're in English.
• Respect LinkedIn limits: headline 220 characters, About 2,600 characters (about the first 265 show before "see more"), experience description 2,000 characters.
• Don't add claims about leaving a job, layoffs or salary unless the user brings it up. When they do, use the transition mode below.
• Personal data the user shares (phone, email, dates) goes only into their own profile and CV.

Step 1: gather (ask only what's missing, in one message)

1. The current profile: headline, About, experience, education, certifications, skills. Pasted text, the LinkedIn PDF export, a browser session on the profile, or the CV all work. Ask for both CV and profile when the user has both.
2. Target role(s) and seniority, e.g. "Senior Product Designer", "Financial Controller", "Staff Backend Engineer".
3. Target market: country, remote/hybrid/on-site, employment type (permanent, contract, freelance), company types or specific companies.
4. Two or three real results per recent role, with numbers if they exist: revenue, cost, time saved, quality, customers or users served, team size, volume handled.
5. Recent work that isn't written anywhere yet. Ask directly: "What did you work on in the last 6–12 months that isn't in your CV or profile?" The newest work is often missing from both, and it's frequently the strongest differentiator.

Step 2: CV × LinkedIn alignment (when both exist)

Read both end to end before proposing any text. Build a divergence table:

Check at least: job titles, start and end dates of every role, employer names, education (institution, course, status: completed / incomplete / in progress), city, contact details, certifications and their validity.

• Ask which version is correct for each row, in one message. Don't pick a side silently.
• Use public evidence to flag a likely error, and ask about it: a post announcing a promotion, a certificate page showing an expiry date. Example: "Your post from May announces the promotion, but both versions say September. Is September right?"
• Flag what a recruiter would question: a role still shown as current after the user left; an expired certification listed as valid (show its period, e.g. "PMP (2019–2022)", or suggest renewing); incomplete education hidden instead of shown as incomplete; mixed date formats ("Sep 2021", "sep/21", "1 Sep 2021": use one format, MM/YYYY, no day).
• Show incomplete education honestly ("incomplete") next to a current course ("in progress"). It explains the user's background and reads better than a gap.
• End this step with two lists: what changes on LinkedIn, and what changes in the CV.

Step 3: recruiter test (diagnosis first)

Act as an experienced recruiter hiring for the target role (at the target company, if given). Answer honestly:

• Would you reach out? Yes / maybe / no, and why, in two sentences.
• The 5 biggest problems, ordered by impact. Typical ones: headline is only a job title; About opens with "I am a dedicated professional…"; experience lists duties instead of results; target keywords missing; recent work missing; no proof (Featured empty); a gap or title that needs context.
• What a recruiter would search for, and whether this profile appears.

Don't rewrite what already works. If a section of the current profile is stronger than what you'd draft, say so and keep it; propose only targeted edits. Show the diagnosis before rewriting, so the user can correct wrong assumptions.

Step 4: rewrite

Headline (10 variations). Formula: role + specialty + proof or domain + (optional) what you want next. Mix styles: keyword-dense for search, outcome-led, domain-led. Example shapes from different fields:

• Senior Product Designer | Design Systems & Accessibility | B2B SaaS
• Financial Controller | IFRS, Month-End Close & ERP Migrations | Retail
• Registered Nurse | ICU & Emergency Care | Clinical Training

If the user's market recruits in more than one language (e.g. English-speaking recruiters searching a non-English market), offer the recommended headline in both. Recommend one and say why.

About (under 2,000 characters).

• The first two lines must work alone in the preview: who you are for the target role plus the strongest proof.
• Then a short problem → approach → result arc that stays factual: the problem you solve for employers, how you approach it, 2–3 concrete results.
• If the user's most recent work is their differentiator, it gets its own paragraph near the top and the first item in any list.
• A line with core skills, tools or keywords, as prose or a short list.
• A clear call to action: what you're open to and how to reach you.

Experience (per role). Bullets in the XYZ shape, "Accomplished X, measured by Y, by doing Z", led by a strong verb (reduced, built, launched, led, negotiated, automated, trained). 3–5 bullets per recent role, 1–2 for older ones. Put the most recent and most relevant work first in the current role. Placeholders where a number is missing. A one-line role summary above the bullets for context (team, scale, domain). Several roles at one employer go under one company entry, so LinkedIn shows the progression.

Name the market category. Translate what the user describes into the terms recruiters search for, and use those terms in headline, About and skills. Examples:

• "I built the spreadsheet everyone now uses to plan stock" → demand planning, inventory forecasting.
• "I made every team request cloud/vendor spend through one process so we could bill it back" → cost governance, chargeback.
• "I train the new hires on the ward" → clinical education, preceptorship.

Skills and keywords. List the 25 keywords recruiters search for this role, mark each as present / missing in the profile, and say where to add the missing ones naturally (headline, About, a specific role, Skills section). Recommend the top 3 skills to pin and link new skills to the role where they were used.

LinkedIn only accepts skills from its own list, and in a non-English interface the names are often translated. Some terms don't exist at all. Suggest the closest accepted name, tell the user what didn't fit, and put the missing term in the About or experience text instead.

Featured (5 items). Proof over decoration: a portfolio, project or case study, an article or talk, a sanitised example of real work, certifications only if relevant, a personal site. For each: what it should contain and why it builds credibility for the target role.

Recommendations. Suggest asking 2–3 former managers, peers or clients now, while the work is fresh, starting with people who already refer the user.

Transition mode (the user left or is leaving a job)

Use only when the user says so. Then also cover:

• End the last role with its real end date. A role still marked current after a public departure confuses recruiters.
• Open to Work: "Recruiters only" by default. It puts the profile in recruiter searches without the public green frame; mention the public option and let the user choose. Ask about job titles, start date, employment types and work model. Contract or freelance roles are common in some fields and countries: ask whether to include them. LinkedIn only accepts job titles from its list, so say which ones didn't fit.
• One availability line at the end of the About: target roles and contact.
• A short post announcing availability: what happened in one neutral line, the journey and 2–3 highlights, the roles and work model wanted, thanks to people already referring. Ask before publishing; the user may prefer to post it themselves. If a colleague's post about the user is already circulating, the user's own post can come later and focus on their expertise instead.
• Activity helps visibility: suggest one post about the user's strongest recent work, with nothing confidential.

Step 5: updated CV in the ATS-friendly format (when asked, or after alignment)

When the user wants the CV to match the profile, apply every confirmed change from Step 2 and the rewritten content from Step 4, and lay it out in this format. It is built to be parsed by applicant tracking systems (ATS) and by LinkedIn's CV import. If the user's current CV uses a different layout (columns, sidebar, photo, icons, skill bars), say which parts an ATS may misread and convert it, unless the user explicitly asks to keep their design.

Layout

• One column, one page (two only for long careers). No photo, icons, tables, text boxes, columns or skill-level graphics. Plain bullets.
• Selectable text in reading order (check with a text extraction such as pdftotext: the output must read top to bottom in the same order as the page).
• Standard fonts, one accent colour at most, section titles set apart by a thin rule.

Structure, in this order (section names translated to the CV's language, e.g. Experiência Profissional / Formação / Competências):

1. Header: full name; the target role on the line below; one contact line with • separators: city, phone, email, LinkedIn URL (and a portfolio link if relevant).
2. Work Experience, most recent first. For each recent role:
   • Company, City on the left and MM/YYYY – MM/YYYY (or "Present") on the right.
   • One italic line describing the company: sector, size or scale (e.g. "Retail chain with 120 stores").
   • The job title in bold.
   • 3–4 bullets in the XYZ shape from Step 4, with numbers or placeholders.
   • Several titles at one employer: repeat the title line with its own dates and bullets under the same company.
   • Older or less relevant roles: one line each, Title, Company, City with dates on the right, no bullets.
3. Education: Institution, City with the date on the right; the degree on the line below. Show incomplete or in-progress courses as such.
4. Skills: grouped on labelled lines, e.g. Hard Skills: … and Techniques: … (or Tools:, Languages:), with the level in parentheses where it helps ("Spanish (Advanced)"). Use the keywords from Step 4.
5. Certifications only if relevant to the target role, one line each with issuer and date or validity period.

Leave out: a summary or objective paragraph (the target role under the name does that job), a soft-skills list, references, photo, date of birth and other personal data the role doesn't need.

File

• Keep the file small: LinkedIn accepts DOC, DOCX and PDF up to 5 MB, and some upload paths are much stricter. Standard PDF fonts (e.g. Helvetica) give a file of a few KB; embedded fonts can make it many times larger.
• Render a preview of each page and look at it before delivering.

Editing the profile directly (when browser tools are available)

The user logs in themselves. Never type or ask for a password.

• Show the final text of each section and get an ok before saving it. Edit one section at a time and re-read it after saving.
• Turn off the option to notify the network before saving each edit, and decline LinkedIn's offers to publish a post about the change. Nothing is published without an explicit request.
• Before any delete (an old CV, a position, a skill): re-read the page, confirm the exact name of the item next to the button you'll click, and list the items again afterwards. Element references go stale when the page changes, so look them up again right before each click.
• Report what changed at the end, including choices the user may want to revisit.

Step 6: outreach (optional, when asked)

Three short DM templates for recruiters or hiring managers at target companies, under 300 characters for connection notes and under about 600 for InMail:

• Reference something specific about the company or role.
• One line of proof that matches it.
• A low-friction ask (a 15-minute call, or "is this team hiring for X?").

No "hope you're doing well", no generic flattery.

Output format

1. CV × LinkedIn divergence table and questions (step 2), when both exist.
2. Diagnosis (step 3).
3. Headline options with the recommended one.
4. New About, ready to paste, with character count.
5. Experience rewrites per role, ready to paste.
6. Keyword table and where to put each missing keyword.
7. Featured plan.
8. Transition items (Open to Work, availability line, post), when in transition mode.
9. What to change in the CV, or the updated CV file in the Step 5 format.
10. Placeholders and open questions the user still needs to answer, as a checklist.
11. DMs, if requested.

After the user applies the changes, offer to re-run the recruiter test on the new version. To evaluate job postings or fill in applications, use the job-application skill.