Skip to content

Glossary

The Claude Code vocabulary

Plain-language definitions for the words that keep coming up. Link directly to any term with /glossary#<slug>.

Terms

In one line

An AI assistant that can take actions on your behalf — read files, run commands, browse the web — not just chat back. Claude Code is one.

In detail

An agent is what you get when you take a language model and give it hands. Specifically: a set of tools it’s allowed to call (read a file, write a file, run a , fetch a URL, query a …) wrapped in a loop that lets it decide which tool to use, call it, read the output, decide again, and continue — until it thinks the task is done.

A chatbot is the same without the loop. One question in, one answer out. It can produce text but it can’t do anything in your environment. Claude.ai and ChatGPT’s web interface are chatbots (mostly — both are growing agent features over time).

Claude Code is an agent. That’s the central thing it does — composing file reads, edits, commands, and its own reasoning into one continuous loop.

What changes when you switch from chatbot to agent:

ChatbotAgent
Blast radiusA paragraph you can ignore.A deleted file, a wrong git push, an outbound call.
Error feedbackYou ignore or correct manually.Errors compound visibly — compile fails, tests fail, file changes you didn’t want.
IterationCopy-paste error → ask again.Automatic — the agent already saw it, already retried.
What you delegateDrafting, brainstorming.Multi-file refactors, debug loops, “make all tests pass.”
What you keepAll execution.Approval on risky actions. Review on every diff.

Subagents — agents inside agents

Inside a session you can spawn subagents — fresh Claude instances with their own , system , and tool set — to handle one focused job. The parent agent collects the result and discards the subagent’s working context. This is the cleanest way to run long, exploratory tasks (research, deep file searches, parallel work) without burning through your main session’s .

Use them when:

  • The sub-task is exploratory (you don’t know what you’ll find)
  • You don’t want the noise polluting your main context
  • The sub-task can be parallelised against others
In one line

The company that makes Claude. Just like OpenAI makes ChatGPT, Anthropic makes Claude — the chatbot, the website, and Claude Code.

In detail

Anthropic is the AI safety company behind Claude. Founded in 2021 by Dario and Daniela Amodei and a group of researchers who left OpenAI, they sit alongside OpenAI, Google DeepMind, and Meta as one of the small set of labs training frontier large language .

Their stated posture is “build the frontier carefully” — they publish their alignment research, operate a Responsible Scaling Policy that gates capability rollouts on safety thresholds, and treat the commercial side (Claude.ai, the , ) as the engine that funds the research.

For day-to-day work all you really need to know is: when you read about a new Claude model, a price change, a usage policy, or a Claude Code feature — that’s coming from Anthropic. Claude Code is their ; the Claude API is their developer endpoint; Claude.ai is their consumer chatbot. One company, several surfaces.

In one line

A door one program opens for another. When an app fetches the weather or sends a message, it's calling an API behind the scenes.

In detail

An API — application programming interface — is the contract one program publishes for other programs to use. It’s a list of things you can ask for, the exact shape of how to ask, and what comes back.

A concrete example: ’s API. Their servers expose a set of HTTP endpoints. If your code sends a properly-shaped request to https://api.anthropic.com/v1/messages with a and an API key, Claude generates a response and sends it back. That’s it — that’s the API. Anyone with a key can call it from any language that can make requests.

APIs are the layer underneath most of the software you use. Your mobile banking app doesn’t talk to a directly — it calls the bank’s API, which talks to the database. ChatGPT, the website, calls OpenAI’s API in the background. Even calls Anthropic’s API every time you press enter.

The reason to care about the distinction between “the API” and “Claude” or “Claude Code”:

  • Claude is the itself — the thing doing the thinking.
  • The Anthropic API is the raw programmatic access — for when you’re building your own software and you want Claude inside it.
  • Claude Code and the claude.ai chat website are products that call the API for you and wrap it in a nicer interface.

When someone says “we’ll call the API,” they mean: our code will send an HTTP request to that service. When you see “API key” or “API ”, that’s the credential proving you’re allowed to make those calls.

In one line

The language you type into a terminal — cd, ls, mkdir, and so on. The default on macOS and Linux. Claude runs shell commands by speaking Bash.

In detail

Bash (short for Bourne Again ) is the language you type into a on most macOS and Linux machines. It’s what’s running when you see a like $ waiting for input.

The handful of commands you’ll see Claude run on day 1:

  • cd <folder> (move to a folder).
  • ls — list what’s in the current folder.
  • mkdir <name> — make a folder.
  • mv <a> <b> / cp <a> <b> / rm <a> — move, copy, remove.
  • cat <file> — print a file to the screen.
  • <cmd1> | <cmd2> — pipe the output of one command into the next.

You don’t need to know Bash deeply. When you run claude --dangerously-skip-permissions and ask Claude to “list every Python file in this folder” or “rename these images”, it speaks Bash on your behalf. The is recognising what the commands do well enough to spot the one that surprises you. If a Bash command shows up in a session that you don’t understand, ask Claude what it does before approving it.

On Windows, the equivalent is PowerShell or — preferably — a Bash-style shell inside .

In one line

A safe side-copy of the project where you can try changes without breaking what everyone else is using. When ready, you merge it back in.

In detail

A branch is a parallel line of work in the same . The team’s default branch is usually main (or master on older repos). You create a feature branch off main, make your changes there, and merge it back through a .

Why branches matter: you can experiment, make a mess, change your mind — without touching main. The branch is your .

Day-to-day, you rarely create branches by hand. You ask Claude (“start a branch for this work”) or use /team / /gsd-* , which handle branching as part of the workflow.

In one line

Build time = Claude helps you make a tool once, then you run the tool yourself. Runtime = the tool itself calls an AI every time it runs.

In detail

Build time helps you write a script, define a workflow, or scaffold a project. Once it’s built, it runs on its own. No in the loop at runtime. Predictable cost. Deterministic behaviour.

