marketing-shibata50/claude-code-ultimate-guide
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(audit): enhanced stack detection with integrations

Browse source 
- Detailed stack breakdown: runtime, framework, test, bundler, database
- Generic integration detection (25+ packages: Clerk, Stripe, OpenAI, Sentry...)
- jq fallback: grep-based JSON parsing when jq not installed
- Stack recap at top of human output + full stack object in JSON
- README prompt updated: Stack Recap first, CLAUDE.md template ~100 lines

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Florian BRUNIAUX 2026-01-12 14:52:55 +01:00
parent 34235a7283
commit 5b526f5e53
24 changed files with 4741 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

22
CHANGELOG.md
View file

@ -6,6 +6,28 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
## [Unreleased]
## [2.9.8] - 2026-01-12
### Enhanced
- **audit-scan.sh** - Enhanced stack detection with detailed breakdown
- Now detects: runtime, framework, test runner, bundler, database/ORM
- Generic integration detection from package.json (auth, payments, AI, monitoring, etc.)
- Works without jq (grep-based fallback for all JSON parsing)
- Stack recap shown at top of human output
- JSON output includes full `stack` object with all detected components
- **README.md** - Updated Full Audit prompt
- Now requests Stack Recap as first output item
- CLAUDE.md template increased from ~60 to ~100 lines
- Added integration-aware suggestions in output description
### Fixed
- **audit-scan.sh** - jq fallback now works for MCP detection in ~/.claude.json
### Stats
- 2 files modified (audit-scan.sh ~150 lines added, README.md prompt updated)
- Detects 25+ common integrations (Clerk, Stripe, OpenAI, Sentry, etc.)
## [2.9.7] - 2026-01-12
### Enhanced

20
README.md
View file

