walkboard

Topics in the source

• Walkboard
• 0. Language, mode, questions, settings
• 1. Write the plan (build)
• 2E. Write the explanation (explain)
• 3. Show and listen
• 4. Build (build)
• 4E. Walk through (explain)
• Keep it cheap

Long text loses people. You write plan.json; Walkboard draws it as a local page; what the user clicks or types there comes back to you. WB = node /bin/walkboard.mjs (Node 18.18+, no install): write it out or make a shell function, wb() { node /bin/walkboard.mjs "$@"; }; a variable holding it does not run in zsh. Files named below are under references/: read one only when you reach it. Use the user's language for everything (questions, plan, replies, suggested commit messages) and set "lang". Code, ids and paths stay as they are. Readers build software: keep technical terms as the team says them (config, deploy, Secret, egress, batch), never translated or invented; say what a thing is or does, not a vague label. Hard terms are explained on hover (glossary for the project's own). build: something new or changed. Sections 1, 3, 4. explain: understand existing code. Sections 2E, 3, 4E. design: choose how to build something that does not exist yet ("what should we use for…", "compare…"). Read design.md, then section 3. /walkboard alone: look through the repository briefly and offer 2-3 things from it by name (a question tool if you have one, else in chat), a real flow to explain first.

This is an excerpt. Refer to the complete source and its current requirements.