coforce-apply CLAUDE.md

CoForce Apply

Skill-first job application agent. The canonical product is the shared skill set under .agents/skills/; .claude/skills is a project-local compatibility symlink to that same tree. Clone the repository and run Claude Code from the checkout—no global skill installation is required. The repo also contains the harness. AGENTS.md is a symlink to this file — one set of rules, two names, no drift.

• User data home: ~/.coforce/ by default — profile.json (schema canonical in the profile skill), config.json (intent + runtime config + consents, one flat object, .agents/lib/config.mjs; it replaced the overlapping preferences.json + apply-config.json pair and migrates them on first read), instructions.md, applications.json, screened.json, accounts.json, campaigns/, applications// archives, email-sync.json (mailbox-scan state, tracker skill). experience/, out/, and research/ (company-research cache, 30-day TTL, schema in the interview skill) are regenerable caches, not contract files. Resolution rule (shared via .agents/lib/data-home.mjs): $COFORCE_HOME env -> <checkout>/.coforce/ if present (private-fork mode — user's PRIVATE fork syncs data in-repo; setup verifies privacy first) -> ~/.coforce. Never commit user data to the public repo.
• ~/.coforce/instructions.md = standing user instructions (never-apply list, preferences). EVERY skill/action touching applications reads it first and treats it as overriding metadata.
• Skills own their runtime assets: tracker/scripts/board.mjs (kanban, serve/static), start/scripts/hunt.mjs (job discovery + dedup), tailor/assets/resume_template.tex. Keep skills self-contained — no repo-relative references from skill instructions (only harness is repo-dev-only and exempt).
• Data files are the contract BETWEEN skills: each schema is canonical in its owning SKILL.md (profile → profile skill, config → setup, applications.json → tracker, screened.json → start, campaign manifest → campaign, experience index → experience) and carries a schema version. applications.json holds applications the user is actually chasing, and status is the pipeline stage only — rejected means a company said no. A posting ruled out for fit never entered the pipeline and goes to screened.json (hunt.mjs screen/unscreen), so every consumer of applications.json stays correct without knowing screening exists. Skill playbooks program against schemas, never against another skill's code; .agents/lib/ holds shared low-level script utilities (e.g. the atomic JSON writer), and the console server may import sibling skill libs as glue.
• Two-module pipeline: Module 1 (supply) generates bullets JD-free from repo contexts and the user reviews them INTO profile.json (source+verifiedAt provenance) — the profile IS the verified pool. Module 2 (demand) follows a JD and strictly SELECTS verbatim bullets from that pool (campaign.mjs pool/select, out-of-pool ids rejected); rewording always goes back through Module 1's review gate. Bullet ids are content hashes — sha256(text)[:8], computed at read time (campaign-lib.mjs) and then persisted as evidenceIds in the campaign manifest. So a bullet's id is stable only while its text is byte-identical: never reformat, trim, re-wrap, or unicode-normalize description[].text in profile.json. Doing so silently detaches every already-matched job ("outside the verified pool").
• Onboarding: setup skill; operating cycle: start skill. Submission runs through the apply skill, the one operator, against docs/OPERATOR.md — the operator contract (inputs, COFORCE_STATUS events, confirmation-gate iron laws). Claude Code is the only implemented runtime; the console spawns it via tracker/scripts/agent-runner.mjs, the single adapter seam.