Runtime — The tool you built calls an LLM ( , Azure OpenAI, Gemini) every time it runs. Used when the task requires judgment — classifying free text, summarising documents, extracting from messy input.

Why this distinction matters at the bank:

  • Use deterministic code when you can — it’s cheaper and easier to debug.
  • Use a runtime LLM only when the task genuinely needs judgement (classification, summarisation, extraction).
  • For real bank data at runtime: it MUST go through Azure OpenAI, not the public Anthropic API. Data residency is non-negotiable.
In one line

Short for 'change directory'. Type `cd some-folder` to move into a folder; `cd ..` to go back up. Like double-clicking a folder, but with the keyboard.

In detail

cd is the command for “change directory”. You’ll see it constantly because almost every session starts with “first, cd into your project folder so I can see your files”.

The five forms you’ll meet on day 1:

  • cd my-project — go into the folder my-project (which has to exist in the current folder).
  • cd /Users/suzy/code/my-project — go to an absolute path. Works from anywhere.
  • cd ~ — go to your home folder (where your user lives — /Users/suzy on Mac, /home/suzy on Linux/).
  • cd .. — go up one folder.
  • cd - — go back to the previous folder you were in.

If a command in a tutorial or a Claude session starts with cd and a folder name you don’t recognise, ask before you press enter. The wrong cd won’t break anything (it just leaves you in a different folder), but knowing where you are matters for everything that comes next.

You can always check where you are by running pwd (print working directory).

In one line

Anthropic's coding AI that lives in your terminal. It reads your project, suggests changes, and runs commands — you approve each step.

In detail

Claude Code is a tool that runs an (Claude) with hands — it can read files, execute commands, edit code, and loop on its own work until done. Four things make it different from a chatbot: hands (it executes, not just suggests), context (it sees the whole project), loops (it iterates autonomously), specialization (it learns your team’s way of working via CLAUDE.md and ).

Mental : it’s a brilliant junior — fast, capable, but you always check what it changed before accepting. Never trust without reviewing the diff.

In one line

The four big AI chatbots: Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google), Grok (xAI). Same basic idea, different companies and styles.

In detail

The chatbot landscape, condensed:

BrandVendorWhat you reachBest known for
Claude (claude.ai)Web/desktop/mobile chatLong context, careful reasoning, thoughtful tone. The family behind .
ChatGPTOpenAIWeb/desktop/mobile chatThe original mainstream chatbot. Largest user base.
GeminiGoogleWeb chat + tight Google Workspace integrationNative integration with Gmail / Docs / Drive.
GrokxAIWeb chat + X/Twitter integrationEdgier tone, real-time X data.

All four are chatbots. You type, they respond. You can ask them to write, summarise, brainstorm, explain. None of them, by default, can read or edit files on your machine. None of them, by default, can run commands. They’re brains in jars.

Claude Code is a different category. It uses Claude models under the hood, but it’s an agent — it runs on your laptop, sees your files, executes commands. Comparing Claude Code to ChatGPT is comparing a coding tool to a chatbot. Comparing Claude Code to Cursor or Cline or Aider is the right level.

Why we picked Claude (the models) and Claude Code (the tool):

  • Long, reliable context (200K in production).
  • Strongest results on hard multi-file refactors.
  • Tone that matches how engineering teams want to work — direct, accurate, willing to say “I don’t know.”
  • -first design that composes with whatever editor you already use.

That doesn’t mean the other vendors are bad — pick the right tool for the job. But for the work the hub covers, Claude is the default.

In one line

A plain-text file you drop in your project to tell Claude the rules: tech stack, conventions, things to avoid. It reads it every session.

In detail

Working with Claude is like working with an assistant who has a great long-term memory but total amnesia about what happened this morning — every new session starts cold. CLAUDE.md is how you brief that assistant before each session, automatically.

It’s the file reads when you open a session in its directory. Put project-specific rules in the ’s CLAUDE.md, and personal preferences that apply across every project in ~/.claude/CLAUDE.md. The rule of thumb: if you’d repeat the instruction in three different sessions, it belongs in a CLAUDE.md.

In one line

Any program you run by typing rather than clicking — CLI is anything you type instead of click. Git is one; Claude Code is one.

In detail

A CLI — command-line interface — is a program you talk to by typing. You open a , type a command, hit return, read the output, type the next command. No mouse, no buttons, no windows. Just text in, text out.

The opposite is a (graphical user interface) — the windowed apps you click around in. GUIs are friendlier on day one; CLIs are faster, scriptable, and composable once you’re used to them. You can pipe one CLI’s output into another, save commands as scripts, run them on a remote server, and reproduce them exactly six months later. None of that is easy with a GUI.

Claude Code is a CLI. You launch it by typing claude in a terminal inside your project folder — there is no app icon. That’s deliberate: it sits next to the other tools you already use at the command line:

  • git — version control
  • gh (, , releases)
  • npm — install and run Node packages
  • claude — start a Claude Code session

When someone says “run it in a terminal” or “run it on the command line,” they mean: use a CLI. Same thing.

In one line

A saved checkpoint of your changes, with a short note explaining what and why. You can always come back to any earlier commit.

In detail

A commit is one saved change-set: a few files, a one-line message, and a parent commit it builds on. Together, commits form your project’s history.

Key thing newcomers miss: a commit is local until you push it. You can commit ten times, change your mind, rewrite history (carefully), and only push the result. Once pushed, others see it — at that point it’s effectively immutable.

never commits without your explicit “yes, commit”. Per the global rules: no version-control operations unless you ask.

Good commit messages explain why, not what — the diff already shows what changed.

In one line

Whatever the model produces back when you give it a prompt. Prompt in, completion out — that is the whole vocabulary.

In detail

A completion is the text the produces back when you give it a prompt. The name comes from the underlying mechanic: the model is completing your input — predicting what comes next, one at a time, until it decides the response is finished.

