skills/autosync-ic-skills/SKILL.md
One-time installer that makes a Claude Code project keep its Internet Computer skills up to date automatically. Sets up a SessionStart hook plus a sync script so .claude/skills/ always mirrors the latest skills published at skills.internetcomputer.org. Use when a user wants to install, bootstrap, or enable "always-latest" Internet Computer / IC / ICP / Motoko skills in a project, or pastes the link to this skill. This is a one-time setup action, not ongoing IC knowledge — after it runs, the installed hook keeps skills current on every session. Do NOT use for IC coding questions themselves — this only configures auto-updating skills.
npx skillsauth add dfinity/icskills autosync-ic-skillsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill installs a small amount of project configuration so that every new
Claude Code session automatically downloads the latest Internet Computer skills
into .claude/skills/, where Claude discovers and triggers them natively.
It is a one-time installer. After you complete the steps below, the user never
needs this link again — the installed SessionStart hook does the work from then on.
.claude/sync-ic-skills.sh — a differential sync script that mirrors the live
skill index into .claude/skills/.SessionStart hook in .claude/settings.json that runs that script.The script is a differential mirror. It fetches the discovery index once and
compares each skill's published hash against a stored manifest, re-downloading only
the skills that actually changed (and pruning ones removed upstream). Unchanged skills
are skipped with no per-file downloads, and the script stays silent unless something
changed. If the server does not publish a hash for a skill, the script falls back to
re-downloading it every run, so it remains correct either way.
Adding a hook means a shell script will run automatically at the start of future sessions. Claude Code will ask the user to review and trust the new hook before it activates — this is expected and correct. Let the user know:
"I'm adding a
SessionStarthook that runs.claude/sync-ic-skills.sh. Claude Code will ask you to approve/trust it before it runs automatically. After that, your IC skills stay current on every session."
Do not attempt to bypass that approval.
curl, jq)The sync script needs curl (virtually always present) and jq (often not).
Before writing anything, check for them:
command -v curl >/dev/null 2>&1 && echo "curl: ok" || echo "curl: MISSING"
command -v jq >/dev/null 2>&1 && echo "jq: ok" || echo "jq: MISSING"
jq is missing, offer to install it (ask the user before running an install
command). Pick the right one for their platform:
brew install jqsudo apt-get update && sudo apt-get install -y jqsudo dnf install -y jqapk add jqsudo pacman -S --noconfirm jqwinget install jqlang.jqjq is absent), and they can install jq
later and the next session will sync.The script is published as a file alongside this skill, so you fetch it verbatim rather
than transcribing it (this guarantees byte-exact content). Create the .claude directory
and download it:
mkdir -p .claude
curl -fsSL https://skills.internetcomputer.org/.well-known/skills/autosync-ic-skills/scripts/sync-ic-skills.sh \
-o .claude/sync-ic-skills.sh
Do not hand-write or paraphrase the script — always fetch the published copy so the sync logic stays correct as it is updated upstream.
What the script does (for the user's awareness):
https://skills.internetcomputer.org/.well-known/skills/index.json once.hash against .claude/skills/.ic-managed.json
(a { "<skill>": "<hash>" } manifest of skills it manages) and re-downloads only the
skills whose hash changed or are new.added / updated / removed summary only when something changed;
otherwise it is silent.jq is missing, and falls back to re-downloading skills the server publishes no
hash for.Add a SessionStart hook to .claude/settings.json that runs the script.
.claude/settings.json does not exist, create it with the content below.SessionStart entry, and only if an equivalent
bash .claude/sync-ic-skills.sh command is not already present (do not create a
duplicate). Parse the existing JSON, insert into the hooks.SessionStart array,
and write it back; never blindly overwrite the file.The entry to ensure is present:
{
"hooks": {
"SessionStart": [
{
"hooks": [
{ "type": "command", "command": "bash .claude/sync-ic-skills.sh" }
]
}
]
}
}
Run the script immediately so the skills are available in this session without waiting for the next session start:
bash .claude/sync-ic-skills.sh
.claude/skills/ now contains skill directories (e.g. motoko,
asset-canister, internet-identity, …) each with a SKILL.md..claude/skills/.ic-managed.json maps each synced skill name to its hash.SessionStart hook is in
place, and that they'll be prompted to trust the hook before it auto-runs next
session. From then on, their IC skills refresh automatically every session..ic-managed.json are ever pruned.hash field in the
discovery index, so a normal session that touches nothing downloads only index.json
and exits silently. Skills are re-downloaded only when their hash changes. Migrating
from an older version of this script (whose manifest was a bare name array) is handled
automatically on the next run.bash .claude/sync-ic-skills.sh manually, or schedule it (e.g. via /loop or a
cron routine) — but the SessionStart hook covers the normal case.tools
Deploys an already-built Internet Computer project to a user's own cloud engine (an OpenCloud / control-panel engine, administered from a web console). Covers verifying the icp CLI, linking the user's console identity to the CLI with `icp identity link web`, defaulting the console origin to https://opencloud.org (overridable when the user signs in to a different console), obtaining the engine's subnet id (asking the user when it is unknown), running `icp deploy` against that subnet, and tagging the canisters with `__META_*` environment variables so the engine console shows a named app with labelled backend/frontend canisters. Use when a developer wants to ship an app to their cloud engine, mentions a cloud engine, OpenCloud, an engine subnet id, linking the icp CLI to an engine console, or giving a deployed app a name in the console. Do NOT use for a general mainnet deploy with no specific engine or subnet (use the icp-cli skill) or for writing canister code.
tools
Guides use of the icp command-line tool for building and deploying Internet Computer applications. Covers project configuration (icp.yaml), recipes, environments, canister lifecycle, and identity management. Use when building, deploying, or managing any IC project. Use when the user mentions icp, dfx, canister deployment, local network, or project setup. Do NOT use for canister-level programming patterns like access control, inter-canister calls, or stable memory — use domain-specific skills instead.
development
Deploy frontend assets to the IC. Covers certified assets, SPA routing with .ic-assets.json5, content encoding, and programmatic uploads. Use when hosting a frontend, deploying static files, or setting up SPA routing on IC. Do NOT use for canister-level code patterns or custom domain setup — use custom-domains instead.
development
Integrate Internet Identity authentication. Covers passkey and OpenID sign-in flows, delegation handling, and principal-per-app isolation. Use when adding sign-in, login, auth, passkeys, or Internet Identity to a frontend or canister. Do NOT use for wallet integration or ICRC signer flows — use wallet-integration instead.