---
name: configure-academic-records
description: Configure or resume Academic Records preferences for an existing records project, locate or create its private profile, change review frequency or source selections, configure the host's recurring review task, or recover missing preferences. Does not import a CV or create a website.
---

Read [private preferences](../../references/preferences.md), [questions](../../references/questions.md), and [setup inventory](../../references/setup.md). For an existing records project, guide preference setup here when no profile exists. For requested first-time CV/site setup or initial source reconciliation, use [initialize-academic-records](../initialize-academic-records/SKILL.md). A missing profile alone does not authorize a new project or repeated CV import. Reuse confirmed answers, ask one question at a time, save each response as a pending answer under the preferences procedure, and resume unresolved settings on return. Combine confirmed answers into one exact profile proposal at a checkpoint; do not edit config.json after each answer. Verify private storage before claiming persistence.
A request to set up preferences authorizes that setup, not automatic record changes, connector access, project creation or schedule activation. Use host permission prompts when writing outside allowed roots. Unknown settings remain pending. Existing incompatible/corrupt profiles need a reviewed recovery path, not replacement with defaults.

For profile-apply, follow [approval evidence](../../references/approval-evidence.md): preserve the actual approving response/context privately, bind it to the exact proposed config bytes/destination and supply --approval-evidence FILE. Keep unknown approval-message times explicitly unknown. This does not authorize new preference choices or native task/route edits, and older receipts are not silently backfilled.

Use the [private-state helper](../../references/private-state.md) for profile creation/updates: propose the exact before/after with dated provenance, obtain actual approval according to the user's requirements, then apply with its proposal ID and approval reference. Unknown keys survive merge patches. Inspect status and use receipt-only verification after interruptions. Do not silently replace unavailable helper safeguards with ad-hoc JSON writes or treat helper flags as authentication. Native scheduler/route changes remain separate authorized operations.
For review setup, follow [routine and broader reviews](../../references/reviews.md). Save cadence separately from scheduler activation. Summarize what is configured and what remains pending, then proceed to the next necessary question. Do not stop at an unexplained missing-file error or repeat settled questions.

Read the [conditional questionnaire](../../references/questionnaire.md) and [scheduler binding](../../references/scheduling.md). Reconcile known legacy profiles/jobs before creating a new authority. Inspect and preserve development_plan_path/design_records. Ask only unresolved relevant user choices, maintain readiness per capability, and distinguish unsupported initializer work from supported preference setup.

When the user requests scheduled reviews, complete the [native task setup procedure](../../references/scheduling.md#configure-the-actual-host-task-during-setup): collect missing specifications, create/update the existing host task when authorized, verify read-back and persist its ID. Saving preferences alone is not completed scheduler setup. Initialization uses this same procedure when scheduled reviews are requested. Existing maintenance setup must not restart new-project initialization.

For check-ins, follow [check-in message and guided update conversation](../../references/check-in.md). Present source-derived suggestions first, then verified CV/site viewing links and linked categories for assistant-guided submissions. Setup must include that flow in tasks it creates. Respect regular-reminder preference and Nothing to add without repeated same-cycle nudges; host UI limitations require honest link/chat fallback.

Keep routine check-in progress separate from preferences using [runtime commands](../../references/private-state.md#routine-check-in-progress). Actual dispatch/closeout needs no new preference approval. Nonnull legacy cycle/completion history requires separately reviewed migration; absent/null history needs no profile edit before the first event.