This is the overall entry point for first use. The completion order is: environment and persistent source code → user-level skill linking → the target repository's harness-install → harness-ceo knowledge initialization and first real task. Between stages, the current Agent continues execution; the user is not required to send the prompt again.
Installing only local tools without initializing a project is also a legitimate user scope; in that case, deliver after the tools and skills are available, and do not arbitrarily pick a repository to write to. When the user specifies complete onboarding, you cannot declare completion after merely finishing the download.
0. Read first, then supplement necessary information
Check the current directory, the user-specified project, existing Harness source code and CLI, system type, Git, Node, npm, installed Agents and their skill directories. Bun is only used to run the Skills CLI, not as a replacement for the Node required by Harness. Installing the skill itself for the first time does not mean the Harness runtime is installed.
Reuse information the user has already given directly. Only consolidate and ask for information that is still missing and affects execution: the target repository, source code placement location (if there is no preference, you may suggest ~/.harness-anything-src), which installed Agents to integrate with, and the first task. Approval for repository identity, owner, and modifications to existing instructions is left to harness-install for the specific reviewable steps.
Record the actual source code, Node path, CLI entry point, and selected skill directory for this session in the installation handoff, pass explicit paths across tool calls, and do not rely on temporary shell variables persisting.
1. Obtain persistent source code and runtime environment
The current release method is to obtain the source code from https://github.com/FairladyZ625/harness-anything.git at main . This skill may first be installed by bunx skills add into a tool-managed copy; that copy contains only the skill and is not a runnable complete repository.
node --version
npm --version
git --version
Require that the source code package.json at engines is authoritative; the current requirement is Node 24+. If dependencies are missing, provide a system-appropriate installation method and complete it within existing authorization; when administrator operations or interactive installation are needed, wait for the corresponding step and continue with other independent preparation. Do not modify the global environment to bypass explicit approval.
Native dependencies may require build tools: on macOS check the command-line developer tools, on Linux check the C/C++ toolchain and Python, and on Windows check a build environment supported by the dependencies. When dependency installation fails, read the actual build errors; do not use --ignore-scripts to mask the failure until the daemon startup stage.
When there is no existing source code, replace <源码目录> with the chosen persistent directory:
git clone --depth 1 --branch main https://github.com/FairladyZ625/harness-anything.git "<源码目录>"
When a directory already exists, first check the remote, branch, and changes; do not overwrite a directory that is not this project, do not reset user changes, and do not pull the main branch directly in the development worktree. Only source installations with clear ownership, clean state, and suitability for updating go through the normal fast-forward update. When testing a candidate branch of this skill, explicitly record that branch; subsequent steps use the same candidate package, and do not secretly switch back to the main branch.
Source code cannot be placed in a temporary directory: skill linking and the daemon both depend on this persistent location afterward.
Execute in the source code directory:
npm ci --no-audit --no-fund
npm run build --workspace @harness-anything/daemon
node packages/cli/src/index.ts --version
node packages/cli/src/index.ts --help
The source CLI's daemon auto-start entry comes from the daemon package's bin (dist/index.js), so the daemon must be built first;--version / --help Success does not prove that the entry point exists. The current Git hooks will not build it for you. When the build fails, keep the error; do not report the download stage as ready.
At this stage, run the CLI from the TypeScript source entry point, to avoid treating ha from a stale PATH as this installation. Do not now try to install an npm package that has not yet been released as the distribution method for this process. When npm distribution is formally provided in the future, this stage should be replaced; two download recipes that drift from each other must not be kept long term.
2. Link the entire skill set to the selected Agent
Use the sole skill synchronization tool in the source. With no arguments, it handles only the source repository's own project directory; user-level installation must explicitly provide the target directory chosen by the user.
For example, when the user selects Codex and Claude Code, and no custom directory is configured:
node "<源码目录>/tools/sync-runtime-skills.mjs" \
--target-dir "$HOME/.codex/skills" \
--target-dir "$HOME/.claude/skills"
When Codex has a custom CODEX_HOME configured, use its skills subdirectory; when Claude Code has CLAUDE_CONFIG_DIR configured, likewise respect its directory. For other Agents, choose according to their actual configuration or the current Skills CLI's Agent directory table; do not guess directories, and do not install for all products just because a directory list exists.
The tool scans the source's skills/, links the entire skill set and their reference materials, and does not maintain a separate skill list. Linking from the same source can be run repeatedly; existing directories, links from other sources, and broken links from other sources are all reported as conflicts first, and are not automatically overwritten. Each user directory and source directory is a local installation surface, and is not written into the project ledger.
A bootstrap copy installed by the Skills CLI may have the same name as the source link target. First verify its source, content, and user customization: a copy that was just installed this time and has not been customized may, within the scope of this installation, be kept outside the skill discovery directory, and then replaced with the source link; for content that was not created this time, contains customizations, or has unclear ownership, present the conflict and the specific handling, then obtain confirmation. Do not delete the Skills CLI's shared storage, because other Agents may still reference it.
On Windows, if a directory symbolic link cannot be created, report the specific permission conditions and guide the user to enable it in a way supported by the host; do not silently switch to copying and then claim that a source link has been established.
Read back the real resolved paths and reference files of harness-download、harness-install、harness-ceo in each target, and confirm that they all point to the selected persistent source. If a host refresh is required for it to appear in the skill list, explain this, but the current Agent can still directly read the files to continue with subsequent stages.
3. Continue initializing the target repository
Read skills/harness-install/SKILL.mdfrom the same source installation, and pass to it the target repository, the absolute CLI source entry point, the discovered environment, and the information the user has already provided. Do not download another copy of the source, and do not require the user to open another task.
When connecting to an existing Fleet hub, directly follow the harness-install edge node route, and do not re-init just because the clone has no ledger. A brand-new local hub must first satisfy the identity prerequisites stated in that skill; a successful download does not mean initialization is already usable.
When there is no ledger and it is indeed a new hub, perform repository initialization. When a ledger already exists, first determine whether it is a currently usable workspace or an old generation that explicitly needs migration; do not re-initialize or migrate just because you see harness/ . Old-generation migration changes existing data; handle it according to the explicit scope and approval of the migration skill, and do not treat download authorization as migration authorization.
Downloading and linking are node-local actions; project initialization is an authoritative write to the hub. When multiple nodes bootstrap the same target repository at the same time, first verify hub registration and owner, and only an authorized coordinator initializes; other nodes connect to the existing workspace and do not each produce their own "authoritative" ledger.
4. Connect the main control and initialize knowledge
Once the repository is readable and writable, read the harness-ceo/SKILL.md and references/initialization.mdin the same installation, and map the user conventions, model matrix, issue records, and execution evidence locations. Reuse existing content; do not require filling in empty forms or testing all models first.
Start the main control process with the first real task specified by the user, sharing one task with the first-task acceptance of harness-install ; do not run two demos. For steps that genuinely require the user or other roles, such as identity confirmation, merging existing instructions, and independent review, wait after delivering the specific materials; do not fake approval or completion.
5. Delivery and continued use later
Deliver the source code location and version, repeatable CLI commands, skill links and the selected Agent, the target workspace and knowledge entry point, the real status of the first task, and the reasons for anything incomplete. Next time you can directly call harness-ceo; for another repository call harness-install, without downloading the tool again.
By default use node "<源码目录>/packages/cli/src/index.ts" .... Only when the user explicitly wants the command to enter PATH should you proceed according to the source code's current build entry point and explain what will be modified; do not silently perform a global npm install. A normal installation does not modify the test-only environment, and does not create a formal workspace in a temporary daemon root that will be lost once this session ends.
Before upgrading the source code, check in-flight executions and shared service ownership, and use the supported update path; after updating, sync the same skill links. The user knowledge matrix and issue records are in the project workspace, and source code updates must not overwrite them.
For installation directories and parameters, refer to Skills CLI；bunx ; for behavior, refer to Bun official documentation. For the first installation, confirm the location according to the current tool's actual response, and do not confuse project-level and user-level directories.