SONUB
EN English 한국어 日本語 中文 हिन्दी বাংলা اردو Español Português Français Deutsch Русский العربية Bahasa Indonesia Tiếng Việt ไทย Türkçe

How to enable notifications

Notifications are unavailable in this browser or on this address. Try a supported browser on the secure SONUB site.

If notifications are blocked, allow them in your browser settings.

  1. Open the site controls beside the address bar, or your browser’s site settings. Set Notifications for this site to Allow.
  2. In your device settings, allow notifications for your browser and check Do Not Disturb or Focus.
  3. Return to SONUB and reload the page. Once notifications are on, the bell disappears.

On iPhone or iPad, add SONUB to your Home Screen, open it there, then allow notifications.

Admin Log in Display theme Default theme Dark theme Pink theme Chat 1:1 Chat Group Chat Forum Notices News Suggestions Introductions Main menu Log out

Claude Code — Anthropic’s agentic coding tool in your terminal

You have installed it and done a first task — now build the habits you will use every day. Learn project instructions (), that many AIs read together, and modes, keeping the tidy and asking well, then finish with practice. The first thing to do is connect the — let open and check the page it changed.

Intermediate — instruction files, permissions, context

Browser connection — let Claude open and check the page it changed

)

For web work, does its best work with the connected. It changes the , opens , follows the flow by clicking and typing, reads the and the , and fixes what is wrong — the whole loop, without you. Checking the real page instead of trusting "the tests pass" is why you should always use the browser connection.

works in (grouped into one tab group per ) and uses your browser's login state. So it can work in admin , Google Docs, Gmail and other you are already signed into, with no connection. Which sites it may click and type on is set by the site of the .

  • Live — read the console errors and the DOM state directly, then fix the code that caused them.
  • Checking the design — open the page to see that it matches the and does not break on wide and narrow screens.
  • a web app — follow user flows such as form checks, sign-in and checkout to the end.
  • Working on signed-in sites — change dashboard settings, fill in forms, upload files from your computer, extract from a page and save it to a file.
  • Recording — record what it did as a or save as files to attach to a report.
claude --chrome

# inside Claude Code
/chrome    # Status: Enabled · Extension: Installed · "Enabled by default"
/mcp       # claude-in-chrome → View tools
I changed the login form validation. Open localhost:3000/login,
submit it with an empty email, and check that the error message
appears and the console has no errors. Fix anything that is wrong.
@browser go to localhost:3000 and check the console for errors

If the tools stop working, choose Reconnect extension in /chrome. If the extension and Claude Code are signed in to a different account or organization, you get "Browser extension is not connected" (check the organization with /status). An blocks browser commands — close it yourself and tell Claude to continue. The browser tools are always loaded, so they use a little more , but for web work keeping them on is far better.

Models and effort — which to use (recommended: Opus 5.5, High)

)

As of November 2026, use Opus 5.5 at High effort for development. Its default effort is medium, so set it as below or run / opus and /effort high. Every model and , and when to go lower or higher, is in Recommended use on Tool Master.

~/.claude/settings.json
{
  "model": "opus",
  "effortLevel": "high"
}
Terminal
claude --model opus --effort high

# inside Claude Code
/model opus
/effort high

CLAUDE.md — project instructions read every session

)

is a file that Claude Code reads every time a session starts. Write down what you are tired of repeating: build and test commands, code , things it must not do. Run and it reads the project and writes a first CLAUDE.md. CLAUDE.md files in several places do not override each other — they are all read together.

  • ~/.claude/CLAUDE.md — your personal instructions for every project
  • ./CLAUDE.md or ./.claude/CLAUDE.md — project instructions the team shares ( it to )
  • ./CLAUDE.local.md — instructions only you use in this project (add it to )
  • CLAUDE.md in a — also read when Claude reads or edits files in that folder. Rule files in .claude/rules/ can apply to certain files only, with
  • Note: if a CLAUDE.md, .claude/CLAUDE.md or exists in the working folder or any folder above it, Claude Code does not read . Your personal ~/.claude/CLAUDE.md does not count — see the next section.
CLAUDE.md
# My App

