Inspect profile

Skill thettwe/nyann/skills/inspect-profile

Nyann (ငြမ်း) is Burmese for scaffolding. Nyann is a Claude Code plugin that sets up and maintains project governance.

Install

npx -y skills add thettwe/nyann --skill inspect-profile

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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`.

SKILL.md

2.8 KB, as published. Nobody here has run it

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.