install-skills

install-skills

Step 1: Immediate execution of a complete CLI command

This is the most common and highest-priority scenario, judged before any planning, verification, or synchronization sections later in this file.

Only when the user message already provides a complete skills add / npx skills add command to be executed, confirmed, restated, or explained, and the command already includes the installation source,--skill or a specific skill name,-g、-y, and an explicit -a / --agent target, does this rule apply. At this point, perform only the following minimal checks; after the checks pass, immediately execute the original command according to the user's intent, or confirm or restate the command as-is.

The minimal checks include only:

• Whether the user's intent is to execute the command, or only to confirm, restate, or explain it.
• Whether the installation source points to a skills directory the user has confirmed as trusted; do not rewrite it on your own based on the current workspace directory or an unverified source. If the source is unclear, do not follow this rule and return to the regular installation planning and verification process.
• Whether quotation marks, placeholders, or obvious truncation are broken.
• Whether the target agent list comes from the user's command itself.

Before the original command has been executed or confirmed according to the user's semantics, it is forbidden to read DEFAULT_PLATFORMS, locate or call sync-local-global-agents-skills, take inventory of targets, or enter release, fallback, agent team, or a long plan. After the original command succeeds, simply review the installation summary for acceptance; only when the user additionally requests synchronization to a local agent platform, site cleanup, manifest inventory, directory-level synchronization, or verification of a new platform, enter the corresponding process below.

The subsequent "verified executable targets", "directory-level links", and DEFAULT_PLATFORMS all belong to directory-level link synchronization, i.e., the responsibility of sync-local-global-agents-skills ; they are unrelated to the CLI installation of skills add ... -a <agent> , and when this rule is hit, there is no need to read or execute them.

Task type quick reference

User request	Exit	Sections to read
Provide a complete skills add command	Execute directly according to user intent, check the summary for acceptance	Only "Step 1"
Inventory, planning, or incomplete installation command information	Provide planning or confirmation after the minimal checks	"Responsibility boundaries", "Scheduling and acceptance"
Uninstall or delete skills	skills remove + double acceptance	"Global skill uninstallation process"
Synchronize installed skills to the local platform	Schedule sync-local-global-agents-skills	From "verified executable targets" to "Scheduling and acceptance"
Troubleshoot or remove third-party contamination	Marker file detection + blacklist removal	"Kimi Desktop (Daimon) contamination troubleshooting and removal"

Responsibility boundaries

This skill is the inventory and scheduling entry point for skills; it does not provide installation scripts, nor does it maintain a second copy of skills. The canonical source directory is ~/.agents/skills。

• Responsible for installation planning for general skills, command confirmation, multi-agent synchronization target determination, and the synchronization scheduling loop after global installation.
• For verified directory-level link targets, the specific installation actions are handed over to sync-local-global-agents-skills。
• Unverified agents or project-level directories only record candidates and pre-verification items; do not fabricate independent skills directories, links, copies, or replacement directories based on impressions.

Global skill uninstall process

When the user requests deletion, uninstallation, or removal of a global skill, a group of skills, or requests that a certain type of skill no longer be discovered by multiple agent entry points, you must prioritize using skills remove. File system deletion can only handle confirmed remnants that the CLI cannot manage, and cannot replace formal uninstallation.

Standard order

1. First write the task contract: the skill or topic scope to be uninstalled, the agent entry points that must no longer display it, the acceptance pattern, and the restriction of "not using physical deletion as the primary path".
2. Use skills list -g --json, or the user-specified agent's skills list -g -a <agent...> --json, to inventory registered candidates.
3. When the user provides a product, vendor, or topic series, identify candidates simultaneously by name, alias, description, and user scope terms; do not match by only one prefix. List candidates before deletion; if retaining synonymous skills, you must explain the reason.
4. For registered targets, use skills remove -g -y <skill...>. Do not pass -a '*'by default; if the current CLI does not accept this wildcard, omit -a, and rely on the CLI's actual management scope and output.
5. After successful uninstallation, synchronize the verified platforms according to the instructions of the installed sync-local-global-agents-skills . The synchronizer is only responsible for post-uninstall distribution and link convergence, and does not replace skills remove。
6. Use the CLI registry and the actual directories for dual acceptance; if either side still has unexplained matches, you must not claim completion.

File system fallback boundaries

Only when all of the following conditions are met may file system remnants be checked or handled:

• skills remove -g -y <skill> explicitly reports that the target cannot be found, or the target is no longer in the skills list --json registry.
• The canonical source directory, verified synchronization targets, or user-specified agent directories still have target remnants.
• The confirmed remnant is a broken link, empty directory, or old directory not managed by the CLI, and its absolute path,LinkType and Target。
• The operation scope only includes that remnant item, and will not touch non-target content outside the canonical source directory.

