Bob Onboarding Pipeline

Problem. A new developer's first weeks are slow and inconsistent. They get a stale README and a wiki link, while a senior spends days re-explaining where the code starts, what is broken, and which tools to install. The knowledge lives in people's heads, so every hire gets a different experience, and the team pays for it twice: the newcomer's ramp-up time and the senior's lost time. Solution. Bob Onboarding Pipeline turns that into one command. A manager or senior developer runs /onboard in Bob IDE. Bob interviews them (codebase, company, the newcomer's role, dates, buddy and manager), scans the real repository, and produces a personalised pack for that hire: a branded PDF covering the company, the role, the codebase, first tasks and a dated timeline; one Markdown file per real issue found (bugs, security, missing tests), each with evidence at file and line and guidance, not a patch; a context folder that the newcomer loads into their own Bob, so they get an AI assistant that already knows their company, role and codebase; an optional narrated code-tour video; a separate brief for the manager. Why it can be trusted. Onboarding material that invents facts is worse than none. So the pipeline never lets the model grade itself. Plain Python checks that every cited file and line exists, that issue files follow the template, and that the video script only retells the pack. Anything Bob cannot confirm is written as "Unknown, ask your buddy" and listed on a flagged list. A human must approve that list before anything is rendered or sent. Tool auto-approve does not count as approval. The target codebase is read-only, and secrets are never copied. Target users. Engineering managers and senior developers who onboard people, and the new hires themselves. Newcomers need no account to read the PDF; they load the context zip into their own Bob. What is different. It is personalised per hire, grounded in the actual code, and delivered on several channels (email, PDF, video, and a Bob-ready context folder), following the onboarding research were viewed. Naming, dates, the newcomer's setup guide and all checks are deterministic code, so runs are repeatable and testable. The core is generic: everything client-specific lives in an instances/ folder, so a new company is a folder, not a code change. Result. In our demo run on a small Java web app, Bob found 10 issues (including three sets of hardcoded credentials), produced a 7-page PDF, a context zip and a narrated tour video, and delivered them by email through an MCP server. Machine time was about 20 minutes plus one minute of human approval, against an estimated 5 hours by hand. This is a proof of concept tested on one project so far.