<img src="banner.png" width="100%" alt="system-onboarding banner">

System Onboarding

Use this protocol to establish a new or rebuilt workstation for local-first agent work. It is a sequencing and verification guide, not an installer and not a source of credentials. Resolve product-specific instructions from each provider's current documentation before changing a live system.

Activation

Use for a new workstation, a reinstalled operating system, a replacement device, or a controlled recovery of one agent runtime. First identify the operating system, target runtime, owner, shared rule surface, and whether the request is a full rebuild or a bounded component repair. Do not assume that a configuration copied from one host is safe or supported on another.

Ordered workflow

1. Establish operating-system updates, Git, authenticated source control, Python and

the current supported Node.js LTS where needed.

1. Install only the requested agent runtimes through their supported installers and

complete their native login flows without placing tokens in project files.

1. Create local configuration roots and load an explicitly selected, canonical rule

surface. Merge templates; never overwrite existing local state blindly.

1. Install portable skills and MCP or plugin configuration only through their stated

deployment procedures. Treat each provider's configuration format as distinct.

1. Configure shared synchronization only after the local runtime works. Share

sanitized contracts and receipts, not credentials, full prompts, or machine-local paths.

1. Recreate a scheduler or automation only through its supported native surface.

Preserve prior state and leave new work disabled until its owner approves activation.

1. Run the appropriate post-install checks and write a local receipt that distinguishes

installation, configuration, scheduler registration and successful outcome.

Read only the matching reference for the target platform:

• overview for boundaries and data placement;
• Windows checklist for Windows;
• macOS checklist for macOS; and
• post-install for verification and recovery.

Boundaries

• Never publish credentials, recovery codes, private prompts, account identifiers, or

raw logs to a shared repository or synchronization folder.

• Keep virtual environments, dependency caches and large runtime artifacts out of

cloud-synchronized project folders.

• Do not make a copied configuration authoritative. The target host must discover and

read back its own supported state.

• Do not register a schedule merely because a task file exists. Native registration

and outcome evidence are separate requirements.

• When an existing host is being repaired, inventory its current state and locks before

changing any configuration.

Completion evidence

A complete onboarding receipt records the target operating system, selected runtimes, their verified versions, the canonical rule references loaded, the explicit skills or extensions deployed, unsupported capabilities, and any deferred user decisions. A successful command exit alone is not evidence that an application loaded its new configuration or that a scheduled task achieved its intended outcome.

Changelog

1.2.0 (2026-07-29)

• Ported the reusable onboarding sequence and platform references into the public

skills catalog after removing host-specific paths, account details and private operational material.