@ -128,19 +128,21 @@ Local .claude/CLAUDE.md:
$LOCAL_CLAUDE_MD
Based on ALL this context (tech stack, business domain, existing instructions), provide:
1. Health Score (0-100) with priority breakdown
2. Findings table: Priority|Element|Status|Action
3. Top 3 quick wins (<5 min) tailored to THIS project's domain
4. CLAUDE.md template (~60 lines) that incorporates existing instructions + improvements
5. Suggested agents/commands/hooks specific to THIS project's business context
6. Ideas to leverage Claude Code for this specific domain"
1. Stack Recap: runtime, framework, test runner, bundler, database, key integrations detected
2. Health Score (0-100) with priority breakdown
3. Findings table: Priority|Element|Status|Action
4. Top 3 quick wins (<5 min) tailored to THIS project's domain
5. CLAUDE.md template (~100 lines) that incorporates existing instructions + improvements
6. Suggested agents/commands/hooks specific to THIS project's business context
7. Ideas to leverage Claude Code for this specific domain and integrations"
```
**What you get**:
- **Stack recap**: Runtime, framework, test runner, bundler, database, and key integrations auto-detected
- Health score with prioritized findings
- Stack-specific CLAUDE.md template that builds on your existing instructions
- Stack-specific CLAUDE.md template (~100 lines) that builds on your existing instructions
- Domain-aware suggestions (e.g., EdTech → session planning agents, E-commerce → inventory commands)
- Custom agents/commands/hooks ideas tailored to your project
- Integration-aware ideas (e.g., Stripe → payment testing commands, Sentry → error monitoring hooks)
**Want maximum depth?** Use [claude-setup-audit-prompt.md](./claude-setup-audit-prompt.md) with `claude --ultrathink`
@ -383,7 +385,7 @@ If this guide saved you time, helped you master Claude Code, or inspired your wo
---
*Version 2.9.7 | January 2026 | Crafted with Claude*
*Version 2.9.8 | January 2026 | Crafted with Claude*
<!-- SEO Keywords -->
<!-- claude code, claude code tutorial, anthropic cli, ai coding assistant, claude code mcp,

2
claude-code-reference.yaml
View file

@ -3,7 +3,7 @@
# Source: english-ultimate-claude-code-guide.md
# Purpose: Condensed index for LLMs to quickly answer user questions about Claude Code
version: "2.9.7"
version: "2.9.8"
updated: "2026-01"
# ════════════════════════════════════════════════════════════════

4
english-ultimate-claude-code-guide.md
View file

@ -10,7 +10,7 @@
**Last updated**: January 2026
**Version**: 2.9.7
**Version**: 2.9.8
---
@ -9009,4 +9009,4 @@ Thumbs.db
**Contributions**: Issues and PRs welcome.
**Last updated**: January 2026 | **Version**: 2.9.7
**Last updated**: January 2026 | **Version**: 2.9.8

175
examples/scripts/audit-scan.sh
View file

@ -16,6 +16,7 @@ RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
CYAN='\033[0;36m'
NC='\033[0m' # No Color
# Output mode (default: human)
@ -87,6 +88,19 @@ count_pattern() {
fi
}
# JSON helper - extract value without jq (fallback)
json_extract() {
local file="$1"
local key="$2"
grep -oE "\"$key\"[[:space:]]*:[[:space:]]*\"[^\"]*\"" "$file" 2>/dev/null | head -1 | sed 's/.*:[[:space:]]*"\([^"]*\)".*/\1/'
}
# JSON helper - extract keys from object (fallback)
json_keys() {
local file="$1"
grep -oE '"[a-zA-Z0-9_@/-]+"[[:space:]]*:' "$file" 2>/dev/null | sed 's/"//g;s/://g;s/[[:space:]]//g' | head -50
}
# Expand home directory
GLOBAL_DIR="${HOME}/.claude"
@ -110,18 +124,140 @@ SKILLS_COUNT=$(count_md_files "./.claude/skills")
HOOKS_COUNT=$(count_script_files "./.claude/hooks")
RULES_COUNT=$(count_md_files "./.claude/rules")
# Tech stack detection
# === ENHANCED STACK DETECTION ===
TECH_STACK="unknown"
STACK_FRAMEWORK=""
STACK_RUNTIME=""
STACK_TEST=""
STACK_BUNDLER=""
STACK_DB=""
STACK_INTEGRATIONS=""
# Detect by manifest file
if [[ -f "package.json" ]]; then
TECH_STACK="nodejs"
STACK_RUNTIME="Node.js"
# Extract dependencies (with or without jq)
DEPS=""
DEV_DEPS=""
if command -v jq &> /dev/null; then
DEPS=$(jq -r '.dependencies // {} | keys[]' package.json 2>/dev/null | tr '\n' ' ')
DEV_DEPS=$(jq -r '.devDependencies // {} | keys[]' package.json 2>/dev/null | tr '\n' ' ')
else
# Fallback: grep-based extraction
DEPS=$(grep -A 1000 '"dependencies"' package.json 2>/dev/null | grep -B 1000 -m 1 '}' | grep -oE '"[^"]+":' | sed 's/"//g;s/://g' | tr '\n' ' ')
DEV_DEPS=$(grep -A 1000 '"devDependencies"' package.json 2>/dev/null | grep -B 1000 -m 1 '}' | grep -oE '"[^"]+":' | sed 's/"//g;s/://g' | tr '\n' ' ')
fi
ALL_DEPS="$DEPS $DEV_DEPS"
# Framework detection
[[ "$ALL_DEPS" == *"next"* ]] && STACK_FRAMEWORK="Next.js"
[[ "$ALL_DEPS" == *"nuxt"* ]] && STACK_FRAMEWORK="Nuxt"
[[ "$ALL_DEPS" == *"@angular/core"* ]] && STACK_FRAMEWORK="Angular"
[[ "$ALL_DEPS" == *"vue"* && -z "$STACK_FRAMEWORK" ]] && STACK_FRAMEWORK="Vue"
[[ "$ALL_DEPS" == *"react"* && -z "$STACK_FRAMEWORK" ]] && STACK_FRAMEWORK="React"
[[ "$ALL_DEPS" == *"express"* && -z "$STACK_FRAMEWORK" ]] && STACK_FRAMEWORK="Express"
[[ "$ALL_DEPS" == *"fastify"* && -z "$STACK_FRAMEWORK" ]] && STACK_FRAMEWORK="Fastify"
[[ "$ALL_DEPS" == *"nestjs"* || "$ALL_DEPS" == *"@nestjs/core"* ]] && STACK_FRAMEWORK="NestJS"
[[ "$ALL_DEPS" == *"svelte"* ]] && STACK_FRAMEWORK="Svelte"
[[ "$ALL_DEPS" == *"astro"* ]] && STACK_FRAMEWORK="Astro"
[[ "$ALL_DEPS" == *"remix"* ]] && STACK_FRAMEWORK="Remix"
# Test framework detection
[[ "$ALL_DEPS" == *"vitest"* ]] && STACK_TEST="Vitest"
[[ "$ALL_DEPS" == *"jest"* && -z "$STACK_TEST" ]] && STACK_TEST="Jest"
[[ "$ALL_DEPS" == *"mocha"* && -z "$STACK_TEST" ]] && STACK_TEST="Mocha"
[[ "$ALL_DEPS" == *"playwright"* ]] && STACK_TEST="${STACK_TEST:+$STACK_TEST + }Playwright"
[[ "$ALL_DEPS" == *"cypress"* ]] && STACK_TEST="${STACK_TEST:+$STACK_TEST + }Cypress"
# Bundler detection
[[ "$ALL_DEPS" == *"vite"* ]] && STACK_BUNDLER="Vite"
[[ "$ALL_DEPS" == *"webpack"* && -z "$STACK_BUNDLER" ]] && STACK_BUNDLER="Webpack"
[[ "$ALL_DEPS" == *"esbuild"* && -z "$STACK_BUNDLER" ]] && STACK_BUNDLER="esbuild"
[[ "$ALL_DEPS" == *"turbo"* ]] && STACK_BUNDLER="${STACK_BUNDLER:+$STACK_BUNDLER + }Turborepo"
# Database/ORM detection
[[ "$ALL_DEPS" == *"prisma"* || "$ALL_DEPS" == *"@prisma/client"* ]] && STACK_DB="Prisma"
[[ "$ALL_DEPS" == *"drizzle"* ]] && STACK_DB="Drizzle"
[[ "$ALL_DEPS" == *"typeorm"* ]] && STACK_DB="TypeORM"
[[ "$ALL_DEPS" == *"mongoose"* ]] && STACK_DB="Mongoose (MongoDB)"
[[ "$ALL_DEPS" == *"sequelize"* ]] && STACK_DB="Sequelize"
# Key integrations detection (generic - look for notable packages)
INTEGRATIONS_LIST=""
# Auth
[[ "$ALL_DEPS" == *"@clerk"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Clerk, "
[[ "$ALL_DEPS" == *"next-auth"* || "$ALL_DEPS" == *"@auth/"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}NextAuth, "
[[ "$ALL_DEPS" == *"@supabase"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Supabase, "
[[ "$ALL_DEPS" == *"firebase"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Firebase, "
# Payments
[[ "$ALL_DEPS" == *"stripe"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Stripe, "
# AI/ML
[[ "$ALL_DEPS" == *"openai"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}OpenAI, "
[[ "$ALL_DEPS" == *"@anthropic"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Anthropic, "
[[ "$ALL_DEPS" == *"langchain"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}LangChain, "
# Communication
[[ "$ALL_DEPS" == *"@daily-co"* || "$ALL_DEPS" == *"daily-js"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Daily.co, "
[[ "$ALL_DEPS" == *"twilio"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Twilio, "
[[ "$ALL_DEPS" == *"sendgrid"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}SendGrid, "
[[ "$ALL_DEPS" == *"resend"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Resend, "
# Monitoring
[[ "$ALL_DEPS" == *"@sentry"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Sentry, "
[[ "$ALL_DEPS" == *"posthog"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}PostHog, "
# CMS/Content
[[ "$ALL_DEPS" == *"sanity"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Sanity, "
[[ "$ALL_DEPS" == *"contentful"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Contentful, "
# State management
[[ "$ALL_DEPS" == *"zustand"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Zustand, "
[[ "$ALL_DEPS" == *"@tanstack/react-query"* || "$ALL_DEPS" == *"react-query"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}TanStack Query, "
[[ "$ALL_DEPS" == *"trpc"* || "$ALL_DEPS" == *"@trpc"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}tRPC, "
# UI
[[ "$ALL_DEPS" == *"tailwindcss"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Tailwind, "
[[ "$ALL_DEPS" == *"@radix-ui"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}Radix UI, "
[[ "$ALL_DEPS" == *"shadcn"* ]] && INTEGRATIONS_LIST="${INTEGRATIONS_LIST}shadcn/ui, "
# Clean up trailing comma
STACK_INTEGRATIONS=$(echo "$INTEGRATIONS_LIST" | sed 's/, $//')
elif [[ -f "pyproject.toml" ]] || [[ -f "requirements.txt" ]]; then
TECH_STACK="python"
STACK_RUNTIME="Python"
# Python framework detection
PYTHON_DEPS=""
if [[ -f "requirements.txt" ]]; then
PYTHON_DEPS=$(cat requirements.txt 2>/dev/null | tr '\n' ' ')
fi
if [[ -f "pyproject.toml" ]]; then
PYTHON_DEPS="$PYTHON_DEPS $(cat pyproject.toml 2>/dev/null | tr '\n' ' ')"
fi
[[ "$PYTHON_DEPS" == *"django"* ]] && STACK_FRAMEWORK="Django"
[[ "$PYTHON_DEPS" == *"fastapi"* ]] && STACK_FRAMEWORK="FastAPI"
[[ "$PYTHON_DEPS" == *"flask"* && -z "$STACK_FRAMEWORK" ]] && STACK_FRAMEWORK="Flask"
[[ "$PYTHON_DEPS" == *"pytest"* ]] && STACK_TEST="pytest"
[[ "$PYTHON_DEPS" == *"sqlalchemy"* ]] && STACK_DB="SQLAlchemy"
[[ "$PYTHON_DEPS" == *"prisma"* ]] && STACK_DB="Prisma"
elif [[ -f "go.mod" ]]; then
TECH_STACK="go"
STACK_RUNTIME="Go"
[[ -f "go.mod" ]] && grep -q "gin-gonic" go.mod 2>/dev/null && STACK_FRAMEWORK="Gin"
[[ -f "go.mod" ]] && grep -q "echo" go.mod 2>/dev/null && STACK_FRAMEWORK="Echo"
elif [[ -f "Cargo.toml" ]]; then
TECH_STACK="rust"
STACK_RUNTIME="Rust"
[[ -f "Cargo.toml" ]] && grep -q "actix" Cargo.toml 2>/dev/null && STACK_FRAMEWORK="Actix"
[[ -f "Cargo.toml" ]] && grep -q "axum" Cargo.toml 2>/dev/null && STACK_FRAMEWORK="Axum"
elif [[ -f "composer.json" ]]; then
TECH_STACK="php"
STACK_RUNTIME="PHP"
[[ -f "composer.json" ]] && grep -q "laravel" composer.json 2>/dev/null && STACK_FRAMEWORK="Laravel"
[[ -f "composer.json" ]] && grep -q "symfony" composer.json 2>/dev/null && STACK_FRAMEWORK="Symfony"
fi
# Quality patterns
@ -147,6 +283,15 @@ if [[ -f "${HOME}/.claude.json" ]]; then
if [[ -n "$MCP_SERVERS" ]]; then
MCP_SOURCE="~/.claude.json (project)"
fi
else
# Fallback: Try to find the project section and extract mcpServers keys
# This is a simplified grep-based approach
if grep -q "\"$CURRENT_DIR\"" "${HOME}/.claude.json" 2>/dev/null; then
MCP_SERVERS=$(grep -A 100 "\"$CURRENT_DIR\"" "${HOME}/.claude.json" 2>/dev/null | grep -A 50 "mcpServers" | grep -oE '"[a-zA-Z0-9_-]+"[[:space:]]*:' | head -10 | sed 's/"//g;s/://g' | tr '\n' ',' | sed 's/,$//')
if [[ -n "$MCP_SERVERS" ]]; then
MCP_SOURCE="~/.claude.json (project)"
fi
fi
fi
fi
@ -224,7 +369,15 @@ if [[ "$OUTPUT_MODE" == "json" ]]; then
"hooks": $HOOKS_COUNT,
"rules": $RULES_COUNT
},
"tech_stack": "$TECH_STACK",
"stack": {
"type": "$TECH_STACK",
"runtime": "$STACK_RUNTIME",
"framework": "$STACK_FRAMEWORK",
"test": "$STACK_TEST",
"bundler": "$STACK_BUNDLER",
"database": "$STACK_DB",
"integrations": "$STACK_INTEGRATIONS"
},
"quality": {
"has_security_hooks": $HAS_SECURITY_HOOKS,
"has_ssot_references": $HAS_SSOT,
@ -243,7 +396,20 @@ else
# Human-readable output
echo -e "${BLUE}=== CLAUDE CODE SETUP AUDIT ===${NC}\n"
echo -e "${BLUE}📁 GLOBAL CONFIG${NC} (~/.claude/)"
# Stack recap at the top
echo -e "${CYAN}💻 STACK DETECTED${NC}"
if [[ "$TECH_STACK" != "unknown" ]]; then
echo -e " Runtime: ${GREEN}$STACK_RUNTIME${NC}"
[[ -n "$STACK_FRAMEWORK" ]] && echo -e " Framework: ${GREEN}$STACK_FRAMEWORK${NC}"
[[ -n "$STACK_TEST" ]] && echo -e " Testing: $STACK_TEST"
[[ -n "$STACK_BUNDLER" ]] && echo -e " Bundler: $STACK_BUNDLER"
[[ -n "$STACK_DB" ]] && echo -e " Database: $STACK_DB"
[[ -n "$STACK_INTEGRATIONS" ]] && echo -e " Integrations: $STACK_INTEGRATIONS"
else
echo -e " ${YELLOW}⚠️${NC} Could not detect stack (no package.json, pyproject.toml, etc.)"
fi
echo -e "\n${BLUE}📁 GLOBAL CONFIG${NC} (~/.claude/)"
[[ "$GLOBAL_CLAUDE_MD" == "true" ]] && echo -e " ${GREEN}✅${NC} CLAUDE.md" || echo -e " ${RED}❌${NC} CLAUDE.md"
[[ "$GLOBAL_SETTINGS" == "true" ]] && echo -e " ${GREEN}✅${NC} settings.json" || echo -e " ${RED}❌${NC} settings.json"
[[ "$GLOBAL_MCP" == "true" ]] && echo -e " ${GREEN}✅${NC} mcp.json (legacy)" || echo -e " ${YELLOW}⚠️${NC} mcp.json (not required, MCP in ~/.claude.json)"
@ -260,9 +426,6 @@ else
echo -e " Hooks: $HOOKS_COUNT"
echo -e " Rules: $RULES_COUNT"
echo -e "\n${BLUE}💻 TECH STACK${NC}"
echo -e " Detected: $TECH_STACK"
echo -e "\n${BLUE}✨ QUALITY PATTERNS${NC}"
[[ "$HAS_SECURITY_HOOKS" == "true" ]] && echo -e " ${GREEN}✅${NC} Security hooks (PreToolUse)" || echo -e " ${RED}❌${NC} Security hooks (recommended)"
[[ "$HAS_SSOT" == "true" ]] && echo -e " ${GREEN}✅${NC} Single Source of Truth (@refs)" || echo -e " ${YELLOW}⚠️${NC} SSoT pattern (recommended)"

30
quiz/package.json Normal file
View file

@ -0,0 +1,30 @@
{
"name": "claude-code-quiz",
"version": "1.0.0",
"description": "CLI quiz to test your Claude Code knowledge",
"main": "src/index.js",
"bin": {
"claude-quiz": "./src/index.js"
},
"scripts": {
"start": "node src/index.js",
"quiz": "node src/index.js"
},
"keywords": [
"claude",
"claude-code",
"quiz",
"cli",
"learning"
],
"author": "Florian BRUNIAUX",
"license": "CC-BY-SA-4.0",
"dependencies": {
"chalk": "^5.3.0",
"inquirer": "^9.2.12",
"yaml": "^2.3.4"
},
"engines": {
"node": ">=18.0.0"
}
}

259
quiz/questions/01-quick-start.yaml Normal file
View file

@ -0,0 +1,259 @@
category: "Quick Start"
category_id: 1
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "01-001"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "What is the recommended universal method to install Claude Code?"
options:
a: "brew install claude-code"
b: "npm install -g @anthropic-ai/claude-code"
c: "pip install claude-code"
d: "curl -fsSL https://claude.ai/install.sh | sh"
correct: "b"
explanation: |
The universal installation method that works across all platforms (Windows, macOS, Linux) is `npm install -g @anthropic-ai/claude-code`. While shell scripts and Homebrew are available for specific platforms, npm is the recommended cross-platform approach. This ensures consistent installation regardless of your operating system.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.1 Installation"
anchor: "#11-installation"
- id: "01-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "After Claude proposes a code change, what options do you have when reviewing the diff?"
options:
a: "Only accept (y) or reject (n)"
b: "Accept (y), reject (n), or edit (e)"
c: "Accept (y), skip (s), or delay (d)"
d: "Commit (c), reject (r), or review (v)"
correct: "b"
explanation: |
When Claude proposes a change, you have three options: press 'y' to accept the change, 'n' to reject and ask for alternatives, or 'e' to edit the change manually. This gives you full control over what gets applied to your codebase. Always review diffs before accepting - this is your safety net.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.2 First Workflow"
anchor: "#12-first-workflow"
- id: "01-003"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "Which command shows all available Claude Code commands?"
options:
a: "/commands"
b: "/list"
c: "/help"
d: "/menu"
correct: "c"
explanation: |
The `/help` command displays all available Claude Code commands. This is the go-to command when you're lost or want to discover available functionality. It's one of the 7 essential commands that cover 90% of daily usage.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#13-essential-commands"
- id: "01-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What does the `!` prefix do in Claude Code?"
options:
a: "Marks a command as urgent"
b: "Runs a shell command directly without asking Claude"
c: "Escapes special characters"
d: "Deletes the previous command"
correct: "b"
explanation: |
The `!` prefix executes shell commands immediately without asking Claude to do it. For example, `!git status` runs the command directly. Use this for quick status checks, view commands, and already-known commands. It's faster than asking Claude when you know exactly what command you need.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#shell-commands-with-"
- id: "01-005"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What does the `@` symbol do when used in a prompt?"
options:
a: "Mentions another user"
b: "References a specific file for targeted operations"
c: "Tags a message as important"
d: "Activates an agent"
correct: "b"
explanation: |
The `@` symbol references specific files in your prompts for targeted operations. For example, `Review @src/auth/login.tsx for security issues` directly loads that file. This provides precision (target exact files), speed (skip file discovery), and clarity (makes your intent explicit). Claude automatically loads the file content.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#file-references-with-"
- id: "01-006"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the recommended approach when migrating from GitHub Copilot to Claude Code?"
options:
a: "Completely stop using Copilot immediately"
b: "Use a hybrid approach: Copilot for autocomplete, Claude Code for complex tasks"
c: "Only use Claude Code for simple tasks"
d: "Export all Copilot settings to Claude Code"
correct: "b"
explanation: |
The guide recommends a hybrid approach: use Copilot for quick autocomplete and boilerplate while using Claude Code for feature implementation, debugging, code reviews, and understanding unfamiliar codebases. This leverages the strengths of both tools - Copilot excels at inline suggestions while Claude Code handles multi-file operations and complex reasoning.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.6 Migrating from Other AI Coding Tools"
anchor: "#migration-guide-github-copilot--claude-code"
- id: "01-007"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "In Plan Mode, what is Claude allowed to do?"
options:
a: "Edit files, run commands, and make commits"
b: "Only read and analyze - no modifications allowed"
c: "Run commands but not edit files"
d: "Create new files but not edit existing ones"
correct: "b"
explanation: |
Plan Mode is Claude Code's "look but don't touch" mode. It allows reading files, searching the codebase, analyzing architecture, and proposing approaches. It prevents editing files, running state-modifying commands, creating new files, and making commits. Perfect for safe exploration before making changes.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.4 Permission Modes"
anchor: "#plan-mode"
- id: "01-008"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What flag allows you to continue your most recent Claude Code conversation?"
options:
a: "--last"
b: "--continue or -c"
c: "--resume-last"
d: "--restore"
correct: "b"
explanation: |
Use `claude --continue` or `claude -c` to automatically resume your most recent conversation. This maintains full context and conversation history across terminal sessions. For resuming a specific session by ID, use `claude --resume <id>` or `claude -r <id>`. This is particularly useful for multi-day features or when interrupted.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#session-continuation-and-resume"
- id: "01-009"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What should you ALWAYS do before accepting a code change from Claude?"
options:
a: "Run the test suite"
b: "Create a backup of the file"
c: "Read the diff carefully"
d: "Ask for Claude's confidence level"
correct: "c"
explanation: |
Always read the diff before accepting changes - this is your safety net. The guide emphasizes this as critical: "Always review diffs before accepting changes." While running tests is good practice, reviewing the diff is the immediate required step before any acceptance. You need to understand what changes are being proposed.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.2 First Workflow"
anchor: "#step-3-review-the-diff"
- id: "01-010"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which keyboard shortcut cancels the current operation in Claude Code?"
options:
a: "Ctrl+Z"
b: "Ctrl+C"
c: "Esc"
d: "Ctrl+Q"
correct: "b"
explanation: |
Ctrl+C cancels the current operation in Claude Code. This is useful for stopping long-running analysis or when Claude is taking an approach you don't want. Esc dismisses the current suggestion, while Ctrl+R retries the last operation. Knowing these shortcuts helps maintain control during your workflow.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#quick-actions--shortcuts"
- id: "01-011"
difficulty: "senior"
profiles: ["senior", "power"]
question: "When should you use auto-accept mode in Claude Code?"
options:
a: "For all operations to save time"
b: "Only for well-defined, reversible operations you trust"
c: "When working on production code"
d: "For complex refactoring tasks"
correct: "b"
explanation: |
Auto-accept mode should only be used for well-defined, reversible operations. The guide warns: "Only use auto-accept for well-defined, reversible operations." It's dangerous for complex or risky changes. Default mode (asking permission) is safest, especially for learning and production work.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.4 Permission Modes"
anchor: "#auto-accept-mode"
- id: "01-012"
difficulty: "power"
profiles: ["power"]
question: "What is the recommended rule of thumb for choosing between Claude Code and autocomplete tools based on code size?"
options:
a: "<10 lines: autocomplete, >10 lines: Claude Code"
b: "<5 lines: autocomplete, 5-50 lines single file: either, >50 lines or multi-file: Claude Code"
c: "Always use Claude Code regardless of size"
d: "<20 lines: autocomplete, >20 lines: Claude Code"
correct: "b"
explanation: |
The guide provides clear guidance: less than 5 lines of code - use Copilot/autocomplete; 5-50 lines in a single file - either tool works; more than 50 lines or multi-file changes - use Claude Code. This helps you choose the right tool for the task's complexity level.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.6 Migrating from Other AI Coding Tools"
anchor: "#common-migration-issues"
- id: "01-013"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What image formats does Claude Code support for visual analysis?"
options:
a: "Only PNG"
b: "PNG, JPG, JPEG, WebP, GIF (static)"
c: "All image formats including RAW"
d: "SVG and PNG only"
correct: "b"
explanation: |
Claude Code supports PNG, JPG, JPEG, WebP, and static GIF formats. You can paste images directly in the terminal (Cmd+V/Ctrl+V), drag and drop, or reference by path. This is useful for implementing UI from mockups, debugging visual issues, analyzing diagrams, and accessibility audits. Note that images consume significant context tokens (1000-2000 words equivalent).
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#working-with-images-and-screenshots"
- id: "01-014"
difficulty: "senior"
profiles: ["senior", "power"]
question: "When resuming a Claude Code session, what context is preserved?"
options:
a: "Only the conversation history"
b: "Full conversation history, files read/edited, CLAUDE.md settings, and MCP server state"
c: "Just the last 10 messages"
d: "Only files that were modified"
correct: "b"
explanation: |
When you resume a session, Claude retains: full conversation history, files previously read/edited, CLAUDE.md and project settings, MCP server state (if Serena is used), and uncommitted code changes awareness. This comprehensive context preservation allows seamless continuation of complex, multi-day tasks.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.3 Essential Commands"
anchor: "#context-preservation"
- id: "01-015"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "What command should you use to verify Claude Code installation?"
options:
a: "claude check"
b: "claude --verify"
c: "claude --version"
d: "claude test"
correct: "c"
explanation: |
Use `claude --version` to verify your installation and display the current version. This is also useful before reporting bugs. After installation, you can also use `claude doctor` to verify auto-updater health and `claude update` to check for available updates.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.1 Installation"
anchor: "#verify-installation"

310
quiz/questions/02-core-concepts.yaml Normal file
View file

@ -0,0 +1,310 @@
category: "Core Concepts"
category_id: 2
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "02-001"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "At what context percentage should you use /compact?"
options:
a: "0-50%"
b: "50-70%"
c: "70-90%"
d: "Only at 100%"
correct: "c"
explanation: |
Use /compact when context reaches 70-90% (the red zone). The context zones are: Green (0-50%) - work freely; Yellow (50-75%) - start being selective; Red (75-90%) - use /compact; Critical (90%+) - must /clear or risk errors. Using /compact at 70% reduces usage by approximately 50% while preserving key context.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#context-zones"
- id: "02-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is Claude's context window size?"
options:
a: "50,000 tokens"
b: "100,000 tokens"
c: "200,000 tokens"
d: "500,000 tokens"
correct: "c"
explanation: |
Claude has a 200,000 token context window. Think of it like RAM - when it fills up, things slow down or fail. This context includes all messages, files read, command outputs, and tool results. Effective context management is described as "the most important concept in Claude Code."
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#the-context-budget"
- id: "02-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What does the statusline 'Ctx(u): 45%' indicate?"
options:
a: "45% of your budget is remaining"
b: "You've used 45% of your context"
c: "45% of files are loaded"
d: "Claude is 45% confident"
correct: "b"
explanation: |
The statusline metric 'Ctx(u): 45%' shows you've used 45% of your context window. The full statusline format is: `Claude Code | Ctx(u): 45% | Cost: $0.23 | Session: 1h 23m`. Monitoring this helps you know when to use /compact or /clear before context-related issues occur.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#reading-the-statusline"
- id: "02-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the difference between /compact and /clear?"
options:
a: "/compact is faster, /clear is more thorough"
b: "/compact summarizes context (preserves key info), /clear starts completely fresh (loses all context)"
c: "/compact clears files, /clear clears conversations"
d: "They do the same thing"
correct: "b"
explanation: |
/compact summarizes the conversation, preserving key context while reducing usage by approximately 50%. Use it when running low on context. /clear starts completely fresh, losing all context - use it when changing topics or context is severely bloated. Choose based on whether you need to maintain continuity.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#context-recovery-strategies"
- id: "02-005"
difficulty: "senior"
profiles: ["senior", "power"]
question: "Which action consumes the MOST context tokens?"
options:
a: "Reading a small file (~500 tokens)"
b: "Running a simple command (~1K tokens)"
c: "Reading a large file or multi-file search (~5K+ tokens)"
d: "Sending a short message"
correct: "c"
explanation: |
Reading large files (5K+ tokens) and multi-file searches (3K+ tokens) consume the most context. A small file costs ~500 tokens, running commands ~1K tokens. Long conversations accumulate over time. To optimize, be specific in queries, use symbol references like "read the calculateTotal function" instead of entire files.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#what-consumes-context"
- id: "02-006"
difficulty: "power"
profiles: ["power"]
question: "What is the 'Last 20% Rule' in context management?"
options:
a: "Always keep the last 20% of your conversation"
b: "Reserve ~20% of context for multi-file operations, corrections, and summary generation at session end"
c: "Delete 20% of context regularly"
d: "Use only 20% of available context"
correct: "b"
explanation: |
The Last 20% Rule recommends reserving approximately 20% of your context for: multi-file operations at end of session, last-minute corrections, and generating summary/checkpoint documents. This buffer ensures you can complete your work properly even as context fills up.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#context-inspection"
- id: "02-007"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is 'context poisoning' (also called context bleeding)?"
options:
a: "When context usage reaches 100%"
b: "When information from one task contaminates another"
c: "When Claude forgets your instructions"
d: "When files get corrupted"
correct: "b"
explanation: |
Context poisoning occurs when information from one task contaminates another. Examples include: style bleeding (blue button style applies to unrelated forms), instruction contamination (conflicting rules cause confusion), and temporal confusion (Claude uses outdated file names). Use explicit task boundaries and clarify priorities to prevent it.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#context-poisoning-bleeding"
- id: "02-008"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the 7-step interaction loop in Claude Code?"
options:
a: "Plan, Code, Test, Deploy, Monitor, Fix, Repeat"
b: "Describe, Analyze, Propose, Review, Decide, Verify, Commit"
c: "Read, Write, Edit, Run, Debug, Test, Push"
d: "Ask, Wait, Accept, Run, Check, Fix, Done"
correct: "b"
explanation: |
The interaction loop is: 1) DESCRIBE - explain what you need, 2) ANALYZE - Claude explores the codebase, 3) PROPOSE - Claude suggests changes (diff), 4) REVIEW - you read and evaluate, 5) DECIDE - Accept/Reject/Modify, 6) VERIFY - run tests, check behavior, 7) COMMIT - save changes (optional). The key insight: you remain in control throughout.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.1 The Interaction Loop"
anchor: "#21-the-interaction-loop"
- id: "02-009"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "How do you exit Plan Mode to start making changes?"
options:
a: "/edit"
b: "/execute"
c: "/start"
d: "/exit-plan"
correct: "b"
explanation: |
Use /execute to exit Plan Mode and begin implementing changes. While in Plan Mode, Claude can only read and analyze - no modifications are allowed. You can also respond to Claude's prompt "Ready to implement this plan?" to transition. This staged approach ensures you understand the plan before execution.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.3 Plan Mode"
anchor: "#exiting-plan-mode"
- id: "02-010"
difficulty: "power"
profiles: ["power"]
question: "What is OpusPlan mode?"
options:
a: "A premium subscription tier"
b: "Using Opus for planning (superior reasoning) and Sonnet for implementation (cost-efficient)"
c: "A debugging mode"
d: "A way to plan without Claude"
correct: "b"
explanation: |
OpusPlan uses Opus for planning (with superior reasoning capabilities) and automatically switches to Sonnet for implementation (more cost-efficient). Enable with `/model opusplan`. This provides Opus-quality planning while preserving tokens through Sonnet-speed execution. Particularly valuable for Pro subscribers with limited Opus tokens.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.3 Plan Mode"
anchor: "#opusplan-mode"
- id: "02-011"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What are symptoms of context depletion?"
options:
a: "Claude types slower"
b: "Shorter responses, forgetting CLAUDE.md instructions, inconsistencies with earlier conversation"
c: "Error messages appear"
d: "Cost increases dramatically"
correct: "b"
explanation: |
Context depletion symptoms include: shorter responses than usual (warning), forgetting CLAUDE.md instructions (serious), inconsistencies with earlier conversation (critical), errors on code already discussed (critical), and "I can't access that file" for files already read (critical). When critical symptoms appear, start a new session immediately.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#context-depletion-symptoms"
- id: "02-012"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What can /rewind do?"
options:
a: "Undo git commits"
b: "Revert Claude's file changes within the current session"
c: "Go back in conversation history"
d: "Restore deleted files from disk"
correct: "b"
explanation: |
/rewind reverts file changes made by Claude. It works across multiple files but only on Claude's changes (not manual edits), only within the current session, and does NOT automatically revert git commits. For risky operations, create a git checkpoint first: "Let's commit what we have before trying this experimental approach."
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.4 Rewind"
anchor: "#24-rewind"
- id: "02-013"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What does Claude NOT have access to regarding your project?"
options:
a: "File structure and code content"
b: "Git state and branches"
c: "Runtime state, external services, and hidden files"
d: "Project rules in CLAUDE.md"
correct: "c"
explanation: |
Claude knows: file structure, code content, git state, and project rules (CLAUDE.md). Claude does NOT know: runtime state (can't see running processes), external services (can't access databases directly), your intent (needs clear instructions), and hidden files (respects .gitignore by default). Understanding this mental model helps you communicate effectively.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.5 Mental Model"
anchor: "#what-claude-doesnt-know"
- id: "02-014"
difficulty: "power"
profiles: ["power"]
question: "What is the purpose of the 'Sanity Check Technique'?"
options:
a: "To verify code compiles correctly"
b: "To verify Claude has loaded your CLAUDE.md configuration correctly"
c: "To check for memory leaks"
d: "To validate test coverage"
correct: "b"
explanation: |
The Sanity Check Technique verifies Claude loaded your configuration. Add identifiable info to CLAUDE.md (like your name, project name, tech stack), then ask Claude "What is my name? What project am I working on?" Correct answers confirm configuration is loaded. For advanced checking, add multiple checkpoints throughout long CLAUDE.md files.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#sanity-check-technique"
- id: "02-015"
difficulty: "senior"
profiles: ["senior", "power"]
question: "When should you use XML-structured prompts?"
options:
a: "For all prompts regardless of complexity"
b: "For multi-step features, bug investigations with context, and code reviews with specific criteria"
c: "Only for simple one-liner requests"
d: "Only when working with APIs"
correct: "b"
explanation: |
Use XML-structured prompts when requests have 3+ distinct aspects (instruction + context + constraints), when ambiguity causes misunderstanding, when creating reusable templates, or for complex hierarchy. Don't use them for simple one-liner requests or quick typo fixes - the overhead outweighs the benefit. Tags like <instruction>, <context>, <constraints> help Claude understand different aspects.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.6 Structured Prompting with XML Tags"
anchor: "#when-to-use-xml-structured-prompts"
- id: "02-016"
difficulty: "power"
profiles: ["power"]
question: "What is a 'Session Handoff Pattern' used for?"
options:
a: "Transferring sessions between team members"
b: "Documenting state, decisions, and next steps to maintain continuity between sessions"
c: "Backing up your code"
d: "Exporting conversation history"
correct: "b"
explanation: |
The Session Handoff Pattern creates a document to bridge gaps between sessions. It includes: what was accomplished, current state, decisions made, next steps, and context for the next session. Create handoffs at end of work day, before context limit, when switching focus areas, or during interruptions. Store in `claudedocs/handoffs/handoff-YYYY-MM-DD.md`.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#session-handoff-pattern"
- id: "02-017"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the typical cost of a 1-hour Claude Code session?"
options:
a: "$0.01 - $0.05"
b: "$0.10 - $0.50"
c: "$1.00 - $5.00"
d: "$10.00 - $20.00"
correct: "b"
explanation: |
A typical 1-hour session costs $0.10 - $0.50 depending on usage patterns. The guide provides cost budgets: quick task (5-10 min) $0.05-$0.10, feature work (1-2 hours) $0.20-$0.50, deep refactor (half day) $1.00-$2.00. Spending $0.50 to save 30 minutes provides 60x ROI if your time is worth $30/hour - don't over-optimize!
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.2 Context Management"
anchor: "#cost-awareness--optimization"
- id: "02-018"
difficulty: "power"
profiles: ["power"]
question: "What is Auto Plan Mode and how do you enable it?"
options:
a: "Automatic planning that's always on by default"
b: "A configuration that forces Claude to present a plan and wait for approval before any tool execution"
c: "A mode that automatically generates project plans"
d: "A premium feature for enterprise users"
correct: "b"
explanation: |
Auto Plan Mode makes Claude present a plan and wait for explicit user approval before executing ANY tool. Configure via `~/.claude/auto-plan-mode.txt` and launch with `claude --append-system-prompt "$(cat ~/.claude/auto-plan-mode.txt)"`. Results in 76% fewer tokens with better results because plans are validated before execution.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "2.3 Plan Mode"
anchor: "#auto-plan-mode"

293
quiz/questions/03-memory-settings.yaml Normal file
View file

@ -0,0 +1,293 @@
category: "Memory & Settings"
category_id: 3
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "03-001"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "What is the correct precedence order for CLAUDE.md files (highest to lowest priority)?"
options:
a: "Global > Project > Local"
b: "Local (.claude/CLAUDE.md) > Project (/project/CLAUDE.md) > Global (~/.claude/CLAUDE.md)"
c: "Project > Local > Global"
d: "All CLAUDE.md files have equal priority"
correct: "b"
explanation: |
The precedence is: Local (.claude/CLAUDE.md) > Project (/project/CLAUDE.md) > Global (~/.claude/CLAUDE.md). More specific beats more general. Local overrides are personal (gitignored), project settings are shared (committed), and global settings apply to all projects. This hierarchy allows personal preferences to override team conventions when needed.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.4 Precedence Rules"
anchor: "#claudemd-precedence"
- id: "03-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Where should team conventions be stored to be shared via version control?"
options:
a: "~/.claude/CLAUDE.md"
b: "/project/.claude/CLAUDE.md"
c: "/project/CLAUDE.md"
d: "/project/.claude/settings.local.json"
correct: "c"
explanation: |
Team conventions should be stored in `/project/CLAUDE.md` (the project root). This file is committed to git and shared with the team. Local overrides go in `/project/.claude/CLAUDE.md` (gitignored), and personal global preferences go in `~/.claude/CLAUDE.md`. This separation ensures team standards are enforced while allowing personal customization.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.1 Memory Files (CLAUDE.md)"
anchor: "#level-2-project-projectclaudemd"
- id: "03-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the purpose of settings.local.json?"
options:
a: "Store team hook configurations"
b: "Define project-wide settings"
c: "Personal permission overrides (gitignored)"
d: "Configure MCP servers for the team"
correct: "c"
explanation: |
settings.local.json stores personal permission overrides and is gitignored. It allows you to customize which tools are auto-allowed, denied, or require asking for your personal workflow without affecting team settings. For example, you might allow all git commands while the team requires confirmation for certain operations.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#settingslocaljson-personal-permissions"
- id: "03-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which folder contains custom agents, commands, hooks, and skills?"
options:
a: "~/.claude/"
b: "/project/CLAUDE.md"
c: "/project/.claude/"
d: "/project/config/"
correct: "c"
explanation: |
The `.claude/` folder in your project contains: agents/ (custom agent definitions), commands/ (custom slash commands), hooks/ (event-driven scripts), skills/ (knowledge modules), rules/ (auto-loaded conventions), and settings files. This is your project's Claude Code configuration directory for all extensions.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.2 The .claude/ Folder Structure"
anchor: "#full-structure"
- id: "03-005"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the permission behavior for tools listed in the 'deny' category?"
options:
a: "Ask for confirmation each time"
b: "Auto-approve without asking"
c: "Block completely"
d: "Log but allow"
correct: "c"
explanation: |
Tools in the 'deny' category are blocked completely - Claude cannot use them at all. The three permission behaviors are: 'allow' (auto-approve without asking), 'deny' (block completely), and 'ask' (prompt for confirmation). For example, denying "Bash(rm -rf *)" prevents accidental destructive operations.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#permission-behavior"
- id: "03-006"
difficulty: "power"
profiles: ["power"]
question: "What is the 'Single Source of Truth Pattern' for multi-tool AI setups?"
options:
a: "Use only one AI tool per project"
b: "Store conventions in docs/conventions/ and reference them from all AI tool configs"
c: "Copy the same rules to each AI tool's config"
d: "Let each AI tool define its own rules"
correct: "b"
explanation: |
The Single Source of Truth Pattern stores conventions in `/docs/conventions/` (coding-standards.md, architecture.md, testing.md, etc.) and references them from CLAUDE.md, CodeRabbit, and other tools. This prevents conflicts where one tool approves code that another flags. All tools enforce the same standards from one source.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.1 Memory Files (CLAUDE.md)"
anchor: "#single-source-of-truth-pattern"
- id: "03-007"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What should be included in a project-level CLAUDE.md file?"
options:
a: "Only personal preferences"
b: "Tech stack, code conventions, architecture patterns, and common commands"
c: "API keys and secrets"
d: "Git history"
correct: "b"
explanation: |
Project CLAUDE.md should include: tech stack (frameworks, versions), code conventions (naming, patterns), architecture (folder structure, layers), and common commands (dev, test, lint). This gives Claude project context. Never include API keys or secrets. Keep it concise with examples, and update when conventions change.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.1 Memory Files (CLAUDE.md)"
anchor: "#level-2-project-projectclaudemd"
- id: "03-008"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What does the permission pattern 'Bash(git *)' match?"
options:
a: "Only the exact command 'git'"
b: "Any git command"
c: "Git commands that start with asterisk"
d: "Git commands with glob patterns"
correct: "b"
explanation: |
The pattern 'Bash(git *)' matches any git command. Permission patterns use wildcards: 'Bash(git *)' matches any git command, 'Bash(pnpm *)' matches any pnpm command, 'mcp__serena__*' matches all Serena MCP tools. You can also use specific patterns like 'Bash(git status:*)' to match only git status.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#permission-patterns"
- id: "03-009"
difficulty: "power"
profiles: ["power"]
question: "What is 'Dynamic Memory' (Profile Switching)?"
options:
a: "Claude's ability to remember across sessions"
b: "Temporarily modifying CLAUDE.md for specific tasks, then restoring"
c: "Automatic memory compression"
d: "Syncing memory between devices"
correct: "b"
explanation: |
Dynamic Memory means temporarily modifying CLAUDE.md for specific tasks then restoring it. Techniques include: git stash (stash original, modify, restore), profile library (keep profiles like security-audit.md, debugging.md in ~/.claude/profiles/), or parallel instances (different CLAUDE.md in different worktrees). Switch profiles with a script: `claude-profile security-audit`.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#dynamic-memory-profile-switching"
- id: "03-010"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What happens to files in the .claude/rules/ directory?"
options:
a: "They must be manually imported"
b: "They are automatically loaded and combined"
c: "They override CLAUDE.md"
d: "They are ignored unless referenced"
correct: "b"
explanation: |
Files in `.claude/rules/` are automatically loaded and combined. You can create multiple files like code-conventions.md, git-workflow.md, and architecture.md - all are loaded automatically without manual imports. This allows modular organization of project conventions that Claude will follow.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.4 Precedence Rules"
anchor: "#rules-auto-loading"
- id: "03-011"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which of these should be gitignored?"
options:
a: "/project/CLAUDE.md"
b: ".claude/agents/"
c: ".claude/settings.local.json and .claude/CLAUDE.md"
d: ".claude/hooks/"
correct: "c"
explanation: |
Files that should be gitignored are: .claude/CLAUDE.md (local personal instructions) and .claude/settings.local.json (personal permissions). Files that should be committed include: agents/, commands/, hooks/, skills/, rules/, and settings.json. This separation allows personal customization while sharing team configurations.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.2 The .claude/ Folder Structure"
anchor: "#what-goes-where"
- id: "03-012"
difficulty: "power"
profiles: ["power"]
question: "What does 'allowedTools' configuration do differently from permission categories?"
options:
a: "Nothing, they are the same"
b: "Provides granular control with tool-specific patterns in ~/.claude.json"
c: "Only works for MCP tools"
d: "Requires admin privileges"
correct: "b"
explanation: |
The allowedTools configuration in ~/.claude.json provides granular control with specific patterns. For example: 'Read(*)' allows all reads, 'Bash(git status:*)' allows only git status, 'Bash(pnpm *:*)' allows pnpm commands. You can set progressive permission levels from beginner (very restrictive) to advanced. Never use --dangerously-skip-permissions.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#allowedtools-configuration-alternative"
- id: "03-013"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the global config path on macOS/Linux?"
options:
a: "/etc/claude/"
b: "~/.claude/"
c: "/usr/local/claude/"
d: "~/.config/claude/"
correct: "b"
explanation: |
On macOS/Linux, the global config path is ~/.claude/. On Windows, it's %USERPROFILE%\.claude\ or C:\Users\YourName\.claude\. This directory contains your global CLAUDE.md, settings, and can include a profiles/ subdirectory for dynamic memory switching.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "1.1 Installation"
anchor: "#platform-specific-paths"
- id: "03-014"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What are the three levels of progressive permission in allowedTools?"
options:
a: "Admin, User, Guest"
b: "Beginner (very restrictive), Intermediate, Advanced"
c: "Read, Write, Execute"
d: "Low, Medium, High"
correct: "b"
explanation: |
The three progressive permission levels are: Beginner (very restrictive - only Read, Grep, Glob), Intermediate (adds Bash git/pnpm, TodoRead/Write), and Advanced (adds Edit, Write, WebFetch, Task). Start restrictive and expand as you gain confidence. This prevents accidents while learning.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#progressive-permission-levels"
- id: "03-015"
difficulty: "power"
profiles: ["power"]
question: "Why should you NEVER use --dangerously-skip-permissions?"
options:
a: "It's deprecated"
b: "It can lead to destructive operations like rm -rf, force push to main, or DROP TABLE"
c: "It costs more"
d: "It's slower"
correct: "b"
explanation: |
Never use --dangerously-skip-permissions because it can lead to destructive operations. Horror stories include: `rm -rf node_modules` followed by `rm -rf .` (path error), `git push --force` to main unintentionally, `DROP TABLE users` in poorly generated migrations, and deletion of .env files with credentials. Always prefer granular allowedTools instead.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#-warning-never-use---dangerously-skip-permissions"
- id: "03-016"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What should a global CLAUDE.md contain?"
options:
a: "Project-specific code conventions"
b: "Personal preferences that apply to all projects (communication style, preferred tools, safety rules)"
c: "Team member contact information"
d: "Git commit history"
correct: "b"
explanation: |
Global CLAUDE.md (~/.claude/CLAUDE.md) should contain personal preferences that apply to all your projects: communication style (be concise, use code examples), preferred tools (TypeScript over JavaScript, pnpm over npm), and safety rules (always run tests, never force push). Project-specific settings go in project CLAUDE.md.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.1 Memory Files (CLAUDE.md)"
anchor: "#level-1-global-claudeclaudemd"
- id: "03-017"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is stored in settings.json (not settings.local.json)?"
options:
a: "Personal permissions"
b: "Hook configurations that are committed to the repo"
c: "API keys"
d: "Cost tracking data"
correct: "b"
explanation: |
settings.json stores hook configurations and is committed to the repo for team sharing. It defines hooks for PreToolUse, PostToolUse, UserPromptSubmit events - specifying matchers and hook scripts. Personal permission overrides go in settings.local.json (gitignored). This separation allows team automation while respecting personal preferences.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "3.3 Settings & Permissions"
anchor: "#settingsjson-team-configuration"

293
quiz/questions/04-agents.yaml Normal file
View file

@ -0,0 +1,293 @@
category: "Agents"
category_id: 4
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "04-001"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "What are agents in Claude Code?"
options:
a: "External software programs"
b: "Specialized AI personas for specific tasks that Claude can delegate to"
c: "Human assistants"
d: "Automated scripts"
correct: "b"
explanation: |
Agents are specialized sub-processes (AI personas) that Claude can delegate tasks to. They encapsulate domain expertise, like a security reviewer knowing OWASP Top 10 or a backend architect understanding API design. Think of them as "expert consultants" - instead of explaining everything in your prompt, you invoke an agent that already has that expertise.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.1 What Are Agents"
anchor: "#41-what-are-agents"
- id: "04-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Where should custom agent files be stored?"
options:
a: "~/.claude/agents/"
b: ".claude/agents/"
c: "/agents/"
d: ".claude/commands/"
correct: "b"
explanation: |
Custom agent files should be stored in `.claude/agents/` within your project directory. They are markdown files with YAML frontmatter. For example: `.claude/agents/backend-architect.md`, `.claude/agents/code-reviewer.md`. These can be committed to version control to share with your team.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.2 Creating Custom Agents"
anchor: "#42-creating-custom-agents"
- id: "04-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What fields are REQUIRED in an agent's YAML frontmatter?"
options:
a: "name, model, tools"
b: "name, description"
c: "name, description, model, tools"
d: "name, role, skills"
correct: "b"
explanation: |
Only `name` and `description` are required in agent frontmatter. Optional fields include: model (sonnet default, opus, or haiku), tools (comma-separated list), skills (to inherit), and disallowedTools. The description is crucial - it determines when Claude auto-activates the agent, so make it clear and specific.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.2 Creating Custom Agents"
anchor: "#frontmatter-fields"
- id: "04-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the advantage of using agents over direct prompts?"
options:
a: "Agents are faster"
b: "Agents encapsulate expertise so you don't need to explain everything each time"
c: "Agents cost less"
d: "Agents can access more files"
correct: "b"
explanation: |
Agents encapsulate expertise. Without agents, you'd write: "Review this code for security issues, focusing on OWASP Top 10, checking for SQL injection, XSS, CSRF..." With agents: "Use the security-reviewer agent to audit this code." The agent already has that expertise, making your prompts shorter and more consistent.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.1 What Are Agents"
anchor: "#agent-vs-direct-prompt"
- id: "04-005"
difficulty: "senior"
profiles: ["senior", "power"]
question: "Which model should you use for agents performing complex architectural analysis?"
options:
a: "haiku - for speed"
b: "sonnet - for balance"
c: "opus - for maximum reasoning"
d: "Any model works equally well"
correct: "c"
explanation: |
Use opus for complex reasoning and architecture tasks. Model selection guidelines: haiku (fast, low cost) for quick tasks and simple changes; sonnet (balanced, default) for most tasks; opus (slow, high cost) for complex reasoning, architecture decisions, and critical security reviews. Match the model to the task's complexity.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.2 Creating Custom Agents"
anchor: "#model-selection"
- id: "04-006"
difficulty: "power"
profiles: ["power"]
question: "What is 'Tool SEO' in agent design?"
options:
a: "Making tools searchable online"
b: "Optimizing the description field to improve when Claude auto-activates the agent"
c: "SEO for documentation"
d: "A marketing technique"
correct: "b"
explanation: |
Tool SEO optimizes the agent's description field to improve auto-activation. Techniques include: using "use PROACTIVELY" to encourage automatic activation, listing explicit trigger keywords, describing specific contexts, and adding short nicknames. A good description: "Security code reviewer - use PROACTIVELY when: reviewing auth code, analyzing API endpoints... Triggers: security, auth, vulnerability, OWASP"
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.6 Advanced Agent Patterns"
anchor: "#tool-seo---optimizing-agent-descriptions"
- id: "04-007"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the best practice for agent design: specialization or generalization?"
options:
a: "Create one generalist agent that does everything"
b: "Create specialized agents for each domain (security, testing, backend, etc.)"
c: "Mix specialized and generalist agents"
d: "Avoid agents entirely"
correct: "b"
explanation: |
Always prefer specialization over generalization. Good: separate agents for backend-architect (API, database, performance), security-reviewer (OWASP, auth, encryption), test-engineer (test strategy, coverage, TDD). Bad: one full-stack-expert that "does everything (poorly)". Specialized agents have focused context and domain-specific expertise.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.4 Best Practices"
anchor: "#specialization-over-generalization"
- id: "04-008"
difficulty: "senior"
profiles: ["senior", "power"]
question: "How can agents inherit knowledge from skills?"
options:
a: "By copying skill content into the agent"
b: "Using the 'skills' field in the frontmatter"
c: "Skills and agents cannot be combined"
d: "By importing skill files"
correct: "b"
explanation: |
Agents inherit skills using the `skills` field in frontmatter. For example: `skills: [security-guardian]`. This composes expertise without duplication - instead of copying OWASP knowledge into every security-related agent, they all inherit from the security-guardian skill. This follows DRY principles for knowledge organization.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.4 Best Practices"
anchor: "#skill-composition"
- id: "04-009"
difficulty: "power"
profiles: ["power"]
question: "What is the '7-Parallel-Task Method'?"
options:
a: "Running 7 Claude instances simultaneously"
b: "Launching 7 specialized sub-agents in parallel to implement complete features"
c: "A debugging technique"
d: "A code review checklist"
correct: "b"
explanation: |
The 7-Parallel-Task Method launches 7 specialized sub-agents in parallel: 1) Components, 2) Styles, 3) Tests, 4) Types, 5) Hooks, 6) Integration, 7) Config. All run in parallel, then results are consolidated. This dramatically speeds up feature implementation by parallelizing independent work streams.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.6 Advanced Agent Patterns"
anchor: "#the-7-parallel-task-method"
- id: "04-010"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the recommended agent weight for frequently-used tasks?"
options:
a: "Heavy (25K+ tokens) for thoroughness"
b: "Medium (10-15K tokens) for balance"
c: "Lightweight (<3K tokens) for speed"
d: "Weight doesn't matter"
correct: "c"
explanation: |
Use lightweight agents (<3K tokens, <1s init time) for frequent tasks and workers. Golden Rule: "A lightweight agent used 100x > A heavy agent used 10x." Agent weight categories: Lightweight (<3K tokens) for frequent tasks, Medium (10-15K) for analysis/reviews, Heavy (25K+) for architecture/full audits. Match weight to task frequency.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.6 Advanced Agent Patterns"
anchor: "#agent-weight-classification"
- id: "04-011"
difficulty: "power"
profiles: ["power"]
question: "In multi-agent orchestration, what model combination is recommended?"
options:
a: "Opus everywhere for quality"
b: "Haiku everywhere for cost savings"
c: "Sonnet orchestrator + Haiku workers + Sonnet validator"
d: "Use the same model for all agents"
correct: "c"
explanation: |
The recommended pattern is: Sonnet as orchestrator (coordinates), Haiku workers (parallel execution), Sonnet validator (final check). This is 2-2.5x cheaper than using Opus everywhere with equivalent quality for 90% of tasks. For example, refactoring 100 files: Sonnet analyzes and plans, Haiku does parallel edits, Sonnet validates - saving 80-90% cost.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.6 Advanced Agent Patterns"
anchor: "#multi-agent-orchestration-pattern"
- id: "04-012"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What should an agent's output format section include?"
options:
a: "Only code examples"
b: "Structured deliverables like reports with sections, severity levels, and recommendations"
c: "Raw text output"
d: "JSON only"
correct: "b"
explanation: |
An agent's output format should specify structured deliverables. For example, a code reviewer agent outputs: Summary, Critical Issues (Must Fix) with file:line references, Warnings (Should Fix), Suggestions (Nice to Have), and Positive Notes. Clear output format ensures consistent, actionable results across all invocations.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.5 Agent Examples"
anchor: "#example-1-code-reviewer-agent"
- id: "04-013"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the purpose of the 'disallowedTools' field in agent frontmatter?"
options:
a: "To list tools the agent must use"
b: "To block specific tools from being used by the agent"
c: "To disable the agent"
d: "To list deprecated tools"
correct: "b"
explanation: |
The disallowedTools field blocks specific tools from being used by the agent. For example, a code reviewer agent might have `disallowedTools: [WebSearch]` to ensure it focuses on the actual code rather than searching the web. This provides security boundaries and focuses the agent on its core purpose.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.2 Creating Custom Agents"
anchor: "#agent-file-structure"
- id: "04-014"
difficulty: "power"
profiles: ["power"]
question: "What is the 'Split Role Sub-Agents' pattern?"
options:
a: "Dividing one agent into multiple files"
b: "Multi-perspective analysis using parallel agents with different expert roles"
c: "Splitting code review into phases"
d: "Assigning agents to different team members"
correct: "b"
explanation: |
Split Role Sub-Agents provide multi-perspective analysis in parallel. Process: 1) Activate Plan Mode + ultrathink, 2) Ask "What expert roles would analyze this?", 3) Select roles (e.g., Security Expert, Senior Dev, Code Reviewer), 4) Run parallel analysis from each perspective, 5) Consolidate reports into recommendations. Great for comprehensive code and UX reviews.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.6 Advanced Agent Patterns"
anchor: "#split-role-sub-agents"
- id: "04-015"
difficulty: "senior"
profiles: ["senior", "power"]
question: "When should parallel execution of agents be avoided?"
options:
a: "When tasks are read-only"
b: "When tasks are destructive (write operations) and dependent on each other"
c: "When using haiku model"
d: "When more than 3 agents are involved"
correct: "b"
explanation: |
Avoid parallel execution for destructive (write) operations that are dependent on each other. The decision matrix: Independent + Non-destructive = Parallel (max efficiency); Independent + Destructive = Sequential with Plan Mode first; Dependent operations = Sequential (order matters). Parallel writes risk conflicts if files share imports/exports.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.6 Advanced Agent Patterns"
anchor: "#parallelization-decision-matrix"
- id: "04-016"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What does a Debugger agent's methodology typically include?"
options:
a: "Only fixing code"
b: "Reproduce, Isolate, Analyze, Hypothesize, Test, Fix, Verify"
c: "Just running tests"
d: "Deleting problematic code"
correct: "b"
explanation: |
A systematic Debugger agent follows: 1) Reproduce - confirm the issue exists, 2) Isolate - narrow down to smallest reproducible case, 3) Analyze - read code, check logs, trace execution, 4) Hypothesize - form theories about cause, 5) Test - verify hypothesis with minimal changes, 6) Fix - implement solution, 7) Verify - confirm fix works without breaking other things. Never guess - always verify.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.5 Agent Examples"
anchor: "#example-2-debugger-agent"
- id: "04-017"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is an example of a BAD agent description?"
options:
a: "'Use when designing APIs, reviewing database schemas, or optimizing backend performance'"
b: "'Backend stuff'"
c: "'Security code reviewer - use PROACTIVELY when reviewing auth code'"
d: "'Use when encountering errors, test failures, or unexpected behavior'"
correct: "b"
explanation: |
"Backend stuff" is a bad description - it's too vague to help Claude know when to activate the agent. Good descriptions are specific: "Use when designing APIs, reviewing database schemas, or optimizing backend performance" or "Security code reviewer - use PROACTIVELY when reviewing auth code." Clear activation triggers improve agent utilization.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.4 Best Practices"
anchor: "#explicit-activation-triggers"

310
quiz/questions/05-skills.yaml Normal file
View file

@ -0,0 +1,310 @@
category: "Skills"
category_id: 5
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "05-001"
difficulty: "junior"
profiles: ["junior", "senior", "power", "pm"]
question: "What is the relationship between Skills and Agents?"
options:
a: "Skills replace agents"
b: "Skills are knowledge packages that agents can inherit"
c: "Agents are a type of skill"
d: "They are completely independent"
correct: "b"
explanation: |
Skills are knowledge packages that agents can inherit. While agents are specialized roles (task-focused), skills are reusable knowledge modules (domain-focused). Multiple agents can inherit the same skill, avoiding duplication. For example, both a code-reviewer and security-auditor agent can inherit the security-guardian skill.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.1 Understanding Skills"
anchor: "#51-understanding-skills"
- id: "05-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Where should skill files be stored?"
options:
a: ".claude/commands/"
b: ".claude/skills/{skill-name}/"
c: ".claude/agents/"
d: "~/.claude/skills/"
correct: "b"
explanation: |
Skills live in `.claude/skills/{skill-name}/` directories within your project. Each skill has its own folder containing at minimum a SKILL.md file, with optional reference.md, checklists/, examples/, and scripts/ subdirectories. This organization keeps knowledge modular and reusable.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.2 Creating Skills"
anchor: "#52-creating-skills"
- id: "05-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the REQUIRED file in a skill folder?"
options:
a: "README.md"
b: "skill.yaml"
c: "SKILL.md"
d: "index.md"
correct: "c"
explanation: |
SKILL.md is the required main file in every skill folder. Optional files include: reference.md (detailed documentation), checklists/ (verification lists), examples/ (code patterns with good/bad examples), and scripts/ (helper scripts). SKILL.md contains the frontmatter and core instructions for the skill.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.2 Creating Skills"
anchor: "#skill-folder-structure"
- id: "05-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the key difference between Skills, Agents, and Commands?"
options:
a: "They all do the same thing"
b: "Skills = knowledge modules (inherited), Agents = specialized roles (delegated), Commands = process workflows (slash invoked)"
c: "Commands are the only reusable component"
d: "Agents cannot use skills or commands"
correct: "b"
explanation: |
The three concepts have distinct purposes: Skills are knowledge modules inherited by agents (like OWASP security knowledge), Agents are specialized roles that Claude delegates tasks to (like a security reviewer), and Commands are process workflows invoked with slash commands (like /tech:commit). They can be combined: agents inherit skills and execute commands.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.1 Understanding Skills"
anchor: "#skills-vs-agents-vs-commands"
- id: "05-005"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What does the 'context' field in SKILL.md frontmatter control?"
options:
a: "The context window size"
b: "Whether the skill runs in isolated (fork) or shared (inherit) context"
c: "The file context to load"
d: "Database connection context"
correct: "b"
explanation: |
The `context` field controls execution context: 'fork' means isolated context (the skill runs independently), 'inherit' means shared context (the skill shares context with the calling agent). Use fork for skills that need clean state, inherit for skills that need access to conversation history and loaded files.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.2 Creating Skills"
anchor: "#skillmd-frontmatter"
- id: "05-006"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Why use skills instead of duplicating knowledge in multiple agents?"
options:
a: "Skills are faster"
b: "Skills provide single source of truth - update once, all agents benefit"
c: "Skills are required by Claude Code"
d: "Skills cost less"
correct: "b"
explanation: |
Skills follow DRY (Don't Repeat Yourself) principles. Without skills, you'd duplicate security knowledge in Agent A, B, and C. With skills, the security-guardian skill is the single source - all agents inherit it, and updates propagate everywhere. This ensures consistency and simplifies maintenance.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.1 Understanding Skills"
anchor: "#why-skills"
- id: "05-007"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What makes a GOOD skill versus a BAD skill?"
options:
a: "Good skills are longer, bad skills are shorter"
b: "Good skills are reusable, domain-focused, and include reference material; bad skills are single-agent specific and too broad"
c: "Good skills use opus, bad skills use haiku"
d: "Good skills have more files"
correct: "b"
explanation: |
Good skills are: reusable across multiple agents, domain-focused (not too broad), contain reference material and checklists, and include verification steps. Bad skills are: specific to only one agent, too broad in scope, just instructions without reference material, and missing verification checklists.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.1 Understanding Skills"
anchor: "#what-makes-a-good-skill"
- id: "05-008"
difficulty: "power"
profiles: ["power"]
question: "What is the TDD (Test-Driven Development) skill's core methodology?"
options:
a: "Write tests after code"
b: "RED (failing test) -> GREEN (minimal code to pass) -> REFACTOR (improve while green)"
c: "Write all tests first, then all code"
d: "Skip tests for speed"
correct: "b"
explanation: |
The TDD skill follows: 1) RED - write a failing test for desired behavior BEFORE code, 2) GREEN - write MINIMUM code to make the test pass, 3) REFACTOR - improve implementation while keeping tests green, then repeat. This cycle ensures tests actually verify behavior by requiring failure first, then incremental improvement.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.4 Skill Examples"
anchor: "#example-2-tdd-skill"
- id: "05-009"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What should a Security Guardian skill include for OWASP coverage?"
options:
a: "Just a list of vulnerabilities"
b: "Checklists for each OWASP Top 10 category with specific verification items"
c: "Links to external security tools"
d: "Password examples"
correct: "b"
explanation: |
A Security Guardian skill should include detailed checklists for each OWASP Top 10 category: A01 Broken Access Control (check authorization, IDOR, privilege escalation), A02 Cryptographic Failures (hardcoded secrets, TLS, password hashing), A03 Injection (SQL, NoSQL, XSS), etc. Each category should have specific verification items with checkboxes.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.4 Skill Examples"
anchor: "#example-1-security-guardian-skill"
- id: "05-010"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the 'agent' field in SKILL.md frontmatter?"
options:
a: "Which agent created the skill"
b: "Whether the skill is 'specialist' (domain-focused) or 'general' (broad)"
c: "The agent that must use this skill"
d: "The agent's name"
correct: "b"
explanation: |
The `agent` field indicates whether the skill is 'specialist' (domain-focused, deep expertise in one area) or 'general' (broad, applicable across domains). Specialist skills like security-guardian provide deep domain knowledge, while general skills might provide widely-applicable patterns or utilities.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.2 Creating Skills"
anchor: "#skillmd-frontmatter"
- id: "05-011"
difficulty: "power"
profiles: ["power"]
question: "What does the 'allowed-tools' field in skill frontmatter control?"
options:
a: "Tools the skill documents"
b: "Tools the skill can use when activated"
c: "Tools that can activate the skill"
d: "Tools to install"
correct: "b"
explanation: |
The `allowed-tools` field specifies which tools the skill can use when activated. For example, a security-guardian skill might have `allowed-tools: Read, Grep, Bash` - allowing it to read files, search for patterns, and run security scanning commands, but not modify files. This provides security boundaries for each skill.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.2 Creating Skills"
anchor: "#skillmd-frontmatter"
- id: "05-012"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What optional folders can a skill directory contain?"
options:
a: "Only SKILL.md is allowed"
b: "reference.md, checklists/, examples/, and scripts/"
c: "src/, dist/, and node_modules/"
d: "tests/, docs/, and config/"
correct: "b"
explanation: |
A skill directory can contain: SKILL.md (required), reference.md (detailed documentation), checklists/ (verification lists like security.md, performance.md), examples/ (code patterns like good-example.ts, bad-example.ts), and scripts/ (helper scripts like audit.sh). This rich structure supports comprehensive domain knowledge.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.2 Creating Skills"
anchor: "#skill-folder-structure"
- id: "05-013"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "In the Security Guardian skill, what is an example of GOOD password hashing?"
options:
a: "md5(password)"
b: "sha1(password)"
c: "argon2 or bcrypt"
d: "Base64 encoding"
correct: "c"
explanation: |
The Security Guardian skill shows argon2 or bcrypt as secure password hashing. BAD examples explicitly listed: md5(password) and sha1(password) - these are cryptographically broken for password storage. Good pattern: `const hashedPassword = await hash(password)` using argon2 library. Always verify password with `await verify(hashedPassword, inputPassword)`.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.4 Skill Examples"
anchor: "#authentication-patterns"
- id: "05-014"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the AAA pattern in TDD testing?"
options:
a: "Ask, Answer, Assert"
b: "Arrange, Act, Assert"
c: "Analyze, Apply, Approve"
d: "Accept, Adjust, Acknowledge"
correct: "b"
explanation: |
AAA stands for Arrange, Act, Assert: 1) Arrange - set up test data and preconditions, 2) Act - execute the code being tested, 3) Assert - verify the result matches expectations. Example: Arrange items array, Act by calling calculateTotal(items), Assert that total equals expected value. This structure makes tests readable and maintainable.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.4 Skill Examples"
anchor: "#test-structure-aaa-pattern"
- id: "05-015"
difficulty: "power"
profiles: ["power"]
question: "What community skill repository focuses on cybersecurity and penetration testing?"
options:
a: "awesome-claude-skills"
b: "claude-security-pack"
c: "zebbern/claude-code-guide with 29 cybersecurity skills"
d: "owasp-claude-skills"
correct: "c"
explanation: |
The zebbern/claude-code-guide repository contains 29 cybersecurity-focused skills covering: penetration testing (SQL injection, XSS, IDOR), security tools (Metasploit, Burp Suite, SQLMap), infrastructure security (AWS, Cloud, Network), and methodologies (ethical hacking, pentest checklists). Important: these should be tested thoroughly and used only with proper authorization.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.5 Community Skill Repositories"
anchor: "#cybersecurity-skills-repository"
- id: "05-016"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What should skills include to be most useful?"
options:
a: "Only theory and concepts"
b: "Checklists, good/bad code examples, and methodology steps"
c: "Links to external websites"
d: "Marketing descriptions"
correct: "b"
explanation: |
Useful skills include: methodology steps (clear process to follow), checklists (verification items with checkboxes), good/bad code examples (showing correct patterns and anti-patterns), and reference material. This combination provides both theoretical knowledge and practical guidance that agents can apply directly to tasks.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.3 Skill Template"
anchor: "#53-skill-template"
- id: "05-017"
difficulty: "senior"
profiles: ["senior", "power"]
question: "How do you reference a skill in an agent's frontmatter?"
options:
a: "import: skill-name"
b: "skills: [skill-name]"
c: "use: skill-name"
d: "require: skill-name"
correct: "b"
explanation: |
Reference skills in an agent's frontmatter using the `skills` array: `skills: [security-guardian, tdd]`. This makes the agent inherit all knowledge from those skills. You can reference multiple skills, and the agent combines their expertise. The skill name matches the folder name in `.claude/skills/`.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "4.4 Best Practices"
anchor: "#skill-composition"
- id: "05-018"
difficulty: "power"
profiles: ["power"]
question: "What disclaimer applies to community cybersecurity skills?"
options:
a: "They are officially certified"
b: "Test thoroughly, ensure authorization, verify against policies, use only legally"
c: "They work on all systems"
d: "No disclaimer needed"
correct: "b"
explanation: |
Community cybersecurity skills come with important disclaimers: test thoroughly before using in production assessments, ensure you have proper authorization before penetration testing, review and validate against your organization's security policies, use only in legal contexts with written permission from system owners, and contribute back if you find issues. Verification is essential for any security tooling.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "5.5 Community Skill Repositories"
anchor: "#important-disclaimer"

306
quiz/questions/06-commands.yaml Normal file
View file

@ -0,0 +1,306 @@
category: "Commands"
category_id: 6
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "06-001"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Where should custom commands be placed to make them available in Claude Code?"
options:
a: "~/.claude/commands/"
b: ".claude/commands/"
c: "/usr/local/claude/commands/"
d: ".claude/config/commands/"
correct: "b"
explanation: |
Custom commands are placed in `.claude/commands/` within your project directory.
This allows project-specific commands that can be committed with your codebase.
The global directory `~/.claude/` is for personal settings, not project commands.
Commands are organized in subdirectories:
- `.claude/commands/tech/` for development workflows
- `.claude/commands/product/` for product workflows
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.2 Creating Custom Commands"
anchor: "#62-creating-custom-commands"
- id: "06-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "How do you invoke a custom command named `commit.md` located in `.claude/commands/tech/`?"
options:
a: "/commit"
b: "/tech-commit"
c: "/tech:commit"
d: "!tech/commit"
correct: "c"
explanation: |
Custom commands use the format `/folder:filename` (without the .md extension).
So `.claude/commands/tech/commit.md` becomes `/tech:commit`.
This naming convention allows organizing commands by domain while keeping invocation intuitive.
Examples:
- `.claude/commands/tech/pr.md` -> `/tech:pr`
- `.claude/commands/product/scope.md` -> `/product:scope`
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.2 Creating Custom Commands"
anchor: "#command-naming"
- id: "06-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What variable is used in command files to access arguments passed to the command?"
options:
a: "$ARGS"
b: "$INPUT"
c: "$ARGUMENTS"
d: "$PARAMS"
correct: "c"
explanation: |
The `$ARGUMENTS` variable contains any text passed after the command invocation.
For example, when you run `/tech:deploy production`, the variable `$ARGUMENTS`
will contain `production`.
This enables dynamic commands that can adapt based on user input.
Commands should document how they handle arguments and what happens if none are provided.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.2 Creating Custom Commands"
anchor: "#variable-interpolation"
- id: "06-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which built-in command shows all available commands including custom ones?"
options:
a: "/commands"
b: "/list"
c: "/help"
d: "/show"
correct: "c"
explanation: |
The `/help` command displays all available commands, both built-in and custom.
Built-in commands include:
- `/clear` - Clear conversation
- `/compact` - Summarize context
- `/status` - Show session info
- `/plan` - Enter Plan Mode
- `/rewind` - Undo changes
Custom commands from `.claude/commands/` are also listed here.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.1 Slash Commands"
anchor: "#61-slash-commands"
- id: "06-005"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What sections should a well-structured command template include according to best practices?"
options:
a: "Purpose, Steps, Output"
b: "Purpose, Process, Arguments, Output Format, Examples, Error Handling"
c: "Name, Description, Code"
d: "Title, Body, Footer"
correct: "b"
explanation: |
A complete command template should include:
1. **Purpose** - Brief description of what the command does
2. **Process** - Step-by-step instructions Claude should follow
3. **Arguments** - How to handle $ARGUMENTS (if provided/not provided)
4. **Output Format** - Expected structure of the output
5. **Examples** - Concrete usage examples
6. **Error Handling** - How to handle edge cases and failures
This comprehensive structure ensures consistent, reliable command execution.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.3 Command Template"
anchor: "#63-command-template"
- id: "06-006"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which command enters Plan Mode for safe, read-only exploration?"
options:
a: "/safe"
b: "/readonly"
c: "/plan"
d: "/explore"
correct: "c"
explanation: |
The `/plan` command enters Plan Mode, where Claude can analyze and explore
the codebase without making any changes.
This is ideal for:
- Understanding unfamiliar codebases
- Architectural analysis before changes
- Safe exploration of risky operations
Use `/execute` to exit Plan Mode when ready to make changes.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.1 Slash Commands"
anchor: "#built-in-commands"
- id: "06-007"
difficulty: "senior"
profiles: ["senior", "power"]
question: "In the commit command example, what is the recommended commit message format?"
options:
a: "Simple description"
b: "Conventional Commits: type(scope): description"
c: "Date - Author - Message"
d: "JIRA-123: Message"
correct: "b"
explanation: |
The guide recommends Conventional Commits format: `type(scope): description`
Common types:
- `feat`: New feature
- `fix`: Bug fix
- `refactor`: Code restructuring
- `docs`: Documentation
- `test`: Test changes
- `chore`: Maintenance
This provides consistent, parseable commit history useful for changelogs and releases.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.4 Command Examples"
anchor: "#example-1-commit-command"
- id: "06-008"
difficulty: "power"
profiles: ["power"]
question: "What technique does the Problem Framer command use to find root causes?"
options:
a: "SWOT Analysis"
b: "5 Whys Analysis"
c: "Pareto Analysis"
d: "Fishbone Diagram"
correct: "b"
explanation: |
The Problem Framer command uses the "5 Whys Analysis" technique.
This involves asking "Why?" five times to drill down to the root cause:
- Why 1: First answer
- Why 2: Deeper answer
- Why 3: Even deeper
- Why 4: Getting to root
- Why 5: Root cause
The command then reframes the problem as: "How might we [action] for [user] so that [outcome]?"
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.4 Command Examples"
anchor: "#example-3-problem-framer-command"
- id: "06-009"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What does the `/rewind` command do?"
options:
a: "Restores a previous git commit"
b: "Undoes Claude's recent changes in the current session"
c: "Clears the entire conversation history"
d: "Rolls back the last command execution"
correct: "b"
explanation: |
The `/rewind` command undoes Claude's recent changes in the current session.
Key points:
- Works only for uncommitted changes made by Claude
- Does NOT create git commits
- Use when Claude made a mistake and you want to try a different approach
For committed changes, use `git revert` instead.
The keyboard shortcut `Esc×2` (double-tap Escape) also triggers rewind.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.1 Slash Commands"
anchor: "#built-in-commands"
- id: "06-010"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What should a PR command's error handling do if the user is NOT on a feature branch?"
options:
a: "Automatically create a feature branch"
b: "Proceed anyway with warnings"
c: "WARN: Create a feature branch first"
d: "Exit silently"
correct: "c"
explanation: |
According to the PR command example, if the user is not on a feature branch,
the command should WARN: "Create a feature branch first".
Similarly, if the working directory is dirty, it should ASK: "Commit changes first?"
Good command design includes clear error handling that:
- Warns users about prerequisites
- Suggests corrective actions
- Prevents accidental mistakes
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.4 Command Examples"
anchor: "#example-2-pr-command"
- id: "06-011"
difficulty: "power"
profiles: ["power"]
question: "What is the recommended order of git commands in a PR creation workflow?"
options:
a: "push, diff, create PR"
b: "status, branch, log, diff, push if needed, create PR"
c: "add, commit, push, create PR"
d: "checkout, status, push, create PR"
correct: "b"
explanation: |
The recommended PR workflow order is:
1. `git status` - Verify clean working directory
2. `git branch` - Confirm on feature branch
3. `git log main..HEAD` - Review all commits
4. `git diff main...HEAD` - See all changes vs main
5. `git push -u origin [branch]` - Push if not already pushed
6. `gh pr create` - Create the PR
This thorough process ensures quality PRs with proper context.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "6.4 Command Examples"
anchor: "#example-2-pr-command"
- id: "06-012"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "How do you reference a file when talking to Claude Code?"
options:
a: "#filename"
b: "@filename"
c: "!filename"
d: "$filename"
correct: "b"
explanation: |
The `@filename` syntax references a file in your conversation with Claude.
Quick actions:
- `@file` - Reference a file
- `!command` - Run a shell command
- `Ctrl+C` - Cancel operation
- `Ctrl+R` - Retry last
This allows you to easily bring specific files into context for Claude to analyze.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.1 Commands Table"
anchor: "#quick-actions"

382
quiz/questions/07-hooks.yaml Normal file
View file

@ -0,0 +1,382 @@
category: "Hooks"
category_id: 7
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "07-001"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What exit code should a hook return to BLOCK an operation?"
options:
a: "0"
b: "1"
c: "2"
d: "255"
correct: "c"
explanation: |
Hook exit codes have specific meanings:
- **Exit code 0**: Success - Allow the operation to proceed
- **Exit code 2**: Block - Prevent the operation from executing
- **Other codes**: Error - Log the error and continue
This is critical for security hooks that need to prevent dangerous commands.
For example, a hook that detects `rm -rf /` should `exit 2` to block execution.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.2 Creating Hooks"
anchor: "#exit-codes"
- id: "07-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which hook event fires BEFORE a tool is executed?"
options:
a: "BeforeToolUse"
b: "PreToolUse"
c: "ToolStart"
d: "OnToolCall"
correct: "b"
explanation: |
The `PreToolUse` event fires before any tool runs.
Common event types:
- **PreToolUse**: Before tool execution (ideal for security validation)
- **PostToolUse**: After tool execution (for formatting, logging)
- **UserPromptSubmit**: When user sends a message (context enrichment)
- **Notification**: When Claude sends a notification
- **SessionStart/SessionEnd**: Session lifecycle events
- **Stop**: When user interrupts
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.1 The Event System"
anchor: "#event-types"
- id: "07-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "How do hooks receive input data from Claude Code?"
options:
a: "As command-line arguments"
b: "As JSON on stdin"
c: "As environment variables"
d: "From a temporary file"
correct: "b"
explanation: |
Hooks receive JSON data on stdin with information about the event.
Example input structure:
```json
{
"tool_name": "Bash",
"tool_input": {
"command": "git status"
},
"session_id": "abc123",
"cwd": "/project"
}
```
Hooks typically parse this with: `INPUT=$(cat)` followed by `jq` for JSON extraction.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.2 Creating Hooks"
anchor: "#hook-input-stdin-json"
- id: "07-004"
difficulty: "senior"
profiles: ["senior", "power"]
question: "In the hook registration (settings.json), what does the `matcher` field specify?"
options:
a: "File extensions to watch"
b: "Regex pattern for which tools trigger the hook"
c: "User permission levels"
d: "Output format requirements"
correct: "b"
explanation: |
The `matcher` field is a regex pattern that determines which tools trigger the hook.
Example configuration:
```json
{
"matcher": "Bash|Edit|Write",
"hooks": [{"type": "command", "command": "./hooks/security-check.sh"}]
}
```
This hook would trigger for Bash, Edit, or Write tools.
You can match specific tools or use `.*` to match all tools.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.2 Creating Hooks"
anchor: "#configuration-fields"
- id: "07-005"
difficulty: "power"
profiles: ["power"]
question: "What is the best use case for the `UserPromptSubmit` hook event?"
options:
a: "Blocking dangerous commands"
b: "Auto-formatting code"
c: "Adding context like git status to every prompt"
d: "Playing notification sounds"
correct: "c"
explanation: |
The `UserPromptSubmit` event is ideal for context enrichment.
Use cases:
- **UserPromptSubmit**: Add context (git status, current branch, staged files)
- **PreToolUse**: Security validation (block dangerous commands)
- **PostToolUse**: Formatting, logging, quality checks
- **Notification**: Sound alerts, desktop notifications
The context enricher example adds git branch, last commit, and staged/unstaged info.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.3 Hook Templates"
anchor: "#template-3-userpromptsubmit-context-enricher"
- id: "07-006"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What exit code allows an operation to proceed?"
options:
a: "1"
b: "0"
c: "2"
d: "-1"
correct: "b"
explanation: |
Exit code 0 means success and allows the operation to proceed.
The exit code system:
- **0**: Success - Allow operation
- **2**: Block - Prevent operation
- **Other**: Error - Log and continue
Always end your hooks with `exit 0` if you want to allow the operation,
or `exit 2` to block it.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.2 Creating Hooks"
anchor: "#exit-codes"
- id: "07-007"
difficulty: "senior"
profiles: ["senior", "power"]
question: "Which commands should a security hook typically block?"
options:
a: "git status, npm test"
b: "rm -rf /, sudo rm, git push --force origin main"
c: "cd, ls, pwd"
d: "npm install, pip install"
correct: "b"
explanation: |
Security hooks should block dangerous operations like:
- `rm -rf /` or `rm -rf ~` - Filesystem destruction
- `sudo rm` - Privileged deletion
- `git push --force origin main` - Force push to protected branches
- `npm publish` - Accidental package publishing
- `> /dev/sda` or `dd if=` - Direct disk operations
Safe commands like `git status`, `npm test`, `ls` should be allowed.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.4 Security Hooks"
anchor: "#recommended-security-rules"
- id: "07-008"
difficulty: "power"
profiles: ["power"]
question: "What JSON structure should a hook return to send a message back to Claude?"
options:
a: '{"message": "text"}'
b: '{"systemMessage": "text", "hookSpecificOutput": {...}}'
c: '{"response": "text"}'
d: '{"output": "text"}'
correct: "b"
explanation: |
Hooks return JSON on stdout with specific fields:
```json
{
"systemMessage": "Message shown to Claude",
"hookSpecificOutput": {
"additionalContext": "Extra information"
}
}
```
- `systemMessage`: Displayed to Claude as context
- `hookSpecificOutput`: Additional structured data
This allows hooks to provide context that Claude can use in its responses.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.2 Creating Hooks"
anchor: "#hook-output"
- id: "07-009"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the recommended approach for tasks that need 'understanding' vs pattern-based tasks?"
options:
a: "Both should use bash scripts"
b: "Both should use AI agents"
c: "Pattern-based use bash scripts; understanding-needed use AI agents"
d: "Pattern-based use AI agents; understanding-needed use bash scripts"
correct: "c"
explanation: |
The guide recommends choosing the right tool:
**Use Bash scripts when:**
- Tasks are deterministic (create branch, push)
- Pattern-based (check for secrets with regex)
- Fast, predictable, no token cost
**Use AI Agents when:**
- Interpretation is needed (code review quality)
- Context-dependent decisions
- Understanding and judgment required
Rule: "If you can write a regex for it, use a bash script."
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.1 The Event System"
anchor: "#shell-scripts-vs-ai-agents-when-to-use-what"
- id: "07-010"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which hook event fires AFTER a tool has finished executing?"
options:
a: "AfterToolUse"
b: "PostToolUse"
c: "ToolComplete"
d: "OnToolDone"
correct: "b"
explanation: |
The `PostToolUse` event fires after any tool completes execution.
Common use cases for PostToolUse:
- Auto-formatting code after edits
- Running linters after file changes
- Logging tool usage for auditing
- Triggering tests after code changes
The Auto-Formatter template uses PostToolUse to run Prettier after Edit/Write operations.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.1 The Event System"
anchor: "#event-types"
- id: "07-011"
difficulty: "power"
profiles: ["power"]
question: "How do you test a security hook before deploying it?"
options:
a: "Run Claude Code and hope it works"
b: "Pipe test JSON to the hook script and check the exit code"
c: "Deploy to production and monitor"
d: "Security hooks cannot be tested"
correct: "b"
explanation: |
Test hooks by piping JSON input and checking the exit code:
```bash
# Test with a blocked command
echo '{"tool_name":"Bash","tool_input":{"command":"rm -rf /"}}' | ./hooks/security-blocker.sh
echo "Exit code: $?" # Should be 2
# Test with a safe command
echo '{"tool_name":"Bash","tool_input":{"command":"git status"}}' | ./hooks/security-blocker.sh
echo "Exit code: $?" # Should be 0
```
This ensures your hook correctly blocks dangerous commands before deployment.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.4 Security Hooks"
anchor: "#testing-security-hooks"
- id: "07-012"
difficulty: "senior"
profiles: ["senior", "power"]
question: "In Windows, how should hooks be invoked to avoid execution policy restrictions?"
options:
a: "Run as Administrator"
b: "Use powershell -ExecutionPolicy Bypass -File script.ps1"
c: "Disable all security settings"
d: "Convert to batch files only"
correct: "b"
explanation: |
Windows hooks should use the full PowerShell invocation:
```json
{
"type": "command",
"command": "powershell -ExecutionPolicy Bypass -File .claude/hooks/security-check.ps1"
}
```
This bypasses the default execution policy that might block script execution.
Batch files (.cmd) can also be used as an alternative for simpler hooks.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.3 Hook Templates"
anchor: "#windows-hook-templates"
- id: "07-013"
difficulty: "power"
profiles: ["power"]
question: "What does the activity logger hook example use to store logs?"
options:
a: "SQLite database"
b: "Plain text files"
c: "JSONL (JSON Lines) files"
d: "CSV files"
correct: "c"
explanation: |
The activity logger hook stores logs in JSONL format (JSON Lines).
Key features:
- Logs to `~/.claude/logs/activity-YYYY-MM-DD.jsonl`
- Each entry contains timestamp, tool name, and session ID
- Auto-cleanup of logs older than 7 days
- Uses `jq` for JSON construction
JSONL is ideal for log files as each line is a valid JSON object,
making it easy to append and parse.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.5 Hook Examples"
anchor: "#example-1-activity-logger"
- id: "07-014"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the default timeout for hooks in the configuration?"
options:
a: "1000ms (1 second)"
b: "5000ms (5 seconds)"
c: "30000ms (30 seconds)"
d: "No timeout by default"
correct: "b"
explanation: |
The example hook configuration shows a timeout of 5000ms (5 seconds).
```json
{
"type": "command",
"command": ".claude/hooks/security-check.sh",
"timeout": 5000
}
```
This prevents hooks from blocking Claude Code indefinitely.
For longer operations like formatting, you might increase this to 10000ms.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "7.2 Creating Hooks"
anchor: "#hook-registration-settingsjson"

364
quiz/questions/08-mcp-servers.yaml Normal file
View file

@ -0,0 +1,364 @@
category: "MCP Servers"
category_id: 8
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "08-001"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What does MCP stand for in the context of Claude Code?"
options:
a: "Model Compute Protocol"
b: "Model Context Protocol"
c: "Multi-Channel Processing"
d: "Module Configuration Protocol"
correct: "b"
explanation: |
MCP stands for Model Context Protocol.
It is a standard for connecting AI models to external tools and data sources.
MCP enables Claude Code to extend beyond built-in tools by connecting to:
- Semantic code analysis (Serena)
- Documentation lookup (Context7)
- Database queries (Postgres)
- Browser automation (Playwright)
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.1 What is MCP"
anchor: "#81-what-is-mcp"
- id: "08-002"
difficulty: "senior"
profiles: ["senior", "power"]
question: "Which MCP server should you use to find all usages of a function across your codebase?"
options:
a: "Context7"
b: "Sequential Thinking"
c: "Serena"
d: "Postgres"
correct: "c"
explanation: |
Serena provides semantic code analysis with tools like `find_referencing_symbols`.
Serena tools include:
- `find_symbol` - Find functions, classes, methods by name
- `get_symbols_overview` - Get file structure overview
- `find_referencing_symbols` - Find all usages of a symbol
- `search_for_pattern` - Regex search across codebase
Use Serena for deep code understanding and symbol-level analysis.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.2 Available Servers"
anchor: "#serena-semantic-code-analysis"
- id: "08-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "Which MCP server is best for looking up official library documentation?"
options:
a: "Serena"
b: "Context7"
c: "Sequential Thinking"
d: "mgrep"
correct: "b"
explanation: |
Context7 is designed for accessing official library documentation.
Use Context7 when:
- Learning new libraries
- Finding correct API usage
- Checking official patterns
For example, "How does React useEffect work?" should use Context7
to get the official documentation rather than generic knowledge.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.4 Server Selection Guide"
anchor: "#server-comparison"
- id: "08-004"
difficulty: "power"
profiles: ["power"]
question: "Which MCP server provides persistent memory across sessions?"
options:
a: "Context7"
b: "Postgres"
c: "Serena"
d: "Sequential Thinking"
correct: "c"
explanation: |
Serena provides session memory that persists across conversations.
Serena memory tools:
- `write_memory` - Save context for future sessions
- `read_memory` - Retrieve saved context
- `list_memories` - List all stored memories
Memory is stored in `.serena/memories/` and survives between Claude Code sessions.
This is crucial for maintaining context on long-running projects.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.2 Available Servers"
anchor: "#session-memory-workflow"
- id: "08-005"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Where is the global MCP configuration file located?"
options:
a: "~/.mcp/config.json"
b: "~/.claude/mcp.json"
c: "/etc/claude/mcp.json"
d: "~/.config/claude/mcp.json"
correct: "b"
explanation: |
The global MCP configuration is at `~/.claude/mcp.json`.
Configuration locations:
- `~/.claude/mcp.json` - Global (applies to all projects)
- `/project/.claude/mcp.json` - Project-specific (overrides global)
The configuration specifies which servers to run and their settings.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.3 Configuration"
anchor: "#mcpjson-location"
- id: "08-006"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the recommended MCP server for complex debugging scenarios?"
options:
a: "Context7"
b: "Serena"
c: "Sequential Thinking"
d: "Postgres"
correct: "c"
explanation: |
Sequential Thinking is designed for multi-step analysis with explicit reasoning.
Use Sequential Thinking for:
- Complex debugging scenarios
- Architectural analysis
- System design decisions
The `sequentialthinking` tool provides step-by-step reasoning that is
ideal for problems requiring systematic investigation.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.4 Server Selection Guide"
anchor: "#decision-tree"
- id: "08-007"
difficulty: "power"
profiles: ["power"]
question: "How can MCP servers work together effectively?"
options:
a: "They cannot - only one server at a time"
b: "Context7 for patterns -> Serena for code -> Sequential for analysis -> Playwright for testing"
c: "All servers must be configured identically"
d: "Servers must be chained in alphabetical order"
correct: "b"
explanation: |
MCP servers can be combined for powerful workflows:
1. **Context7** - Get official pattern for auth
2. **Serena** - Find existing auth code in codebase
3. **Sequential** - Analyze how to integrate
4. **Playwright** - Test the implementation
This combination leverages each server's strengths for comprehensive development.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.4 Server Selection Guide"
anchor: "#combining-servers"
- id: "08-008"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What variable can you use in mcp.json to reference the current project path?"
options:
a: "${projectPath}"
b: "${workspaceFolder}"
c: "${cwd}"
d: "${PROJECT_DIR}"
correct: "b"
explanation: |
The `${workspaceFolder}` variable expands to the current project path.
Variable substitution in mcp.json:
- `${workspaceFolder}` - Current project path
- `${env:VAR_NAME}` - Environment variable
Example:
```json
"env": {
"PROJECT_PATH": "${workspaceFolder}"
}
```
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.3 Configuration"
anchor: "#variable-substitution"
- id: "08-009"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the key advantage of Serena over Claude Code's built-in tools?"
options:
a: "It's faster"
b: "It provides indexation that Claude Code lacks"
c: "It uses less memory"
d: "It works offline"
correct: "b"
explanation: |
Serena fills a critical gap: Claude Code has no built-in indexation (unlike Cursor).
Serena provides:
- **Indexation**: Pre-indexes your codebase for efficient symbol lookup
- **Project Memory**: Stores context between sessions
- **Onboarding**: Auto-analyzes project structure on first run
For large codebases (>10k lines), Serena's indexation dramatically improves performance.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.2 Available Servers"
anchor: "#serena-semantic-code-analysis"
- id: "08-010"
difficulty: "power"
profiles: ["power"]
question: "What distinguishes a Plugin from an MCP Server in Claude Code?"
options:
a: "Plugins are faster"
b: "Plugins bundle Claude-specific workflows; MCP servers add external tool capabilities"
c: "They are identical"
d: "MCP servers are for beginners, plugins for experts"
correct: "b"
explanation: |
The rule of thumb:
- **Plugin** = "How Claude thinks" (new workflows, specialized agents)
- **MCP Server** = "What Claude can do" (new tools, external systems)
Plugins bundle agents, skills, and configuration into installable modules.
MCP servers add external capabilities like database access or browser automation.
Installation differs too:
- Plugins: `claude plugin install`
- MCP: Add to `settings.json` MCP config
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.5 Plugin System"
anchor: "#plugin-vs-mcp-server"
- id: "08-011"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Which MCP server is used for browser automation and E2E testing?"
options:
a: "Serena"
b: "Context7"
c: "Playwright"
d: "Sequential Thinking"
correct: "c"
explanation: |
Playwright MCP provides browser automation capabilities.
Playwright tools include:
- `navigate` - Go to URL
- `click` - Click element
- `fill` - Fill form field
- `screenshot` - Capture screenshot
Use Playwright for:
- E2E testing
- Visual validation
- Browser debugging
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.2 Available Servers"
anchor: "#playwright-browser-automation"
- id: "08-012"
difficulty: "senior"
profiles: ["senior", "power"]
question: "How do you add an MCP server with environment variables via CLI?"
options:
a: "claude mcp add --env API_KEY=key server"
b: "claude mcp add -e API_KEY=key my-server -- npx @org/server"
c: "claude mcp install server --api-key key"
d: "claude add mcp server -k key"
correct: "b"
explanation: |
Use the `-e` flag to pass environment variables:
```bash
claude mcp add -e API_KEY=your-key my-server -- npx @org/server
```
For multiple environment variables:
```bash
claude mcp add -e DATABASE_URL=postgres://... -e DEBUG=true postgres -- npx @prisma/postgres
```
This is quicker than manually editing mcp.json.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.3 Configuration"
anchor: "#cli-based-mcp-configuration"
- id: "08-013"
difficulty: "power"
profiles: ["power"]
question: "What is mgrep's key differentiator compared to Serena?"
options:
a: "It's faster"
b: "It provides semantic search by intent, not just patterns"
c: "It supports more languages"
d: "It has better documentation"
correct: "b"
explanation: |
mgrep excels at intent-based search using natural language:
```bash
# Traditional grep (exact match required)
grep -r "authenticate.*user" .
# mgrep (intent-based)
mgrep "code that handles user authentication"
```
While Serena focuses on symbol-level analysis, mgrep finds code by
describing what it does rather than exact patterns.
Use mgrep for onboarding to unfamiliar codebases or exploring by intent.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.2 Available Servers"
anchor: "#mgrep-semantic-search-alternative"
- id: "08-014"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What command lists all installed plugins in Claude Code?"
options:
a: "claude plugins list"
b: "claude plugin"
c: "/plugins"
d: "claude list plugins"
correct: "b"
explanation: |
Running `claude plugin` (without subcommand) lists all installed plugins with status.
Plugin commands:
- `claude plugin` - List installed plugins
- `claude plugin install <name>` - Install plugin
- `claude plugin enable <name>` - Enable plugin
- `claude plugin disable <name>` - Disable plugin
- `claude plugin uninstall <name>` - Remove plugin
- `claude plugin validate <path>` - Validate plugin manifest
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "8.5 Plugin System"
anchor: "#plugin-commands"

438
quiz/questions/09-advanced-patterns.yaml Normal file
View file

@ -0,0 +1,438 @@
category: "Advanced Patterns"
category_id: 9
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "09-001"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What are the three components of 'The Trinity' pattern?"
options:
a: "Git, VSCode, Terminal"
b: "Plan Mode, Ultrathink, Sequential Thinking"
c: "Serena, Context7, Playwright"
d: "Agent, Skill, Command"
correct: "b"
explanation: |
The Trinity is the most powerful Claude Code pattern combining:
1. **Plan Mode** - Safe exploration without changes
2. **Ultrathink** - Deep analysis with extended thinking
3. **Sequential Thinking (MCP)** - Structured multi-step reasoning
Combined, these provide maximum understanding before taking action.
Use for architecture decisions, complex debugging, and legacy modernization.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.1 The Trinity"
anchor: "#91-the-trinity"
- id: "09-002"
difficulty: "power"
profiles: ["power"]
question: "What is the approximate token usage for --ultrathink?"
options:
a: "~1K tokens"
b: "~4K tokens"
c: "~10K tokens"
d: "~32K tokens"
correct: "d"
explanation: |
Ultrathink levels and token usage:
| Flag | Thinking Depth | Token Usage | Best For |
|------|----------------|-------------|----------|
| `--think` | Standard | ~4K | Multi-component analysis |
| `--think-hard` | Deep | ~10K | Architectural decisions |
| `--ultrathink` | Maximum | ~32K | Critical redesign |
Higher levels increase latency and cost - use the smallest level that works.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.1 The Trinity"
anchor: "#ultrathink-levels"
- id: "09-003"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What CLI flag runs Claude Code without interactive prompts for CI/CD?"
options:
a: "--ci"
b: "--headless"
c: "--batch"
d: "--automated"
correct: "b"
explanation: |
The `--headless` flag runs Claude Code without interactive prompts:
```bash
# Basic headless execution
claude --headless "Run the tests and report results"
# With timeout
claude --headless --timeout 300 "Build the project"
```
Essential for CI/CD integration, automated pipelines, and scripted workflows.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.3 CI/CD Integration"
anchor: "#headless-mode"
- id: "09-004"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "How do you pipe content to Claude Code with a prompt?"
options:
a: "claude | cat file.txt -p 'analyze'"
b: "cat file.txt | claude -p 'analyze this code'"
c: "claude < file.txt --prompt 'analyze'"
d: "file.txt > claude -p 'analyze'"
correct: "b"
explanation: |
Use standard Unix piping with the `-p` flag:
```bash
cat file.txt | claude -p 'analyze this code'
git diff | claude -p 'explain these changes'
npm test 2>&1 | claude -p 'summarize test failures'
```
This enables powerful shell integration for automated code analysis.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.3 CI/CD Integration"
anchor: "#unix-piping-workflows"
- id: "09-005"
difficulty: "power"
profiles: ["power"]
question: "What is the 'Rev the Engine' pattern?"
options:
a: "Running tests in parallel"
b: "Multiple rounds of write-critique-improve cycles"
c: "Restarting Claude Code between tasks"
d: "Using higher compute models"
correct: "b"
explanation: |
The "Rev the Engine" pattern uses multiple rounds of critique for quality:
```
Round 1: [Initial implementation]
Critique: [What's wrong]
Improvement: [Better version]
Round 2: [Improved implementation]
Critique: [What's still wrong]
Improvement: [Even better version]
Round 3: [Final implementation]
Final check: [Verification]
```
Typically 3 rounds are recommended for quality work.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.2 Composition Patterns"
anchor: "#the-rev-the-engine-pattern"
- id: "09-006"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What output format flag gets structured JSON from Claude for scripting?"
options:
a: "--format json"
b: "--output-format json"
c: "--json"
d: "--structured"
correct: "b"
explanation: |
Use `--output-format` to control response format:
| Format | Use Case |
|--------|----------|
| `text` | Human-readable output (default) |
| `json` | Machine-parseable structured data |
| `stream-json` | Real-time streaming for large outputs |
Example:
```bash
git log --oneline -10 | claude -p 'Categorize commits' --output-format json
```
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.3 CI/CD Integration"
anchor: "#output-format-control"
- id: "09-007"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is 'Vibe Coding' according to the guide?"
options:
a: "Coding while listening to music"
b: "Rapid prototyping through natural conversation before committing to implementation"
c: "Using AI to generate random code"
d: "Coding in a relaxed environment"
correct: "b"
explanation: |
Vibe Coding is rapid prototyping through natural conversation.
When to vibe code:
- Early exploration: Testing if an approach works
- Proof of concept: Quick validation before full implementation
- Learning: Understanding a new library or pattern
Rules:
- No production code - exploration only
- Throw away freely
- Focus on learning
- Signal clearly: "This is vibe code, not for production"
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.8 Vibe Coding & Skeleton Projects"
anchor: "#vibe-coding"
- id: "09-008"
difficulty: "power"
profiles: ["power"]
question: "What is the Verify Gate Pattern before creating a PR?"
options:
a: "Just run tests"
b: "Build -> Lint -> Test -> Type-check -> THEN create PR"
c: "Create PR first, then fix issues"
d: "Manual review only"
correct: "b"
explanation: |
The Verify Gate Pattern ensures all checks pass before PR creation:
```
Build -> Lint -> Test -> Type-check -> THEN create PR
```
If ANY step fails:
- Stop immediately
- Report what failed and why
- Suggest fixes
- Do NOT proceed to PR creation
This prevents wasted CI cycles and review time.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.3 CI/CD Integration"
anchor: "#verify-gate-pattern"
- id: "09-009"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the key insight of 'Todo as Instruction Mirrors'?"
options:
a: "Todos are just for tracking"
b: "What you write as a todo becomes Claude's instruction"
c: "Todos should be vague for flexibility"
d: "Always use bullet points"
correct: "b"
explanation: |
The Mirror Principle: What you write as a todo becomes Claude's instruction.
Bad (vague todo -> vague execution):
"Fix the bug"
Good (specific todo -> precise execution):
"Fix null pointer in getUserById when user not found - return null instead of throwing"
Well-crafted todos guide Claude's execution with precision.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.6 Todo as Instruction Mirrors"
anchor: "#the-mirror-principle"
- id: "09-010"
difficulty: "power"
profiles: ["power"]
question: "According to 'Continuous Improvement Mindset', what should you ask after every manual intervention?"
options:
a: "Was this my fault?"
b: "How can I improve the process so this error can be avoided next time?"
c: "Who is responsible for this?"
d: "Should I use a different AI?"
correct: "b"
explanation: |
After every manual intervention, ask:
"How can I improve the process so this error or manual fix can be avoided next time?"
The improvement pipeline:
1. Can a linting rule catch it? -> Add lint rule
2. Can it go in conventions/docs? -> Add to CLAUDE.md or ADRs
3. Neither? -> Accept as edge case
The meta-skill: instead of fixing code, fix the system that produces the code.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.10 Continuous Improvement Mindset"
anchor: "#the-key-question"
- id: "09-011"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is a Skeleton Project?"
options:
a: "A project with no code"
b: "A minimal, working template that establishes patterns before full implementation"
c: "A deprecated project"
d: "A project outline document"
correct: "b"
explanation: |
A skeleton project is a minimal, working template that establishes patterns.
Skeleton principles:
1. **It must run**: `pnpm dev` works from day 1
2. **One complete vertical**: Full stack for one feature
3. **Patterns, not features**: Shows HOW, not WHAT
4. **Minimal dependencies**: Only what's needed
Progression: Skeleton (Day 1) -> MVP (Week 1) -> Full (Month 1)
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.8 Vibe Coding & Skeleton Projects"
anchor: "#skeleton-projects"
- id: "09-012"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is OpusPlan mode?"
options:
a: "Using only Opus for everything"
b: "Opus for planning, Sonnet for execution"
c: "A special debugging mode"
d: "Planning without AI"
correct: "b"
explanation: |
OpusPlan mode combines model strengths:
- **Planning**: Opus for high-level thinking
- **Execution**: Sonnet for implementation
This provides strategic thinking + cost-effective execution.
```bash
/model opusplan
Shift+Tab x 2 # Enter Plan Mode (Opus)
# Design architecture...
Shift+Tab # Exit Plan Mode (Sonnet)
# Implement the plan...
```
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.13 Cost Optimization Strategies"
anchor: "#model-selection-matrix"
- id: "09-013"
difficulty: "power"
profiles: ["power"]
question: "When should you NOT use --dangerously-skip-permissions?"
options:
a: "In CI/CD pipelines"
b: "On production systems or sensitive codebases"
c: "For automated testing"
d: "In Docker containers"
correct: "b"
explanation: |
Never use `--dangerously-skip-permissions` on production systems or sensitive codebases.
Safe usage:
- CI/CD pipelines with isolated environments
- Automated testing with limited scope
- Development containers
Unsafe usage:
- Production systems
- Codebases with secrets
- Environments with sensitive data
The flag bypasses all permission prompts, creating security risks.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.11 Common Pitfalls & Best Practices"
anchor: "#security-pitfalls"
- id: "09-014"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What prompt format does the guide recommend for effective requests?"
options:
a: "Simple natural language"
b: "WHAT, WHERE, HOW, VERIFY"
c: "Subject, Body, Footer"
d: "Title, Description, Acceptance Criteria"
correct: "b"
explanation: |
The recommended prompt format:
- **WHAT**: Concrete deliverable
- **WHERE**: File paths/locations
- **HOW**: Constraints/approach
- **VERIFY**: Success criteria
Example:
```
WHAT: Add input validation to the login form
WHERE: src/components/LoginForm.tsx, src/schemas/auth.ts
HOW: Use Zod schema validation, display errors inline
VERIFY: Empty email shows error, invalid format shows error
```
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.11 Common Pitfalls & Best Practices"
anchor: "#effective-prompt-format"
- id: "09-015"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the recommended learning progression for Claude Code?"
options:
a: "Learn everything at once"
b: "Start with advanced features"
c: "Week 1: Basic commands -> Week 2: CLAUDE.md -> Week 3: Agents -> Month 2+: MCP servers"
d: "Skip to MCP servers immediately"
correct: "c"
explanation: |
The guide recommends progressive learning:
1. **Week 1**: Basic commands, context management
2. **Week 2**: CLAUDE.md, permissions
3. **Week 3**: Agents and commands
4. **Month 2+**: MCP servers, advanced patterns
Start with simple, low-risk tasks and build up complexity gradually.
This avoids overwhelm and builds solid fundamentals.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.11 Common Pitfalls & Best Practices"
anchor: "#learning--adoption-pitfalls"
- id: "09-016"
difficulty: "power"
profiles: ["power"]
question: "What git workflow enables working on multiple features simultaneously with isolated contexts?"
options:
a: "Git stash"
b: "Git worktrees"
c: "Git branches only"
d: "Git submodules"
correct: "b"
explanation: |
Git worktrees create multiple working directories from the same repository.
Benefits:
- Work on multiple features simultaneously
- Each worktree has independent Claude Code context
- No need for stash/switch operations
- Parallel testing while developing
```bash
git worktree add ../myproject-hotfix hotfix
git worktree add ../myproject-feature-a feature-a
```
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.12 Git Best Practices & Workflows"
anchor: "#git-worktrees-for-parallel-development"

465
quiz/questions/10-reference.yaml Normal file
View file

@ -0,0 +1,465 @@
category: "Reference"
category_id: 10
source_file: "english-ultimate-claude-code-guide.md"
questions:
- id: "10-001"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What keyboard shortcut enters Plan Mode (toggles plan/execute)?"
options:
a: "Ctrl+P"
b: "Shift+Tab"
c: "Alt+P"
d: "Ctrl+Shift+P"
correct: "b"
explanation: |
`Shift+Tab` toggles between Plan Mode and Execute Mode.
Plan Mode navigation:
- `Shift+Tab` once: Toggle plan/execute
- `Shift+Tab` twice: Enter deep Plan Mode (with Opus in OpusPlan)
Plan Mode allows safe, read-only exploration before making changes.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.2 Keyboard Shortcuts"
anchor: "#session-control"
- id: "10-002"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What keyboard shortcut rewinds to a previous checkpoint (undo Claude's changes)?"
options:
a: "Ctrl+Z"
b: "Esc (double-tap)"
c: "Ctrl+R"
d: "Alt+Z"
correct: "b"
explanation: |
Double-tap `Esc` (Esc×2) rewinds to the previous checkpoint.
This is equivalent to the `/rewind` command.
It undoes Claude's recent changes in the current session without creating git commits.
Use when Claude made a mistake and you want to try a different approach.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.2 Keyboard Shortcuts"
anchor: "#session-control"
- id: "10-003"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What does `/compact` do?"
options:
a: "Compresses files on disk"
b: "Summarizes and compresses the conversation context"
c: "Minimizes the terminal window"
d: "Reduces Claude's response length"
correct: "b"
explanation: |
`/compact` summarizes and compresses the conversation context.
Use `/compact` when:
- Context usage reaches 70-90%
- Responses become slow
- Claude starts forgetting earlier context
This frees up context space while preserving important information.
Check context usage with `/status`.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.1 Commands Table"
anchor: "#built-in-commands"
- id: "10-004"
difficulty: "senior"
profiles: ["senior", "power"]
question: "At what context percentage should you run /compact according to best practices?"
options:
a: "50%"
b: "70-90%"
c: "95%+"
d: "Only when errors occur"
correct: "b"
explanation: |
Context management guidelines:
| Context Level | Action |
|--------------|--------|
| 0-50% | Work freely |
| 50-75% | Be selective |
| **75-90%** | **Use `/compact`** |
| 90%+ | Use `/clear` |
Proactive compaction at 70% prevents context degradation and maintains performance.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.4 Troubleshooting"
anchor: "#context-recovery"
- id: "10-005"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What keyboard shortcut cancels the current operation?"
options:
a: "Esc"
b: "Ctrl+C"
c: "Ctrl+Z"
d: "Alt+C"
correct: "b"
explanation: |
`Ctrl+C` cancels the current operation.
Important shortcuts:
- `Ctrl+C`: Cancel operation
- `Ctrl+D`: Exit Claude Code
- `Ctrl+R`: Retry last operation
- `Ctrl+L`: Clear screen (keeps context)
- `Esc`: Dismiss current suggestion
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.2 Keyboard Shortcuts"
anchor: "#session-control"
- id: "10-006"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the correct permission pattern to allow ALL git commands?"
options:
a: 'Bash(git)'
b: 'Bash(git *)'
c: 'git:*'
d: 'Bash(*git*)'
correct: "b"
explanation: |
The pattern `Bash(git *)` allows any git command.
Permission pattern examples:
- `Bash(git *)` - Any git command
- `Bash(npm test)` - Exactly "npm test"
- `Edit` - All file edits
- `mcp__serena__*` - All Serena tools
Wildcards (*) enable flexible permission matching.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.3 Configuration Reference"
anchor: "#permission-patterns"
- id: "10-007"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "Where should project-specific CLAUDE.md be placed (committed to git)?"
options:
a: "~/.claude/CLAUDE.md"
b: "/project/.claude/CLAUDE.md"
c: "/project/CLAUDE.md"
d: "~/.config/claude/project.md"
correct: "c"
explanation: |
CLAUDE.md locations:
| Location | Scope | Committed |
|----------|-------|-----------|
| `~/.claude/CLAUDE.md` | All projects | N/A (global) |
| `/project/CLAUDE.md` | This project | **Yes** |
| `/project/.claude/CLAUDE.md` | Personal | No |
The root `CLAUDE.md` is committed and shared with the team.
The `.claude/CLAUDE.md` is personal and should be in `.gitignore`.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.3 Configuration Reference"
anchor: "#claudemd-locations"
- id: "10-008"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What does the --mcp-debug flag do?"
options:
a: "Disables MCP servers"
b: "Debugs MCP server connections with verbose output"
c: "Tests MCP configurations"
d: "Enables MCP auto-discovery"
correct: "b"
explanation: |
The `--mcp-debug` flag enables debug mode for MCP server connections.
MCP debugging techniques:
```bash
claude --mcp-debug # Debug all MCP connections
/mcp # View MCP status inside Claude Code
```
Use when MCP servers aren't connecting or tools aren't appearing.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.4 Troubleshooting"
anchor: "#mcp-debugging-techniques"
- id: "10-009"
difficulty: "power"
profiles: ["power"]
question: "If an MCP server name validation fails with pattern error, what characters ARE allowed?"
options:
a: "Letters only"
b: "Letters, numbers, underscores, hyphens (max 64 chars)"
c: "Any characters except spaces"
d: "Alphanumeric and periods"
correct: "b"
explanation: |
MCP server names must match: `^[a-zA-Z0-9_-]{1,64}`
Allowed:
- Letters (a-z, A-Z)
- Numbers (0-9)
- Underscores (_)
- Hyphens (-)
- Maximum 64 characters
Not allowed:
- Spaces
- Special characters (@, #, etc.)
- More than 64 characters
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.4 Troubleshooting"
anchor: "#error-1-tool-name-validation-failed"
- id: "10-010"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What command shows session info including context usage and cost?"
options:
a: "/info"
b: "/status"
c: "/stats"
d: "/session"
correct: "b"
explanation: |
The `/status` command shows session information.
Output includes:
- Model being used
- Context usage percentage
- Session cost
- Token counts
Example output:
`Model: Sonnet | Ctx: 45.2k | Cost: $1.23 | Ctx(u): 42.0%`
Use `/stats` for usage statistics with activity graphs.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.1 Commands Table"
anchor: "#built-in-commands"
- id: "10-011"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What flag limits maximum API spend in headless mode?"
options:
a: "--cost-limit"
b: "--max-budget-usd"
c: "--spending-cap"
d: "--budget"
correct: "b"
explanation: |
The `--max-budget-usd` flag sets maximum API spend (only with `--print`):
```bash
claude -p "analyze" --max-budget-usd 5.00
```
This prevents runaway costs in automated pipelines.
The operation stops if the budget is exceeded.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.3 Configuration Reference"
anchor: "#cli-flags-reference"
- id: "10-012"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "How do you run a shell command directly from Claude Code prompt?"
options:
a: "shell: command"
b: "!command"
c: "$command"
d: "run command"
correct: "b"
explanation: |
The `!command` prefix runs a shell command directly.
Quick actions:
- `!command` - Run shell command
- `@filename` - Reference file
- `Ctrl+C` - Cancel operation
- `Ctrl+R` - Retry last
Example: `!git status` runs git status without Claude interpreting it.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.1 Commands Table"
anchor: "#quick-actions"
- id: "10-013"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What is the correct way to resume a specific session by ID?"
options:
a: "claude --session abc123"
b: "claude -r abc123"
c: "claude --load abc123"
d: "claude -s abc123"
correct: "b"
explanation: |
Use `-r` or `--resume` to resume a specific session:
```bash
claude -r abc123 # Resume session abc123
claude --resume abc123 # Same as above
claude -c # Resume last session (short)
claude --continue # Resume last session (long)
```
Combine with `-p` for scripting: `claude -r abc123 -p "check status"`
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.3 Configuration Reference"
anchor: "#cli-flags-reference"
- id: "10-014"
difficulty: "power"
profiles: ["power"]
question: "What is the recommended .gitignore pattern for Claude Code files?"
options:
a: "Ignore all .claude/ contents"
b: "Ignore settings.local.json and .claude/CLAUDE.md, keep agents/commands/hooks"
c: "Don't ignore anything"
d: "Ignore only agents/"
correct: "b"
explanation: |
Recommended .gitignore:
```gitignore
# Claude Code - Personal (ignore)
.claude/settings.local.json
.claude/CLAUDE.md
.claude/.serena/
# Claude Code - Team (keep/commit)
# .claude/agents/
# .claude/commands/
# .claude/hooks/
# .claude/settings.json
```
This keeps team workflows shared while personal settings stay private.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "9.11 Common Pitfalls & Best Practices"
anchor: "#recommended-gitignore"
- id: "10-015"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What is the daily workflow morning setup according to the guide?"
options:
a: "Just start coding"
b: "Git pull, /status, load project memory, review yesterday's progress"
c: "Run all tests first"
d: "Clear all context"
correct: "b"
explanation: |
Morning setup workflow:
1. Git pull latest changes
2. Review context with `/status`
3. Load project memory (`/sc:load` if using Serena)
4. Review yesterday's progress
This ensures you start with fresh code and full context awareness.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.6 Daily Workflow & Checklists"
anchor: "#daily-workflow-pattern"
- id: "10-016"
difficulty: "senior"
profiles: ["senior", "power"]
question: "What flag adds additional directories to context?"
options:
a: "--include-dir"
b: "--add-dir"
c: "--context-dir"
d: "--load-dir"
correct: "b"
explanation: |
Use `--add-dir` to add additional directories to context:
```bash
claude --add-dir ../shared ../utils
claude --add-dir packages/api
```
This is more efficient than loading the entire monorepo.
Multiple directories can be specified for multi-package projects.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.3 Configuration Reference"
anchor: "#cli-flags-reference"
- id: "10-017"
difficulty: "power"
profiles: ["power"]
question: "When Sequential Thinking MCP seems slow or unresponsive, what should you expect?"
options:
a: "It's broken and needs restart"
b: "10-30 second responses are normal due to significant compute"
c: "Switch to a different MCP"
d: "Reduce the query complexity"
correct: "b"
explanation: |
Sequential Thinking uses significant compute - expect 10-30 second responses.
This is not an error, just be patient.
Tips for Sequential:
- Works best with specific, well-defined problems
- Good: "Debug why user authentication fails on mobile"
- Bad: "Make the app better"
The longer response time reflects deeper analysis.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.4 Troubleshooting"
anchor: "#sequential-thinking-mcp-issues"
- id: "10-018"
difficulty: "junior"
profiles: ["junior", "senior", "power"]
question: "What shortcut opens an external editor for composing long text input?"
options:
a: "Ctrl+E"
b: "Ctrl+G"
c: "Ctrl+O"
d: "Ctrl+L"
correct: "b"
explanation: |
`Ctrl+G` opens an external editor for composing long text.
Useful input shortcuts:
- `Ctrl+A`: Jump to beginning of line
- `Ctrl+E`: Jump to end of line
- `Ctrl+W`: Delete previous word
- `Ctrl+G`: Open external editor
- `Tab`: Autocomplete file paths
The external editor allows comfortable editing of complex prompts.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "10.2 Keyboard Shortcuts"
anchor: "#input--navigation"

132
quiz/src/dynamic.js Normal file
View file

@ -0,0 +1,132 @@
/**
* Dynamic question generation using claude -p
*/
import { execSync } from 'child_process';
import YAML from 'yaml';
const TOPICS = {
1: 'Quick Start & Installation',
2: 'Core Concepts',
3: 'Memory & Settings',
4: 'Agents',
5: 'Skills',
6: 'Commands',
7: 'Hooks',
8: 'MCP Servers',
9: 'Advanced Patterns',
10: 'Reference & Troubleshooting'
};
const TOPIC_SECTIONS = {
1: '1.1-1.6',
2: '2.1-2.6',
3: '3.1-3.4',
4: '4.1-4.5',
5: '5.1-5.4',
6: '6.1-6.4',
7: '7.1-7.5',
8: '8.1-8.5',
9: '9.1-9.5',
10: '10.1-10.6'
};
/**
* Generate a question dynamically using claude -p
*/
export async function generateDynamicQuestion(categoryId, difficulty = 'senior') {
const categoryName = TOPICS[categoryId] || 'Claude Code';
const sections = TOPIC_SECTIONS[categoryId] || '';
const prompt = `Based on the Claude Code documentation section "${categoryName}" (sections ${sections}), generate a multiple-choice question at ${difficulty} difficulty level.
Output format (YAML only, no explanation):
\`\`\`yaml
id: "dyn-${Date.now()}"
difficulty: "${difficulty}"
profiles: ["junior", "senior", "power"]
question: "Your question here?"
options:
a: "First option"
b: "Second option"
c: "Third option"
d: "Fourth option"
correct: "a"
explanation: |
Explanation of why this is correct and what the user should learn.
doc_reference:
file: "english-ultimate-claude-code-guide.md"
section: "${categoryName}"
anchor: "#${categoryId}-${categoryName.toLowerCase().replace(/[^a-z0-9]+/g, '-')}"
\`\`\`
Requirements:
- Test practical understanding, not trivia
- Include one clearly correct answer
- Make distractors plausible but distinguishable
- Explanation should teach, not just state the answer
- Question should be answerable from the documentation`;
try {
// Check if claude CLI is available
const result = execSync(`claude -p "${prompt.replace(/"/g, '\\"')}" --model haiku`, {
encoding: 'utf-8',
timeout: 30000,
maxBuffer: 1024 * 1024
});
// Extract YAML from response
const yamlMatch = result.match(/```yaml\n([\s\S]*?)```/);
if (!yamlMatch) {
throw new Error('No YAML block found in response');
}
const question = YAML.parse(yamlMatch[1]);
// Validate question structure
if (!question.question || !question.options || !question.correct) {
throw new Error('Invalid question structure');
}
// Add category info
question.category = categoryName;
question.category_id = categoryId;
question.source_file = 'english-ultimate-claude-code-guide.md';
question.generated = true;
return question;
} catch (err) {
console.error('Dynamic generation failed:', err.message);
return null;
}
}
/**
* Check if claude CLI is available
*/
export function isClaudeAvailable() {
try {
execSync('which claude', { encoding: 'utf-8' });
return true;
} catch {
return false;
}
}
/**
* Generate multiple questions for a category
*/
export async function generateQuestions(categoryId, count = 5, difficulty = 'senior') {
const questions = [];
for (let i = 0; i < count; i++) {
const question = await generateDynamicQuestion(categoryId, difficulty);
if (question) {
questions.push(question);
}
// Small delay between requests
await new Promise(resolve => setTimeout(resolve, 1000));
}
return questions;
}

187
quiz/src/index.js Normal file
View file

@ -0,0 +1,187 @@
#!/usr/bin/env node
/**
* Claude Code Knowledge Quiz
* Test your understanding of Claude Code with interactive MCQs
*
* Part of: claude-code-ultimate-guide
* Author: Florian BRUNIAUX
*/
import { createRequire } from 'module';
import { fileURLToPath } from 'url';
import { dirname, join } from 'path';
import { parseArgs } from 'util';
import { displayHeader, displayHelp } from './ui.js';
import { selectProfile, selectTopics } from './prompts.js';
import { loadQuestions, filterQuestions, shuffleArray } from './questions.js';
import { runQuiz } from './quiz.js';
import { displayFinalScore, offerRetry } from './score.js';
import { loadSession, saveSession } from './session.js';
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
// CLI argument parsing
const { values: args } = parseArgs({
options: {
profile: { type: 'string', short: 'p' },
topics: { type: 'string', short: 't' },
count: { type: 'string', short: 'c' },
dynamic: { type: 'boolean', short: 'd', default: false },
help: { type: 'boolean', short: 'h', default: false },
version: { type: 'boolean', short: 'v', default: false }
},
strict: false
});
// Profile configurations
const PROFILES = {
junior: {
name: 'Junior Developer',
description: '45 min to productivity',
questionCount: 15,
focusTopics: [1, 2, 3, 6],
difficultyWeight: { junior: 0.8, senior: 0.2, power: 0 }
},
senior: {
name: 'Senior Developer',
description: '40 min to mastery',
questionCount: 20,
focusTopics: [2, 3, 4, 7, 9],
difficultyWeight: { junior: 0.3, senior: 0.5, power: 0.2 }
},
power: {
name: 'Power User',
description: '2 hours for full mastery',
questionCount: 25,
focusTopics: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10],
difficultyWeight: { junior: 0.2, senior: 0.4, power: 0.4 }
},
pm: {
name: 'Product Manager',
description: '20 min overview',
questionCount: 10,
focusTopics: [1, 2, 3],
difficultyWeight: { junior: 1, senior: 0, power: 0 }
}
};
// Topic names
const TOPICS = {
1: 'Quick Start & Installation',
2: 'Core Concepts',
3: 'Memory & Settings',
4: 'Agents',
5: 'Skills',
6: 'Commands',
7: 'Hooks',
8: 'MCP Servers',
9: 'Advanced Patterns',
10: 'Reference & Troubleshooting'
};
async function main() {
// Handle help/version
if (args.help) {
displayHelp();
process.exit(0);
}
if (args.version) {
console.log('claude-code-quiz v1.0.0');
process.exit(0);
}
// Display header
displayHeader();
// Profile selection
let profile;
if (args.profile && PROFILES[args.profile]) {
profile = args.profile;
} else {
profile = await selectProfile(PROFILES);
}
// Topic selection
let selectedTopics;
if (args.topics) {
selectedTopics = args.topics.split(',').map(t => parseInt(t.trim())).filter(t => t >= 1 && t <= 10);
if (selectedTopics.length === 0) selectedTopics = PROFILES[profile].focusTopics;
} else {
selectedTopics = await selectTopics(TOPICS, PROFILES[profile].focusTopics);
}
// Question count
let questionCount = PROFILES[profile].questionCount;
if (args.count) {
const parsed = parseInt(args.count);
if (parsed > 0 && parsed <= 50) questionCount = parsed;
}
// Load and filter questions
const questionsDir = join(__dirname, '..', 'questions');
const allQuestions = await loadQuestions(questionsDir);
const filteredQuestions = filterQuestions(allQuestions, {
profile,
topics: selectedTopics,
count: questionCount,
difficultyWeight: PROFILES[profile].difficultyWeight
});
if (filteredQuestions.length === 0) {
console.log('\nNo questions available for selected criteria. Try different topics.');
process.exit(1);
}
// Shuffle questions
const quizQuestions = shuffleArray(filteredQuestions).slice(0, questionCount);
// Run quiz
const results = await runQuiz(quizQuestions, {
profile,
topics: selectedTopics,
dynamicEnabled: args.dynamic
});
// Display final score
displayFinalScore(results, TOPICS);
// Save session
await saveSession(results);
// Offer retry
const retryChoice = await offerRetry(results);
if (retryChoice === 'retry-wrong') {
// Filter to only wrong questions and run again
const wrongQuestions = results.questions.filter(q => !q.correct);
if (wrongQuestions.length > 0) {
const retryResults = await runQuiz(wrongQuestions.map(q => q.question), {
profile,
topics: selectedTopics,
dynamicEnabled: args.dynamic,
isRetry: true
});
displayFinalScore(retryResults, TOPICS);
await saveSession(retryResults);
}
} else if (retryChoice === 'new-quiz') {
// Restart with different questions
const newQuestions = shuffleArray(filteredQuestions).slice(0, questionCount);
const newResults = await runQuiz(newQuestions, {
profile,
topics: selectedTopics,
dynamicEnabled: args.dynamic
});
displayFinalScore(newResults, TOPICS);
await saveSession(newResults);
}
// else 'exit' - do nothing
}
main().catch(err => {
console.error('Error:', err.message);
process.exit(1);
});

