| 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.
- 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.
- Print the failing lines.
- 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.
- 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.
-
List the immediate subdirectories of the project's .claude/skills/
directory (each subdirectory is one skill, containing a SKILL.md).
-
For each skill, read the name and description from its SKILL.md YAML
frontmatter.
-
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.
-
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.
