What You'll Build
A single-page HTML tool that acts as your intelligent coding companion. Paste any JavaScript function into it, and it does three things automatically: writes tests for it, explains any confusing terms in plain English, and uses AI-simulated sampling logic to decide how deep to go based on your skill level.
- A code input area where you paste any JavaScript function
- An automated test generator that writes Jest-style unit tests for your function
- A personal glossary panel that captures and explains tech terms from the code
- A skill-level selector that uses MCP sampling logic to adapt explanations to you
- A copy-to-clipboard button on every output panel so nothing gets lost
What You'll Need
Build the Layout and Code Input
Every good tool starts with a clear interface. In this step you're asking Claude to scaffold the full HTML page — dark theme, three output panels, a skill-level dropdown, and a textarea for pasting code. Getting the structure right now means the rest of the steps slot in cleanly.
Build me a single-file HTML tool called "Smart Test & Glossary Generator". It should have: - A dark background using #0a0f1a with surface cards at #111827 - A top header with the title in a serif font and a short subtitle - A left column with: a textarea labeled "Paste your JavaScript function here", a dropdown to select skill level (Beginner, Intermediate, Advanced), and a green "Analyze" button - A right section with three output panels stacked vertically: 1. "Generated Tests" — shows AI-written Jest unit tests 2. "Glossary Terms" — shows tech terms and plain-English definitions 3. "AI Decision Log" — shows what decisions the sampling logic made and why - Each panel should have a "Copy" button in the top-right corner - Use 'DM Sans' for body text and 'JetBrains Mono' for code blocks - Include placeholder text in each output panel that says "Run analysis to see results here" - All panels should have a subtle border at rgba(255,255,255,0.05) and rounded corners - Do not wire up any JavaScript logic yet — just the HTML and CSS layout
Claude should return a complete, self-contained HTML file you can save as index.html and open in a browser. The three output panels should be visible and clearly separated. If anything looks cramped or the layout breaks on a smaller screen, ask Claude to add a CSS media query for two-column layout before moving on.
Add the Automated Test Generator
This step brings in the skill from this week's testing tutorial. You're going to teach the tool how to analyze a JavaScript function and write meaningful Jest unit tests for it — covering happy paths, edge cases, and error conditions. The key here is the prompt structure you feed into the generator logic, not just the output.
Now add the JavaScript logic for the test generator. When the user clicks "Analyze", read the code from the textarea and the selected skill level from the dropdown. For the "Generated Tests" panel, write a function called generateTests(code, skillLevel) that: 1. Parses the function name from the code string using a regex 2. Builds a detailed prompt string that instructs an AI (simulated here) to write Jest unit tests 3. The prompt string should explicitly ask for: one happy path test, one edge case test (empty input, zero, null), and one test that expects an error or failure 4. For now, instead of calling a real API, have the function return a realistic hardcoded example output block of Jest tests as a template string — use a simple addition function called "add(a, b)" as the example, with describe() and it() blocks 5. Display the output in the "Generated Tests" panel inside a styled code block 6. If no function is detected in the textarea, show an error message in the panel instead Do not touch the other two panels yet. Show me the full updated index.html file.
After clicking Analyze with some code in the textarea, the "Generated Tests" panel should fill with properly formatted Jest test code — describe(), it(), and expect() blocks. You should also see the error message appear if the textarea is empty. The copy button on that panel should work.
Wire Up the Glossary Term Extractor
Here's where this week's glossary tutorial comes alive. Instead of manually copying terms into a notes doc, your tool scans the pasted code and automatically identifies technical vocabulary — things like "callback", "async", "prototype", "destructuring" — and explains each one in plain English matched to the user's skill level. This is the panel that will genuinely teach you something every time you use it.
Now add the glossary extractor logic to the existing file. When the user clicks "Analyze", also run a function called extractGlossaryTerms(code, skillLevel) that does the following:
1. Scan the code string for any of these technical terms (match case-insensitively): async, await, callback, promise, prototype, destructuring, closure, arrow function, reduce, map, filter, typeof, spread operator, rest parameter, try/catch
2. Return only the terms that actually appear in the pasted code
3. For each matched term, generate a plain-English definition object with: { term, definition, example }
4. Adjust the definition depth based on skillLevel:
- Beginner: one sentence, no jargon, real-world analogy
- Intermediate: two sentences with one code concept mentioned
- Advanced: two sentences using correct technical vocabulary
5. Hardcode realistic definitions for at least 5 of the terms above as a dictionary inside the function
6. Render each term in the "Glossary Terms" panel as a card with: the term in green bold, the definition below it, and the example in a small monospaced block
7. If no known terms are found, show "No recognized terms found — try pasting a more complex function"
Show me the full updated file.
Paste a function that uses async/await or reduce and check that those exact terms appear as cards in the Glossary panel. Switch the dropdown from Beginner to Advanced and re-run — the definitions should visibly change in depth and vocabulary. If both show the same text, ask Claude to debug the skillLevel conditional logic.
Implement the MCP Sampling Decision Log
This is the most interesting part — and the one that ties directly to this week's MCP sampling tutorial. MCP sampling is about letting the AI make judgment calls mid-task rather than blindly following one instruction. Here, you're simulating that same decision-making loop: the tool inspects the code, reasons about its complexity and the user's skill level, and logs a transparent explanation of every decision it made. It's AI that shows its work.
Now build the "AI Decision Log" panel logic. This panel simulates MCP sampling — the idea that an AI agent inspects context and makes a series of small decisions rather than applying one fixed rule. Write a function called runSamplingLog(code, skillLevel, detectedTerms) that returns an array of decision log entries. Each entry is a plain-English sentence explaining a judgment call the system made. Include at least these decision checks: 1. Code length check: If the code is under 5 lines, log "Code is short — generating minimal test suite (1 happy path, 1 edge case)". If over 5 lines, log "Code is substantial — expanding test suite to include error condition tests." 2. Skill level routing: Log which definition depth was chosen and why, e.g. "User selected Beginner — using analogy-first definitions to reduce jargon load." 3. Term count decision: If more than 3 glossary terms were found, log "High term density detected — prioritizing the 3 most commonly misunderstood terms in the glossary.". If 0 terms found, log "No recognized terms in code — skipping glossary generation." 4. Async detection: If the word 'async' appears in the code, log "Async pattern detected — flagging Promise and await for glossary inclusion even if not explicitly listed." 5. Final summary line: Always log "Analysis complete. Decisions made: [N]. Confidence: High." Render each log entry in the "AI Decision Log" panel as a numbered line in a monospaced font, with a small green dot icon before each line. Show me the full updated file.
The Decision Log panel should read like a readable audit trail — five or so lines, each explaining a choice the system made about your specific code. Try pasting a short function vs. a long one and watch entries 1 and 5 change. That dynamic response is exactly what MCP sampling feels like in a real agent: transparent, context-aware reasoning you can inspect and trust.
Polish the UX and Add a Reset Flow
The logic is done — now make it feel like a real tool. A polished UX means loading states, clear feedback, and a way to start fresh. This step also adds a subtle animated state to the Analyze button so users know something is actually happening when they click it. Small touches that make a big difference.
Do a final polish pass on the tool. Make these changes to the existing file: 1. Loading state: When the user clicks "Analyze", immediately change the button text to "Analyzing..." and disable it. After a 600ms simulated delay (using setTimeout), run all three panel functions and then re-enable the button with its original text. This makes it feel like real processing is happening. 2. Reset button: Add a secondary "Reset" button next to the Analyze button. When clicked, it should: clear the textarea, reset the skill-level dropdown to Beginner, and restore all three panels to their original placeholder text. 3. Empty state guard: Before running analysis, check that the textarea is not empty or only whitespace. If it is, show a small red error message below the textarea that says "Please paste a JavaScript function before analyzing." — remove this message once the user starts typing. 4. Scroll behavior: After analysis completes, smoothly scroll the page down to the output panels using scrollIntoView with behavior: smooth. 5. Page footer: Add a simple footer that says "Built with Claude · Smart Test & Glossary Generator" in small muted text. Show me the complete final index.html file with all five steps integrated.
Open the final file in your browser and run through it properly: click Analyze with an empty textarea (error should appear), paste a real function and click again (button disables, then all three panels fill, page scrolls down), then hit Reset (everything clears). If the scroll behavior feels jarring or the delay is too short, ask Claude to adjust the timing or add a CSS opacity fade-in on the panels.
Common Issues
setTimeout in Step 5 might be firing before the functions actually return values. Ask Claude: "The output panels are not updating after the delay — check whether the three generator functions are being called inside the setTimeout callback or outside it."detectedTerms array passed to runSamplingLog() might be empty because the glossary function runs asynchronously or returns before it resolves. Ask Claude to ensure both functions share a single extracted terms array before either panel renders.innerText from the wrong element. Ask Claude: "Fix the copy button so it reads the textContent of the output panel's inner code or div element, not the panel container itself."What You Learned
Tips for Going Further
The tool you've built is already useful — but there's a lot of room to grow it. Here are some directions worth exploring once you've got the basics working.
-
→
Connect it to a real AI API. Right now the outputs are hardcoded examples. Wire the Analyze button to Claude's API (or OpenAI's) and pass the actual code as part of the prompt — the glossary and test outputs will become genuinely dynamic.
-
→
Persist the glossary across sessions. Use localStorage to save every term that gets extracted. Add a "My Glossary" tab that shows all terms collected so far across every function you've analyzed — your own growing personal dictionary.
-
→
Add support for Python or TypeScript. Add a language selector and update the test template and term dictionary accordingly. Python would use pytest syntax; TypeScript would include type annotation terms like interface, generic, and union type.
-
→
Make the sampling log interactive. Let users click on any decision in the log to override it — for example, forcing the "Advanced" test suite even when the code is short. Then watch how the other panels respond. That's a real MCP-style feedback loop.
-
→
Export everything as a Markdown file. Add an "Export" button that packages the generated tests, glossary cards, and decision log into a single
.mdfile the user can download. Perfect for dropping into a project wiki or personal notes system.