114
quiz/src/prompts.js Normal file
View file

@ -0,0 +1,114 @@
/**
* User prompts using inquirer
*/
import inquirer from 'inquirer';
import chalk from 'chalk';
export async function selectProfile(profiles) {
const { profile } = await inquirer.prompt([
{
type: 'list',
name: 'profile',
message: 'Select your profile:',
choices: Object.entries(profiles).map(([key, value]) => ({
name: `${value.name} (${value.description})`,
value: key
}))
}
]);
return profile;
}
export async function selectTopics(topics, defaultTopics) {
const { topicChoice } = await inquirer.prompt([
{
type: 'list',
name: 'topicChoice',
message: 'Select topics to quiz:',
choices: [
{ name: chalk.green('All topics (recommended)'), value: 'all' },
{ name: 'Profile defaults', value: 'defaults' },
{ name: 'Custom selection...', value: 'custom' }
]
}
]);
if (topicChoice === 'all') {
return Object.keys(topics).map(Number);
}
if (topicChoice === 'defaults') {
return defaultTopics;
}
// Custom selection
const { selectedTopics } = await inquirer.prompt([
{
type: 'checkbox',
name: 'selectedTopics',
message: 'Select topics (space to toggle, enter to confirm):',
choices: Object.entries(topics).map(([id, name]) => ({
name: `[${id}] ${name}`,
value: parseInt(id),
checked: defaultTopics.includes(parseInt(id))
})),
validate: (answer) => {
if (answer.length === 0) {
return 'You must select at least one topic.';
}
return true;
}
}
]);
return selectedTopics;
}
export async function promptAnswer() {
const { answer } = await inquirer.prompt([
{
type: 'list',
name: 'answer',
message: 'Your answer:',
choices: [
{ name: 'A', value: 'a' },
{ name: 'B', value: 'b' },
{ name: 'C', value: 'c' },
{ name: 'D', value: 'd' },
new inquirer.Separator(),
{ name: chalk.gray('Skip question'), value: 'skip' },
{ name: chalk.gray('Quit quiz'), value: 'quit' }
]
}
]);
return answer;
}
export async function promptContinue() {
const { cont } = await inquirer.prompt([
{
type: 'confirm',
name: 'cont',
message: 'Continue to next question?',
default: true
}
]);
return cont;
}
export async function promptRetry() {
const { retry } = await inquirer.prompt([
{
type: 'list',
name: 'retry',
message: 'What would you like to do?',
choices: [
{ name: 'Retry wrong questions only', value: 'retry-wrong' },
{ name: 'New quiz (different questions)', value: 'new-quiz' },
{ name: 'Exit', value: 'exit' }
]
}
]);
return retry;
}

