AI coding agents become more useful when they can follow a repeatable workflow, but copying prompt folders between projects creates a quiet maintenance problem. A skill can be duplicated, overwritten, or installed into the wrong agent directory without leaving much evidence.
This tutorial uses the open-source Tech Leads Club agent-skills repository and its @tech-leads-club/agent-skills CLI to install one skill into a project. The result is deliberately small: a pinned installation, a copied skill directory, and a lockfile that records what happened.
The commands below target the repository's stable v1.4.10 tag. That tag declares Node.js 24 or newer and the CLI package is MIT licensed. The repository also contains skill content with separate attribution requirements, so read the license notes before redistributing a skill.
Use the CLI's non-interactive form when you already know the skill and target agent:
npx --yes @tech-leads-club/agent-skills@1.4.10 install -s tlc-spec-driven -a cursor
From the project directory, this installs tlc-spec-driven as a copy under .cursor/skills and records the operation under .agents/.skill-lock.json. The exact result depends on the catalog and the agent configuration available when you run it.
You need:
v1.4.10 CLI package engine..cursor/ and .agents/.
The repository's README lists interactive and command-line workflows. This tutorial uses the command-line path because it is easier to reproduce in a clean directory and does not require raw terminal input.
Create a temporary project or open an existing project where the skill should live:
mkdir agent-skills-demo
cd agent-skills-demo
Run the pinned CLI command:
npx --yes @tech-leads-club/agent-skills@1.4.10 install -s tlc-spec-driven -a cursor
The -s option selects the skill by catalog name. The -a option selects the target agent. Because neither -g nor --global is supplied, the installation is local to the current project. The default method is copy, which makes the installed files visible in the project and avoids making the project depend on a local symlink.
On a successful run, the CLI reports that one skill was installed for Cursor. The repository's documented alternative is --symlink, but that changes the trust and portability model: the target depends on a link that can point somewhere outside the project. Use it only when that relationship is intentional.
Inspect the two artifacts created by the operation:
agent-skills-demo/
.agents/
.skill-lock.json
.cursor/
skills/
tlc-spec-driven/
SKILL.md
The exact skill may contain additional references/ or scripts/ directories. The important checks are that the skill directory is inside the selected agent directory and that the lockfile names the installed skill.
On Windows PowerShell, use:
Get-ChildItem -Force .cursor\skills\tlc-spec-driven
Get-Content .agents\.skill-lock.json
The lock entry should identify tlc-spec-driven, the cursor agent, the copy method, and a content hash. In my clean checkout, the command completed successfully and created those two project-local paths. Treat the hash as an integrity record for the installed content, not as proof that the skill is safe for every use.
You can also confirm the CLI version without entering the interactive interface:
npx --yes @tech-leads-club/agent-skills@1.4.10 --version
The expected version is 1.4.10. Pinning the version makes a future rerun explicit instead of silently selecting a newer package.
The project describes .agents/.skill-lock.json as the source of truth for installed skills. The security policy says the lockfile is validated with a strict schema, written through a backup and temporary file, and populated with content hashes. That gives a team a reviewable record of which catalog item was installed and which content was copied.
This is more useful than treating a skill directory as an opaque prompt bundle. A reviewer can inspect the SKILL.md files, compare the lock entry, and decide whether an update should be accepted. The CLI also keeps an audit log for install, update, and remove operations according to the project's security documentation.
The project documents several defenses, but they are boundaries to evaluate, not a universal security guarantee.
First, the CLI sanitizes names and checks resolved paths before reading, writing, or deleting files. Its security policy specifically describes path traversal and symlink checks. This reduces the risk that a skill name escapes the intended installation directory.
Second, the catalog is still content that can influence an AI agent. Read the skill before enabling it, especially when it references shell commands, network access, credentials, or external services. A readable file is auditable, but readability does not make every instruction trustworthy.
Third, the MCP server described by the project is a separate component. The security policy describes it as read-only, local over stdio, and limited to catalog files. Do not generalize those properties to every skill or to the CLI's installation behavior.
Finally, the repository says some skill files use CC-BY-4.0 while the software engine uses MIT. If you copy a skill into a distribution, check that skill's own attribution and license before publishing it.
The v1.4.10 package declares node >=24. An older runtime can fail before the CLI starts. Check node --version and install a supported Node.js release before debugging the catalog.
Catalog names are exact. Start with a documented name such as tlc-spec-driven, and avoid guessing a directory name from a display title. The interactive mode is useful when you need to browse the catalog, but it requires a real terminal with stdin support.
The list command renders an interactive interface. In a non-interactive process without raw stdin support, it can fail before showing the catalog. Use a terminal for browsing, or use the explicit install -s ... -a ... form when the skill and agent are already known.
Symlinks depend on filesystem permissions and path layout. The documented default is copy. Prefer the default for a portable project, then review the copied files as part of the change.
Do not assume the catalog is immutable forever. Pin the CLI version, inspect the lockfile, and review updates before accepting them. The repository's content hashing helps detect changes, but your review still determines whether the new skill belongs in the project.
No. The example omits -g, so it targets the current project. Add the global option only when you intentionally want the skill under the user's agent configuration.
Yes. The README documents multiple names after -s, for example agent-skills install -s aws-advisor coding-guidelines docs-writer. Keep the set small enough to review, and verify the resulting lockfile.
It provides catalog, integrity, and installation controls. Those controls do not replace human review of a skill's instructions, references, scripts, or license.
1.4.10 instead of using npx without a version?
An unpinned command can resolve a different release later. A versioned command keeps the documented behavior and the verification target aligned.
A local agent skill should be treated like a dependency with a filesystem destination, an integrity record, and a review boundary. Pin the CLI, install with an explicit skill and agent, inspect .cursor/skills and .agents/.skill-lock.json, and keep the default copy method unless a symlink is a deliberate choice.
What would you add to your team's review checklist before allowing a new agent skill into a repository?
AI assistance disclosure: I used AI assistance to organize and edit this tutorial. The commands, version, installation result, repository details, and security boundaries were checked against the v1.4.10 project sources and a clean local package installation.
Primary sources: v1.4.10 README, CLI package metadata, security policy, MIT license and attribution note, and the stable Git tag.