Polish and ship-ready
Turn working code into a finished product
⏱ Est. ~9 min
01 · Read
Your game works. Two players can find each other, play tic-tac-toe in realtime, and handle disconnects gracefully. But working and finished are different.
A finished project has a clean UI, a README that explains what it is, no debug logs left in the code, and proper git history. This is the difference between a side project and a portfolio piece — something you'd actually show another engineer or a hiring manager.
This lesson is about the final 10% that makes the first 90% of your work shine.
Key points
- Working code and finished code are not the same
- Polish means: clean UI, README, no debug logs, proper git
- The README is the first thing anyone sees when they look at your project
- This is what separates a side project from a portfolio piece
02 · Prompt template
Ask Claude to improve the visual polish of the game. Give specific feedback on what feels rough.
Improve the UI for my tic-tac-toe game. Specific requests: (1) Add a smooth transition animation when a symbol appears in a cell. (2) When someone wins, highlight the three winning cells with a different background color. (3) Add a visual indicator of whose turn it is — for example, pulse the status text, or change its color to the current player's symbol color. (4) While searching for an opponent, disable the Find Game button and show a loading spinner or animation. (5) Make sure the game looks good on mobile — the board should scale down for small screens.
03 · Prompt template
Every project needs a README. Ask Claude to write one explaining what the project is, how to run it, and what tech it uses.
Help me create a README.md for the tic-tac-toe project. Include: (1) A title and one-sentence intro. (2) A 'How to Play' section explaining the game flow (find opponent, take turns, win/draw). (3) A 'Tech Stack' section listing Node.js, Express, Socket.io, and plain HTML/CSS/JS. (4) A 'Run Locally' section with step-by-step instructions: clone, npm install, node server.js, open localhost:3000. (5) A 'How It Works' section with a brief explanation of the client-server architecture and WebSocket communication. Keep it concise — no one reads a 500-line README.
04 · Checklist
Walk through this ship-ready checklist. Each item is what separates an amateur project from a professional one.
- Remove all debug console.log statements (keep only the connection/disconnection logs in server.js)
- Game UI looks clean — no overlapping elements, broken layouts, or placeholder text
- README explains what the project is and how to run it
- Create a .gitignore file that excludes node_modules/
- No hardcoded localhost URLs in the code — use relative paths so it works when deployed
- After all the polish changes, test the full game flow one more time
05 · Real-machine exercise
Initialize a git repository, make your first commit, and push to GitHub. This is the workflow you learned in Level 4.
06 · Quiz
Why should you remove debug console.log statements before shipping?
- They slow down the server significantly
- They expose internal state to anyone with DevTools open, clutter your server logs, and make real issues harder to find
- JavaScript doesn't allow console.log in production mode
- Socket.io conflicts with console.log
07 · Fill in the blank
A _____ file tells other engineers what your project is, how to install it, and how to run it.
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.