124
quiz/src/questions.js Normal file
View file

@ -0,0 +1,124 @@
/**
* Question loading and filtering
*/
import { readdir, readFile } from 'fs/promises';
import { join } from 'path';
import YAML from 'yaml';
/**
* Load all questions from YAML files in the questions directory
*/
export async function loadQuestions(questionsDir) {
const allQuestions = [];
try {
const files = await readdir(questionsDir);
const yamlFiles = files.filter(f => f.endsWith('.yaml') || f.endsWith('.yml'));
for (const file of yamlFiles) {
try {
const content = await readFile(join(questionsDir, file), 'utf-8');
const parsed = YAML.parse(content);
if (parsed && parsed.questions && Array.isArray(parsed.questions)) {
// Add category info to each question
const questionsWithCategory = parsed.questions.map(q => ({
...q,
category: parsed.category || 'Unknown',
category_id: parsed.category_id || 0,
source_file: parsed.source_file || 'english-ultimate-claude-code-guide.md'
}));
allQuestions.push(...questionsWithCategory);
}
} catch (err) {
console.warn(`Warning: Could not parse ${file}: ${err.message}`);
}
}
} catch (err) {
console.error(`Error reading questions directory: ${err.message}`);
}
return allQuestions;
}
/**
* Filter questions based on profile, topics, and difficulty
*/
export function filterQuestions(questions, options) {
const { profile, topics, count, difficultyWeight } = options;
// Filter by topics
let filtered = questions.filter(q => topics.includes(q.category_id));
// Filter by profile (if profiles array exists on question)
filtered = filtered.filter(q => {
if (!q.profiles || !Array.isArray(q.profiles)) return true;
return q.profiles.includes(profile);
});
// Weight by difficulty
if (difficultyWeight) {
filtered = weightByDifficulty(filtered, difficultyWeight, count);
}
return filtered;
}
/**
* Weight questions by difficulty distribution
*/
function weightByDifficulty(questions, weights, targetCount) {
const byDifficulty = {
junior: questions.filter(q => q.difficulty === 'junior'),
senior: questions.filter(q => q.difficulty === 'senior'),
power: questions.filter(q => q.difficulty === 'power'),
all: questions.filter(q => q.difficulty === 'all' || !q.difficulty)
};
const result = [];
// Add 'all' difficulty questions first
result.push(...byDifficulty.all);
// Calculate target counts for each difficulty
const remaining = targetCount - result.length;
const juniorCount = Math.floor(remaining * (weights.junior || 0));
const seniorCount = Math.floor(remaining * (weights.senior || 0));
const powerCount = Math.floor(remaining * (weights.power || 0));
// Add questions by difficulty
result.push(...shuffleArray(byDifficulty.junior).slice(0, juniorCount));
result.push(...shuffleArray(byDifficulty.senior).slice(0, seniorCount));
result.push(...shuffleArray(byDifficulty.power).slice(0, powerCount));
// Fill remaining slots with any available questions
const used = new Set(result.map(q => q.id));
const unused = questions.filter(q => !used.has(q.id));
const stillNeeded = targetCount - result.length;
if (stillNeeded > 0) {
result.push(...shuffleArray(unused).slice(0, stillNeeded));
}
return result;
}
/**
* Shuffle array using Fisher-Yates algorithm
*/
export function shuffleArray(array) {
const result = [...array];
for (let i = result.length - 1; i > 0; i--) {
const j = Math.floor(Math.random() * (i + 1));
[result[i], result[j]] = [result[j], result[i]];
}
return result;
}
/**
* Get category name from ID
*/
export function getCategoryName(categoryId, topics) {
return topics[categoryId] || 'Unknown';
}

