DocuGate Tours

Problem. When a developer joins a project, the hardest part is not the syntax, it is the meaning. They see a number on screen, like an invoice Total, and have no idea where it comes from. The answer is spread across the frontend component, the API client, the endpoint and the backend code, and nobody writes it down. So every new developer traces it again by hand, and the senior developer who knows it answers the same questions again and again. Solution. DocuGate Tours puts the answer next to the element, inside the running app. A developer runs npm i -g docugate, then docugate init in their project. Setup asks a few numbered questions (what the repository is, sign in, where the docs live, which AI writes the tour), and IBM Bob reads the code and writes a tour: one markdown file per screen in .docugate/tour/. Each step says what an element is, the endpoint and field its value comes from, the file that shows it, and the file that computes it. How people use it. They start their project as usual (npm run dev) and a Tour button appears in the corner, in development only. The Walkthrough shows the page's steps as a checklist: start it, and a ring marks each element with a card explaining it. The Inspector is one switch: click anything to see its explanation, edit it when the AI got something wrong, or add a step for an element that has none. Every change is saved straight into the repository, so it is reviewed in a pull request like code. What makes it different. The tour cannot quietly go stale: docugate check verifies every step against the code (the files exist, the component still calls the endpoint, the element is still there) and fails CI when one no longer holds. It works in any web app, with no framework plugin: one script in a shadow DOM. And it connects to DocuGate, which publishes the project's markdown documentation as a site; the Tour button links straight to it. Target users. Teams onboarding new developers, open source maintainers, and anyone taking over an unfamiliar codebase.