@fmlima4/artificial-intelligence

A global CLI that lets any developer interactively copy shared skills, prompts, agents, and MCP guides into a project so GitHub Copilot picks them up automatically.

The value is the content. The code only exists to make assets easy to discover and copy.

Global install

npm install -g @fmlima4/artificial-intelligence

Requires Node.js 22+. Install once per machine; use in any project.

Import assets into a project

Navigate to any project and run:

ai-library import

The CLI will:

1. Ask which kind of asset you want — skill, agent, prompt, or MCP guide.
2. Show a checkbox list of all available assets for that kind.
3. Copy the selected files into the correct .github/ subfolder of the current directory, with Copilot-ready frontmatter.
4. Skip any file that already exists (never overwrites).

Example session:

$ ai-library import
? What kind of asset do you want to import? Skill
? Select skills to copy into this project:
 ◉ review-node-service
 ◯ update-readme
 ◉ create-pr-description

  copied  .github/instructions/review-node-service.instructions.md
  copied  .github/instructions/create-pr-description.instructions.md

Done. 2 copied, 0 skipped.

Where files land

| Asset type | Destination | |---|---| | skill | .github/prompts/<name>.prompt.md | | mcp | .github/instructions/<name>.instructions.md | | prompt | .github/prompts/<name>.prompt.md | | agent | .github/prompts/<name>.prompt.md |

Files are copied with the correct Copilot frontmatter already set:

• skill / prompt → mode: ask (appears as a slash-command in chat)
• mcp → applyTo: "**" (VS Code applies the instruction automatically)
• prompt → mode: ask (appears as a slash-command in chat)
• agent → mode: agent (runs as an agentic prompt)

Commit the generated files. Copilot in VS Code picks them up from .github/ without any other setup.

Other CLI commands

# List available assets
ai-library list skills
ai-library list agents
ai-library list prompts
ai-library list mcps

# Print a single asset to stdout
ai-library show skill review-node-service
ai-library show agent backend-reviewer
ai-library show prompt code-review
ai-library show mcp postgres

The list and show commands are read-only and work without being inside a project.

Asset format

Every asset is a markdown file with optional YAML frontmatter:

---
name: update-readme
description: Update project README based on source code
tags:
  - documentation
---

Body of the asset, written as normal markdown.

• name — optional. Defaults to the filename (without .md).
• description — optional single line. Used in the Copilot frontmatter when copying.
• tags — optional, informational only.

Directory structure

@fmlima4/artificial-intelligence
├── skills/
│   ├── update-readme.md
│   ├── create-pr-description.md
│   └── review-node-service.md
├── agents/
│   ├── backend-reviewer.md
│   ├── security-reviewer.md
│   └── solution-architect.md
├── prompts/
│   ├── feature-design.md
│   ├── bug-investigation.md
│   └── code-review.md
├── mcps/
│   ├── aws.md
│   ├── github.md
│   └── postgres.md
├── src/
│   ├── cli.ts
│   ├── import.ts
│   ├── loader.ts
│   ├── paths.ts
│   └── types.ts
└── test/
    └── index.test.ts

Adding a new asset

1. Pick the right folder: skills/, agents/, prompts/, or mcps/.

2. Create a new file named <your-asset-name>.md (lowercase, kebab-case).

3. Add YAML frontmatter with at least name and description.

4. Write the body in plain markdown.

5. Run the tests:

   npm test

6. Open a PR. No code changes needed — the CLI picks up new files automatically.

Notes

• Install globally on a developer machine; run ai-library import inside any project.
• The CLI reads assets from the npm package directory at runtime, so do not bundle it with webpack/esbuild.
• There is intentionally no remote download, plugin system, or marketplace. Assets are versioned and shipped with the package.

Version and publish pipeline

This repository is configured for tag-driven publishing. The recommended flow uses Changesets; a manual flow with npm version is preserved as a fallback.

Before the first release

1. Create an npm publish token in npm.
2. Save it in GitHub as the repository secret NPM_TOKEN.
3. Confirm that .github/workflows/publish.yml is present and configured to publish on pushed v* tags.

Recommended flow with Changesets

1. Make your code changes on a feature branch.

2. Run npm run changeset and describe the change. This creates a file under .changeset/.

3. Commit the changeset file with your code and open a pull request.

4. After merging to main, run locally (or via a release workflow):

   npm run changeset:version

   This updates package.json, CHANGELOG.md and removes consumed changesets.

5. Commit those changes and create the matching tag:

   git add .
   git commit -m "Release v$(npm pkg get version | tr -d '\"')"
   git tag "v$(npm pkg get version | tr -d '\"')"
   git push
   git push --tags

6. The publish workflow validates that the tag matches package.json#version, runs the full check suite, runs npm audit signatures, and publishes to npm with provenance.

Legacy manual flow

1. Make the code changes for the release.

2. Update CHANGELOG.md with the user-visible changes included in the release.

3. Review what changed:

   git status
   git diff

4. Run the local validation commands:

   npm run check
   npm pack --dry-run

5. Commit the release changes:

   git add .
   git commit -m "Describe the change"

6. Bump the version with npm. Choose one of:

   npm run release:patch
   npm run release:minor
   npm run release:major

   These commands update package.json, create a Git commit, and create a Git tag like v0.1.1.

7. Push the branch and the new tag:

   git push
   git push origin v0.1.3

   If you prefer, you can also push all tags with:

   git push --tags

8. GitHub Actions runs .github/workflows/publish.yml when a v* tag is pushed.

9. The workflow installs dependencies with npm ci, validates the tag against package.json#version, runs the full check suite (typecheck, tests, build, publint, @arethetypeswrong/cli, npm audit signatures), and publishes to npm with provenance.

What changes in each version type

• patch: bug fixes and small compatible improvements, for example 0.1.2 -> 0.1.3
• minor: new backward-compatible features, for example 0.1.2 -> 0.2.0
• major: breaking changes, for example 0.1.2 -> 1.0.0

If npm version fails because of Git signing

If your Git configuration requires GPG or SSH signing and the machine cannot unlock the key, npm version may fail after updating package.json and package-lock.json.

In that case, complete the version step manually:

git add package.json package-lock.json
git -c commit.gpgsign=false commit -m "0.1.3"
git -c tag.gpgSign=false tag v0.1.3

After that, continue with the normal push step:

git push
git push origin v0.1.3

How to confirm the release worked

1. Open the Actions tab in GitHub.
2. Check that the Publish package workflow started from the pushed tag.
3. Confirm the workflow passed the Install dependencies, Build package, and Publish to npm steps.
4. Confirm the new version appears in npm.

If the publish fails

1. Read the GitHub Actions log to identify whether the failure happened in install, build, or publish.
2. Fix the problem in a new commit.
3. Release a new version number instead of trying to reuse the failed one if npm already published it.

Quick checklist for every release

git status
nano CHANGELOG.md
npm run build
npm pack --dry-run
git add .
git commit -m "Describe the change"
npm run release:patch
git push
git push origin v0.1.3

GitHub Actions setup

Before the first publish, add this repository secret in GitHub:

• NPM_TOKEN: an npm automation token with permission to publish this package

Because this is a scoped package, the workflow publishes with public access enabled.

The publish workflow currently uses Node.js 22 and publishes only when a tag matching v* is pushed.

License

MIT — see LICENSE.