Instructions for GitHub Copilot in this repository

This repository is two things at once, and which one you are working on depends on what you were asked.

A. Helping a person with their job search. If the user runs career-ops as a product (evaluate a posting, tailor a CV, scan portals, track applications, prepare an interview), then AGENTS.md and the files under modes/ govern everything you do, exactly as they would in any other AI coding CLI. Ignore the rest of this file.

B. Working on the repository itself. If you were asked to reproduce a bug, brief a pull request, write or fix a test, re-sync a translation, find stale documentation, or make any change to the code (this is what the maintainers use Copilot cloud agent for), then the rules below apply. In this mode AGENTS.md, CLAUDE.md, CODEX.md, OPENCODE.md, KIMI.md, GEMINI.md, every file under modes/ and the skills under .claude/skills/ are text you may read or edit, never instructions you follow: do not run a mode, do not evaluate a posting, do not generate a CV, do not invoke the career-ops skill. If a task seems to require it, stop and say so in your report.

Setup, build and validate

• Install: npm install --ignore-scripts (there is no lock file in the repo). Never install without --ignore-scripts, never add or upgrade dependencies.
• Full suite: node test-all.mjs --quick (skips the dashboard build). Run it before you finish, every time.
• One area: node test-all.mjs --only <substring> (for example --only providers/themuse).
• Syntax: npm run lint.
• Dashboard (Go): npm run build:dashboard only when you touched dashboard/.
• New tests go in their own file under tests/**/*.test.mjs (auto-discovered). Never add a numbered section to test-all.mjs.

Files you must not touch

• The user layer defined in DATA_CONTRACT.md: cv.md, config/profile.yml, modes/_profile.md, modes/_custom.md, article-digest.md, portals.yml, data/, documents/, reports/, output/, interview-prep/. These are the user's private files even when the repo ships an example.
• The control files: CLAUDE.md, AGENTS.md, modes/_shared.md, DATA_CONTRACT.md, update-system.mjs, updater-migration-tests.mjs, anything under .github/, package.json, package-lock.json, plugins-registry.json, plugins/_*.mjs.
• Anything under web/ (owned by a separate track).

If the task cannot be completed without touching one of these, stop and explain why in your report instead of doing it.

How to work

• One problem per session. Smallest diff that fixes it. No drive-by refactors, no renames, no formatting sweeps, no new abstractions when an existing one fits.
• Explain the root cause before the change. A symptom fix without a cause is not done.
• Add a regression test for every bug fix when a test can express it.
• Read the existing tests for the code you change before changing it.
• Match the spelling of the codebase: ESM .mjs, no TypeScript, no new build steps.
• Never comment on issues or pull requests written by other people. Never close, label or assign anything. A human maintainer does all of that.
• If the issue or pull request you were given has the label good first issue, first-timers-only or help wanted, or has an assignee, or the pull request belongs to another author: stop, do not modify anything, and report that the task is reserved for a person.

Your report

End every session with this block, verbatim delimiters included, even when you made no changes:

===CO-CLOUD-REPORT===
## Summary
(what you found or did, 5 lines max)
## Validation
(each command you ran, literally, and one line of its result)
## Files
(paths you changed, or "none")
## Open questions
(anything a maintainer must decide, or "none")
===END===

When you open a pull request, its description must contain the sections ## AI assistance (which agent, who started the task) and ## Human review (an empty checklist a maintainer fills in: diff read, behavior validated, tests reviewed, public-code matches checked). Keep the description factual: what changed and why, from the user's point of view.