For junctions or symlinks, only the link itself may be removed; do not recursively delete its target. If any of the directory responsibilities, link target, or impact scope is unclear, stop and explain the information to be confirmed to the user.

Uninstall acceptance

Determine the target pattern before starting uninstallation. Before completion, check at least the following two types of evidence:

$items = skills list -g --json | ConvertFrom-Json
$matches = @($items | Where-Object {
  $_.name -match '<pattern>' -or $_.path -match '<pattern>'
})
"MATCH_COUNT=$($matches.Count)"

• In the CLI registry, the target pattern's MATCH_COUNT is 0。
• ~/.agents/skills, from DEFAULT_PLATFORMS confirmed verified synchronization targets, and the agent skills directories the user explicitly requested to cover, the number of matches for the target pattern is all 0。

If retaining a synonymous or related skill, or if the remnant directory is not managed by the CLI, you must explain item by item its source, whether it is registered, and the reason for retention or subsequent handling.

Kimi Desktop (Daimon) contamination investigation and removal

Kimi Desktop's Daimon provider (kimi-daimon setup) writes built-in skills as fixed steps into the canonical source directory ~/.agents/skills. These skills are not installed by the skills CLI, the registry has no source record, they pollute the skill surface shared by all agents, and they are written again when Kimi Desktop updates or re-provisions.

Contamination detection

When discovering skills in the global skills directory that the user did not actively install, or during routine inventory, first check the marker file:~/.agents/skills/.daimon-managed-builtin-skills.json. The existence of the marker file is evidence of Kimi Desktop contamination; its skills array is the blacklist for this cleanup,sourceRoot points to the bundled skill source within the Kimi Desktop application.

Cleanup Procedure

1. Read the marker file's skills array as the blacklist; the blacklist is dynamic, and skill names or counts must not be hardcoded.
2. Validate the legitimacy of blacklist entries: only process names that conform to ^[a-z0-9][a-z0-9-]*$ ; report and skip the rest.
3. Collect evidence item by item before deletion:lstat confirm the type of each entry; if it is a symbolic link, remove only the link itself; if it is a real directory, compare its SKILL.md with sourceRoot to confirm ownership; if the contents do not match, record it as version drift, still handle it according to the blacklist, but report it truthfully.
4. Delete the directory corresponding to each blacklist entry, and finally delete the marker file itself; only after the marker file is deleted can contamination detection be reproduced.
5. Double acceptance:~/.agents/skills the blacklist directories remaining in 0, the marker file does not exist, and each agent entry no longer lists the corresponding skills.

Boundaries and Recurrence Warnings

• Only delete the skills named in the blacklist; skills with the same name installed by the user through skills add or other means must not be deleted by mistake. When the user needs skills with the same name from other vendors, reinstall them after deletion through the skills add procedure.
• Kimi Desktop updates or Daimon re-provisioning will write these built-in skills again and recreate the marker file; after each Kimi Desktop update, if you want to keep the global directory clean, re-execute this procedure.
• For the evidence chain, event timeline, and historical cleanup records, see references/kimi-desktop-daimon-contamination.md。

Verified Executable Targets

The following targets are readable snapshots excerpted from DEFAULT_PLATFORMS at the time this skill was published, and have been confirmed by sync-local-global-agents-skills to support establishing directory-level links from ~/.agents/skills . Before actual execution, you should still relocate the installed sync skill and read its DEFAULT_PLATFORMS：

This table only describes platform executable targets that establish directory-level links from ~/.agents/skills , and falls within the scope of responsibility of sync-local-global-agents-skills .Not applicable to skills add ... -a <agent> CLI installation semantics: CLI installation targets are natively supported by the skills CLI, regardless of whether they are in this table, and this table does not need to be verified.

Platform	Target Directory	Scheduling Policy
WorkBuddy	~/.workbuddy/skills	Hand over to sync-local-global-agents-skills
QoderWork	~/.qoderworkcn/skills	Hand over to sync-local-global-agents-skills
Kimi Work	~/AppData/Roaming/kimi-desktop/daimon-share/daimon/skills	Hand over to sync-local-global-agents-skills
CodeBuddy	~/.codebuddy/skills	Hand over to sync-local-global-agents-skills
Qoder	~/.qoder/skills	Hand over to sync-local-global-agents-skills

Qoder refers to Qoder IDE and the Qoder agent itself, and its dedicated skills directory is ~/.qoder/skills. It must not be confused with other similarly named directories on the same machine:~/.qoder-cli（Qoder CLI）、~/.qoder-cn（Qoder CN IDE）、~/.qoderwork and ~/.qoderworkcn(QoderWork / QoderWork CN, where ~/.qoderworkcn/skills is already listed separately as the QoderWork platform).

