skills-marketplace/plugins/cascade-knowledge-base/skills/ckb-quiz/SKILL.md

name	description
ckb-quiz	Quiz the user on knowledge captured in the wiki. Reads wiki pages, generates questions in the user's chosen format (open questions or multiple choice), runs the quiz one question at a time with score tracking and immediate feedback. Use when the user asks for a quiz, wants to test their knowledge, or says "quiz me on X".

Quiz skill

Purpose

Turn the wiki knowledge base into a live, scored quiz. Read the relevant wiki pages, generate questions grounded in actual facts from those pages, run them one at a time, give immediate feedback, and deliver a final score with a brief verdict.

The quiz should feel like a game — fast-paced, specific, and satisfying to get right.

---

How to run this skill

Step 1 — Setup (three questions, one at a time)

Ask these questions one at a time. Wait for each answer before asking the next.

Q1 — Topic

"What would you like to be quizzed on? You can name a specific topic (e.g. 'Saffron's financials', 'information security', 'the supplier onboarding process'), an entity, a concept, or just say 'everything' to draw from the whole wiki."

Q2 — Number of questions

"How many questions? 5, 10, 15, or a custom number?"

Accept any integer between 3 and 30. If they say "quick" or "short", use 5. If they say "full" or "long", use 15.

Q3 — Format

"Which format do you prefer?

• A — Open questions: I ask, you write your answer, I judge it.
• B — Multiple choice: four options, pick the letter.
• C — Mixed: roughly half and half."

---

Step 2 — Load the wiki

Before generating questions, read the wiki to find material relevant to the chosen topic.

1. Read wiki/index.md to identify relevant pages.
2. Read each relevant page in full. For a broad topic or "everything", read wiki/overview.md plus all entity and concept pages.
3. Do not tell the user you are doing this - just do it silently.

From the content, note all specific, verifiable facts: names, numbers, dates, roles, decisions, technical details, relationships between entities. These are your question material. Vague or general claims make poor quiz questions - only use facts sharp enough to have a single correct answer.

---

Step 3 — Generate questions

Generate exactly the requested number of questions before starting. Do not show them to the user yet.

Quality rules for questions:

• Every question must be grounded in a specific fact from a wiki page. If you cannot point to the source page, discard the question.
• Prefer questions with surprising or non-obvious answers - these are more satisfying to get right.
• Vary the difficulty across the set: roughly one-third easy (basic recall), one-third medium (specific detail), one-third harder (connection between two facts or precise number/date).
• Do not repeat the same subject across more than two questions.
• Avoid questions with ambiguous answers. If a fact is contested or unclear in the wiki, skip it.

For open questions:

• Write a clear question with a single, specific correct answer.
• Prepare a model answer of one sentence plus the source page it comes from.

For multiple choice:

• Write a clear question.
• Generate four options (A, B, C, D): one correct, three plausible distractors. Distractors should be wrong but believable - not obviously silly.
• Randomise the position of the correct answer across the question set (do not always put it at A or B).
• Prepare the correct letter and a one-sentence explanation.

---

Step 4 — Run the quiz

Display a header before the first question:

Quiz: [topic]
Format: [Open / Multiple choice / Mixed]
Questions: [N]

Let's go.

Then for each question:

Present the question

Show the question number and total prominently:

Question [X] of [N]
[Score so far: X correct]

[Question text]

[Options if multiple choice:
A. ...
B. ...
C. ...
D. ...]

Wait for the answer. Do not give any hints. If the user says "skip" or "pass", move on and count it as a miss (but do not count it against their streak).

Give immediate feedback

For a correct answer:

Correct. [One sentence with the fact and where it comes from in the wiki, e.g. "Saffron had GBP 1.545bn of assets at 31 December 2025 — from the deep research report."]

For a wrong answer:

Not quite. The answer is [correct answer]. [One sentence explanation.]

For open questions, use judgement: if the user's answer captures the key fact even imperfectly, count it as correct and acknowledge what they got right. Only mark wrong if the core fact is missing or incorrect. When in doubt, count it as correct - the point is learning, not catching the user out.

Track state silently. Do not list the running score after every question. Show it only inside the question header (line: "Score so far: X correct").

Streak tracking. After three correct answers in a row, add a brief line:

3 in a row.

After five in a row:

5 in a row. On a streak.

Reset the streak message on a wrong answer. Do not add streak messages more than once per milestone per run.

---

Step 5 — Final score

After the last question, show the results:

---

Final score: [X] / [N]

[Verdict — see below]

[One or two sentences on what the results suggest — which areas were strong, which came up as gaps.]

Verdicts by percentage:

Score	Verdict
100%	Perfect. Nothing left to learn here.
80–99%	Strong. One or two things to look up.
60–79%	Solid base. Worth revisiting the gaps.
40–59%	Mixed. A second pass through the wiki would help.
Under 40%	Plenty to learn. Try again after another read.

---

Step 6 — Offer a follow-up

After the verdict, always ask one of these (choose the most relevant):

• If score was under 60%: "Would you like me to run a shorter quiz on just the topics you missed?"
• If score was 80%+: "Would you like a harder set on the same topic?"
• Otherwise: "Would you like to try a different topic?"

Wait for the answer. If yes, go back to Step 2 with the new parameters. If no, close: "Good work. The wiki is there whenever you want another round."

---

Style rules during the quiz

• Keep all quiz output tight. No filler sentences.
• Use British English spelling.
• No banned vocabulary from CLAUDE.md (testament, pivotal, seamless, crucial, etc.).
• Feedback lines should be direct and specific. "Correct. Saffron was founded in January 1849." - not "Great job! That's absolutely right, the answer is..."
• Never be condescending about wrong answers. State the correct fact and move on.
• Do not add "Well done!", "Excellent!", "Nice try!" — these are noise. A plain "Correct." is better.

---

Edge cases

Not enough material. If the wiki has too few verifiable facts for the requested number of questions (e.g. user asks for 15 questions on a single stub page), say: "I can only find enough material for [N] solid questions on that topic. Shall I run [N] questions, or broaden the topic?" Do not pad with weak questions.

No wiki content. If the topic has no coverage in the wiki at all, say: "That topic does not appear in the wiki yet. Choose a different topic, or ingest a source on it first."

Ambiguous open answers. When an open answer is on the border — partially right — mark it correct, note what was right and what the full answer includes. Do not leave the user unsure whether they got credit.

---

Licensed under the Apache License, Version 2.0 — see LICENSE at the repository root, or http://www.apache.org/licenses/LICENSE-2.0.