Skill v1.0.1
currentAutomated scan96/100+2 new
version: "1.0.1" name: skill-index-updater description: "Add GitHub skill repos to the ASM index: clone, audit, eval, regenerate index, rebuild catalog, open PR. Use when given GitHub URLs to onboard. Don't use for authoring (skill-creator), improving (skill-auto-improver), or install (asm install)." license: MIT compatibility: Claude Code allowed-tools: Bash Read Write Edit Grep Glob WebFetch Agent effort: high metadata: version: 1.3.0 author: luongnv89
Skill Index Updater
You are adding new skill repository sources to the ASM (Agent Skill Manager) curated index. This is the pipeline that powers the skill catalog at https://luongnv.com/asm/ — every repo you add here becomes discoverable and installable by thousands of users.
When to Use
- The user pastes one or more GitHub URLs and asks to "add to the index", "index these", "onboard this repo"
- The user wants to refresh the catalog after upstream skill repos change
- A new skill collection is ready to ship to the ASM website catalog
If the user wants to author a skill from scratch, send them to skill-creator. If they want to improve a single existing skill, use skill-auto-improver. If they only want to install one skill, use asm install.
Example
User: add github.com/anthropics/skills to the indexSkill output:Step 1: Parsed 1 URL → anthropics/skills (NEW)Step 2: Discovered 14 SKILL.md filesStep 3: Audit OK on 14/14, eval scores 71–94Step 6–8: data/skill-index-resources.json + data/skill-index/anthropics_skills.json updated, catalog rebuiltStep 10: PR #312 opened — feat(index): add anthropics/skills (14 skills)
Repo Sync Before Edits (mandatory)
Before modifying any files, pull the latest remote branch:
branch="$(git rev-parse --abbrev-ref HEAD)"git fetch origingit pull --rebase origin "$branch"
If the working tree is dirty: stash, sync, then pop. If origin is missing or conflicts occur: stop and ask the user before continuing.
Input
The user provides one or more GitHub repository URLs. These can be in various formats:
https://github.com/owner/repogithub.com/owner/repogithub:owner/repoowner/repo(shorthand)
Normalize all inputs to extract owner and repo.
Pipeline
Follow these steps in order. Each step has a verification check — do not proceed to the next step if verification fails.
Step 1: Parse and Validate Input URLs
For each URL provided:
- Extract
ownerandrepofrom the URL - Verify the repository exists by checking
https://api.github.com/repos/{owner}/{repo} - Check if the repo is already in
data/skill-index-resources.json— if so, mark it for update instead of add
Output a summary table:
| # | Owner/Repo | Status | Notes ||---|---------------------|----------|--------------------------|| 1 | owner/repo | NEW | Will be added || 2 | other/repo | EXISTS | Will be re-indexed || 3 | bad/repo | INVALID | 404 - repo not found |
If ALL repos are invalid, stop and tell the user.
Step 2: Discover Skills in Each Repository
For each valid repository, clone it to a temp directory and scan for SKILL.md files (up to 5 levels deep). This is what the ASM tool does internally, and we replicate the logic here:
# Clone to tempTEMP_DIR=$(mktemp -d)git clone --depth 1 "https://github.com/{owner}/{repo}.git" "$TEMP_DIR/{repo}"# Find SKILL.md files (max 5 levels deep, matching ASM's discoverSkills)find "$TEMP_DIR/{repo}" -maxdepth 5 -name "SKILL.md" -type f
For each discovered SKILL.md, parse the YAML frontmatter to extract:
name(required)description(required)version(defaults to "0.0.0")licensecreatorcompatibilityallowed-tools/allowedTools
Report how many skills were found per repo. If a repo has zero SKILL.md files, flag it and ask the user whether to still include it (it might have skills added later).
Step 3: Audit and Evaluate Discovered Skills
For each discovered skill, perform two checks — a lightweight audit and a quality evaluation using asm eval. Both run against the temp clone from Step 2; do not re-clone.
3a. Lightweight audit
- Frontmatter completeness: Does it have at minimum
nameanddescription? - Content check: Does the SKILL.md have meaningful instruction content (not just frontmatter)?
- Security scan: Check for suspicious patterns in the skill files:
- Shell execution (
exec,spawn,child_process,bash -c) - Network access (
curl,wget,fetch(,axios) - Credential patterns (
API_KEY=,SECRET_KEY=,PASSWORD=) - Obfuscation (
atob(, base64 encoded strings, hex escape sequences)
This is a lightweight check — the full security audit runs when users install individual skills via asm install. The goal here is to catch obvious red flags before adding a repo to the curated index.
3b. Quality evaluation with asm eval
Run asm eval on each discovered skill directory and capture the JSON report. This gives reviewers a quality signal (structure, description, prompt engineering, safety, testability, naming) before the repo lands in the index, so they can spot obvious quality issues early:
asm eval "$TEMP_DIR/{repo}/{relPath}" --json
The JSON report contains overallScore (0-100), a letter grade (A/B/C/D/F), and a categories[] array with per-category scores. You do not need to re-run eval during indexing — npm run preindex (Step 7) invokes the evaluator via the ingester and writes evalSummary + tokenCount into data/skill-index/{owner}_{repo}.json automatically. The explicit run here is for pre-commit visibility only.
Combined report
Merge both checks into a single table so the user can see quality and safety at a glance:
Repo: owner/repo (N skills discovered)skill-name-1 OK 92 / A name + description present, no security flagsskill-name-2 WARN 58 / D missing descriptionskill-name-3 FLAG 71 / C contains shell execution patterns (exec, spawn)
Columns: audit status, eval overallScore / grade, notes.
The current policy is permissive — accept all repos that have at least one valid skill (with name + description). Security warnings and low eval scores are informational only and do not block inclusion; they exist so the reviewer can make an informed call. If a user asks "should we really add this one?", point at the eval categories for specifics. This policy may become stricter in future versions.
Where the eval result ends up
After Step 7 regenerates the index, each skill entry in data/skill-index/{owner}_{repo}.json gains two derived fields:
tokenCount: heuristic token estimate for the SKILL.md bodyevalSummary:{ overallScore, grade, categories[], evaluatedAt, evaluatedVersion }
These power the "est. tokens" and "eval score" badges shown in the website catalog, the TUI, and asm inspect. No manual editing required — the ingester populates them as part of preindex.
Step 4: Check for Existing Repos to Update
For repos already in the index (EXISTS status from Step 1):
- Compare the existing index file (
data/skill-index/{owner}_{repo}.json) against freshly discovered skills - Report what changed:
- New skills added
- Skills removed
- Skills with updated metadata (version, description, etc.)
Ask the user to confirm updates before proceeding.
Step 5: Create Feature Branch
Only proceed if there are legitimate new repos to add or existing repos to update.
git checkout -b feat/index-add-{repo-names}
Use a descriptive branch name. If adding multiple repos, abbreviate: feat/index-add-multiple-repos-{date}.
Step 6: Update skill-index-resources.json
For each NEW repo, add an entry to data/skill-index-resources.json in the repos array:
{"source": "github:{owner}/{repo}","url": "https://github.com/{owner}/{repo}","owner": "{owner}","repo": "{repo}","description": "{repo description from GitHub API}","maintainer": "@{owner}","enabled": true}
Also update the updatedAt timestamp at the top level to the current ISO date.
Step 7: Generate Index Files
For each repo (new and updated), generate the index JSON file. Use the project's built-in preindex script if possible:
cd "$(git rev-parse --show-toplevel)"npm run preindex
If npm run preindex fails or takes too long, generate the index file manually by creating data/skill-index/{owner}_{repo}.json with this structure:
{"repoUrl": "https://github.com/{owner}/{repo}.git","owner": "{owner}","repo": "{repo}","updatedAt": "{ISO timestamp}","skillCount": N,"skills": [{"name": "skill-name","description": "Skill description from frontmatter","version": "0.0.0","license": "","creator": "","compatibility": "","allowedTools": [],"installUrl": "github:{owner}/{repo}:{relative/path/to/skill}","relPath": "relative/path/to/skill","tokenCount": 0,"evalSummary": {"overallScore": 0,"grade": "F","categories": [{ "id": "structure", "name": "Structure & completeness", "score": 0, "max": 10 }],"evaluatedAt": "{ISO timestamp}","evaluatedVersion": "0.0.0"}}]}
The installUrl format matters — it's how asm install locates skills. For single-skill repos (SKILL.md at root), omit the path portion. For multi-skill repos, include the relative path to the skill directory.
If you fall back to manual generation, you can populate tokenCount and evalSummary by calling asm eval <path> --json on each skill directory and lifting the overallScore, grade, categories, evaluatedAt fields into the skill entry. When preindex succeeds, the ingester handles this for you automatically.
Step 8: Rebuild Website Catalog
Run the catalog build script to regenerate website/catalog.json:
npx tsx scripts/build-catalog.ts
Verify the output:
website/catalog.jsonwas updated- Total skill count increased (or stayed the same for pure updates)
- No errors in the build output
Step 9: Verify Everything
Run a final check:
data/skill-index-resources.jsonis valid JSON and contains the new entries- Each new
data/skill-index/{owner}_{repo}.jsonexists and is valid JSON - Each skill entry in those index files has
tokenCount(number) andevalSummary(object withoverallScore,grade,categories) populated — if any are missing, re-runnpm run preindexor fall back to manual population as described in Step 7 website/catalog.jsonis valid JSON and includes the new skillsgit diff --statshows only the expected files changed
Report a summary to the user:
Added N new repo(s), updated M existing repo(s)Total new skills indexed: XFiles changed: list of filesReady to commit and create PR.
Step 10: Commit, Push, and Create PR
Stage and commit with the conventional commit format:
Note: website/catalog.json is gitignored and rebuilt by CI (deploy-website.yml) on merge. Do NOT stage it — only stage the data files.
git add data/skill-index-resources.json data/skill-index/*.jsongit commit -m "feat(index): add {owner}/{repo} to curated skill index"
For multiple repos:
git commit -m "feat(index): add N new skill sourcesAdded:- owner1/repo1 (X skills)- owner2/repo2 (Y skills)"
Push and create a PR:
git push -u origin HEADgh pr create --title "feat(index): add {description}" --body "$(cat <<'EOF'## Summary- Added N new skill repository source(s) to the curated index- Total new skills: X### New Repos| Repo | Skills | Description ||------|--------|-------------|| [owner/repo](url) | N | description |### Audit SummaryAll skills passed the lightweight audit. No critical security flags.## Test Plan- [ ] `data/skill-index-resources.json` is valid JSON- [ ] Index files generated in `data/skill-index/`- [ ] `website/catalog.json` rebuilt successfully- [ ] CI passesEOF)"
Expected Output
On a successful run, the user should see (and the agent should verify) all of the following:
- Branch created with name
feat/index-add-{repo-names}checked out. - `data/skill-index-resources.json` parses as valid JSON, contains a new entry for each NEW repo, and has an updated
updatedAttimestamp. - One file per repo under
data/skill-index/{owner}_{repo}.json, each containing:
repoUrl,owner,repo,updatedAt,skillCount,skills[]- Every skill in
skills[]has populatedtokenCount(number > 0) andevalSummary.overallScore(number 0–100).
- `website/catalog.json` rebuilt without errors and includes the new skills (note: gitignored, do not stage).
- A summary report posted back to the user, in this exact shape:
``` Added 2 new repo(s), updated 0 existing repo(s) Total new skills indexed: 7 Files changed: M data/skill-index-resources.json A data/skill-index/owner_repo1.json A data/skill-index/owner_repo2.json
Ready to commit and create PR. ```
- Open PR on GitHub, conventional-commit title (
feat(index): ...), body filled from the template in Step 10.
If any of items 1–5 fails verification in Step 9, do not proceed to Step 10. Re-run the failing step or surface the error to the user.
Edge Cases
Inputs the skill must handle without crashing, in order of likelihood:
- Repo URL points to a 404 / private repo: mark
INVALIDin the Step 1 table and skip; do not abort the whole run if other URLs are valid. - Repo has zero SKILL.md files: flag and ask the user whether to include anyway (some repos seed empty and add skills later).
- Repo has 50+ SKILL.md files: keep going, but warn the user about runtime —
asm evalover many skills is slow. - Repo is already in the index but unchanged: report
EXISTS, no diffand skip the index regeneration for that repo. - Repo is already in the index with breaking changes (skill removed, name renamed): show a diff and require explicit user confirmation before overwriting.
- `npm run preindex` is missing or fails: fall back to manual generation per Step 7; do not block the PR.
- `npx tsx scripts/build-catalog.ts` fails: stop — this is structural and a PR with a broken catalog should not land.
- `gh` CLI not authenticated: prompt the user to run
gh auth login; do not attempt to push without auth. - User passes a non-GitHub URL (GitLab, Bitbucket): reject in Step 1 — this skill only indexes github.com.
- User passes a URL to a single skill subdirectory (
github.com/owner/repo/tree/main/skills/foo): treat as the parent repo URL and let Step 2's discoverer pick up just that skill.
When in doubt, prefer surfacing the issue to the user over silently dropping a repo. The reviewer policy is permissive but transparent.
Error Handling
- Git clone fails: Skip the repo, report the error, continue with others
- No SKILL.md found: Warn the user, ask whether to include anyway
- preindex script fails: Fall back to manual index file generation
- Build catalog fails: Stop and report — this likely means a structural issue
- PR creation fails: Ensure
ghCLI is authenticated, suggestgh auth loginif needed
Cleanup
After completion, remove any temp directories used for cloning:
rm -rf "$TEMP_DIR"