122
quiz/src/quiz.js Normal file
View file

@ -0,0 +1,122 @@
/**
* Quiz engine - handles the quiz flow
*/
import chalk from 'chalk';
import { displayQuestion, displayCorrect, displayIncorrect, displayProgress } from './ui.js';
import { promptAnswer, promptContinue } from './prompts.js';
import { generateDynamicQuestion } from './dynamic.js';
const TOPICS = {
1: 'Quick Start & Installation',
2: 'Core Concepts',
3: 'Memory & Settings',
4: 'Agents',
5: 'Skills',
6: 'Commands',
7: 'Hooks',
8: 'MCP Servers',
9: 'Advanced Patterns',
10: 'Reference & Troubleshooting'
};
/**
* Run the quiz with given questions
*/
export async function runQuiz(questions, options = {}) {
const { profile, topics, dynamicEnabled, isRetry } = options;
const results = {
profile,
topics,
totalQuestions: questions.length,
correctCount: 0,
skippedCount: 0,
startTime: Date.now(),
endTime: null,
questions: [],
byCategory: {}
};
// Initialize category tracking
for (const topicId of topics) {
results.byCategory[topicId] = { correct: 0, total: 0, name: TOPICS[topicId] };
}
console.log(chalk.gray('\n' + '-'.repeat(60)));
if (isRetry) {
console.log(chalk.yellow(`Retrying ${questions.length} missed questions...`));
} else {
console.log(chalk.yellow(`Starting quiz: ${questions.length} questions for ${profile} profile`));
}
console.log(chalk.gray('-'.repeat(60)));
// Quiz loop
for (let i = 0; i < questions.length; i++) {
const question = questions[i];
const categoryName = question.category || TOPICS[question.category_id] || 'Unknown';
// Display question
displayQuestion(question, i, questions.length, categoryName);
// Get answer
const answer = await promptAnswer();
// Handle special inputs
if (answer === 'quit') {
console.log(chalk.yellow('\nQuiz ended early.'));
break;
}
if (answer === 'skip') {
results.skippedCount++;
results.questions.push({
question,
userAnswer: null,
correct: false,
skipped: true
});
if (results.byCategory[question.category_id]) {
results.byCategory[question.category_id].total++;
}
continue;
}
// Validate answer
const isCorrect = answer === question.correct.toLowerCase();
// Update results
if (isCorrect) {
results.correctCount++;
displayCorrect();
} else {
displayIncorrect(question, answer);
}
results.questions.push({
question,
userAnswer: answer,
correct: isCorrect,
skipped: false
});
// Update category stats
if (results.byCategory[question.category_id]) {
results.byCategory[question.category_id].total++;
if (isCorrect) {
results.byCategory[question.category_id].correct++;
}
}
// Show progress
displayProgress(i + 1, questions.length, results.correctCount);
// Prompt to continue (only on wrong answers to give time to read)
if (!isCorrect && i < questions.length - 1) {
await promptContinue();
}
}
results.endTime = Date.now();
return results;
}

