Welcome to Claude Code.

Who this guide is for

You — a product person, business analyst, or domain expert. Maybe you're joining our team, or maybe you're a bank colleague curious to try Claude Code on your own work. Either way, you probably have zero coding background and that is completely fine — you won't need it. What you'll need is what you already have: good judgment, the ability to describe a problem clearly, and patience to iterate.

The guide is structured so anyone in the bank can read it and walk away with a working setup and a clear mental model. The parts that are specific to our team (our skills marketplace, our project conventions, our GitHub org) are flagged so you know what's "ours" and what's general — borrow the parts that fit.

The big picture in 60 seconds

What we do has three layers, stacked. Read top to bottom: the top is where we live and have leverage; each layer underneath is the machinery that makes it possible.

The LLM — the engine

Think of it as a very smart text-completion box. You type, it produces text back. That's literally all it does. It has no memory between conversations, no ability to see your files, no ability to do anything in the world. claude.ai in your browser is this layer in pure form: a brilliant chat partner who can't actually touch anything.

Claude Code — the tool

A program that wraps the LLM and gives it hands and eyes. Same brain, now wired up to your laptop: it can open files, read them, write new ones, run scripts, talk to GitHub. This is what turns "a chat box" into "something that can actually build working things." Without this layer you can think with the LLM but you can't do anything with it.

Our way of working — what we add

The rules, conventions, and skills we layer on top of Claude Code: the CLAUDE.md files, our skills marketplace, our standard project folder shape. Without it, Claude Code is incredibly capable but it'll do things slightly differently every time, in whatever the average correct way is — not necessarily our way. With it, every session produces consistent, predictable, team-shaped results.

What is Claude Code, really?

The four things that make it different from "just ChatGPT"

