cerf

name

cerf

description

The user invokes `/cerf` to see the project skill index plus a health check of the dev environment. It runs the repo's environment doctor (`setup.ps1 -Check`) to confirm git hooks are active via core.hooksPath, the .claude hooks are present and runnable, submodules are initialised and vcpkg is integrated. On a broken clone it leads with the diagnosis and the fix; on a healthy clone it prints the one-liner-per-skill menu. Invoke when the user types `/cerf`.

/cerf - environment doctor + project skill index

Two jobs, in this order: check this clone's dev environment, then print the skill index.

Git does not clone .git/hooks/, and core.hooksPath lives in local .git/config, which is not cloned either - so a fresh clone runs no git hooks at all until setup.cmd wires them up.

Step 1 - run the doctor

From the repo root:

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

Read-only. Prints one tab-separated line per check - STATUS<TAB>key<TAB>detail, where STATUS is OK, WARN or FAIL - and exits 1 if anything FAILed.

setup.ps1 owns the check list; read its output rather than testing any of this directly here.

What a FAIL means:

key	consequence
git-repo	not a git repo - nothing else is meaningful
git-hooks	core.hooksPath is not .githooks -> .githooks/pre-commit never runs
submodules	a declared submodule is empty -> the build fails
python	py -3 is not runnable -> every .claude/hooks/*.py hook is a silent no-op
claude-hooks	.claude/settings.json missing/unparseable, or a referenced hook script is absent or does not compile
vcpkg	vcpkg integrate install was never run -> build.ps1 refuses to build

stale-local-hooks is a WARN: leftovers in .git/hooks/ are shadowed by core.hooksPath and cannot fire, but they mislead whoever reads them. Mention it, don't dramatise it.

Step 2 - report

All OK (exit 0): print one short line - e.g. "Environment: healthy - git hooks and .claude hooks both active." - then the index. Don't print the table. Name any WARN lines in one line.

Anything FAILed: diagnosis first, index after.

1. Say what is broken in terms of its consequence, not its key name - read the consequence off the table above, and off .githooks/pre-commit itself for what that hook enforces.
2. Print the failing lines.
3. Give the fix. git-hooks and submodules are fixed by setup.cmd. python and vcpkg are outside the repo - install the Python launcher, or run vcpkg integrate install from <VS install>\VC\vcpkg\vcpkg.exe; setup.cmd reports these but cannot fix them.
4. Offer to run setup.cmd when the failures are the fixable kind - ask once in plain chat, run it if the user agrees. Never run it unprompted: it writes git config and may initialise submodules.

Then print the index.

Step 3 - the skill index

Open with a brief welcome line - a one/two-line greeting to the CERF Claude development environment. Keep it short and warm; don't pad it into a paragraph.

1. List the immediate subdirectories of the project's .claude/skills/ directory (each subdirectory is one skill, containing a SKILL.md).

2. For each skill, read the name and description from its SKILL.md YAML frontmatter.

3. Condense each description to a single short line - the frontmatter descriptions are long; you distil one clause that says what the skill is for. Do not paste the whole description.

4. Print the result as a compact list, one skill per line:

   /<name> - <one-line explanation>
   

   Ordering: /start-board-implementation is ALWAYS listed first (it's the entry point for the project's core work - bringing up boards). Every other skill follows it, alphabetical by name. If /start-board-implementation isn't present in the directory, just list the rest alphabetically.

Scope & rules

• Project skills only. Enumerate .claude/skills/ in the repo root. Do not list built-in CLI commands (/help, /clear, …) or global/user-level skills that don't live in this project's .claude/skills/.
• Read the directory live - never hardcode the list. Skills are added and removed over time; a baked-in list rots. Always enumerate the directory in THIS run so the output reflects what's actually present.
• One line each, genuinely one line. If a description is a paragraph, summarise its purpose in a handful of words. Keep the column readable.
• If a subdirectory has no SKILL.md or no parseable frontmatter, list it by its directory name with (no description) rather than skipping it silently.
• No confirmation prompts and no follow-up questions beyond the single offer-to-run-setup above. Print, and stop.