/inspect-profile

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.