1. It has hands. A web chatbot only talks. Claude Code can actually do things — open files, edit them, run scripts, fetch data, push commits to GitHub.
2. It has context. It sees the whole project folder. When you ask "fix the bug in this report," it can read every relevant file before answering.
3. It works in loops, not just turns. A chat box does one prompt → one reply. Claude Code can plan, execute, check, adjust, and continue on its own — for many minutes, across many steps, sometimes splitting work into parallel sub-agents — until the goal is actually met. You don't have to babysit every step. It's a workflow engine, not a Q&A bot.
4. It can specialise. Through skills (we'll get there), we teach it how our team works — our naming conventions, our project shape, our deployment process. So it doesn't just work generically; it works our way.

What a session actually looks like

You open a terminal in a project folder. You type natural language. Claude responds, and may ask permission to do things. Here's a real-feeling exchange — the kind of "Tuesday afternoon" task we all run into:

What's in this folder?

Claude › 12 files. Mostly Excel files with the monthly numbers, plus
        a draft PowerPoint deck and your one-page project brief.
        Want me to summarise any of them?

Read the deck and the brief. Are they saying the same thing?

Claude › Mostly, but there's a mismatch:
        • The brief states a 12% Q1 growth target.
        • The deck references "double-digit growth" verbally,
          but the chart on slide 6 shows projected Q1 at 9%.
        Looks like the chart wasn't updated when the target moved.

Fix the chart in the deck — Q1 should read 12%, matching the brief.

Claude › I'll update slide 6 in `q1-review-draft.pptx`.
        Save a backup copy first as `.bak`? [Y/n]

Notice three things: you spoke English, Claude read across multiple files and spotted a problem you might have missed, and it asked before changing anything. That last part — the asking — is the safety model. You stay in the driver's seat.

Setting up & running Claude Code day-to-day

The practical handful of things that make Claude Code feel like home. None of it is hard; all of it pays off the first day.

Pick a terminal

Claude Code runs inside your terminal. The terminal you choose affects how pleasant the experience is. Both built-in terminals work, but a modern one is much nicer for agent work — better colours, image previews, smoother input.

Starting Claude Code

From inside any project folder, just type:

claude

claude --dangerously-skip-permissions

Resuming a previous conversation

Closed the terminal? Paused for a meeting? Coming back the next morning? Run:

claude --continue

(short form: claude -c). Claude picks up exactly where you left off — same context, same project understanding, same conversation history. You don't have to re-explain what you were doing.

Stopping Claude mid-response

Press Esc. Claude stops its current response immediately. Useful when:

• It's going down a wrong path and you want to correct course.
• It's about to run something you didn't quite expect.
• You realised mid-sentence that you need to clarify the request.

After stopping, you can just type the clarification and continue. Nothing is lost.

Showing Claude a screenshot

You can give Claude UI mockups, error screenshots, design references, diagrams, a photo of a whiteboard — anything visual. Claude reads them as part of the context. The flow is different on each OS:

How Claude reaches outside your laptop

Out of the box, Claude Code can read and write files in your project folder and run shell commands. But how does it talk to external services — GitHub, your email, SharePoint, Jira, a database? There are two routes, and it's worth knowing which is which.

Managing the conversation's memory (the context window)

Claude has a working-memory limit per conversation, called the context window. Think of it like a colleague who can hold maybe 200 pages of working notes in their head at once. Once that fills up, older parts of the conversation start to get summarised or forgotten.

Signs you're running low:

• Claude getting noticeably slower to respond.
• Claude forgetting things you said earlier in the session.
• Claude proactively asking to compact the conversation.

Two things you can do about it:

• /compact — ask Claude to summarise the conversation so far. The summary stays, the full transcript is dropped, you keep room for more work. Useful for long sessions on one topic.
• /clear, or just start a fresh claude session — for when you change topic entirely. Cheaper than dragging a giant context with you.

Talking to Claude — the basics of a good prompt

Six rules that cover most of it

1. Context first, ask second. "Look at <file>, then…" beats "Build me X."
2. Describe the business value, not the steps — and not the tools either. Say what done looks like at the user / outcome level. Don't prescribe how ("open the CSV, group by email, count > 1…") and don't prescribe which tools ("use pandas / use regex"). Claude usually picks a better path than the one you'd dictate. "Find the duplicate customers in this list and produce a clean version" beats "loop through rows, hash the email column, mark duplicates."
3. Pin constraints, not methods. Constraints bound the space ("no external services," "must run on Windows," "keep it under 100 lines"). Methods dictate the path ("use library X") — and they cost you. State the constraints once, early; leave the path to Claude.
4. One thing per prompt. Don't pile five asks together. Do one, review, then the next.
5. Iterate, don't restart. When something's off, say what's off and let Claude adjust. Don't begin again from scratch.
6. Show, don't describe. Paste the error, paste the screenshot, paste an example row of data — beats three paragraphs of explanation. (Section 3 covers how to paste images.)

A bad opener vs a good opener

Fix the dashboard.

Look at `app/dashboard.tsx`. The status badges
aren't refreshing when I switch users — the
previous user's badge stays. Reproduce by clicking
"Switch user" on a row. Find the cause and propose
a fix before changing anything.

The rhythm of a session

You're the product person in the loop. Claude proposes; you accept, redirect, or push back. Three steps, looping:

1. Describe what you want, with context.
2. Read what Claude proposes.
3. Accept, refine, or correct — then go again.

That's the work. No coding required. The skill compounds — better prompts mean better proposals mean faster sessions.

Two ways to use LLMs — build time vs runtime

When does a tool need an LLM inside it?

The honest question to ask: "Could this task be done with a plain script — pattern matching, lookups, if-statements?" If yes, don't put an LLM inside the tool. You're wasting money and inviting unpredictability. If no — if the task requires understanding meaning — then you need an LLM at runtime.

Classic signals that you do need one:

Which API key for which job

Once you've decided your tool needs an LLM inside it, there are three providers you'd pick between. The choice is mostly about data sensitivity and document size.

Concrete examples — scenario → verdict

Pattern to remember: Build with is almost always Claude Code. The interesting decision is Run with — and the data sensitivity does most of the picking for you.

Build time or runtime? (decision helper)

Two quick questions — we'll suggest the right tool.

How our team actually uses Claude Code

The fastest way to get oriented is to clone one of our projects from GitHub, open it locally, and run claude inside it. You'll see our pattern instantly.

The pattern

Almost every project follows the same shape:

1. A GitHub repository in our team's organisation, cloned to a folder on your laptop
2. A CLAUDE.md file at the root — the project's "user manual" for Claude (rules, conventions, the ports it uses). This is the file we cover in depth in the next section — read it carefully when you join a project.
3. An Issues - Pending Items.md — the standing list of known issues for this project
4. A planning folder (.planning/) if the project uses the optional GSD framework — most don't
5. The actual project content: a web app, a Python notebook, a Power Apps canvas YAML, an Excel + script combo, depending on what we're building

Working in a project

Day-to-day usage looks like this:

cd <path-to-the-cloned-project>
claude
# (Claude Code starts, reads CLAUDE.md, knows the project)

What did we work on last? Anything pending?
Claude › The pending list shows 2 items: one rule is missing,
        and the date format on the export is wrong.

Let's fix the export date format first.
Claude › Looking at exporter.ts… proposing this change…

CLAUDE.md — the single most important file in any project

What is it?

A plain Markdown file that Claude reads automatically at the start of every conversation, before you've even typed your first prompt. It contains your rules — conventions, glossary, do's and don'ts, hard-learned lessons. Whatever you write here, Claude obeys across every session, every team member, every time.

Why it's crucial (and not optional)

The two CLAUDE.md files you'll meet

The two layers compose. Both apply in any project. Where they disagree, the project's CLAUDE.md wins for that project — it's the more specific authority.

A skeleton project CLAUDE.md to copy

Compact starter — covers the team's standard folder layout, the rules that recur project-to-project, and the slots you fill in per project.

# <Project Name>

<One-paragraph description: what this project does, who uses it, what business problem it solves.>

## Tech stack
- Frontend: <framework / language>
- Backend:  <framework / language>
- Database: <engine>
- Deployment: <target>

## Ports
- Frontend dev server: <port>
- Backend API:         <port>

## Structure (folder layout)

- `docs/design/`     — plans (`plan-NNN-<short-desc>.md`), `project-design.md`, `project-functions.md`
- `docs/reference/`  — PDFs, schemas, screenshots, other teams' docs
- `docs/tools/`      — one document per reusable tool built in this project
- `test_scripts/`    — test runners and fixtures
- `prompts/`         — reusable prompts, numbered (`001-<name>.md`)
- `Issues - Pending Items.md` (at root) — pending items on top (most critical first), completed below

## Project-specific rules

- <Naming conventions specific to this project's domain>
- <Architecture rules — "never X for Y in this codebase">
- <Anything that bit us in THIS project that the global CLAUDE.md doesn't already cover>

## Tools built in this project

One concise entry per tool — the full doc lives at `docs/tools/<tool-name>.md`. Claude reads the doc on demand when the tool is relevant.

- **`<tool-name>`** — <one-line description of what the tool does>. See `docs/tools/<tool-name>.md`.

## Domain glossary

- **<Term>** — <what it means in this project's domain>.

## Hard-learned rules

- <Things that bit us once and we never want to forget — incidents, edge cases, anti-patterns specific to this project>

Best practices

• Keep it short. One to two pages. Not a novel. If it grows past that, split into linked sub-files.
• Lead with rules that have teeth — "never X", "always Y", "if Z then…". Vague aspirations don't help Claude (or humans).
• Add a rule when you've corrected Claude on the same thing twice. Once might be a glitch. Twice is a pattern worth saving.
• Update it during the session, not later. The moment you notice a missing rule, say "add this to CLAUDE.md so we never have to say it again." Claude will do it.
• Be specific. "Use ISO 8601 dates" beats "use a good date format". Claude follows instructions literally.
• Never put secrets in it. Keys, passwords, customer data — never. This file is in version control. Use environment variables.
• Review it during PR reviews. If a change in a PR implies a new convention, the same PR should update CLAUDE.md.

How to start one

Two easy paths:

• From scratch in a new project: run /claudemd — our scaffold skill drops a starter CLAUDE.md tailored to the team's standard project shape.
• From an existing project that doesn't have one: open a Claude Code session and ask "Look at this project and propose a CLAUDE.md." Claude drafts one from what it sees. You review, edit, save.

Skills — teaching Claude how we work

Why skills matter

Without skills, every team member would describe things differently, Claude would do things slightly differently each time, and we'd never build muscle memory. With skills, the team's way of working becomes reproducible. Anyone on the team installs them once and the same workflows kick off identically — on your laptop, on mine, on a new joiner's.

How we distribute them: a team plugin marketplace

Rather than scatter our skills across many small repos, we keep them in one place — a plugin marketplace on GitHub: 556LowCodeNoCode/Skills. Each plugin lives in its own folder; a single marketplace.json manifest lists them all.

The payoff:

• One-time install per machine — no copying files around.
• One update command picks up every skill that's been added or improved.
• One place to contribute — when you build a skill, you open a PR against the marketplace and everyone gets it on their next update.

Two kinds of skills you'll meet

/plugin marketplace add 556LowCodeNoCode/Skills
/plugin install team@556LowCodeNoCode-skills
/plugin install claudemd@556LowCodeNoCode-skills
/plugin install deploy@556LowCodeNoCode-skills
/plugin install uat-panel@556LowCodeNoCode-skills

The skills we use the most

Why we build our own skills

Out-of-the-box skills are great, but they don't know our project layout, our deployment process, our domain, or our hard-learned rules. When we notice ourselves repeating the same instructions to Claude — "use singular table names, never kill a process on a port, register every issue in Issues - Pending Items.md" — that's the moment to turn it into a skill and push it to the marketplace so the whole team gets it forever.

How to create a skill — two paths

You don't have to plan a skill before you start. Two routes work — pick whichever fits how the moment came up.

GSD — Get Shit Done

Before reading the rest of this section, remember: you always have a choice of how much structure to wrap around a piece of work. There are three levels, and you pick per project. GSD is just the heaviest of them — used only when it actually pays off.

What it offers

GSD adds a persistence layer on top of a project: a .planning/ folder that holds a roadmap, the current milestone, each phase's plan, the audit trail, and verification reports. Claude reads this folder at the start of every session, so the project carries its own memory across many days and many sessions.

The problem it's designed to solve

Claude Code is great in a single session — you ask, it builds, you review. But if a project takes weeks, across many sessions, possibly with a 2-week pause in the middle, you'd lose the thread. You'd forget what you decided. Claude would have no memory of yesterday's discussion. GSD's planning layer prevents that — at the cost of more upfront structure.

The shape of a GSD project (if you use one)

1. New project: /gsd-new-project — Claude interviews you about goals, constraints, who the users are, and writes a PROJECT.md.
2. Roadmap: breaks the project into milestones and phases.
3. Per phase: discuss → spec → plan → execute → verify → secure. Each step is its own command.
4. Audit: at any point ask /gsd-progress and Claude reports exactly where you are.
5. Ship: /gsd-ship creates a clean PR ready for review.

When it tends to pay off

• Long horizon — the project will span weeks or months, with many sessions.
• Multiple collaborators — you want a clear audit trail of what was decided and why.
• You care about traceability — every phase has falsifiable acceptance criteria; "done" means something measurable.
• Resumability matters — you may pause and pick up two weeks later without losing context.

When it's overkill

• One-off scripts and quick analyses — just use Claude Code directly.
• Single-sitting prototypes — /team is faster and lighter.
• Exploratory hacking where you don't yet know what you're building.

If you want to try it

/gsd-new-project        # start a fresh GSD project here
/gsd-progress           # where are we? what's next?
/gsd-do "add a date filter to the report"   # smart router — picks the right command
/gsd-next               # advance to the next logical step
/gsd-help               # the full command index (~90 sub-commands)

Don't feel obliged to memorise the GSD command list. Even people who use it daily look up /gsd-help when they need something specific.

Choosing your workflow — a decision aid

You've seen the three options (Section 8 has the side-by-side). This is the short cheat to use when you're staring at a task and wondering which level of structure to wrap around it.

Rule-of-thumb table

When in doubt, start lighter — escalate to /team or GSD only when you actually feel the gap.

GitHub

What it is, in plain terms

• A backup with a brain. Every change you save (a "commit") is permanently recorded with the date, who did it, and why.
• A history book. You can go back to any past version of any file. Mistakes are reversible.
• A place to collaborate. When you propose changes to shared code, your teammate can comment line-by-line before merging it in. That conversation is the "pull request" (PR).
• A home for issues. Bug reports, feature requests, discussions — they all live there.

Why we use it

• Our team has its own GitHub organisation — all our work lives there.
• It's how we collaborate on projects without stepping on each other's toes.
• It's how new joiners — and any bank colleague we've added — discover what we've built. Clone a repo and you have it locally.
• Code reviews ("PR reviews") are where we learn from each other.

The good news: you don't talk to GitHub directly

You talk to Claude Code, and Claude talks to GitHub using a tool called gh (the GitHub CLI). You don't need to learn git commands or GitHub's web UI deeply. Anything you can do in the web interface, Claude can do for you in plain English:

Show me the open issues on this repo.

Create an issue titled "Date format on export is wrong"
   with the description from our last conversation.

What was changed in the last 5 commits to this project?

Commit the changes I've made and push them up.

Open a pull request for my branch with a summary of what changed.

Check the PR I opened yesterday — any new comments?

The one tool to install — GitHub CLI (gh)

Claude doesn't talk to GitHub by magic — it uses a small terminal program called gh (the official GitHub CLI). Think of it as the bridge between your terminal and GitHub. Install it once, authenticate it once, and from then on Claude drives it for you in plain English.

Install (one-time)

brew install gh

sudo apt install gh

winget install --id GitHub.cli

First-time authentication

Connect gh to your GitHub account:

gh auth login

Follow the prompts: pick GitHub.com, pick HTTPS, then "Login with a web browser". gh shows a one-time code, opens GitHub in your browser, you paste the code, click Authorize. Done — you won't need to do this again on this machine.

Hit a "gh: command not found" error? You skipped the install step above. Ask Claude — it'll walk you through it.

Concepts worth knowing the names of

Quick cheat sheet

House rules (from our global CLAUDE.md)

• No silent fallbacks. If a configuration is missing, the tool throws an error rather than guessing. We want to know.
• Singular table names — Customer, not Customers.
• Never kill a process on a port — another teammate may be using it. Switch to a different port instead.
• Every project has an Issues - Pending Items.md — that's where we track problems. Most critical at the top.
• Claude doesn't commit unless you say so. No surprise git operations.