agentleFS
Sign inStart free
siostechlabssiostechlabs/brainygym-skills/skills/learn-codebase/SKILL.md

learn-codebase

Skill0 starsChanged 20 days agoMITView on GitHub

Use when the user wants to understand or get onboarded to the current repository or project ("help me learn this codebase", "I'm new to this repo", "make me a course about how this project works"). Reads the project's documentation and structure, proposes a course on its architecture, concepts and workflows, saves it to BrainyGym after the user approves it, and starts a first quiz. Does not copy source code or secrets into the course.

  • Reads credentials

14 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use oh-my-issues, what-the and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • tuliosalustiano27Skill

    oh-my-issues

    Cluster a GitHub issue backlog by root cause into a small set of plan-master issues, redirect children with a standardized comment, and bundle architectural-fix PRs that close clusters atomically. Use when an issue tracker has accumulated dozens of reports that share underlying defects, when asked to triage / consolidate / cluster / dedupe issues, when asked to build a plan series or roadmap from open issues, or when routing a new incoming bug into an existing plan.

    Also in 3 projects that use this

  • tuliosalustiano27Skill

    what-the

    What the? Use when the user wants a plain-English breakdown of something technical — the who, what, where, why, and when.

    Also in 3 projects that use this

  • thedotmackSkill

    pathfinder

    Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to "find the ideal path," unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus per-system /make-plan prompts.

    Also in 5 projects that use this

  • tunnckoCoreSkill

    how-it-works

    Use for 'how does X work', code walkthroughs before changing something, and placement / ownership / layering questions ('where should this live', 'which package owns this', 'is this the right layer'). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation.

    Also in 4 projects that use this

  • barrelcSkill

    mem-search

    Search kimi-mneme's persistent cross-session memory database. Use when user asks "did we already solve this?", "how did we do X last time?", "what did we do yesterday?", or needs work from previous sessions.

    Also in 3 projects that use this

  • TrecekSkill

    make-plan

    Create implementation plans through deep codebase understanding. Use when user asks to create, devise, or write a plan. Leverages subagents to explore approaches, understand systems, and design aligned solutions.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 14 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ask one question: what do they need to be able to do in this project (fix bugs in one area, ship features end to end, review pull requests, …

    line 26
  2. Distinctive:

    Read, in this order and only as much as needed: the README and contributing guides, agent instruction files (AGENTS.md, CLAUDE.md), …

    line 31
  3. Distinctive:

    Ask whether the project is private or internal: If it is, keep everything at the level of architecture and concepts: describe components by …

    line 39
  4. Distinctive:

    Never include credentials, tokens, keys, internal URLs or hostnames, customer data or personal data, whatever the answer.

    line 42
  5. Distinctive:

    Never copy source code into the course, even from an open-source project.

    line 44
  6. Very specific:

    Call get_course_authoring_guide and follow it exactly.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 14 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Learn this codebase

Turns the current repository into a BrainyGym onboarding course, so the user can review how the project works with spaced repetition instead of re-reading the code. BrainyGym schedules reviews of each concept and puts them in the user's daily session on the web and the app.

Reply in the user's language. BrainyGym supports Spanish (es) and English (en); for any other language, ask which of the two they prefer.

0. Check the connection

This skill needs the BrainyGym tools (save_course, start_quiz, get_course_authoring_guide). If they are not available, tell the user how to connect, then stop:

  • Claude Code: claude mcp add --transport http brainygym https://brainygym.com/mcp, then /mcp to sign in.
  • Other agents: add the remote MCP server https://brainygym.com/mcp (Streamable HTTP) in the agent's MCP settings and sign in with a BrainyGym account (free to start, 18+).

1. Ask about the goal

Ask one question: what do they need to be able to do in this project (fix bugs in one area, ship features end to end, review pull requests, run it locally)? The answer decides what the course covers.

2. Read the project

Read, in this order and only as much as needed: the README and contributing guides, agent instruction files (AGENTS.md, CLAUDE.md), architecture or design docs, the top-level layout, the build and test setup, and the entry points of the main modules. Do not read secrets (.env*, credentials, keys).

3. Decide what may leave the machine

The course is stored in the user's BrainyGym account, outside this repository. Before writing it:

  • Ask whether the project is private or internal. If it is, keep everything at the level of architecture and concepts: describe components by their role ("the background job worker", "the payments adapter"), not by internal names, and include no source code.
  • Never include credentials, tokens, keys, internal URLs or hostnames, customer data or personal data, whatever the answer.
  • Never copy source code into the course, even from an open-source project. For open-source projects you may use real module names; any code example must be written from scratch as a generic illustration.

4. Propose the course and wait for approval

Show a draft syllabus first and do not save anything yet: a title, a one-line goal and 3–8 modules in learning order (for example: what the product does, architecture overview, data model, a request end to end, how to run and test it, conventions, the riskiest areas), each with its concepts. State what will and will not be stored. Save only after a clear yes.

5. Write and save it

Call get_course_authoring_guide and follow it exactly. Questions should test understanding of how the project works ("Where would you add X?", "What happens when Y fails?"), not trivia. Save with save_course (a new UUID as requestId), then share the course link from the tool result.

6. First practice

Offer a first quiz with start_quiz. If the BrainyGym quiz view is shown, the user answers there; otherwise ask one question at a time and grade each with submit_quiz_answer. Never reveal the answer before the user answers and never invent grades.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free