Level 7 — Package Your Workflows: Skills and Commands

10 questions, drawn from a bank of 28 across 24 topics. Pass at 80%. Every wrong option carries a note explaining why it is tempting — those notes are the point of the quiz, so read them whether you pass or not.

attempt 1

1 / 10 · Choose one
A skill must run its own bundled script without a permission prompt, from whatever directory the session shell happens to be in, on any machine it is installed on. Which version does that?
A skill must run its own bundled script without a permission prompt, from whatever directory the session shell happens to be in, on any machine it is installed on. Which version does that?
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *) — and the body says: Run scripts/render.sh <csv-file>allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *) — and the body says: Run ${CLAUDE_SKILL_DIR}/scripts/render.sh <csv-file>allowed-tools: Bash(~/.claude/skills/render-chart/scripts/render.sh *) — and the body says: Run ${CLAUDE_SKILL_DIR}/scripts/render.sh <csv-file>allowed-tools: Bash(${CLAUDE_PROJECT_DIR}/scripts/render.sh *) — and the body says: Run ${CLAUDE_PROJECT_DIR}/scripts/render.sh <csv-file>
2 / 10 · Choose one
This is .claude/skills/deploy/SKILL.md in your repository. What do you type to invoke it?
terminal
```
---
name: deploy-production
description: Deploy the current branch to production
disable-model-invocation: true
---
 
Run the deploy checklist...
```
This is .claude/skills/deploy/SKILL.md in your repository. What do you type to invoke it?
/deploy — the directory name is the command, and name only sets the label shown in skill listings/deploy-production — name sets the command, and the directory name is only where Claude Code looks for the fileEither — Claude Code registers the directory name and the name field as aliases, the way the bundled /code-review also answers to /reviewNeither — a name that disagrees with its directory fails validation, so the skill never loads
3 / 10 · Choose one
A deploy skill exists in both ~/.claude/skills/ and the repository’s .claude/skills/. You edit the project one, save, run /deploy, and get the old behaviour. What is happening?
A deploy skill exists in both ~/.claude/skills/ and the repository’s .claude/skills/. You edit the project one, save, run /deploy, and get the old behaviour. What is happening?
The personal skill wins — enterprise over personal, personal over project — and /skills shows you each skill’s sourceBoth load and their instructions are concatenated the way two CLAUDE.md files are, so the older text is arguing with your editThe project skill wins, because the closer scope overrides the broader one the way settings.local.json overrides settings.json, so the file cannot have savedSkill files are read once at startup, so the edit needs a restart before /deploy picks it up
4 / 10 · Choose one
A skill sets allowed-tools: Bash(npm test *). You invoke it, Claude runs the tests, and you reply "now fix the failures". Does that grant still apply?
A skill sets allowed-tools: Bash(npm test *). You invoke it, Claude runs the tests, and you reply "now fix the failures". Does that grant still apply?
Yes, for the rest of the session — the field behaves as an allow rule that Claude Code holds until you /clear the conversationYes, until the conversation is compacted, when the skill body is re-attached under its token budget and the grant is re-applied with itNo — it cleared when you sent that message, even though the skill’s content is still sitting in the conversationNo, and the skill’s instructions went with it — the rendered body left the conversation at the same moment
5 / 10 · Choose one
Your api-conventions skill lists the team’s REST rules and nothing else. A colleague adds context: fork so it "does not clutter the main context". What comes back from the next invocation?
Your api-conventions skill lists the team’s REST rules and nothing else. A colleague adds context: fork so it "does not clutter the main context". What comes back from the next invocation?
The same behaviour as before, applied to your current work: the fork reads your conversation history and returns only its conclusions, so the rules cost you less contextNothing useful — the skill content becomes the subagent’s prompt, and a set of guidelines with no task is not an actionable promptThe conventions, summarised by the subagent and delivered back into your conversationAn error, because context: fork needs an agent named alongside it, and Claude Code refuses to dispatch a fork without one
6 / 10 · Choose one
A skill checked into a shared repository keeps firing on requests it should not. You still want to run it yourself, and the file is not yours to edit. What do you set?
A skill checked into a shared repository keeps firing on requests it should not. You still want to run it yourself, and the file is not yours to edit. What do you set?
skillOverrides for that skill to "user-invocable-only" — hidden from Claude, still on your / menuskillOverrides for that skill to "name-only", which drops the description Claude matches your requests against, so it stops choosing the skillskillOverrides for that skill to "off", which takes it out of the listing Claude sees while leaving it on your own / menuAdd disable-model-invocation: true to the skill’s frontmatter, which also takes its description out of context
7 / 10 · Choose one
You clone a stranger’s repository to review a pull request, and it ships a .claude/skills/ directory. What does the documentation tell you to do before you start Claude Code in it?
You clone a stranger’s repository to review a pull request, and it ships a .claude/skills/ directory. What does the documentation tell you to do before you start Claude Code in it?
Read those skills’ allowed-tools — a skill can grant itself broad tool access, and workspace trust does not gate that grantNothing extra: accepting the workspace trust dialog is what turns a project skill’s grants onDelete the repository’s .claude/ directory, since there is no other way to keep its skills from loadingNothing extra: a project skill’s tools still reach the permission prompt, so you keep your say at the moment a command is about to run
8 / 10 · Choose one
You invoke a 900-line skill at ten in the morning, keep the same session open, and by late afternoon you are twenty turns downstream on unrelated work. What has that skill cost you?
You invoke a 900-line skill at ten in the morning, keep the same session open, and by late afternoon you are twenty turns downstream on unrelated work. What has that skill cost you?
Its rendered content has been in the window on every one of those turns — it enters the conversation once and stays there across later turnsOne turn’s worth — the body is dropped when the task that invoked it finishes, the way the skill’s allowed-tools grant clears on your next messageOnly its listing entry, since a body is loaded fresh for each invocation and then discarded when that turn ends, so nothing accumulates across the afternoonNothing after the first turn, because Claude Code prompt-caches the skill content, and a cache read is not charged as new context on the turns that follow
9 / 10 · Choose one
A code-review skill injects !npm run lint. It has worked for weeks. Today lint finds three problems and the skill produces only Shell command failed for pattern "...". What happened?
A code-review skill injects !npm run lint. It has worked for weeks. Today lint finds three problems and the skill produces only Shell command failed for pattern "...". What happened?
Only that placeholder was dropped, and the rest of the skill reached Claude with a short note standing in for itLint exited 1, and a non-zero exit outside the search-and-comparison carveout aborts the whole invocation — Claude never saw the skill contentAn ask rule in your settings now matches npm run lint, and a matching ask rule aborts an injected command regardless of allowed-toolsThe lint output passed the Bash tool’s inline ceiling, so the invocation was cut short instead of rendered
10 / 10 · Put these in order
A skill directory bills you in four different ways. Put them in order, from the one charged most often to the one never charged at all.
1. 1The rendered SKILL.md body — charged on every turn after you invoke it, because it enters the conversation and stays
2. 2A supporting file such as reference.md — charged only if and when something points Claude at it
3. 3The listing entry — name and description — charged on every turn from startup, whether or not the skill is ever used
4. 4A bundled script such as scripts/helper.py — never loaded, only executed

9 questions still to answer