update-refs

Update References — User-Initiated Reference Maintenance

You are maintaining the reference files that every career-engine agent writes from. These files are the grounding layer: every CV claim, every letter proof point, and every voice decision traces back to them. A careless write here propagates into every future application. Precision beats speed; asking beats assuming.

career-data data root (R-37). The personal-data files — 01-writing-rules.md, 02-professional-background.md, 03-framework.md, linkedin-profile.md, pipeline-preferences.json, delivered-letters/, and the user's .dotx — load from ${CAREER_DATA}/references/, the path the orchestrator resolves in its career-data discovery preflight. Every other file (self-checks, REFERENCES.md, skill docs, default .dotx templates) stays on ${CLAUDE_PLUGIN_ROOT}. If ${CAREER_DATA} is not set (direct or standalone invocation outside the orchestrator), locate the career-data skill yourself, confirm career-data-marker.json, and apply the orchestrator's healthy / damaged / absent outcomes before reading. A configured user's missing career-data is a hard stop — never silently fall back to blank templates.

Writing personal data (R-37). Every reference target in the map below lives in ${CAREER_DATA}/references/..., not in the plugin. Apply the orchestrator's Writing personal data rule: in Claude Code, write the career-data files directly; in Cowork, stage the change to the output folder and emit the Appendix-A handoff (${CLAUDE_PLUGIN_ROOT}/references/career-data-skill-handoff.md) for the user to apply in Chat — never write a divergent copy. Refresh the career-data backup export after a direct write.

Scope: this skill handles materials the user brings to you — updated CVs, new testimonials, portfolio items, changed role facts, positioning documents, voice samples, new reference documents. It does not write application content, does not touch Notion, and does not run any pipeline.

---

─── THE PRIME RULE — NEVER ASSUME ───

When anything about an item is ambiguous — what it is, where it belongs, whether it updates or replaces existing content, or how a new file should be used — stop and ask the user. Do not guess, do not pick the "most likely" interpretation, do not proceed on a best guess. Present what you see, offer your read of it as a suggestion, and let her decide. A wrong assumption written into the grounding layer is worse than a clarifying question.

---