CODEBASE MENTOR BY JESTATS
New codebase.
A clearer way in.¶
Understand the architecture. Find the right place to change it.
Ask your coding agent for answers grounded in the source it actually reads.
Claude Code · Codex · IBM Bob · Open skills
No extra API key or service needed for skills.
Find your bearings¶
“How does this request reach the database?” Follow an execution path with links to the files and symbols that matter.
Plan your next change¶
“Where do I add a new endpoint?” Find the closest working example, relevant tests, and the gotchas your team knows.
Check what changed¶
“Is our onboarding doc still true?” Compare its claims with current source and get a report of drift and missing evidence.
Start with one question¶
Install for your agent, open any repository, and paste:
Use Codebase Mentor to trace one important execution path in this repo.
Explain it to a new contributor. Cite the files and symbols you read,
and flag anything you cannot verify.
You can start without an ONBOARDING.md. The mentor works from source. When you want to capture the design decisions and pitfalls source does not explain, ask the onboard skill to draft your team's map.
Install where you already work¶
Run inside Claude Code:
/plugin marketplace add jestatsio/codebase-mentor
/plugin install codebase-mentor@codebase-mentor
Run with a current Codex CLI:
codex plugin marketplace add jestatsio/codebase-mentor
codex plugin add codebase-mentor@codebase-mentor
Or add the GitHub marketplace in the Codex app's plugin interface.
From the repository you want to understand:
curl -fsSL https://raw.githubusercontent.com/jestatsio/codebase-mentor/main/install.sh | bash -s -- --agent bob --project
Installs both skills in .bob/skills/.
All installation options, updates, and troubleshooting →
The doc is the map. Source is the truth.¶
A short ONBOARDING.md points your agent toward the right code and records the context your team cares about. The mentor protocol asks it to read those anchors, verify behavior, and distinguish facts from unresolved questions.
Every architecture or change-guidance claim must be backed by a symbol or file read in the current session.
Missing evidence should be visible. A stale doc should be corrected with evidence. A proposed new symbol should be clearly labeled as a proposal.
These are instructions to your agent, not a guarantee of correctness. Review the cited source before acting. The original case study explains what was evaluated and its limits.
Built to share with your team¶
- Create an onboarding map with seven concise sections and a named owner.
- Roll it out through native plugins or committed project skills.
- Review real examples from services, libraries, and a workflow application.
- Catch doc drift in CI with an optional scheduled scan.