# Skill-chip typing performance proof

Use a separate checkout and fresh database for each commit. Run `T3CODE_DEV_SEED=0 vp run dev`, pair a Chromium browser, and use its default project's empty new thread. Keep the viewport at 1280 × 800 and the light theme. Do not send an agent turn.

1. Click the composer and type `$`. Wait for the skills menu, then press Enter to select `contribution-triage`.
2. Start recording. Evaluate `typing-driver.js` in the browser document. It appends synthetic ordinary text, then measures 60 single-character `document.execCommand('insertText')` insertions at each of three prompt sizes. Each measurement ends after two `setTimeout(0)` ticks. Stop recording.
3. Clear the composer through its editable selection and `document.execCommand('delete')`. Evaluate the identical driver again as the plain-text control.
4. Compare the returned medians, sample arrays, and chip counts. The reported lengths are the final lengths after each 60-character sample batch. The chip remained present for all chip measurements.

Base: [62dc589d6d](https://github.com/pingdotgg/t3code/commit/62dc589d6dff48c73002842e4603c5ab89a6880f).
Head: [3f86b2ce21](https://github.com/pingdotgg/t3code/commit/3f86b2ce214ec4c5636b0566570aa2085f2e9e2e).

Both runs used the same visible browser tab. These absolute times differ from background-tab triage times. The base reproduces the growing chip penalty (29.4 vs 19.4 ms near 900 characters; 39.0 vs 21.3 ms near 3000). The head removes that growing penalty (18.5 vs 17.5 ms; 19.2 vs 19.8 ms).

The scenario documentation explicitly excludes performance regressions from supported proofs, so this was a manual real-app browser comparison, not an assertion-based scenario. No unit-test or isolated helper benchmark is used as evidence.

Videos were reviewed across their duration and cropped identically to the composer to exclude private operational labels. No playback speed changes. Only synthetic prompt text is visible.

AI-assisted; verified with the tests and tools listed above.