agentleFS
r-jellyr-jelly/chronicle/skills/quiz-project/SKILL.md

quiz-project

Skill0 starsChanged 4 months agoMITView on GitHub

Run an adaptive interview quiz from a Chronicle project using why, what, how, trade-off, failure, performance, and ownership questions. Use when reviewing a project for interviews, practicing follow-up questions, testing whether resume claims can be explained, or running a mock project deep dive.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 10 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the project is ambiguous, ask for the project once.

    line 19
  2. Distinctive:

    Ask one intuition-first main question.

    line 33
  3. Distinctive:

    Wait for the user's answer.

    line 34
  4. Distinctive:

    Ask a focused follow-up when an important claim is vague or unsupported.

    line 35
  5. Distinctive:

    If the user asks for a hint, give incremental hints:

    line 36
  6. Distinctive:

    If the user says they do not know, explain directly from prerequisites to the project-specific answer, then ask a short transfer question.

    line 40
  7. Distinctive:

    Never treat an inferred project claim as the answer key.

    line 42
  8. Distinctive:

    Do not manufacture adversarial facts.

    line 46
  9. Distinctive:

    After the answer, provide:

    line 50
  10. Distinctive:

    Use the score diagnostically, not as a hiring prediction.

    line 65
  11. Distinctive:

    Only then summarize strengths, recurring gaps, and the next review target.

    line 70

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Quiz Project

Quiz the user from their own project evidence. Let the user answer before teaching or evaluating.

Prepare

Resolve <vault>/chronicle/projects/<project-id>/. Read:

  • PROJECT.md, OWNERSHIP.md, DECISIONS.md, EVIDENCE.md, and STAR.md;
  • relevant session records;
  • QUIZ_HISTORY.md before choosing a question.

If the project is ambiguous, ask for the project once. If no usable project record exists, stop and suggest capture-session or update-project.

Select a question that is not a near-duplicate of recent history. Prefer a weak area, stale topic, important resume claim, or unresolved decision. Rotate:

  • Why: selection criteria, constraints, rejected alternatives, trade-offs;
  • What: responsibility, architecture, data flow, interfaces, success criteria;
  • How: mechanism, implementation, validation, failure handling;
  • Deep dive: performance, cost, scale, security, evaluation, ownership, collaboration, failure, or retrospective.

Run the Quiz

  1. Ask one intuition-first main question.
  2. Wait for the user's answer. Do not reveal the answer in the question.
  3. Ask a focused follow-up when an important claim is vague or unsupported.
  4. If the user asks for a hint, give incremental hints:
    • Hint 1: restate the relevant constraint or boundary;
    • Hint 2: identify the concept or comparison axis;
    • Hint 3: outline the reasoning path without giving a polished answer.
  5. If the user says they do not know, explain directly from prerequisites to the project-specific answer, then ask a short transfer question.
  6. Never treat an inferred project claim as the answer key. Call out uncertainty in the source record.

In mock-interview mode, use more skeptical follow-ups but remain evidence-based. Do not manufacture adversarial facts.

Evaluate

After the answer, provide:

  • what was correct and specific;
  • what was missing or weak;
  • any conflict with the project record;
  • a stronger reasoning structure, not a script to memorize;
  • one concise example answer only after evaluation.

Score each dimension from 0 to 2:

  • factual accuracy;
  • why/what/how depth;
  • evidence and ownership;
  • communication clarity.

Use the score diagnostically, not as a hiring prediction.

Finish and Record

Continue until the user ends the quiz or the agreed question count is complete. Only then summarize strengths, recurring gaps, and the next review target.

Append one entry to <vault>/chronicle/projects/<project-id>/QUIZ_HISTORY.md only after the quiz finishes and the user approves saving. Use <plugin-root>/templates/project/QUIZ_HISTORY.md. Let <plugin-root> be ${CLAUDE_PLUGIN_ROOT} when Claude Code supplies it; otherwise use the directory two levels above this SKILL.md.

Record the main question, mode, score, strengths, gaps, completed follow-ups, and next review date. Do not update history for an abandoned question.

Choose the next review interval from the 0–8 total score: 1–3 days for 0–4, one week for 5–6, and two weeks for 7–8. Shorten it when the answer contradicted a resume claim or exposed an ownership gap.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.