## Commands
- Install: npm install
- Test: npm test
- Lint: npm run lint

## Rules
- TypeScript strict mode. Do not use `any`.
- Put new API routes in src/routes/.
- Never edit files in vendor/.
- Run the tests before you say a task is done.

@docs/architecture.md

Keep it short (the official docs suggest under lines). It is read every time, so a long file takes up room and buries the important rules. /memory shows the instruction files that were loaded and opens them for editing, and @path (like @docs/architecture.md) pulls in another file. If you use several AIs together, it is best to keep only AGENTS.md in the project instead of CLAUDE.md — see the section right below.

Use only AGENTS.md — so every AI works from the same instructions

)

Why do this? If one project uses other AIs such as , or alongside Claude Code, separate instruction files for each tool soon drift apart. AGENTS.md is an open format that many read. Write the rules once in AGENTS.md and every follows the same instructions, whichever one you work with. The method below exists for exactly this — so that in one project, many AIs all use the same instructions through AGENTS.md.

Claude Code can read AGENTS.md directly too (v2.1.277 or later), but not quite like CLAUDE.md.

  • With the default setting it reads AGENTS.md only when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in the working folder or any folder above it. Adding just one CLAUDE.local.md for personal notes stops AGENTS.md from being read (~/.claude/CLAUDE.md and .claude/rules/ do not count here).
  • Claude reads a subfolder's AGENTS.md when it opens an existing file in that folder with the Read tool and that folder has no CLAUDE.md of its own. If Claude creates a new file there before reading an existing file, it may not have loaded the folder's instructions yet. A subfolder's CLAUDE.md is loaded when Claude reads, creates or edits files there.
  • AGENTS.local.md, and files under a ./ folder are not read, and neither is the AGENTS.md of a folder added with --add-dir.

The best way is not to use CLAUDE.md in the project folder at all and use only AGENTS.md. Your instructions in ~/.claude/CLAUDE.md are still loaded by default, and in the project folder AGENTS.md is used. Other AIs such as Codex read the same AGENTS.md, so you edit the rules in one place only — AGENTS.md.

But if you use CLAUDE.md in even one place — the project folder, the , a or a subfolder — you must use CLAUDE.md in every folder. If there is even one CLAUDE.md in the working folder or above it, Claude Code does not read AGENTS.md, so mixing them means some folders' rules are read and others are left out. If you still want to use AGENTS.md in that case, just add one line, @AGENTS.md, to each CLAUDE.md. @path is the that pulls a file's contents in at that spot, and the official docs say this import never makes Claude read AGENTS.md twice.

  1. Write the shared rules (install and test commands, code rules, things not to do) in AGENTS.md at the top of the project. You can also create it with Codex's /init.
  2. Do not create CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md anywhere in the project (not in the current folder, parent folders or subfolders).
  3. Keep your personal instructions for every project in ~/.claude/CLAUDE.md — it is always loaded together with AGENTS.md.
  4. If a subfolder has its own rules (for example api/), put an AGENTS.md there as well.
  5. Open /memory in Claude Code and check that AGENTS.md was loaded. If you decided to use CLAUDE.md, also check that every folder's CLAUDE.md has the one line @AGENTS.md.
Best — AGENTS.md only
~/.claude/CLAUDE.md    ← your personal rules (still loaded by default)

my-project/
├── AGENTS.md          ← shared rules for every AI (Claude Code, Codex, Cursor, Gemini …)
└── api/
    └── AGENTS.md      ← rules only for api/

(no CLAUDE.md anywhere in the project)
If you use CLAUDE.md anywhere — put one in every folder
my-project/
├── AGENTS.md
├── CLAUDE.md          ← @AGENTS.md
└── api/
    ├── AGENTS.md
    └── CLAUDE.md      ← @AGENTS.md
CLAUDE.md
@AGENTS.md

Good to know, and other ways. ① Set Project instructions in /config to claude-md-and-agents-md and each folder's AGENTS.md is read right after its CLAUDE.md. ② A (ln -s AGENTS.md CLAUDE.md) also works, but with in the mix the one line @AGENTS.md is safer.

Permissions and modes — decide what it may do without asking

)