in, completion out. That’s the whole vocabulary.

In a chat product like Claude.ai or ChatGPT, the completion is the message you see appear in the conversation. In Claude Code, a completion is broader — it includes the prose Claude types back in the , every file edit it proposes, every tool call it makes, and every reasoning step it shows. All of it is “what the model produced in response to the prompt.”

A few things worth knowing:

  • Completions are statistical, not authored. The model has no plan when it starts generating. It picks the next token, then the next, then the next — and the completion emerges. That’s why a tighter prompt usually yields a tighter completion: less ambiguity to drift through.
  • Completions are billed by the token. Every token the model produces — every word in its reply, every line of code, every comment — counts against the token budget for the session and against your usage limit on the .
  • Completions are not memory. Once a completion finishes, it sits in the context window as part of the conversation history. If the window fills up, the completion can be summarised or dropped just like anything else. The model does not “remember” what it said — it re-reads it from the window each turn.

When someone says “the completion was wrong” or “the completion hallucinated,” they mean the model’s output was inaccurate. The fix is at the prompting end — clearer instructions, tighter context, more grounding — or at the verification end (review the diff, don’t trust unverified citations). The model itself doesn’t know whether a completion is correct; it only knows it is plausible.

In one line

A self-contained running copy of an app with everything it needs. Behaves the same on any machine. Docker builds them; Kubernetes runs many of them.

In detail

A container is one running copy of an application, packaged with everything it needs to run — runtime, libraries, system tools, config — so it behaves the same whether you start it on your laptop, on a colleague’s machine, or in production.

Two related things in everyday conversation:

  • Container image — the built bundle, sitting on disk or in a registry, ready to run. You don’t “run” the image directly; you start a container from it.
  • Container — a running instance of an image. You can start, stop, restart, kill, and tail logs from a container.

Why containers matter for work: when you ask Claude to “run this service locally” or “deploy this”, it almost always means starting a container. The Dockerfile describes how the image is built; the deployment script describes which container to start, where, and how. Read the diff — most containers are small and the runtime config is the part worth scrutinising.

See also: Docker, the most common tool for building and running containers.

In one line

How much Claude can remember in one conversation. Once it fills up, the oldest messages get forgotten — like short-term memory has a limit.

In detail

Every Claude session has a finite context window — think of it as a glass of water. Every you send, every file Claude reads, every command output, and every reply Claude writes pours something in. When the glass is full, the oldest content spills out and Claude starts forgetting earlier parts of the conversation.

That’s why answers get vaguer or repeat themselves in long sessions — the glass overflowed and the file Claude read an hour ago is no longer in scope.

Two commands to manage it:

  • /compact — summarises the conversation so far and continues with the condensed version (good when you’re still on the same task)
  • /clear — wipes everything and starts fresh (good when you’re switching to an unrelated task)

The discipline: don’t carry irrelevant history. Start fresh for unrelated tasks.

In one line

Where a software service stores its data so it survives between sessions. Filing cabinet for the program — structured rows and columns.

In detail

A database is the part of a software system that stores data so it doesn’t disappear when the application restarts. Anything a service needs to remember — a list of customers, the history of every transaction, today’s exchange rates — lives in a database.

Most databases you’ll encounter at the bank are relational: data lives in tables (rows and columns, like a spreadsheet), and tables reference each other by id. SQL is the language used to ask the database questions.

Common databases by name:

  • — open-source, the team default for new internal services.
  • MySQL — also open-source, common in older services.
  • SQL Server / Oracle — commercial, common in legacy enterprise systems.

The reason a database matters for work: when you ask Claude to make a change that involves stored data (“add a new column”, “fix this query that’s slow”), it’s working against a real database schema. The schema rules — column types, indexes, constraints — are what stop bad data getting in. Read the for any database conventions (“singular table names”, “money values as integer minor units”) before you accept the change.

In one line

A way to pack an app and everything it needs into one box that runs the same on any laptop or server. No more 'works on my machine'.

In detail

Docker is the tool teams use to make sure code that runs on a developer’s laptop also runs on the production server — and on every laptop in between — without “works on my machine” surprises.

The idea: package the application with its operating-system slice (libraries, language runtime, system tools, config) into a single immutable bundle called a . A container is built from a tiny script called a Dockerfile. Running the container anywhere — your laptop, a colleague’s laptop, Azure, AWS — gives you the same behaviour.

What you’ll see in conversations:

  • “Just dockerize it” — package the app as a container so it can be deployed somewhere.
  • Dockerfile — the recipe (5–30 lines, usually) for building the container image.
  • docker compose up — run a small set of containers together (e.g. an + a ) locally.

You don’t need to know Docker deeply to work with . When you ask Claude to “deploy this” or “run this locally”, it will often propose a Dockerfile and explain what it does. Read the diff, ask questions, accept.

Learn more
In one line

The little block of settings at the top of a markdown file, between two --- lines. Stores info like title, date, and tags.

In detail

Frontmatter is the block of metadata that sits at the very top of a file, fenced by a pair of --- lines. Everything between the fences is YAML; everything after is the prose body. It’s how a plain .md file carries structured data alongside its content.

You’ll see frontmatter on every content file in this glossary/, tips/, skills/, journeys/, news/published/. Here’s a minimal example:

---
type: glossary
title: Frontmatter
audience: beginner
authored: "2026-05-25"
internal: false
---

Why we use it:

  • Build-time validation. The Astro site reads every frontmatter block through a Zod schema. A missing or mistyped field fails the build, not silently in production.
  • Structured query. Pages can filter “all beginner tips” or “all glossary terms tagged claude-code” because the metadata is machine-readable.
  • Search and sort. Pagefind indexes the body; the frontmatter drives ordering, badges, and audience filtering.

If you’re authoring a new entry, copy the frontmatter from a neighbouring file and edit the values — that’s the fastest way to stay on-schema.

In one line