116
quiz/src/score.js Normal file
View file

@ -0,0 +1,116 @@
/**
* Score tracking and display
*/
import chalk from 'chalk';
import { displayCategoryScore } from './ui.js';
import { promptRetry } from './prompts.js';
/**
* Display final score summary
*/
export function displayFinalScore(results, topics) {
const { totalQuestions, correctCount, skippedCount, startTime, endTime, byCategory } = results;
const answeredCount = results.questions.filter(q => !q.skipped).length;
const percentage = answeredCount > 0 ? Math.round((correctCount / answeredCount) * 100) : 0;
const duration = Math.round((endTime - startTime) / 1000);
const minutes = Math.floor(duration / 60);
const seconds = duration % 60;
console.log(chalk.cyan('\n' + '='.repeat(60)));
console.log(chalk.cyan.bold(' QUIZ COMPLETE'));
console.log(chalk.cyan('='.repeat(60)));
// Overall score
let scoreColor = chalk.green;
if (percentage < 50) scoreColor = chalk.red;
else if (percentage < 75) scoreColor = chalk.yellow;
console.log();
console.log(chalk.white.bold('Overall Score: ') + scoreColor.bold(`${correctCount}/${answeredCount} (${percentage}%)`));
if (skippedCount > 0) {
console.log(chalk.gray(`Skipped: ${skippedCount} questions`));
}
// Category breakdown
console.log();
console.log(chalk.white.bold('By Category:'));
const categoryScores = [];
for (const [categoryId, stats] of Object.entries(byCategory)) {
if (stats.total > 0) {
const categoryName = stats.name || topics[categoryId] || `Category ${categoryId}`;
console.log(displayCategoryScore(categoryName, stats.correct, stats.total));
categoryScores.push({
id: categoryId,
name: categoryName,
correct: stats.correct,
total: stats.total,
percentage: Math.round((stats.correct / stats.total) * 100)
});
}
}
// Weak areas (< 75%)
const weakAreas = categoryScores.filter(c => c.percentage < 75);
if (weakAreas.length > 0) {
console.log();
console.log(chalk.yellow.bold('Weak Areas (< 75%):'));
for (const area of weakAreas) {
console.log(chalk.yellow(` - ${area.name}: Review section ${area.id} in the guide`));
}
}
// Recommended reading
if (weakAreas.length > 0) {
console.log();
console.log(chalk.blue.bold('Recommended Reading:'));
for (const area of weakAreas.slice(0, 3)) {
const anchor = getSectionAnchor(area.id);
console.log(chalk.blue(` ${area.id}. english-ultimate-claude-code-guide.md${anchor}`));
}
}
// Time
console.log();
console.log(chalk.gray(`Time: ${minutes > 0 ? `${minutes} min ` : ''}${seconds} sec`));
console.log(chalk.gray('\n' + '-'.repeat(60)));
}
/**
* Get section anchor for documentation link
*/
function getSectionAnchor(categoryId) {
const anchors = {
1: '#1-quick-start-day-1',
2: '#2-core-concepts',
3: '#3-memory--settings',
4: '#4-agents',
5: '#5-skills',
6: '#6-commands',
7: '#7-hooks',
8: '#8-mcp-servers',
9: '#9-advanced-patterns',
10: '#10-reference'
};
return anchors[categoryId] || '';
}
/**
* Offer retry options after quiz
*/
export async function offerRetry(results) {
const wrongCount = results.questions.filter(q => !q.correct && !q.skipped).length;
if (wrongCount === 0) {
console.log(chalk.green.bold('\nPerfect score! No questions to retry.'));
return 'exit';
}
console.log(chalk.gray(`\nYou missed ${wrongCount} question${wrongCount > 1 ? 's' : ''}.`));
return promptRetry();
}

