| name | inspect-profile |
| description | Explain in plain English what a nyann profile enables — stack, branching, hooks, extras, conventions, documentation. TRIGGER when the user says "what does the nextjs-prototype profile do", "explain the python-cli profile", "show me what <name> enables", "what's in profile X", "describe the <name> profile", "inspect profile X", "/nyann:inspect-profile". Do NOT trigger on "show this repo's setup" — that's the `explain-state` skill (reads the repo, not a profile file). Do NOT trigger on "apply profile X to this repo" — that's `bootstrap-project`. Do NOT trigger on "save this setup as a profile" — that's `learn-profile`.
|
inspect-profile
Read-only. Wraps bin/inspect-profile.sh. Loads a profile via
load-profile.sh (user profiles shadow starters with the same name)
and renders a human-readable summary.
1. Resolve the profile name
- The user names it explicitly most of the time ("what does
nextjs-prototype do"). Use that.
- If the user is ambiguous ("what does my profile do"), ask — the
skill doesn't infer from the repo. For "show this repo's setup",
route to
explain-state instead.
- Names match the regex
^[a-z0-9][a-z0-9-]*$. Reject anything else
with a clear message rather than handing a bad name to the backend.
2. Invoke
bin/inspect-profile.sh <name> [--user-root <dir>]
--user-root defaults to ~/.claude/nyann. Only override when the
user says something like "check my team-installed profile at
<path>".
3. Read the output back
The backend already formats sections (Profile, Stack, Branching,
Hooks, Extras, Conventions, Documentation, GitHub integration). Your
job is to relay those faithfully and add context when the user asks
a follow-up. Don't re-summarize — the backend's blurbs for each hook
(e.g. "ESLint runs on staged JS/TS") are authoritative.
When the user asks "is this the right profile for my repo", do NOT
guess — suggest running explain-state (reads the repo) and
comparing, or running doctor (reports drift against a chosen
profile).
4. Handle "not found"
Exit code 2 means the profile isn't in user root or starters. The
backend prints the available list; relay it and ask the user to
pick one. Never invent profile names.
5. Handle shadow warnings
load-profile.sh warns on stderr when a user profile shadows a
starter with the same name. Don't hide this — explicitly tell the
user which version was loaded (user wins by design).
When to hand off
- "Apply this profile to a new repo" →
bootstrap-project with
--profile <name>.
- "Change something in this profile" → edit the JSON at
~/.claude/nyann/profiles/<name>.json; the skill doesn't mutate.
- "Save my repo's current state as a profile named X" →
learn-profile.
- "Why doesn't my repo match this profile" →
doctor against the
named profile.
