/cerf - project skill index

SkillAI & models

The user types `/cerf` to see the index of the project skills. The skill lists each skill in `.claude/skills/`, with one line for each. Then it offers the environment doctor (`setup.ps1 -Check`) and stops. The doctor runs only when the user agrees. The doctor makes sure that the git hooks are active through core.hooksPath, that the .claude hooks are present and compile, that the submodules are initialized, and that vcpkg is integrated. Invoke when the user types `/cerf`.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the /cerf - project skill index skill

What this skill tells your AI

The instructions your AI receives, as published by gweslab/cerf in .claude/skills/cerf/SKILL.md and read by ahel’s review.

Print the index of the project skills. Then offer the environment doctor. Do not run the doctor unless the user agrees.

Step 1 - print the skill index

Open with a short welcome line for the CERF Claude development environment. Use one or two lines. Do not write a paragraph.

  1. List the immediate subdirectories of .claude/skills/ in the repo root. Each subdirectory is one skill.

  2. Read the name and the description from the SKILL.md of each skill.

  3. Condense each description to one short line. The descriptions in the frontmatter are long. Write one clause that gives the purpose of the skill.

  4. Print one line for each skill:

    /<name> - <one-line explanation>
    

Order: print /start-board-implementation first. It is the entry point for the core work of the project, which is board bring-up. Print the other skills after it, in alphabetical order by name. If /start-board-implementation is absent, print all the skills in alphabetical order.

Step 2 - offer the environment doctor

After the index, write one short line that offers the doctor. For example: "I can run the environment doctor (setup.ps1 -Check) for a health report on this clone."

Then stop. Do not run the doctor. Do not ask more questions.

Note: git does not clone .git/hooks/. core.hooksPath lives in the local .git/config, which git also does not clone. A fresh clone runs no git hooks until setup.cmd writes this configuration.

Step 3 - run the doctor

Run this step only when the user agrees.

From the repo root, run this command:

powershell -NoProfile -ExecutionPolicy Bypass -File setup.ps1 -Check

The doctor changes nothing. It prints one line for each check, with a tab between the fields: STATUS<TAB>key<TAB>detail. STATUS is OK, WARN, or FAIL. The exit code is 1 when one check or more failed.

setup.ps1 owns the list of checks. Read the output of setup.ps1. Do not test any of these conditions directly in this skill.

A FAIL has these consequences:

keyconsequence
git-repoThis directory is not a git repo. No other check has a meaning.
git-hookscore.hooksPath is not .githooks, so .githooks/pre-commit never runs.
submodulesA declared submodule is empty, so the build fails.
pythonpy -3 does not run, so every .claude/hooks/*.py hook is a silent no-op.
claude-hooks.claude/settings.json is absent or does not parse, or a hook script that it names is absent or does not compile.
vcpkgNobody ran vcpkg integrate install, so build.ps1 refuses to build.

stale-local-hooks is a WARN. core.hooksPath shadows the leftover files in .git/hooks/, so those files cannot run. But they give wrong information to the reader. Name this warning in one line. Do not dramatize it.

Report the result

If every check is OK, print one short line. For example: "Environment: healthy - the git hooks and the .claude hooks are both active." Do not print the table. Name each WARN line in one line.

If one check or more failed, give the diagnosis first:

  1. Give the consequence of each failure, not the name of the key. Read the consequence from the table above. Read .githooks/pre-commit for the rules that this hook enforces.
  2. Print the failing lines.
  3. Give the fix. setup.cmd corrects git-hooks and submodules. python and vcpkg are outside the repo. For python, install the Python launcher. For vcpkg, run vcpkg integrate install from <VS install>\VC\vcpkg\vcpkg.exe. setup.cmd reports these two conditions, but it cannot correct them.
  4. If setup.cmd corrects the failures, offer to run setup.cmd. Ask one time in plain chat. If the user agrees, run it.

CAUTION: Do not run setup.cmd without agreement from the user. It writes the git configuration and it can initialize submodules.

Scope and rules

  • Print the project skills only. List the subdirectories of .claude/skills/ in the repo root. Do not list the built-in CLI commands (/help, /clear). Do not list the global skills or the user skills that are outside this directory.
  • Read the directory in this run. Never write a fixed list of skills into this file. Skills change over time, and a fixed list becomes wrong.
  • Write one line for each skill. If a description is a paragraph, give its purpose in a few words. Keep the column short.
  • If a subdirectory has no SKILL.md, or the frontmatter does not parse, print the name of the directory with (no description). Do not omit the directory.
  • Ask no questions, except the offer in Step 2 and the offer in Step 3.

Signals

GitHub stars
91
Forks
9
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
cerf
Source
github.com/gweslab/cerf