Fernando Paladini 的 agent-skills 教程：如何從 GitHub 安裝並驗證可重用 AI 智能體技能

AI assistants become easier to trust when their repeated work is packaged as a small, reviewable skill instead of copied into every prompt. The challenge is that an installed skill can influence future work, while a poorly structured repository can quietly add stale instructions, unsafe examples, or credentials.

This tutorial shows a practical installation and validation path using Fernando Paladini's agent-skills repository. The repository contains reusable skills for technical work, including a DEV.to publishing skill, plus sanitized MCP configuration examples. We will install one skill locally, inspect what it contains, and run the repository's documented checks without treating the project as a trusted executable.

TL;DR

Clone the repository, copy the devto-publish-expert directory into your agent's skills directory, then validate the skill and the committed MCP examples. The result is a reusable local capability with a visible instruction file, deterministic checks, and no need to commit real credentials.

Prerequisites

You need:

• Git.
• Python 3.11 or newer for the repository's TOML-aware validation script.
• A local agent host that supports skills stored as directories with a SKILL.md entrypoint.
• A writable skills directory for your agent.

The repository is public, non-archived, non-forked, non-empty, and MIT licensed. At the time of writing, its default branch is main and it does not publish a tagged release. That means this tutorial uses the current documented main workflow, not a versioned package contract. Pin a commit in your own automation if you need repeatable installation.

Install one skill

The repository README documents a focused installation model: copy only the skill directory you need. That keeps unrelated skills and configuration examples out of the runtime search path.

On macOS or Linux:

git clone https://github.com/paladini/agent-skills.git
cp -R agent-skills/skills/devto-publish-expert ~/.codex/skills/

On Windows PowerShell:

git clone https://github.com/paladini/agent-skills.git
Copy-Item -Recurse agent-skills\skills\devto-publish-expert $env:USERPROFILE\.codex\skills\

The copied directory should contain SKILL.md, a references/ directory, and the supporting scripts used by the skill. Restart the agent host after installation when it only discovers skills during startup. If your host uses another skills directory, adapt the destination while preserving the skill's internal layout.

The important boundary is that installation copies instructions and helper files. It does not grant the skill permission to publish, modify repositories, or access secrets. Those permissions come from the host and from the workflow that invokes the skill.

Validate the skill structure

The repository README separates skill validation from article validation. Use the Agent Skills validator supplied by your host or skill tooling, then run the repository's bundled unit tests for the skill scripts.

python path/to/skill-creator/scripts/quick_validate.py skills/devto-publish-expert
python -m unittest discover -s skills/devto-publish-expert/scripts -p "test_*.py"

The first command is structural validation. It should answer questions such as whether the skill has the expected entrypoint and layout. The second command checks deterministic helper behavior. These are different signals: a directory can be shaped correctly while a helper script still contains a regression.

For a local installation, also inspect the entrypoint before using it:

sed -n '1,220p' skills/devto-publish-expert/SKILL.md

On PowerShell, the equivalent is:

Get-Content .\skills\devto-publish-expert\SKILL.md -TotalCount 220

Read the instructions as policy, not as an authority escalation. A skill can describe a safe workflow, but the host still needs to enforce the final boundary around external writes.

Check sanitized MCP examples

The same repository stores example MCP configurations for restoring publishing workflows. Examples are useful only when a reader can distinguish placeholders from live authentication data.

Run the repository's configuration checker from its root:

python scripts/validate_mcp_configs.py

The checker expects three JSON examples and three TOML examples. It parses both formats, verifies the expected top-level server objects, looks for likely credential patterns, and requires the placeholder REPLACE_WITH_LOCAL_SECRET in .env.example. A successful check does not prove that an external account is configured correctly. It proves that the committed examples have the expected shape and do not contain obvious secrets.

If you adapt an example, keep the real value outside Git. For example, use a local environment file that is ignored by the repository, or configure the connector through your desktop agent's secret store. Never replace the placeholder in a public example and commit the result.

Expected result and reproducible verification

After installation, verification should leave you with three independently checkable facts:

1. The skill directory is present in the host's skills location.
2. The structural and helper checks complete without errors.
3. The MCP example checker accepts the repository's committed configuration samples.

You can record the exact source revision used for installation:

git -C agent-skills rev-parse HEAD
git -C agent-skills status --short

The first command gives you a commit to pin in documentation or automation. The second confirms that your clone has no local changes before you reason about its contents. Because the repository currently documents its workflow on main and has no release tag, this revision check is especially important for repeatable setup.

Why this works

The useful design choice is the narrow installation boundary. A skill is a directory with a clear entrypoint and optional references and scripts. Copying one directory makes the dependency visible and reviewable. It also avoids treating every file in a larger repository as an instruction that must be loaded for every task.

The validation split is equally important. Structure, helper behavior, and configuration safety are separate concerns. Keeping them as separate checks makes failures easier to interpret and reduces the temptation to declare a skill safe because one broad command happened to pass.

Failure modes and security boundaries

If the host does not discover the copied skill, check the destination path and restart the host. Do not duplicate the same skill under several locations until discovery happens; duplicate installations can make it unclear which revision is active.

If Python cannot parse the MCP checker, use a supported Python version rather than weakening the script or skipping validation. The checker imports tomllib, so the documented runtime should provide that module.

If validation reports a possible credential, stop and inspect the exact file. Do not suppress the warning just to obtain a green run. Remove the secret, restore the documented placeholder, rotate any exposed credential, and then validate again.

This workflow is local and reviewable, but it is not a security guarantee. A skill can still contain incorrect instructions, and a host can still grant excessive permissions. Review SKILL.md, pin the source commit, minimize connector scopes, and keep publishing or repository writes behind an explicit workflow gate.

FAQ

Do I need to install every skill?

No. Copy only the directory required by your workflow. Smaller installation scope makes updates and review simpler.

Is the current main branch a stable release?

No release tag was present when this tutorial was checked. Treat main as the current documented source and pin a commit when reproducibility matters.

Can the MCP examples be used with real credentials?

They can be adapted locally, but the committed examples are templates. Keep real credentials in a secret store or ignored local configuration and never publish them.

Does structural validation prove that the skill is correct?

No. It checks expected shape and selected helper behavior. Human review is still required for claims, permissions, and external side effects.

Takeaway

A reusable AI skill is easiest to maintain when installation, source revision, structure, helper behavior, and credential hygiene are all visible. Start with one directory, validate each boundary separately, and pin the commit before making it part of a repeatable agent workflow.

What additional check would you require before allowing a locally installed skill to perform an external write?

AI assistance disclosure: I used an AI assistant to organize this tutorial and check its Markdown structure. The repository facts, commands, and security boundaries are based on the current public source and documented examples linked above.