Initialization should not depend on the first command

The request sounded like a missing feature: could initialization link the skills too? Plain co init already did. Someone who started with co init ./ or co create received an identity and project files, but missed the same coding agent integration. An existing private key also sent co setup past its own bootstrap. The implementation remembered that setup had once started rather than checking whether it had finished.

We considered adding another instruction to the getting-started guide: run co skills link after creating a project. That would leave every caller carrying knowledge about which initialization command they had used. Calling a separate installed co init from setup was already fragile: PATH could select an older version, and a module could retain paths from an earlier invocation.

The fix for issue #2675, available in 1.9.3rc22, shares the local preparation across all four entry points. The identity remains the machine's; a missing local profile is created; installed coding agents get the bundled skills and generated command index. Every run checks the pieces again. User skill directories, profile edits and instruction text outside the generated block survive. Project --force does not become permission to replace someone's own skill library.

Creating a default profile exposed a second problem. A later co setup --name ... --bio ... must actually customize it. Explicit fields now update those fields while preserving other profile metadata. Full profile replacement keeps its separate backup behavior. Discovery, copying, manifests and runtime skill lookup also resolve the current global directory together; preparing a library in one place is useless if the agent searches another.

Ten filesystem regressions failed against the original implementation, covering the entry points, selected roots, missing environment file and rerun behavior. The first shared implementation passed those cases. Wider checks caught a runtime lookup path still pointing at the default library. Independent review then caught manual skill listings lost during a profile refresh, healthy personal links being replaced, and an announcement preview selecting the wrong root. The corrected candidate merges metadata, keeps healthy personal links, and carries the selected root through both runtime loaders and publication previews. Invalid bundled YAML descriptions are now quoted, so a fresh imported library does not report those shipped skills as broken. These local preparation changes are published in the preview; connected services still need their own setup and acceptance checks.

The release handoff exposed the same drift in documentation. The inherited handwritten email page described reads and replies differently from the package's guide. Rendering the guide removed that duplicate, but made its copy boundaries visible: a read example also contained state changes and sends. We split those actions and the two send-budget alternatives, then kept the preview designation in the exported text as well as its web badge. A shared source helps only when the copied piece still carries the context a reader needs to act on it.

The boundary is local preparation. Importing a person's separate library remains an explicit setup operation. Account login, browser installation, publication and recurring work keep their own commands. We would revisit that boundary if one of those becomes a necessary prerequisite for the first useful local action. For now, a user should be able to choose the right starting command and receive the same foundation, then rerun it to repair what is missing.