169
quiz/src/session.js Normal file
View file

@ -0,0 +1,169 @@
/**
* Session persistence - save quiz history to ~/.claude-quiz/
*/
import { mkdir, writeFile, readFile, readdir } from 'fs/promises';
import { join } from 'path';
import { homedir } from 'os';
const QUIZ_DIR = join(homedir(), '.claude-quiz');
const SESSIONS_DIR = join(QUIZ_DIR, 'sessions');
const STATS_FILE = join(QUIZ_DIR, 'stats.json');
/**
* Ensure quiz directories exist
*/
async function ensureDirs() {
try {
await mkdir(QUIZ_DIR, { recursive: true });
await mkdir(SESSIONS_DIR, { recursive: true });
} catch (err) {
// Ignore if already exists
}
}
/**
* Generate session ID from current timestamp
*/
function generateSessionId() {
const now = new Date();
const date = now.toISOString().split('T')[0];
const time = now.toTimeString().split(' ')[0].replace(/:/g, '');
return `${date}_${time}`;
}
/**
* Save quiz session to file
*/
export async function saveSession(results) {
try {
await ensureDirs();
const sessionId = generateSessionId();
const sessionData = {
session_id: sessionId,
profile: results.profile,
topics: results.topics,
questions_total: results.totalQuestions,
questions_correct: results.correctCount,
questions_skipped: results.skippedCount,
percentage: results.questions.filter(q => !q.skipped).length > 0
? Math.round((results.correctCount / results.questions.filter(q => !q.skipped).length) * 100)
: 0,
duration_seconds: Math.round((results.endTime - results.startTime) / 1000),
by_category: results.byCategory,
wrong_questions: results.questions
.filter(q => !q.correct && !q.skipped)
.map(q => ({
id: q.question.id,
category: q.question.category,
category_id: q.question.category_id,
question: q.question.question,
user_answer: q.userAnswer,
correct_answer: q.question.correct,
doc_reference: q.question.doc_reference
})),
timestamp: new Date().toISOString()
};
// Save session file
const sessionFile = join(SESSIONS_DIR, `${sessionId}.json`);
await writeFile(sessionFile, JSON.stringify(sessionData, null, 2));
// Update aggregate stats
await updateStats(sessionData);
return sessionId;
} catch (err) {
// Silent fail - don't break quiz if persistence fails
console.error('Warning: Could not save session:', err.message);
return null;
}
}
/**
* Update aggregate statistics
*/
async function updateStats(sessionData) {
let stats = {
total_sessions: 0,
total_questions: 0,
total_correct: 0,
by_category: {},
by_profile: {},
last_session: null
};
// Load existing stats
try {
const existing = await readFile(STATS_FILE, 'utf-8');
stats = JSON.parse(existing);
} catch {
// File doesn't exist yet
}
// Update totals
stats.total_sessions++;
stats.total_questions += sessionData.questions_total;
stats.total_correct += sessionData.questions_correct;
stats.last_session = sessionData.timestamp;
// Update by category
for (const [categoryId, categoryStats] of Object.entries(sessionData.by_category)) {
if (!stats.by_category[categoryId]) {
stats.by_category[categoryId] = { name: categoryStats.name, correct: 0, total: 0 };
}
stats.by_category[categoryId].correct += categoryStats.correct;
stats.by_category[categoryId].total += categoryStats.total;
}
// Update by profile
if (!stats.by_profile[sessionData.profile]) {
stats.by_profile[sessionData.profile] = { sessions: 0, correct: 0, total: 0 };
}
stats.by_profile[sessionData.profile].sessions++;
stats.by_profile[sessionData.profile].correct += sessionData.questions_correct;
stats.by_profile[sessionData.profile].total += sessionData.questions_total;
// Save updated stats
await writeFile(STATS_FILE, JSON.stringify(stats, null, 2));
}
/**
* Load previous session (for retry)
*/
export async function loadSession(sessionId) {
try {
const sessionFile = join(SESSIONS_DIR, `${sessionId}.json`);
const content = await readFile(sessionFile, 'utf-8');
return JSON.parse(content);
} catch {
return null;
}
}
/**
* List recent sessions
*/
export async function listSessions(limit = 10) {
try {
await ensureDirs();
const files = await readdir(SESSIONS_DIR);
const jsonFiles = files.filter(f => f.endsWith('.json')).sort().reverse();
return jsonFiles.slice(0, limit).map(f => f.replace('.json', ''));
} catch {
return [];
}
}
/**
* Get aggregate stats
*/
export async function getStats() {
try {
const content = await readFile(STATS_FILE, 'utf-8');
return JSON.parse(content);
} catch {
return null;
}
}

