How retrieval picks examples
When I draft a resume bullet with Claude, the draft is shown a few approved bullets that are close in meaning to the work being described. This page shows that step for 13 fixed test queries, with the real scores. It runs nothing in your browser: every score was worked out when this site was built.
How to read it
- Each query is a plain description of some work, written the way I would describe it.
- A score runs from 0 to 1, and higher means closer in meaning. A bullet is shown only if it scores 0.60or more, and at most 5 are shown, best first.
- For 10 of the queries I know which approved bullet should be found, and it is markedExpected match. The other 3 are off topic on purpose: nothing should reach the floor, and the draft would then use the writing rules alone.
Result
The expected bullet was in the top 3 for 9 of 10 queries (90%). The test needs at least 8 of 10.
The miss: “Before each release of my Excel add-in I walk through a list of what every button is supposed to do, so each release gets the same check.” The expected bullet ranked 5th (score 0.64), behind bullets that are only loosely related. I show it because a result like this is the reason to test retrieval instead of trusting it.
The queries
Open a query to see which bullets were picked.
Before each release of my Excel add-in I walk through a list of what every button is supposed to do, so each release gets the same check.Expected bullet missed the top 3: it ranked 5
- 0.67Stored user settings in the Windows registry after finding that Excel never saves an add-in on close, so each user's choices now persist between sessions.
- 0.66Created a pre-release check that confirms the source code matches what ships inside the built add-in, so what users install is always what was reviewed.
- 0.65Built and maintained an open-source VBA Excel add-in that turns Smartsheet exports into branded customer equipment lists, project schedules, and vendor quote packages, cutting a 4+ hour, several-hundred-click manual build to 4 clicks and about 10 seconds.
- 0.65Added a GitHub Actions workflow that checks every code change for broken ribbon buttons and missing coding-standard declarations, catching those problems before merge instead of in users' hands.
- 0.64Wrote a manual smoke-test checklist with expected results for every ribbon tool, holding every release to the same check before it shipped. Expected match
When something broke I dug through the server error logs in Kibana and attached the log lines to the bug report so developers could see what happened.Expected bullet found at position 1
- 0.80Investigated defects through Kibana error logs and filed them with log evidence, giving developers concrete detail to act on. Expected match
- 0.76Built Kibana dashboards and saved searches the team used for error monitoring and defect investigation, giving testers one place to spot trouble and trace its cause quickly.
- 0.71Monitored application error logs in Kibana from the war room at every device launch and peak retail event, escalating live production issues to development and operations teams while the launch was still underway, limiting customer impact during the highest-traffic days.
- 0.70Inspected network logs, session data, cookies, and mobile browser behavior in Chrome DevTools during testing, pinpointing whether a failure came from the page, the network, or the server before filing it.
- 0.68Added a GitHub Actions workflow that checks every code change for broken ribbon buttons and missing coding-standard declarations, catching those problems before merge instead of in users' hands.
I set it up so that pushing a version tag builds the Android app, signs it, and publishes it and the web app without anyone doing it by hand.Expected bullet found at position 1
- 0.79Automated releases end to end: pushing one version tag builds, signs, verifies, and publishes the Android app to GitHub Releases and the web app to GitHub Pages, with v1.0.1 shipped entirely by the pipeline, making every release faster and more consistent. Expected match
- 0.64Created a pre-release check that confirms the source code matches what ships inside the built add-in, so what users install is always what was reviewed.
- 0.64Led a 4-phase migration to Kotlin Multiplatform and Compose Multiplatform, sharing about 80% of the code between Android and the web (WebAssembly) with no change in behavior on Android, letting one shared codebase power both platforms.
- 0.62Configured GitHub Actions CI with branch protection and parallel Android and web jobs, requiring lint, tests, coverage, a documentation check, and the build to pass before any merge, keeping broken code off the main branch.
- 0.62Moved the add-in from an unversioned single file to a source-controlled project with a scripted build, making every release repeatable and every change traceable.
Every change to my site starts as a GitHub issue, goes through a pull request, and only merges once the build passes.Expected bullet found at position 1
- 0.78Established an issue-first workflow in which every change ships through a reviewed pull request and merges only after the build check passes, making every change reviewed, traceable, and tested. Expected match
- 0.77Configured GitHub Actions to run the suite on every pull request and a smoke test against the live site after each deploy and weekly, catching broken changes before they merge and live-site problems that appear between deploys.
- 0.76Added a GitHub Actions workflow that checks every code change for broken ribbon buttons and missing coding-standard declarations, catching those problems before merge instead of in users' hands.
- 0.70Synchronized the wiki with the docs and README on every merge and added a bot that flags any pull request changing what users see without updating the user guide, keeping documentation current without manual effort.
- 0.69Configured GitHub Actions CI with branch protection and parallel Android and web jobs, requiring lint, tests, coverage, a documentation check, and the build to pass before any merge, keeping broken code off the main branch.
I tested checkout with every major credit card brand across the 3D Secure, address, and security code combinations.Expected bullet found at position 1
- 0.76Proved card authentication held across the full 3D Secure, address, and security code matrix on Visa, Mastercard, Amex, and Discover, making sure that only verified cardholders' payments were authorized. Expected match
- 0.68Validated every way customers paid, from cards, PayPal, and ACH to gift cards, account credit, and split payments, across checkout, bill pay, and AutoPay, keeping revenue flowing through launches and peak retail events.
- 0.65Tested the checks as well as the product, breaking coverage and breaking tags on purpose to confirm the gate caught both, proving the traceability gate can be trusted.
- 0.64Built credit-check test coverage from scratch in about two weeks for the device installment plan launch, partnering with credit, billing, and data teams to create test customers across credit classes.
- 0.63Validated fraud-related fixes across test environments, production, and regression cycles, confirming every exploit stayed closed in later releases and shielding customers and revenue from repeat attacks.
I stood up a stand-in for the company intranet server on Windows Server so I could try web parts safely, resetting it every week from a snapshot.Expected bullet found at position 1
- 0.72Built a local replica of Nucor's SharePoint server on Windows Server to deploy and test web parts, restoring it weekly from a saved image, letting the team test safely without touching the live system and start every test from a clean state. Expected match
- 0.64Developed VB.NET forms and SharePoint web parts that drove the approval workflow and business logic through SQL procedures, giving HR approvals that ran automatically without manual routing.
- 0.63Resolved a Windows-versus-server difference that incorrectly flagged saved resume layouts as out of date, ending false build failures and making the resume build behave the same on every machine.
- 0.62Wrote an automated smoke test for the live website that loads the production build, taps a tile, checks for errors, then stops the server and confirms the app still works offline, catching a broken release as soon as it goes live.
I fix guitars and amplifiers for customers, adjusting the setup and re-soldering broken connections while they wait.Expected bullet found at position 1
- 0.79Performed guitar setups and soldering repairs on clients' instruments and amps, fixing problems on the spot and saving clients weeks of repair downtime and significant cost. Expected match
- 0.67Provided on-the-spot technical support for performers unfamiliar with shared gear, troubleshooting setups under time pressure between sets, keeping every set on schedule.
I moved a couple dozen old reports onto a new data source, which cut down on numbers that did not match.Expected bullet found at position 1
- 0.82Migrated 25+ legacy reports to a new data source, reducing data mismatches and manual reconciliation. Expected match
- 0.66Caught a traceability report understating linked tests (491 of 634) by checking the live page after release, traced it to a de-duplication step that collapsed parametrized tests sharing a title, and fixed it with a test that fails on the old counting, keeping the published coverage numbers accurate.
- 0.62Derived test expectations from the same YAML files the site is built from, eliminating a second hand-copied list that can go stale and keeping every test accurate as the content changes.
- 0.61Documented how to add each kind of content in plain-language guides beside the data, making a new resume bullet, project, art piece, or release a data-and-image update instead of a code change.
- 0.60Refactored the codebase in small, reviewable changes, removing duplicated code across five user forms and replacing silent failures with errors users can see and report.
We ran the music festival cheaply so more local bands got heard and the leftover money went to charity.Expected bullet found at position 1
- 0.71Designed the festival to stay low-cost, maximizing exposure for local bands while still returning surplus to charity. Expected match
- 0.70Set clear, upfront expectations with performers: paid out-of-town bands fairly, asked local bands to donate their time, and directed all surplus to the charity, building trust and avoiding disputes over money.
- 0.64Organized an annual charity music festival for 11 years as one of three volunteer organizers, raising about $2,000 each year for Y'all Rock Camps, an inclusive music camp program.
Before shipping, I install the new app version over the old one and check that saved recordings and boards still work.Expected bullet found at position 1
- 0.77Built upgrade testing into the release checklist: installed each new version over the previous one and confirmed recordings, boards, and settings survived, protecting users' irreplaceable recordings through each update. Expected match
- 0.71Designed data-integrity safeguards: older saved boards keep loading after format changes, tiles with missing audio reset themselves instead of failing silently, and cleanup never deletes audio a saved board still uses, protecting users' recordings and boards through updates and cleanups.
- 0.70Created a pre-release check that confirms the source code matches what ships inside the built add-in, so what users install is always what was reviewed.
- 0.65Explored the app hands-on and found layout breaks in landscape mode, fixed the header height, tile layout, and sticky rows, and tested both orientations from then on, keeping the board usable in both landscape and portrait.
- 0.64Protected irreplaceable recordings with a weekly backup reminder that never blocks the board.
My sourdough starter needs feeding twice a day and the crust came out too pale last weekend.Off topic: nothing reached the floor, as it should
No bullet scored 0.60 or more, so no examples are shown and the draft uses the writing rules alone.
It rained all afternoon, so the picnic moved indoors and we played cards until the sun came back.Off topic: nothing reached the floor, as it should
No bullet scored 0.60 or more, so no examples are shown and the draft uses the writing rules alone.
The tomato plants in the back garden need staking before the next windy week.Off topic: nothing reached the floor, as it should
No bullet scored 0.60 or more, so no examples are shown and the draft uses the writing rules alone.