career-engine-setup

Career Engine Onboarding

Registry: this pipeline is listed in the Pipeline Registry in skills/career-engine/SKILL.md. Actions owned by another pipeline's registry row are out of scope here — route to that pipeline instead of improvising.

This skill sets up the plugin for a new user. It builds the three reference files that all pipeline agents read before writing anything:

• 01-writing-rules.md — fabrication guards, attribution rules, framing constraints, contact details
• 02-professional-background.md — role facts, approved content, portfolio
• 03-framework.md — positioning, voice, methodology, domain narratives

Output target — the career-data skill, not in-plugin references (R-37). Setup builds these files into the user's external career-data skill, not into the plugin's references/. Author the data files (01/02/03, linkedin-profile.md, pipeline-preferences.json, delivered-letters/, and the user's .dotx) into a working career-data/ skill directory as you go. Installing that directory as a real skill is environment-specific and is the single step that most often goes wrong — follow references/career-data-skill-handoff.md (a.k.a. "Appendix A"): in Cowork, you cannot save a skill directly, so you emit a /skill-creator handoff prompt the user pastes into Chat (skills are shared between Chat and Cowork, so it lands in both); in Claude Code, you write ~/.claude/skills/career-data/ directly. The dedicated Build & install step at the end of this skill runs that handoff. Write the first backup export of career-data to the output folder. The plugin's in-plugin references/ stay as blank {{...}} templates — never personalized.

Placeholder resolution (single-build). Identity and config values are NOT substituted into the plugin's agent/skill/reference files — that would personalize the shared build. They live in career-data and agents resolve them at runtime: identity from career-data 01-writing-rules.md §8, output folder and CV template from the career-data config (see CLAUDE.md → Placeholder resolution). Every step below writes these values into career-data, never into plugin files.

How onboarding works: You send your existing career materials. The agent reads them and synthesizes 03-framework.md. You review it and respond — with feedback or approval. That response triggers a targeted interview that fills gaps and captures what the materials didn't fully show. Integration (Notion, output path) comes after.

Run order matters. Phase 0 (environment check) → Phase 1 (identity) → Phase 2 (content submission) → Phase 3 (synthesis) → Phase 4 (review and interview) → Phase 5 (integration) → Phase 6 (permissions) → Phase 7 (job-preferences) → Build & install career-data (the closing handoff step). Phases 5–7 can be deferred — the pipeline can run with Phases 1–4 complete. Whenever a setup session ends (all phases done, or the user stops), run the Build & install step so the work authored this session actually becomes an installed skill.

Onboarding can be paused and resumed. The Phase 4 interview in particular can take time. If the user needs to stop, they can resume later by running /career-engine:setup --phase 4. The state of 03-framework.md is preserved between sessions — sections already confirmed have no [DRAFT] or [REVIEW] markers; sections still needing work do. The pre-flight check uses this to report progress accurately.

---