Skip to content
CodexgreenfieldWeb6 files · +1654 −15

Build a Taboo-style word game with in-browser Tiny Aya (Gradio Space)

Session from clue-vibes-traces on Hugging Face by build-small-hackathon · CC-BY-4.0 · condensed by Coders Talk

22msession
0interventions
GOAL

Implement a hackathon Taboo-style word-guessing game as a Gradio Space, where a player writes a clue for a target word (avoiding banned words) and an in-browser Tiny Aya ONNX model tries to guess it within 30 seconds and up to three attempts.

  1. Prompt · +0
    Build a Taboo-style clue game as a Gradio Space: player writes a clue avoiding banned words, an in-browser Tiny Aya ONNX model guesses within 30s/280 chars, up to 3 guesses, using a 7000+ word dataset.
  2. Agent did · +0m
    Explored the repo, hackathon rules, dataset and sibling Gradio example projects, then built app.py (FastAPI/Gradio Server backend for card selection and validation), index.html, static/app.js (browser-side Tiny Aya via Transformers.js) and styles.css implementing the full start-screen → download → game → score loop; verified Python compiles and JS parses.
  3. Break · 57h 19m away, not counted
  4. Prompt · +9m
    Small visual bug: after winning a round and starting a second one, the bottom card still shows 'tiny aya found it' instead of resetting to 'awaiting'.
  5. Agent did · +9m
    Traced startRound() and found it didn't reset the round-status UI; added a resetRoundUi() helper to reset the message, model chip and clue box together, then verified with node --check.
  6. Break · 46h 49m away, not counted
  7. Prompt · +10m
    Add a How To Play button/modal explaining the game and warning about the ~2GB model download; also verify whether passing an HF token would speed up the download so it could be set as a Space secret.
  8. Agent did · +10m
    Confirmed the q4f16 model is ~2.3GB and that an HF token would not speed browser-side downloads (and shouldn't be exposed client-side); added a styled How To Play modal with open/close wiring. Then, for a follow-up request, changed timer-expiry behavior so a valid in-progress clue auto-submits instead of causing an instant loss, only losing immediately on empty/blocked clues.
  9. Break · 10h 48m away, not counted
  10. Prompt · +12m
    Can we check if the layout is responsive and works well on mobile too?
  11. Fail · +12m
    Tried to get real viewport verification: in-app browser skill file missing, persistent Node REPL crashed under the Windows sandbox, and the bundled Playwright package couldn't load because its sibling playwright-core module was missing, even after adjusting NODE_PATH — no working browser automation was found for a real responsive check.
  12. Outcome · +22m
    Session ended mid mobile-responsiveness check: game fully implemented and iterated through three bug/feature fixes, but automated viewport testing was never achieved due to missing tooling (Playwright/playwright-core unavailable), so no mobile layout verdict was delivered.
VERDICT

Next time I'd mention upfront that local browser automation tooling (Playwright etc.) is flaky in this sandboxed Windows environment, so we don't burn a long stretch discovering that mid-session. The interventions that mattered were quick, precise bug reports (the stuck round-status label, the timer-loses-instantly behavior) — those one-line corrections got fixed fast because I pointed exactly at the visible symptom rather than the code.

I tried this · 0

Discussion · 0

How Builds work