GitHub's official command-line tool. Claude Code uses it to talk to GitHub — clone projects, open tickets, submit changes.

In detail

gh is ’s . You don’t talk to GitHub directly — Claude does it for you via gh when you ask in plain English (“show me the open ”, “open a with these changes”).

One-time setup:

  • macOS: brew install gh
  • / Linux: sudo apt install gh
  • PowerShell: winget install --id GitHub.cli
  • Then: gh auth login (opens a browser, one-time)

Useful commands worth knowing by name:

  • gh repo clone <org/repo> — clone
  • gh repo view --web — open in browser
  • gh issue list / gh issue create
  • gh pr create / gh pr view --web / gh pr checks
  • gh auth status — confirm you’re authenticated

In practice you rarely type these — Claude does. But knowing they exist helps when you’re reading what Claude is about to run.

In one line

The website where the team's code lives. Every project, every change, and every discussion about the code is stored and tracked there.

In detail

GitHub is where every line of code, every script, every Claude , and every document the team writes lives. One per project; one per bug or idea; one per change. It’s the industry standard — every software team uses it for the same reasons.

You touch GitHub through three doors:

  • The website (github.com) — read history, comment on PRs, browse code in the browser
  • gh (the GitHub ) — what actually uses under the hood
  • A cloned folder on your laptop — where Claude reads and edits files

You almost never need to “know git”. Claude proposes, you approve, gh does the work.

The team’s repos live at github.com/orgs/556LowCodeNoCode/repositories. Newcomers get read access on day one; specific contributor access is added per repo when needed.

Learn more
In one line

A community add-on that helps Claude pick up long projects across many sessions by keeping the plan and progress in a folder.

In detail

GSD is an optional community framework for managing projects that span weeks or months. The whole idea: persist project state in a .planning/ folder so Claude (and you) can resume work without re-explaining context.

What lives in .planning/:

  • PROJECT.md and ROADMAP.md — the long-horizon plan
  • Per-phase folders with discuss / spec / plan / execute / verify / secure steps
  • Audit trail for what was decided, why, and when

When GSD pays off:

  • Multi-week project, multiple collaborators
  • Traceability matters (audit, compliance)
  • You need to put the work down and resume next week

When it’s overkill:

  • One-off scripts, single-sitting prototypes, exploratory hacking

Common commands: /gsd-new-project, /gsd-progress, /gsd-do, /gsd-next, /gsd-help.

In one line

The clickable, windowed kind of software — Word, Slack, Chrome. Anything you use with a mouse. The opposite of a CLI.

In detail

A GUI — graphical user interface — is the windowed kind of program you click around in with a mouse. Word, Slack, Chrome, your IDE, Photoshop, your operating system itself — all GUIs. Friendly on day one, no typing required, the whole world of an app laid out as menus and buttons.

The opposite is a CLI (), which you drive by typing commands in a terminal instead. CLIs win once you’re used to them, for three reasons:

  • Composable. Pipe one program’s output into another. Try doing that with two GUI apps.
  • Scriptable. Save a sequence of commands as a file, run it tomorrow on a different machine, get the same result.
  • Reproducible. “Click File → Export → choose format → set quality → save” is unwriteable as documentation; convert in.png -resize 800x out.jpg is.

Claude Code is a CLI, not a GUI. There is no app icon. You launch it by opening a , cd-ing into a project folder, and typing claude. That’s deliberate — it sits next to the other tools developers already use at the command line (git, gh, npm) and inherits all the composability that comes with the territory.

In one line

When the AI confidently makes something up that sounds right but isn't. A fake function name, a wrong citation, a made-up fact.

In detail

A hallucination is when the invents content that sounds correct but isn’t — a function name that doesn’t exist, a citation that was never published, a configuration flag the library never shipped. It’s not lying in the human sense; it’s pattern-completing on what should come next, with no internal mechanism to check whether what it produced is real.

Common triggers:

  1. pressure. When the context window fills up, earlier instructions and source material lose attention weight. The model leans more on its general training instincts and less on the actual file in front of it. Researchers call this the “lost in the middle” effect.
  2. Knowledge cutoff. The model’s training data was frozen at some past date. Anything newer than that, it has to guess.
  3. Premise flattery. Ask a leading question (“Doesn’t support feature X?”) and the model is statistically inclined to agree with the framing — even when X doesn’t exist.
  4. Long autonomous loops. When an agent goes deep on its own, early mistakes get locked in and built upon. Each iteration adds compounding error.

Defences in practice:

  • Trust nothing past the 70% context-fill mark without re-reading the diff. Use /compact or /clear to reset.
  • Always check the diff before accepting. A hallucinated import won’t compile — let the compiler catch it.
  • Specifically distrust references — citations, links, file paths, package names. Verify any non-trivial claim against the source.
  • Use the right model for the job. Hard problems → Opus. Routine work → Sonnet. Don’t ask Haiku to architect a system.

The rule of thumb: Claude Code is a brilliant junior — capable, fast, occasionally confidently wrong. Review the work.

Learn more
In one line

A command Claude Code runs automatically at certain moments — before a tool runs, when a session ends. Used for guardrails and automation.

In detail

A hook is a runs automatically at a specific event point in a session. The event points include:

  • PreToolUse — fires before a tool call (file edit, command, web fetch). Can block the call.
  • PostToolUse — fires after a tool call completes
  • SessionStart — fires when a session boots
  • Stop — fires when Claude finishes a turn
  • a handful of others (notification, subagent-stop, etc.)

Hooks are configured in JSON, either at the user level in ~/.claude/settings.json or per-project in .claude/settings.local.json. Each entry binds an event to a shell command:

{
  "hooks": {
    "Stop": [
      { "command": "scripts/check-decisions-updated.sh" }
    ]
  }
}