Ecosystem Entries and Candidates Pending Verification

Claude Code, Codex, Cursor, Antigravity, Trae, etc. usually read skills through the global skills directory or the skills CLI ecosystem. When an independent skills directory has not been confirmed in verified materials, it can only be regarded as a candidate pending verification, and links must not be created or directories copied based on it.

Before confirming a new target, at least verify:

1. Whether the agent reads ~/.agents/skills or has a public, stable independent skills root directory.
2. Whether the independent directory only assumes the responsibility of the skills root directory and is not mixed with configuration, cache, or other resources.
3. Whether the agent accepts directory-level symlinks or requires its own installation mechanism.

Project-level candidate directories

The following directories are project-level candidates, not default batch link targets:

Candidate directory	Handling principle
.agents/skills	First confirm project authorization and the current agent's read semantics.
.claude/skills	First confirm Claude Code's project-level discovery rules and existing content.
.agent/skills	First confirm the owning agent's directory semantics to avoid mistakenly taking over a mixed directory.

Project-level synchronization must not default to batch symlinking. Authorization, directory responsibilities, and scope of coverage must be confirmed per individual project and per individual agent before proceeding.

Directory-level link strategy

• The default and only synchronization strategy is symlinking (directory-level linking); copying the canonical source directory as a physical duplicate is prohibited. Only one physical copy may exist machine-wide.
• Use a directory-level link only when the target directory serves solely as the skills root directory.
• If the target does not exist, a link may be created; if it is already a correct link pointing to the canonical source directory, skip it.
• If the target is a real directory, back it up first, then replace it with a link.
• If the target is a link pointing to the wrong location, verify first, then rebuild it.
• If the target directory's responsibilities are uncertain, it contains mixed configuration, or link compatibility cannot be confirmed, do not replace it automatically; preserve the status quo and request further confirmation.
• Explanation of the expected form: once a directory-level link is established, the platform skills directory itself is a link; the entries seen when browsing are the real entries of the canonical source directory, which is a normal phenomenon of link traversal, not a physical copy, and it will not produce per-entry shortcut arrows. To determine whether an erroneous copy has occurred, use whether a file written at the link target appears immediately in the platform directory as the criterion.

Dispatch and acceptance

1. First distinguish whether this instance is installation, uninstallation, inventory, or directory-level synchronization. For uninstallation tasks, first complete the "global skill uninstallation process"; for installation and synchronization tasks, then confirm that the canonical source directory is ~/.agents/skills, and determine whether the target belongs to verified targets, candidates pending verification, or project-level candidates.
2. Verified targets invoke sync-local-global-agents-skills for execution; for the remaining targets, first complete directory semantics and compatibility verification.
3. Before execution, list the directories that will be created, skipped, backed up, or replaced; after execution, confirm that the target is a correct link and that the source directory has not been copied into multiple duplicates. For uninstallation scenarios, satisfy both the CLI registry and directory residue dual acceptance criteria.

For maintainers only: manifest sources and synchronization maintenance discipline

The authoritative source for verified executable targets is not the table in this document, but the sync-local-global-agents-skills inside the installed src/platforms.tsskill. When maintaining this skill, locate that skill directory via the current agent's skills registry, theskills list output, or the skill name in the current global skills root directory; after locating it successfully, read its src/platforms.ts, and use DEFAULT_PLATFORMS as the criterion to confirm the current executable targets. Do not treat repository source relative paths, the current project directory, or the relative path of the install-skills directory itself as stable runtime paths.

The "verified executable targets" table in this file is only an agent-facing readable summary, not a second independent source of truth. When maintaining the manifest, bidirectional synchronization must be observed:

• When adding, deleting, or renaming a verified executable target, first update the sync-local-global-agents-skills/src/platforms.ts of DEFAULT_PLATFORMS, then synchronously update the summary in this document.
• When only recording an agent pending verification, do not change DEFAULT_PLATFORMS; it may only be written in "Ecosystem Entry Points and Pending Verification Candidates," and the verification conditions must be retained.
• When the summary of this document is inconsistent with the DEFAULT_PLATFORMS in the located synchronization skill, DEFAULT_PLATFORMS shall prevail, and the document drift must be corrected immediately.
• When the installed sync-local-global-agents-skillscannot be located, or its src/platforms.ts does not exist, stop claiming "verified executable target" and first report the missing dependency; the table in this document may only serve as a release-time snapshot to assist troubleshooting and must not be used as an authoritative runtime checklist.