Claude Code asks before it edits a file or runs a command. If approving the same thing every time gets tiresome, turn it into a rule, and switch modes to suit the job.

  • — switch modes: default (ask every time) → (file edits without asking) → plan ( and show a plan). If you started in , the first press switches to default.
  • /permissions — see and edit the allow, ask and deny rules and which file each one comes from.
  • holds rules the team shares (commit it), .claude/settings.local.json holds rules only you use, and ~/.claude/settings.json holds rules for all your projects.
  • Rules are checked in the order deny → ask → allow. Anything denied anywhere cannot be allowed elsewhere, so block files such as with deny.
.claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

(--dangerously-skip-permissions) turns every check off. Use it only where damage does not matter, such as a or with no internet access.

Managing context — when the conversation gets long

)

How much Claude can see at once (the ) is fixed. The conversation, the files it read and command output all pile up there, and when it is full the earlier part gets summarized. The longer it grows, the fainter earlier instructions become, so make tidying up a habit.

  • /context — see, as coloured blocks, what is taking up the context and how much.
  • /compact — summarize the conversation so far to free up room. You can say what to keep (for example /compact focus on the login fix).
  • — start a new conversation with empty context when you begin unrelated work. The earlier conversation is not deleted: brings it back.
  • claude -c continues the last conversation in this folder, and claude -r or /resume lets you pick an earlier one to continue.
  • twice (or /rewind) — pick an earlier point from the list and the conversation and code. Files deleted or moved with are not restored, so it does not replace Git commits.

One job per conversation. When the job changes, starting fresh with /clear is the easiest way to tidy up.

Save context — set Claude Code to auto compact at 444k (SONUB setting)

)

Asking well — where, what and how to check

)
  • Vague request: "Fix the login"
  • Clear request: "In @app//Controllers/LoginController.php a wrong password gives a 500 error. Make it return 422 with an , add a test to tests/Feature/LoginTest.php and check that it passes."
  • Type @ to pick a file and attach it to your request (@src/login.ts).
  • For error screens and design mock-ups, paste or drag in a screenshot.
  • For a big job, enter first with /plan (or Shift+Tab). Claude looks through the code and writes a plan, and edits no files until you approve it.
  • For a hard problem, raise the model and effort level in /model, or put in your request so it thinks harder on that only.
  • <> — Claude keeps taking turns without a new request until the finish line is met (e.g. /goal all tests in tests/ pass, or stop after 20 turns). /goal alone shows the status; /goal clear removes it.

Best practices — how Anthropic recommends using Claude Code

)

In short: give Claude a way to check its work, plan hard work first, be specific, keep CLAUDE.md short, and use /clear when you switch to a new, unrelated task — keep the current context for related follow-up work. The six good habits from both official guides, with commands for Claude Code and Codex, are in Recommended use.

Common mistakes — and how to fix them

)

The official guide warns about five failure patterns — the kitchen-sink session, correcting over and over, an over-long CLAUDE.md, trusting without checking and endless exploration. All ten mistakes from both guides, each with its fix, are in Recommended use.

Intermediate practice — try it in your own project

)
  1. Create an AGENTS.md file in your project's root with the test command and three rules, and check that there is no CLAUDE.md in the project.
  2. Open /memory and check that AGENTS.md and ~/.claude/CLAUDE.md were loaded.
  3. In .claude/settings.json allow one test command and deny .env, then check with /permissions.
  4. Ask for one small feature in plan mode, read and adjust the plan, then approve it.
  5. Look at how much is used with /context, shrink it with /compact and look again.

Done all five? Finally, use /clear if you are ready to move on to a new, unrelated task — then go to the [Advanced] tab.

Official documentation

Checked against the official documentation on 2026-10-19. These tools change often — if a command fails, see the official docs.

Claude Code lab Sonub Lab — Claude Code practice Use the real Claude Code on your own computer in this page’s terminal — install it in three steps and run sonub start. It uses the SONUB practice brain, so you need no Claude subscription or API key.

Glossary

Pick a word you don't know. You'll see a simple explanation and related terms.

No matching term yet.

Pick a term to see its explanation.

Reading window