Why they matter. They’re how you enforce policy that Claude itself can’t be trusted to remember. NbgAiHub uses a Stop hook to warn when source files change but DECISIONS.md/SCOPE.md/Issues - Pending Items.md haven’t — exactly the kind of thing a will skip on turn 50 of a long session. Hooks catch it deterministically because the harness runs them, not the model.

The sharp edge. Hooks execute in the host , not inside Claude’s . They can do anything bash can do — touch your filesystem, hit the network, eat CPU, for input. A misconfigured PreToolUse hook that exits non-zero will block every single tool call until you fix it. Edit them with the same care you’d edit a git pre- hook.

Inspect or edit the active set with /hooks from inside Claude Code.

In one line

The language computers use to talk over the web. Every page you load and every API call uses HTTP. HTTPS is the encrypted version.

In detail

HTTP — HyperText Transfer Protocol — is the language two programs use to talk to each other across the internet. One side sends a request (“give me this page”, “save this data”), the other side sends a response (“here you go”, “no, that didn’t work”).

You use HTTP every time you load a webpage. Your browser sends a request to a server, the server sends back HTML, your browser renders it. The “https” you see at the start of a URL is the same thing with an encrypted transport so nobody in the middle can read what you’re sending.

For developers, HTTP also runs every API call. When a script “calls an ”, it’s sending an HTTP request to a URL and parsing the response. When talks to ’s , it makes HTTP requests in the background to Anthropic’s API endpoints. Same protocol, different consumer.

Common HTTP verbs you’ll see in documentation:

  • GET — read something (most page loads)
  • POST — create something (submit a form, send a message)
  • PUT / PATCH — update something existing
  • DELETE — remove something

You don’t need to remember the spec. You just need to know that “talking to a server over HTTP” means “sending it requests and reading its responses” — and that’s what most software does most of the time.

In one line

A ticket on GitHub for one bug, idea, or piece of work. Anyone on the team can open one, discuss it, and close it when it's done.

In detail

An issue is a thread for one piece of pending work — a bug, a feature, an idea, a question. Each issue has a title, a body, labels (bug, enhancement, question), an assignee, and a state (open or closed).

Why the team uses them:

  • The backlog is shared and visible
  • Discussion sticks to the issue, not buried in chat
  • can reference issues — closing a PR can auto-close its linked issue

Ask Claude in plain English: “list the open issues”, “create an issue for this bug”, “close issue #42 — I just fixed it”. Behind the scenes Claude calls gh issue list / create / close.

In one line

The AI behind chatbots like Claude. It learned from huge amounts of text to predict what word comes next — that's the whole trick.

In detail

A large language (LLM) is the engine. Given some text as input, it computes a probability distribution over what the next (roughly: a word-piece) should be, picks one, and repeats. That’s it. Doing this trick a billion times on text scraped from the public internet — books, code, conversations — turns out to produce something that feels astonishingly close to understanding.

Three properties matter in practice:

  1. It’s predictive, not deliberative. There’s no internal logic prover. It produces what looks like reasoning by imitating reasoning text from its training data.
  2. It has a frozen knowledge cutoff. What it “knows” was baked in when it was trained. Ask about events after that date and it may invent plausible-sounding nonsense ().
  3. It has no memory between sessions. Anything it knows about your project, your conventions, your past conversations is what’s currently in its context window. When the session ends, it forgets.

Claude, ChatGPT, Gemini, Grok — all LLMs. Same underlying trick, different training data and tuning.

Best plain-language explanations: 3Blue1Brown’s “Large Language Models explained briefly” (10 min), and Andrej Karpathy’s “Intro to LLMs” (1 hour, worth every minute).

In one line

A simple way to format text using symbols like ** for bold or # for headings. Plain text you can read raw. Used everywhere on the web.

In detail

Markdown is a plain-text format for writing prose with light formatting. You write # Heading instead of <h1>Heading</h1>, and a markdown processor converts it to HTML at build time. The raw .md file stays diff-friendly and readable; the rendered HTML is what your browser displays.

Every content file in this — every glossary term, tip, , journey, news item — is a .md file. Astro reads them at build time, runs them through its markdown pipeline, and emits a static HTML page per file. You never edit HTML; you edit markdown.

