---
name: initialize-academic-records
description: Guide requested first-time Academic Records CV/site setup or initial source reconciliation from a CV, an existing website or local project, or a fresh start. Stage the supported site/Word-CV starter and private CV candidate reconciliation. Use configure-academic-records for existing-project preferences, including a missing profile; do not restart routine maintenance.
---

Start with the user's goals and current assets, not technical commands. Use [initialization](../../references/initialization.md), reading its relevant branch progressively. Ask one question at a time using the host's supported question UI, with a single chat question as fallback. Reuse saved answers. Missing preferences for an existing records project belong in [configure-academic-records](../configure-academic-records/SKILL.md), without repeating CV import. An inaccessible or corrupt profile requires access/reviewed recovery, not a fresh initializer. Do not treat this skill as permission to alter an existing user's profile or project.

1. Discover existing setup before creating anything: project instructions, authorized local folder, existing website/repository and any selected private profile/route. Existing functioning projects go through configure-academic-records; incompatible sites get a concrete adapter assessment, not automatic replacement. Never create a second authority because a file is inaccessible.
2. For a new user, ask CV, website or both; then whether an existing website/local project should be retained. Inspect available tools before asking about missing R, an appropriate IDE/editor, Quarto or Git. GitHub is relevant to selected hosting, not mandatory for private CV work. For Git/GitHub beginners, follow [Git setup guidance](../../references/git-setup.md), using Happy Git as the linked learning guide and current official documentation for security, installation and hosting details. Explain optional integrations/extensions and alternatives before separately authorized installation/connection. Read current official setup instructions when giving version-specific installation guidance; do not guess commands or credentials.
3. Choose authorized private bootstrap storage outside any public/Git project. `scripts/initialize.py` supports resumable start/status/answer without a fake project root. Record actual responses/references and pending choices. The helper returns one next question, not a questionnaire to dump on the user. Unknown capability readiness stays pending even when the questionnaire is answered. It does not grant filesystem permission.
4. Confirm the user's actual current CV/import source and public/private exclusions. Before reading/copying patient-related material, follow the mandatory privacy warning/hold. Obtain private processing approval, then use extract to stage DOCX/PDF/TXT text. Keep contact information and extracted text private; never copy a raw CV into the public starter. No OCR or layout/entry completeness is claimed. Read the source or seek a better version if text extraction is insufficient. Headers, tables and PDF reading order need human/assistant inspection. A generated output is not a new import baseline for maintenance.
5. Use the bundled same-layout starter only after discussing the supported approach. stage-starter extracts to private staging, not the chosen project. Show the exact new-folder/file/configuration plan and obtain approval before any actual project creation/copy, source-code edits, rendering, Git or publication. Existing destinations are never replaced implicitly. The starter has empty YAML sequences, no personal records, and an anonymized Word formatting reference. Visual Word review/provenance verification remain prerequisites before claiming finished distribution or an approved layout for a new user. It is a tested starter prototype, not a general template converter.
6. Read extracted text and construct candidates with provenance plus a coverage ledger. Every segment must be classified as candidate/context/excluded/unresolved with an explanation; a segment is not necessarily a whole CV entry. Split/merge entries explicitly and review completeness against the original, including extraction limitations. The ledger helper checks structural coverage only. It neither invents facts nor verifies factual mapping, required record fields or public visibility. Publications require duplicate checks and the user's selected authority (Zotero when confirmed), not automatic BibTeX writes. Do not infer unlisted mentees/projects from coauthorship alone.
7. Show a readable candidate/import plan, unresolved facts and exclusions; obtain exact approval before real record imports through supported update/Zotero workflows. Establish the actual project/consumers and create the full private profile only when real boundaries and choices are known, using configure-academic-records/private-state safeguards. Preserve bootstrap history in that same private authority, not a competing config. Bootstrap files are not a profile and must not be passed to record helpers.
8. Stage and inspect requested outputs before a separately approved deployment. Reuse existing rendering preferences or ask the needed assistance question. If the user has no capable maintainer, offer a concrete maintainer request with required access and pending tasks. Finish setup with current preferences/source scopes, reminder/checklist flow and native task setup only when relevant and authorized, following scheduling.md. Never report a schedule or GitHub site created merely because preferences exist. Report exactly which stages ran and the next unresolved question.