122
quiz/src/ui.js Normal file
View file

@ -0,0 +1,122 @@
/**
* UI utilities for terminal display
*/
import chalk from 'chalk';
export function displayHeader() {
console.log(chalk.cyan('\n' + '='.repeat(60)));
console.log(chalk.cyan.bold(' CLAUDE CODE KNOWLEDGE QUIZ'));
console.log(chalk.gray(' Master Claude Code: The Complete Guide'));
console.log(chalk.cyan('='.repeat(60) + '\n'));
}
export function displayHelp() {
console.log(`
${chalk.cyan.bold('Claude Code Knowledge Quiz')}
Test your understanding of Claude Code with interactive MCQs.
${chalk.yellow('Usage:')}
npx claude-code-quiz [options]
node quiz/src/index.js [options]
${chalk.yellow('Options:')}
-p, --profile <type> Pre-select profile (junior|senior|power|pm)
-t, --topics <list> Quiz specific sections (1-10, comma-separated)
-c, --count <n> Limit number of questions (1-50)
-d, --dynamic Enable dynamic question generation via claude -p
-h, --help Show this help message
-v, --version Show version
${chalk.yellow('Profiles:')}
junior Junior Developer (15 questions, sections 1-3, 6)
senior Senior Developer (20 questions, sections 2-4, 7, 9)
power Power User (25 questions, all sections)
pm Product Manager (10 questions, sections 1-3)
${chalk.yellow('Topics:')}
1 Quick Start & Installation
2 Core Concepts
3 Memory & Settings
4 Agents
5 Skills
6 Commands
7 Hooks
8 MCP Servers
9 Advanced Patterns
10 Reference & Troubleshooting
${chalk.yellow('Examples:')}
npx claude-code-quiz # Interactive mode
npx claude-code-quiz -p senior # Senior profile, default topics
npx claude-code-quiz -p power -t 4,7,8 # Power user, specific topics
npx claude-code-quiz -c 10 # Quick 10-question quiz
${chalk.gray('Part of: https://github.com/FlorianBruniaux/claude-code-ultimate-guide')}
`);
}
export function displayQuestion(question, index, total, categoryName) {
console.log(chalk.gray('\n' + '-'.repeat(60)));
console.log(chalk.yellow(`Question ${index + 1}/${total}`) + chalk.gray(` [${categoryName}]`));
console.log();
console.log(chalk.white.bold(question.question));
console.log();
const options = ['A', 'B', 'C', 'D'];
Object.entries(question.options).forEach(([key, value], i) => {
console.log(chalk.cyan(` ${options[i]}) `) + value);
});
console.log();
}
export function displayCorrect() {
console.log(chalk.green.bold('\n✓ CORRECT!\n'));
}
export function displayIncorrect(question, userAnswer) {
const options = ['a', 'b', 'c', 'd'];
const correctLetter = question.correct.toUpperCase();
const correctText = question.options[question.correct];
console.log(chalk.red.bold(`\n✗ INCORRECT.`) + chalk.white(` The correct answer is ${chalk.green(correctLetter)}) ${correctText}`));
console.log();
console.log(chalk.yellow('Explanation:'));
console.log(chalk.gray(question.explanation.trim()));
console.log();
if (question.doc_reference) {
const ref = question.doc_reference;
const githubUrl = `https://github.com/FlorianBruniaux/claude-code-ultimate-guide/blob/main/${ref.file}${ref.anchor || ''}`;
console.log(chalk.blue('See: ') + chalk.underline(githubUrl));
if (ref.line) {
console.log(chalk.gray(` (Line ${ref.line})`));
}
}
console.log();
}
export function displayProgress(current, total, correct) {
const percentage = Math.round((correct / current) * 100) || 0;
const progressBar = createProgressBar(current, total, 20);
console.log(chalk.gray(`Progress: ${progressBar} ${current}/${total} | Score: ${correct}/${current} (${percentage}%)`));
}
function createProgressBar(current, total, width) {
const filled = Math.round((current / total) * width);
const empty = width - filled;
return chalk.green('█'.repeat(filled)) + chalk.gray('░'.repeat(empty));
}
export function displayCategoryScore(categoryName, correct, total) {
const percentage = Math.round((correct / total) * 100);
const barWidth = 10;
const filled = Math.round((percentage / 100) * barWidth);
const bar = chalk.green('█'.repeat(filled)) + chalk.gray('░'.repeat(barWidth - filled));
let color = chalk.green;
if (percentage < 50) color = chalk.red;
else if (percentage < 75) color = chalk.yellow;
return ` ${categoryName.padEnd(30)} ${correct}/${total} ${color(`(${percentage}%)`)} [${bar}]`;
}