The syntax you actually need on day one:

  • Headings: # H1, ## H2, ### H3
  • Bold: **bold**; italic: *italic*
  • Inline code: `code`
  • Links: [link text](https://example.com)
  • Lists: lines starting with - or 1.
  • Fenced code blocks: three backticks on a line of their own, language name after the opening fence:
const greeting = 'hello';

That covers maybe 90% of what you’ll write. Everything else (tables, footnotes, images, blockquotes) you can look up when you need it.

The thing to remember: readers see the rendered HTML, not your markdown. That **bold** becomes a bold word in the browser — they never see the asterisks.

In one line

A standard way to plug Claude Code into outside tools and data — Jira, Slack, your calendar. Think of it as a universal adapter for AI.

In detail

MCP is the protocol uses to plug into the outside world: , file systems, , Jira, Gmail, Figma. Each integration ships as an MCP server you register once and then call by name in conversation. The big win is that you don’t write glue code every time — the server exposes its capabilities and Claude figures out how to use them.

In one line

A specific version of Claude. Opus is the smartest, Haiku is the fastest, Sonnet is the middle ground. Switch with /model in Claude Code.

In detail

A model in this context is a specific trained version of Claude that has published. It’s the large language model the is wrapped around — the actual prediction engine doing the work. , the , the loop, the tools — those are the scaffolding. The model is what’s thinking.

Anthropic currently ships three families, each with numbered releases:

  • Opus — deepest reasoning, slowest, most expensive. The right call for ambiguous specs, novel architecture, hard debugging, cross-cutting design decisions, long-horizon plans. Latest: Opus 4.7.
  • Sonnet — the daily driver. Multi-file edits, refactors, building from a clear spec, normal debugging, scaffolding. Right the first try on most work. Latest: Sonnet 4.6.
  • Haiku — cheap and instant. Only the right pick for truly one-shot mechanical work: format conversion, batch rename, single-file grep-and-edit, pure transformation. The moment any judgment is needed, prefer Sonnet — it’ll be net faster because it’ll be right the first try. Latest: Haiku 4.5.

Inside Claude Code, switch models with:

/model <name>

The optimisation target here is speed × task fit, not cost. A heavy model on a trivial task is over-spec’d but not broken; a light model on a complex task is genuinely problematic — it’ll churn, miss the point, and burn more wall-clock time than the model upgrade would have cost. Asymmetric tolerance: lean heavier rather than lighter when in doubt.

The model number bumps roughly every few months. The family names stay stable — Sonnet will keep meaning “the daily driver” even when 4.6 becomes 4.7 becomes 5.0.

In one line

A bundle of skills and commands you can install into Claude Code with one line, similar to a browser extension.

In detail

A plugin is what you reach for when a single isn’t enough. Plugins ship multiple skills together with (automated behaviors), commands, and wiring. They live in a marketplace.json manifest so other people can install them with one command. If a skill is a function, a plugin is the library.

In one line

An open-source database used by most team services. Think of it as the filing cabinet where structured data (users, transactions, settings) lives.

In detail

Postgres (short for PostgreSQL) is an open-source . When a team service needs to remember things between requests — a customer list, a transaction log, a config table — that data usually lives in a Postgres database somewhere.

You’ll see it referenced as:

  • A connection string in environment files (postgres://user:pass@host:5432/dbname).
  • A psql that lets you type SQL queries by hand.
  • Migration files under db/migrations/ that describe schema changes over time.

You don’t need to know SQL well to start working with . When you ask Claude to “fetch the last 10 transactions” or “add a new column for customer tier”, it will write the SQL, explain what it’s doing, and wait for you to approve. Read the diff and ask if anything looks unusual.

Postgres is “relational” — data lives in tables (think spreadsheets) with rows and columns, and tables reference each other by id. Most data the team works with fits this shape.

In one line

Whatever you type to an AI as input. Prompt in, completion out — that is the whole vocabulary.

In detail

A prompt is the text you give a language model as input. Anything you type into is a prompt. The ’s response back is the . Prompt in, completion out — that’s the whole vocabulary.

The model’s response is conditioned on the prompt plus whatever else is in the context window: conversation history, files it has read, the system prompt, CLAUDE.md, and any skills currently active.

Three layers of prompting in Claude Code:

  1. System prompt — the always-loaded instructions ships, plus your (project + global). Sets baseline behaviour. You don’t see it but it’s always there.
  2. User prompt — what you type each turn.
  3. Tool output — what gets fed back into the context after a tool call (file contents, output, etc.). Indirect, but still part of what the model is conditioning on.

Good prompts share five properties:

  1. Specific. “Refactor auth.ts to extract the -validation logic into its own module” beats “clean up auth.”
  2. Constrained. “Don’t change the public ” beats hoping the model intuits it.
  3. Example-led. “Use the same pattern as validator.ts” beats explaining the pattern in prose.
  4. Outcome-shaped. “All tests in auth/ pass after the change” gives the model a check.
  5. Short on flattery, heavy on facts. “Please be careful” adds zero information. “The customer-id is always a UUID v4; never coerce it” adds real signal.

Prompting is half the productivity gain. The other half is keeping context clean. The /tips/ page covers concrete patterns.

In one line

A request to add your changes into the main project. Teammates review the diff and comment before it gets merged in.

In detail

A Pull Request (PR) is how proposed changes enter the team’s main code line. You push your , open a PR, and the rest of the team can read the diff, comment on lines, request changes, approve, and merge.

What a PR carries:

  • The diff (what changed)
  • A summary (the “why”)
  • Comments and review threads
  • CI checks (tests, linters, validators that run automatically)
  • Approval(s) and merge state

opens PRs for you when you ask (“open a PR for these changes”). The body it drafts follows a standard template — summary + test plan. Tweak it before merging if you want.

In one line

A project's home on GitHub. One folder that contains all the code, every change ever made, and the discussions around it.

In detail

A repository (repo) is where a single project lives on . One folder, one project. It holds the files, the full history of every change ever made, the tracker, and the review surface.

The team’s repos live under github.com/orgs/556LowCodeNoCode/repositories. New joiners get read access on day one; specific contributor access is added per repo when needed.

You’ll spend most of your time inside one repo at a time, with running in that folder.

In one line

An old but reliable way to subscribe to a site's updates without checking it manually. NbgAiHub uses RSS to pull in daily news from five tech sources.

In detail

RSS stands for Really Simple Syndication. It’s the boring, two-decades-old XML format that every blog, news site, podcast host, and project release page quietly publishes alongside its human-readable HTML. Point a reader at the feed URL and you get a machine-readable list of recent items — title, link, body, timestamp — without scraping the page.

It has been “about to die” approximately every year since 2010 and is somehow still the best signal-to-noise content distribution channel on the open web. No algorithm. No login. No ads in your face. Just a list.

NbgAiHub uses RSS as the input to its news pipeline. A Action runs daily, fetches five feeds, and runs every new item through Azure OpenAI triage to decide what’s worth keeping:

  • r/ClaudeAI and r/ClaudeCode — community signal from Reddit
  • Hacker News frontpage — broader tech zeitgeist
  • Wired AI and The Verge — editorial tech press

The site’s News surface is currently routed externally to a colleague’s site (see SCOPE 2026-05-25), but the pipeline still runs and the published items still land in news/published/ for the hub to read.

Atom is RSS’s slightly younger sibling — different XML, same idea. The parser library NbgAiHub uses handles both without caring which one a feed actually serves.

In one line

NBG's personal cloud Linux VM with Claude Code pre-installed. One per colleague, reached through a small desktop app. Bank data stays in the cloud.

In detail

The Sandbox is an internal NBG offering that gives every colleague their own personal Linux , sitting in the bank’s private Azure cloud, with already installed and ready to use.

You reach it from a small desktop app called Sandbox Connect. One click connects your laptop to your VM; files move by drag-and-drop; whatever Claude builds on the VM opens in your laptop’s browser as if it ran locally. The technical plumbing — network, certificates, identity, audit logging — is handled for you.

Why use the Sandbox instead of running Claude on your laptop:

  • Bank data never touches your machine. Files live on the VM. travel from the VM to Claude inside NBG’s own cloud — never through your laptop.
  • Lost or stolen laptop = nothing on disk + one click to revoke access.
  • No install gymnastics. Claude Code, , Node + pnpm, Python via uv, Playwright, and Git all come pre-loaded.

When to skip the Sandbox: public OSS work, hackathon side projects, throwaway examples where you’re just learning Claude. For “anything you’d hesitate to paste into a public chatbot”, reach for the Sandbox. The full setup walkthrough is shipping later this week — until then, the Day 1 page carries the heads-up.

In one line

The program inside the terminal that reads what you type and runs it. Terminal is the window; shell is the brain.

In detail

A shell is the program that listens inside a . The terminal is the window; the shell is what’s running inside the window, reading what you type and translating it into something the computer can do.

The shells you will meet:

  • — the default on most Linux systems and older macOS systems. Still the most common shell in tutorials and documentation.
  • zsh — the default on modern macOS. Behaves like Bash for everyday commands; you usually do not need to know the difference.
  • PowerShell — the default on Windows. Different syntax from Bash; the team avoids it for Claude Code work and uses (which gives you Bash) instead.

When you read “open a shell” or “in a shell, run X” in any tutorial, it means “open a terminal and type X at the ”. The two terms are used loosely and interchangeably in conversation, even though they technically refer to different things.

Claude Code speaks shell on your behalf. When it runs commands like or ls or , those commands are interpreted by your shell — Bash, zsh, or whatever is running inside your terminal.

In one line

Commands you type in the terminal to get things done — list files, change folders, run a script. Claude can run them for you with your OK.

In detail

A shell command is one instruction you type at the and press return on. ls, cd, git status, npm install, claude — all commands. The shell part is the program (, zsh, fish, PowerShell) that reads what you typed, runs it, and prints the result back into the terminal window.

You usually type commands directly, but you can also stitch them together — pipe one’s output into another (git log | grep fix), save a sequence as a script, or run them on a remote server over SSH. The composability is the whole point of working at the .

The reason this matters for : running shell commands on your behalf is one of the four “hands” that makes it more than a chatbot. Watch a Claude session and you’ll see it propose commands — grep -r 'foo' ., npm run build, git diff HEAD — and either run them or ask permission first, depending on your permission settings. Two practical rules:

  • Read every command before allowing it. Especially the destructive ones (rm, git push --force, anything piped to sudo). Claude is right almost always — but almost is not always.
  • Configure permissions deliberately. Allow the safe read-only stuff (git status, ls, cat) so you’re not approving the same harmless command for the fiftieth time. Keep destructive commands on .
In one line

A pre-packaged ability you give Claude — a folder of instructions Claude follows when you trigger it, often via a slash command.

In detail

A skill is a folder with a SKILL.md (the instructions Claude follows) plus any supporting scripts, , or assets. Drop it into ~/.claude/skills/ and Claude will pick it up. Skills are how you stop pasting the same 200-line prompt and instead say “use the X skill.” They’re the boring-but-good answer to “how do I scale this?”

In one line

A shortcut inside a CLI tool — type / followed by a name (/clear, /compact, /help). Triggers a built-in action, different from a normal prompt.

In detail

A slash command is a shortcut inside . You type /, a name appears in a menu, you pick one — or just keep typing the full name and hit return. They cover everything from switching the to running a whole installed .

The ones you’ll meet on day one:

  • /help — list everything you can do
  • /model — switch between Opus, Sonnet, Haiku
  • /clear — wipe the conversation and start fresh
  • /compact — summarise the conversation so far to free up context
  • /hooks — inspect or edit the per-project
  • /plugin — install or manage

Every skill you install also shows up as a slash command. The team’s hub installs commands like /hub-news, /hub-skills, /hub-onboard. When a colleague says “run /jira” or “use /deploy”, they mean type those into Claude Code.

Type / on its own with nothing after it to see the live menu of every command available in the current session.

In one line

The window on your computer that takes typed commands instead of clicks. Terminal is the window; the shell is the brain inside it.

In detail

A terminal is the window where you type commands instead of clicking icons. It is the oldest interface in computing and where developers and do most of their work.

On macOS, the default is Terminal.app (Applications then Utilities then Terminal). Other popular ones: cmux, Ghostty, iTerm2, Warp. On Windows, your terminal lives inside by default. On Linux, you have already used one.

What you see inside a terminal:

  • A — usually ending in a dollar sign — waiting for you to type.
  • The commands you type, ls, git pull, claude, and so on.
  • The output that those commands print back.

Claude Code runs inside a terminal. When you type claude —dangerously-skip-permissions, you are starting a session that takes over the terminal until you press Esc enough times or quit. The terminal is not a separate app from Claude — Claude is running inside the terminal you opened.

The terminal is also where (or another ) interprets what you type — see the shell entry for the distinction.

In one line

The chunks of text an AI thinks in — roughly three-quarters of a word each. Pricing and memory limits are both counted in tokens.

In detail

A token is the unit a language reads and produces. Not a character, not exactly a word — somewhere in between. Common English words are often a single token; less-common words split into two or three. Code symbols, punctuation, and whitespace also count.

Quick rule of thumb: 1 token ≈ ¾ of a word ≈ 3-4 characters. A 500-line source file is about 2,000-3,000 tokens. A typical chat exchange might be 100-1,000 tokens per turn. Your CLAUDE.md might be 500-2,000 tokens — paid once per session.

Tokens matter because they’re the unit of currency for two things you actually care about:

  1. size. Modern Claude models hold ~200,000 tokens of working memory. Everything in the conversation — your , the model’s replies, the files it reads, the tool outputs — counts against that budget.
  2. Pricing on the . Pay-per-token billing. Input tokens are cheaper than output tokens. Long sessions get expensive fast.

OpenAI ship a tokenizer playground where you can paste text and see how it splits. Useful for building intuition.

Not to be confused with: API tokens (an authentication string), NFT tokens, OAuth tokens, or any other “token” in the security/auth sense.

In one line

How an AI does things beyond chatting — reading a file, running a command, fetching a webpage. Each ability the AI can use is called a tool.

In detail

Tool use is the mechanism by which a language model does anything beyond producing text. The is given a list of tools — functions it’s allowed to call — each described by a name, a JSON schema of its arguments, and a one-line summary of what it does. When the model decides a tool is the right next step, it emits a structured “call this tool with these arguments” message instead of regular text. The runtime sees the call, executes the tool, packages the output, and feeds it back into the model’s context for the next turn.

Examples of tools in :

ToolWhat it does
ReadRead a file from the filesystem
WriteCreate or overwrite a file
EditApply a string-replace edit to an existing file
BashRun a
GrepSearch file contents with a regex
WebFetchFetch a URL and convert to
AgentSpawn a subagent for a focused sub-task

Tool use is what turns a model into an agent. Without tools, an can only describe what you should do; with tools, it can do it. This is the difference between Claude.ai (chatbot) and Claude Code ().

Two things to know in practice:

  1. You can register your own tools via MCP servers or via custom . Anything you wire up — a query, an internal call, a deploy script — the model can then orchestrate.
  2. Tool calls cost . The model’s “call this tool” message plus the tool’s output both count against your context window. A noisy tool that returns 50K tokens of output will eat your context fast.
In one line

Short for virtual machine — a full computer running as software on a shared physical host. Has its own OS, files, and network.

In detail

A VM (virtual machine) is a computer that runs as software inside another, larger computer. From the outside it behaves exactly like an ordinary machine — its own operating system, hostname, files, network — but the CPU, memory, and disk underneath are shared with other VMs running on the same physical hardware.

VMs are the building block for almost everything that runs “in the cloud”. When NBG provisions a Linux server in Azure, that “server” is a VM. When you SSH into a cloud machine, you’re SSHing into a VM. When the bank’s programme gives you a personal Linux box pre-loaded with , that box is a VM — sitting in NBG’s private cloud, one per colleague.

Why this matters for Claude Code work: the typical “where am I running this?” question has three sensible answers — your laptop, a colleague’s laptop, or a VM. The VM answer is what unlocks “I can use Claude with real bank data without anything sensitive sitting on my laptop”. See Sandbox for the NBG-specific shape of this.

In one line

Windows Subsystem for Linux — runs a full Linux shell inside Windows. The team's default Windows setup for Claude Code work.

In detail

WSL (Windows Subsystem for Linux) is Microsoft’s first-party way of running a Linux environment inside Windows. It is not a in the traditional sense — it is a tighter integration where Linux files, processes, and tools coexist with your Windows ones.

Why the team uses it for work on Windows:

  • The Linux () is what most Claude Code documentation assumes.
  • Common dev tools (, git, npm, python) install with a single command via apt.
  • File paths, line endings, and permissions behave the way the rest of the team expects.

WSL 2 is the version everyone uses now. WSL 1 still exists but is mostly historical.

Installing WSL:

The happy-path command (Windows 10 build 19041+ or Windows 11, admin rights, internet access) is one line in PowerShell as Administrator:

wsl --install

This installs WSL 2, enables the virtualization features it needs, and downloads Ubuntu by default. After the reboot it for a Linux username and password. Full Microsoft instructions: learn.microsoft.com/windows/wsl/install.

Common blockers on a managed laptop:

  • No admin rights. File a request with IT to enable WSL — it is a one-time policy change, not an ongoing exception. While you wait, Git Bash (from Git for Windows) handles basic shell commands.
  • Virtualization disabled in BIOS. IT controls this on managed machines. Same request route.
  • Microsoft Store blocked. Microsoft ships offline WSL installer packages (.msi) that bypass the Store.

Once WSL is installed, every Claude Code session runs inside WSL, not in regular PowerShell. The you launch (Windows Terminal is the cleanest one) lets you pick “Ubuntu” as the profile.

In one line

A simple way to write settings using indentation and colons, like name: Alice. Easier to read than JSON. Used in lots of config files.

In detail

YAML (“YAML Ain’t Markup Language”) is a config file format optimised for humans to read and write. It supports the same shapes as JSON — scalars, lists, nested objects — but uses indentation and dashes instead of braces and commas:

name: nbg-ai-hub
audience: beginner
topics:
  - foundations
  - tools
maintainers:
  primary: suzy
  backup: null

Where you’ll see it in this :

  • .github/workflows/*.yml — every Actions workflow is YAML.
  • blocks in every .md under glossary/, tips/, skills/, journeys/, news/published/.
  • docs/archive/refined-requests/ and a few other doc fragments where structured fields are easier than prose.

Not YAML, despite the similar feel:

  • config/rss-sources.json — JSON (braces, commas).
  • site/astro.config.mjs — JavaScript (an ES module that exports an object).

YAML vs JSON: YAML is friendlier to read and supports comments; JSON is stricter and universal across languages. We use YAML where humans edit it daily (frontmatter, workflows) and JSON where machines pass it around.

Common gotchas:

  • Indentation matters. Two spaces per level, never tabs. A single rogue space breaks the file.
  • Quote your dates. authored: 2026-05-25 parses as a date object in some parsers; authored: "2026-05-25" parses as a string everywhere. We use strings.
  • null, ~, and empty are all the same thing. Pick one (we use null) and stay consistent.
Learn more