No silent software/account/repository creation, connector connection, import, overwrite, rendering or publication. Preserve existing records, code and outputs unless the user explicitly authorizes their modification within the current setup scope. Missing optional setup does not block an otherwise ready maintenance capability.

For the user who selects “set it up for me,” follow [reviewed setup execution](../../references/setup-execution.md). Prepare one concrete scope covering the actual project/source files, required installation/account actions, exact R/Quarto commands, public Git paths, remote/branch and publication mode. The new-project helper can execute approved local creation/commands/Git commit and a gated push. Reuse the approved scope without repeated prompts for unchanged actions. Host-level installation, account/repository creation, permissions and authentication still use actual authorized tools. Publication can either wait for human preview approval or proceed after actual agent verification when that condition was explicitly authorized. Recommend human preview for new users; explain that the explicitly chosen agent-verified alternative can push without another confirmation and may publish before the user sees the preview. Reuse existing confirmed choices, and leave undecided publication pending. Never substitute a preference for approval or a successful command for an inspected output/deployment.

For a new personal website at USERNAME.github.io, follow [personal-site deployment](../../references/personal-site-deployment.md). Reuse the authenticated account, preserve existing sites, and verify Pages separately from push. Offer relevant available Posit skills as optional setup enhancements: Quarto authoring for website work; R development/testing skills only when corresponding work is selected. Inspect already installed skills and current trusted distribution/skill-installer guidance, explain purpose and source, and obtain authorization before installation. Do not require a whole skill bundle, silently install it, or treat optional skill absence as missing R/Quarto capability.

When a user wants additional pages or fewer visible sections, use [page adaptation](../../references/page-adaptation.md). Reuse existing YAML and page patterns, propose exact source/navigation changes, and preserve hidden records. This is coordinated website work subject to actual project permissions, not a routine YAML-write scope expansion.

For staged starter handoff, use stage-starter's project_source_root for source inspection and adaptation; metadata_folder (also exposed as legacy folder) is private operation history. Never copy that wrapper or its receipts into the project. See initialization.md for resumed and legacy receipts.

Before initial import approval, follow initialization.md's per-output coverage review: show a readable expected CV/website inclusion table with consumer evidence and pending/omitted items. Store optional output_coverage metadata outside each candidate's record. Have the user accept or defer omissions or separately approve a consumer change; a structurally complete ledger is not a complete CV/site. Recheck actual generated entries after authorized execution. Do not automatically add Word sections.

If publications are requested and Zotero is selected or under consideration, follow [first-time Zotero setup](../../references/zotero-initialization.md). Distinguish missing Desktop, stopped Desktop, missing integration, empty versus existing library, and optional account/sync. CV/PubMed candidate reconciliation can proceed privately while connection setup is pending. Reuse update-zotero-records for exact imports; verify scoped export/citation keys and actual consumers separately. Do not require an online account for local Desktop use or claim publication setup was tested merely because unrelated synthetic outputs rendered.

Before a new-project setup plan, show the [readiness report](../../references/readiness.md) for the selected goals, using actual saved/host runtime paths and R library. Summarize missing/blocked items in plain language and ask one next question. Do not install, modify settings or run project scripts from this check. Existing-project preferences still route to configure; installation/authentication and remote deployment require their actual separate workflows.

During the initial output interview, follow [optional CV PDF initialization](../../references/cv-pdf-initialization.md). Ask website users whether they want a public CV PDF and private-CV users whether they want Word only or Word plus PDF, one applicable question at a time. Reuse saved choices/deferrals. A yes requires coordinated privately staged generator/converter, privacy check, page, resource/navigation, styling and output/Git planning before exact setup approval. The bundled starter remains Word-only; do not claim the preference implements PDF conversion. Preserve existing projects and routine maintenance scope.