First steps with AI coding: agents, skills and plugins

A coding agent reads the repository, edits files and runs commands on its own. With one, your job becomes deciding what to build, giving the agent a check it can run and reviewing what it wrote.

The examples use Claude Code in the terminal. Install it with the native installer its documentation publishes. Then open a terminal in the project directory and run claude, which asks you to log in the first time¹. Claude Code also exists as a VS Code and JetBrains extension, as a desktop app and in the browser. All of them read the same configuration¹. In Cursor, the agent is built into the editor and needs no separate installation.

Measurements were taken on 26 and 27 September 2026 with Claude Code 2.1.283, git 2.49.0, Node.js 24.19.0 and npm 11.8.0. The Cursor documentation was read on 8 September 2026. All the code is rebuilt for the article.

Section 13 describes a prompt that prepares the basics in your project: the instructions file, the block on secrets and a skill that reviews every change. Copy it with the Copy prompt button in the Prepare the project panel. The complete setup, with subagents that review every change, is in How to set up a complete environment for coding with agents.

1. What sets an agent apart from a chat

A language model can be used for coding in three ways, and they differ in who applies the change.

Autocomplete proposes the end of the line you are typing, inside the editor. You accept or reject each suggestion, so control is complete and the reach is one function at most.

Chat takes a question and returns text. You copy that code into the project, adapt it to the real names and check that it compiles. Since the model has not seen the repository, the code assumes a structure that may not match the real one.

An agent takes a task, decides which files to read, reads them, writes the changes and runs commands to check them. The Claude Code documentation defines it this way: the AI reads files, runs commands and makes changes autonomously. Meanwhile, you watch, redirect it or let it work on its own. The documentation contrasts it with chat assistants, which only respond with text you have to apply yourself².

A model becomes an agent when it has tools. A tool is an action the model can ask for: read a file, edit it, run a shell command or search the project. According to the same documentation, without tools the model can only respond with text².

Each of the three has its use. Autocomplete finishes a line, chat answers questions that do not touch the repository and the agent handles tasks that span several files.

How to check it. In an agent session, tool calls appear before the answer: which file it read, which command it ran and what came back. In Claude Code, Ctrl+O toggles the transcript viewer, with the detail of every call³. If the session produced only text, it did not work as an agent.

2. How an agent works

An agent does not answer once. It repeats a cycle until it considers the task done. The documentation describes it in four steps: gather context, take action, verify the result and repeat. The result of each tool use decides the next step².

A turn is one complete response from the agent. It starts when you send a message and ends when the agent finishes responding, with as many tool calls as it needs². For example, to fix a simple bug, the agent finds the file, reads it, writes the change and runs the tests. Then it reads the failure they return, fixes it and runs them again. That is six tool calls in one turn, where a chat would have given a single answer.

The model does not run those tools. It only produces text, including the request to use a tool. A separate program interprets that request, executes it against the filesystem or the terminal and hands the output back.

That program is called the harness. The documentation defines it as the tools, context management and execution environment that turn a model into an agent. Claude Code is the harness, and Claude is the model working inside it².

Cursor describes its agent with three pieces. They are the instructions that guide its behaviour, the tools for editing, searching and running commands, and the model chosen for the task⁴. That is why choosing the model and choosing the harness are two separate decisions.

How to check it. Run a task and count the tool calls before the final answer. If the agent solved something without reading a single file, it wrote it from memory.

3. What the context window is and how to measure it

The context window is the text the model has available during the session. It holds the conversation history, the files read, command output, the project instructions file and the system instructions². The agent knows nothing that is not in there. Its size is measured in tokens, the unit the model counts text in. For Claude, a token is roughly 3.5 characters of English text⁵.

The /context command shows how it is split. This is its output, trimmed, on opening a new session in a sample repository. The project instructions file takes 29 tokens and the personal one 96:

**Tokens:** 19k / 1m (2%)

| Category                | Tokens | Percentage |
|-------------------------|--------|------------|
| System prompt           | 2.3k   | 0.2%       |
| System tools            | 4.6k   | 0.5%       |
| MCP server instructions | 686    | 0.1%       |
| Custom agents           | 374    | 0.0%       |
| Memory files            | 125    | 0.0%       |
| Skills                  | 9.9k   | 1.0%       |
| Messages                | 1k     | 0.1%       |
| Free space              | 948k   | 94.8%      |
| Autocompact buffer      | 33k    | 3.3%       |

Apart from Free space and Autocompact buffer, every row is text sent with every request in the session:

• System prompt and System tools: Claude Code’s fixed instructions and the description of its tools. They do not depend on the project.
• MCP server instructions: what the connected external tool servers add, covered in section 10.
• Custom agents and Skills: the description of each installed subagent and skill, not its full content.
• Memory files: the project and personal instruction files, covered in section 8.
• Messages: the conversation. This is the row that grows with every file read and every command run.
• Autocompact buffer: space reserved for summarising the conversation when the window fills up.

That automatic summary is called compaction. It drops old tool output first and then summarises the rest. The instructions file is re-read from disk, but anything said only in the conversation can be lost². The whole conversation is also sent with every request, so a long session costs more⁶.

How to do it.

1. Run /context when the session opens and note the total.
2. When a task is done, run /clear to start a new conversation, with an empty context, before the next one.
3. If a long task gets close to the limit, run /compact to summarise the conversation at that point. It takes an instruction: /compact keep the list of files touched.
4. Put whatever has to survive compaction in the instructions file, not in a message.

How to check it. Run /context before and after the first task. The difference in Messages is what that task took up. With that figure you can decide when to close the session.

4. Which tasks to give an agent

A task suits an agent when there is a command that decides whether it is done. The documentation calls that the verification loop. You give the agent a check it can run: a test, a build or a comparison. The agent repeats the work until the check passes. Without one, the only thing that decides the agent is done is the agent itself².

Suits it	Command that decides the end
Fixing a bug reproduced by a test	the test passes
Migrating a library call across twenty files	the project builds
Writing tests for code that has none	the tests pass, and fail when the code is broken
Clearing linter warnings	the linter finishes with no warnings

Tasks without such a command suit it badly, such as deciding the architecture of a new module or tuning a visual design with no reference image. Neither does a task whose only criterion is that someone likes the result. In those cases the agent helps explore alternatives, but the decision is yours.

Declare that condition with /goal. At the end of each turn, a small model checks whether it holds. While it does not, the agent starts another turn instead of handing control back to you⁷.

/goal all tests in test/auth pass and the linter finishes with no warnings, or stop after 20 turns

Each part of that line has a job. “All tests in test/auth pass” is the measurable end state. “The linter finishes with no warnings” is a constraint that has to hold throughout the work. “Or stop after 20 turns” limits how long it runs.

The evaluator runs nothing: it judges what the agent has written in the conversation. That is why the condition has to be provable with a command’s output⁷. /goal clear removes the condition early.

How to check it. Before writing the request, name the command that will decide whether the task is done. If you cannot find one, the task is not ready for an agent yet.

5. How to write a request

The agent solves the statement it receives, so the statement has to include the condition that will be checked afterwards. “Add order cancellation” does not include it. This request does:

In src/orders.js, add cancelOrder(orders, id).
Return null if the order does not exist.
If it exists, set status to 'cancelled' and return the order.
Do not add dependencies.
Criterion: node --test passes with both tests in tests/orders.test.js.

What each line does:

• The file bounds where the change goes and saves the agent reading half the repository to find it.
• The behaviour in each case, error case included, gives the result something to be checked against.
• The constraint settles in advance something that, if the request does not say it, the agent decides on its own.
• The criterion names the command that decides the end and the result it has to return.

Also add what the model cannot work out from the code, such as the package manager version. In the first session, include it in the request. Section 8 explains where to store it so you do not have to repeat it.

In plan mode, the agent reads, searches and runs exploration commands, but does not edit the code: it presents a plan and waits for your approval². That way, the first review happens on a short text. You correct a wrong approach in that text, with no files to revert.

How to do it.

1. Type /plan followed by the request, or press Shift+Tab until the status bar shows plan mode on⁸.
2. Read the plan. If it names files the request did not ask to touch, correct it in your reply.
3. Approve the plan. The agent leaves plan mode and applies the changes.

How to check it. The request contains a runnable command and the result that command has to return. If it does not, you will have to read the whole change to decide whether it is finished.

6. How to stop, correct and undo the agent’s work

An agent works over several turns, so you need to be able to stop it halfway through a task and go back. There are three mechanisms, and each covers a different case:

Mechanism	What it does	When to use it
Esc	Stops the response or tool in progress and keeps what was done so far	the agent is doing something other than what you asked and one instruction is enough
/rewind or Esc Esc	Opens the checkpoint menu	a whole batch of edits has to go
git	Returns the repository to a commit	everything the other two do not cover

Ctrl+C also interrupts. With nothing running, the first press clears the input and the second exits Claude Code³.

Claude Code saves the state of the code before each request that starts a turn, and calls each capture a checkpoint. It keeps file snapshots for the 100 most recent checkpoints in the session⁹. /rewind lists the requests you sent and, on the one you pick, offers five actions⁹:

1. Restore code and conversation: returns both the code and the conversation to that point.
2. Restore conversation: goes back to that message and leaves the code as it is.
3. Restore code: undoes the file changes and keeps the conversation.
4. Summarize from here: summarises the conversation from that point on to free space in the context window.
5. Summarize up to here: summarises the conversation before that point and keeps later messages intact.

The two code restore actions only appear if there were edits after that point. Never mind returns to the list without changing anything⁹.

How to do it.

1. Before the request, run git status --porcelain. The output has to be empty; if it is not, commit what is pending or set it aside with git stash.
2. If the agent drifts from what you asked, press Esc and correct it with one sentence.
3. If the whole result has to go, run /rewind, pick the request and choose Restore code.
4. Then run git status --porcelain again.

How to check it. If the last step still shows modified files, they are the ones the menu does not cover. Discard them with git; section 12 explains the two commands that do it and their risk.

7. How to use the agent to learn

When the agent writes the code, you skip the part of the work where the learning happens. These three ways of asking keep that part, and all three are ordinary requests:

Instead of	Ask	What you get
“Fix the validation bug”	“In plan mode, explain which files are involved and why it fails”	the explanation over the real code, with no changes
“Add validation to the endpoint”	“Where is the request body validated, and in which file does the path start”	a map that serves the next tasks
“Write the function”	“Review my version against error handling, edge cases and naming”	the difference between the two versions

An agent is good at questions about where something is, because it can search the repository instead of guessing. Check against the documentation, however, anything it says about a library or a standard. The answer sounds just as sure when the fact is right as when it is wrong.

How to check it. After an explanation, close the session and try to rebuild what was explained without it. Whatever you cannot rebuild is what you need to read again.

Do you learn to code if the AI writes it? explains what the experiments on this topic measured and how to check what you learned.

8. How to document the project: AGENTS.md and CLAUDE.md

Every Claude Code session starts with a fresh context window, with nothing from previous conversations¹⁰. The instructions file holds what the agent needs to know about the project. You write it once and Claude Code loads it at the start of every session.

AGENTS.md is the file name several coding agents read. Claude Code reads it directly from version 2.1.277 if the repository has no CLAUDE.md. If it has one, by default it reads only CLAUDE.md, which can import AGENTS.md with an @AGENTS.md line¹⁰. A personal file at ~/.claude/CLAUDE.md also holds your preferences for every project. Claude Code adds every file it finds to the context instead of keeping just one¹⁰.

This is a complete file for a small project:

# orders

## Commands
- Install: npm ci
- Tests: node --test
- Single test: node --test tests/orders.test.js
- Lint: npx eslint .

## Environment
- Node.js 24, npm 11. ES modules.

## Conventions
- Dates are stored in UTC and formatted only in the UI.
- Functions in src/ do not write to the console; they return the error.

## Before calling a task done
1. node --test exits 0.
2. npx eslint . finishes with no warnings.
3. No dependency was added that the task did not ask for.

What each part does:

• Commands: the agent does not have to guess how tests run or which package manager installs. The single-test command saves it running the whole suite on every attempt.
• Environment: what cannot be worked out with certainty by reading the code.
• Conventions: the project’s decisions that the code does not explain.
• Before calling a task done: the verification loop from section 4, written once for every task.

Leave out what the agent can read from disk, such as the directory listing or the dependency list. The documentation recommends staying under 200 lines, because a long file takes more context and the model follows its instructions less reliably. It also asks for instructions that can be checked: “use 2-space indentation” rather than “format the code well”¹⁰.

The instructions file is context: the model reads it, but nothing forces it to comply. Set up as a hook whatever has to happen every time at a fixed point, such as formatting the code after every edit. A hook is a command Claude Code runs at that point of the cycle without asking the model¹⁰.

How to do it.

1. Run /init, which analyses the project and generates a first CLAUDE.md. If the project already uses AGENTS.md, write in that file instead.
2. Run every command the file names and delete any that does not work.
3. Add the conventions and the “Before calling a task done” list.
4. To edit the instruction files later, run /memory.

How to check it. Run /context all. The Memory Files list shows the loaded files, with their path and tokens. If the file is not there, the agent is not reading it.

9. What path rules and skills are

The instructions file loads in full in every session, so everything you add to it takes up context in every task. For what is needed only sometimes, there are two mechanisms that load on a condition.

Path rules are files in .claude/rules/ with a paths header. They only enter the context when the agent works on a file that matches those paths¹⁰:

---
paths:
  - "src/api/**/*.ts"
---

- Every endpoint validates its input before using it.
- Errors use the standard response format.

A skill is a folder with a SKILL.md file holding instructions, knowledge or a procedure. When the session opens, only its description loads. The full content comes in when a request matches that description or when you invoke it with /name¹¹.

---
name: change-summary
description: Summarises uncommitted changes and flags anything risky. Use it when asked what changed or for a commit message.
disable-model-invocation: false
---

Current changes:

!`git diff HEAD --stat`

Summarise those changes in two or three points, then list the risks:
missing error handling, hard-coded values or tests to update.
If there are no changes, say so.

What each part does:

• name: the command name, /change-summary. It uses lowercase letters, digits and hyphens, matching the folder¹².
• description: the only text the agent uses to decide whether to load the skill on its own. It says what the skill does and when to use it, in the words someone would type when asking.
• disable-model-invocation: with true, the skill only runs when someone types its command, never on the agent’s own decision¹¹.
• !`command`: runs before the skill is sent to the model, and its output replaces the line¹¹.
• The body: the instructions, which enter the conversation as a single message.

The skill also accepts the $ARGUMENTS variable, which is replaced by whatever is typed after the command. With /fix-issue 123, the body receives 123¹¹.

The format does not belong to one product. Skills follow the Agent Skills open standard, which makes name and description required and license, compatibility, metadata and allowed-tools optional¹². disable-model-invocation is a Claude Code extension.

How to do it.

1. Create .claude/skills/change-summary/SKILL.md for this project, or put it under ~/.claude/skills/ for every project on the machine¹¹.
2. Paste the example and adjust the description to how your team would ask for it.
3. Open a new session, because descriptions are read at start-up.

How to check it. Type / in the session: the skill has to appear in the list. Then make a request that matches its description without naming it, and check whether it loaded on its own. If it does not, the problem is the description.

10. What plugins are and what installing one costs

A plugin is an installable package that bundles skills, agents, hooks and MCP servers¹³. MCP, short for Model Context Protocol, is an open protocol for connecting a model to external data sources and tools⁵. An MCP server adds new tools to the agent, for example for Slack, Jira, a database or a browser.

Plugins are distributed through catalogues called marketplaces. Anthropic’s official one, claude-plugins-official, is registered the first time you open an interactive session, so installing from it takes a single command¹³:

/plugin install commit-commands@claude-plugins-official

commit-commands is the plugin’s name, and it adds commands for committing, pushing and opening pull requests. What follows @ is the catalogue it comes from. A third-party catalogue is registered first with /plugin marketplace add <owner>/<repo>, which installs nothing¹³. /plugin with no arguments opens the panel of catalogues, installed plugins and load errors, and /mcp manages connections to MCP servers¹⁴.

Before installing, each plugin’s details show two things. Context cost is what it adds to every message, and what its skills and agents add once loaded. Will install lists the commands, agents, skills, hooks and servers it brings¹³. The first takes up context in every session, including the ones that never use the plugin.

Code intelligence plugins connect a language server, the component that gives an editor features such as go-to-definition. With one installed, the agent sees the type errors its own edits introduce without waiting for a build. The plugin does not include the server, which is installed separately¹⁵.

How to check it. Run /context before and after installing. If a plugin adds context every turn and you never use it, uninstall it.

11. Which permissions to give the agent

An agent runs commands and reads files. Before the first long session there are two things to decide: when it stops to ask, and which files it can read.

The first is set by the permission mode, which you change with Shift+Tab and see in the status bar. These are the main modes and what each one does without asking⁸:

Mode	What it does without asking
default	Reads only. Claude Code calls it Manual, and the status bar shows it as manual mode on.
acceptEdits	Reads, edits files and runs basic file commands such as mkdir or mv.
plan	Reads and explores, but does not edit the code.
auto	Everything, with background safety checks.
bypassPermissions	Everything, with no checks at all.

From version 2.1.283, terminal and VS Code sessions start in auto⁸. The documentation restricts bypassPermissions to isolated environments, such as containers or virtual machines, where the agent cannot cause damage¹⁷.

The second matters because the agent sends the content of the files it reads to the provider’s server. A .env with credentials goes out just like the code. To exclude it, declare the rule in .claude/settings.json¹⁸:

{
	"permissions": {
		"deny": ["Read(./.env)", "Read(./.env.*)"]
	}
}

deny is the list of actions Claude Code always refuses. Read(./.env) is the read tool on that exact file, and Read(./.env.*) covers .env.local, .env.production and the rest.

Being in .gitignore does not protect the file. In the measurement, without the rule, the read tool returned the file with no error. With the rule, it returns this block:

File is in a directory that is denied by your permission settings.

The rule also covers shell commands that name the file, such as cat .env or head .env. It does not cover a script that opens the file itself, such as a Node or Python program¹⁷.

Cursor works differently. By default it ignores what .gitignore lists plus a built-in list that includes .env*, and anything else is excluded in .cursorignore. Its documentation warns that the agent’s terminal and external tools cannot block access to what that file covers¹⁹.

In both products, the exclusion is declared in configuration, not in the instructions file. Permission rules are enforced by the harness, not the model¹⁷. So a line in AGENTS.md saying “do not read .env” does not change what Claude Code allows.

One cost decision remains: which model the session uses. Change it with /model. The documentation recommends starting with Sonnet, which handles most coding tasks well and costs less than Opus⁶.

How to check it. Ask the agent for the contents of .env. With the rule in place, the read tool returns the block instead of the file. The model replying that it will not do it checks nothing, because the rule did not produce that reply.

12. How to review what the agent did

The agent edits files directly, so what is left when it finishes is a diff. A diff is the list of lines that changed between the previous state of the repository and the current one. The diff is only useful if the starting point was clean. That is why git status --porcelain has to print nothing before the request.

The usual command to see which files changed does not show the new ones:

git diff --stat

 package.json  | 2 +-
 src/orders.js | 8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

The session had also created src/util/date.js. git diff with no arguments compares the files in the working directory with the index, the area where the next commit’s changes are staged²⁰. A new file is not in the index yet, so it does not show up. git status does show it, marked with ??:

git status --short --untracked-files=all

 M package.json
 M src/orders.js
?? src/util/date.js

To read the contents of the new files in the diff too, mark them with git add -N. The option records the file in the index without its contents, so git diff compares it with an empty file and shows it in full²⁰. It stages nothing for the commit:

git add -N . && git diff --stat

 package.json     | 2 +-
 src/orders.js    | 8 ++++++++
 src/util/date.js | 3 +++
 3 files changed, 12 insertions(+), 1 deletion(-)

The missing file imports a new dependency declared in package.json, and the request asked for none. That dependency enters the lockfile, installs on every deploy and has to be kept up to date.

Read three things first:

1. Files the request did not name.
2. Deleted lines, because an agent rewriting a whole function can drop a check that was needed.
3. Changes to configuration, the Dockerfile and continuous integration, which decide what runs outside your machine.

A change that builds does not show that it does what was asked either, because it can pass the linter without meeting the request. The last check is running the program along the path the change touches. Inside the session, /diff shows the same, including the agent’s edits¹⁴.

How to check it. Run git status --short --untracked-files=all and compare that list with the request. Read in full every file that does not belong before continuing.

13. How to prepare the basics with a prompt

You can apply sections 8, 11 and 12 by hand. The agent can also do it with a prompt. Copy it with the Copy prompt button in the Prepare the project panel and paste it into a session opened at the project root. The agent follows six phases:

1. It surveys the project without writing anything: where its tool reads each file, the real test, lint and type commands, and the secret files, without opening them.
2. It proposes and waits. It presents the files it will create and the result of each command, and stops until you confirm.
3. It writes AGENTS.md with the verified commands and the “Before calling a task done” list from section 8.
4. It blocks reading secrets with the permission rule from section 11, and checks it by trying to read .env.
5. It creates the review-change skill, which applies the checks from section 12 to the diff and ends with a verdict.
6. It checks and delivers a report with what it created, the commands that failed and what it could not check.

The prompt was run once, as a demonstration, with Claude Code 2.1.283 in non-interactive mode (claude -p) and the Spanish version of the prompt. The sample project was an Express API with one test and a .env. Phases 1 and 2 took just over a minute, and the rest another minute.

.claude/ is a protected path: Claude Code never approves writing to it on its own, and in that mode, with nobody to answer the prompt, it denies the write. The rule and the skill were created after granting permission. When it tried to read .env, the tool returned “File is in a directory that is denied by your permission settings.”

The agent also flagged two things it was not its job to touch: .gitignore did not ignore .env.*, and one route returned every user’s orders.

How to check it. New skills are registered when the session opens, so close it and open it again. Then /review-change appears when you type /, and reading .env returns the block. git status --porcelain shows only the files the agent proposed in phase 2.

The subagents that review every change, the work agents and the optional tools are in How to set up a complete environment for coding with agents.

Which commands to use from day one

Type them inside the session; /help shows the full list¹⁴.

Command	What it does	When to use it
/init	Generates a first CLAUDE.md by analysing the project.	The first session in a repository.
/memory	Opens the instruction files and auto memory.	To correct an instruction.
/context	Shows how the context window is split.	On opening the session and after each task.
/clear	Starts a new conversation with an empty context.	Between two unrelated tasks.
/compact	Summarises the conversation to free context.	When a long task nears the limit.
/plan	Enters plan mode; takes the task after it.	Before letting it edit.
/goal	Sets a condition and the agent keeps going until it holds.	Tasks with a command that decides the end.
/rewind	Opens the checkpoint menu.	To discard a batch of edits.
/diff	Shows the uncommitted changes.	When it finishes, before committing.
/permissions	Manages allow, ask and deny rules.	To add the .env rule.
/plugin	Manages plugins and catalogues.	Before and after installing one.
/mcp	Manages connections to MCP servers.	To see which external tools are available.
/model	Switches model and saves it as the default.	To trade cost against capability.
/usage	Shows the session’s usage. Alias: /cost.	To know what a task cost.

Four keyboard shortcuts are needed³:

Shortcut	What it does
Esc	Interrupt mid-turn, or close a dialog.
Esc Esc	With the input empty, open the rewind menu.
Shift+Tab	Cycle permission modes.
Ctrl+O	Toggle the transcript viewer, with the detail of every tool call.

Where to go next

Start with the check: a command that says whether a task is done (section 4). Then add the instructions file and the skills as a task repeats, or prepare them with the prompt in section 13. When the project grows, How to set up a complete environment for coding with agents adds subagents that review every change and work agents.

Two topics remain, each with its own article. The first is what to look for in the code the agent writes. Eight things to check in the code your AI writes covers eight common security failures, each with its fix and the command that checks it.

The second is how to get the review to run on every change by itself, without depending on someone remembering it. That is the subject of how to ask an AI for secure code.

Once the environment is ready, How to secure a web application goes through the ten security layers of an application with users and links the article for each one.

References

1. Claude Code. Overviewinstallation, starting in the project directory, and the available surfaces.code.claude.com↩
2. Claude Code. Glossarydefinitions of agentic coding, harness, agentic loop, tool, context window, compaction, plan mode and verification loop.code.claude.com↩
3. Claude Code. Interactive modekeyboard shortcut table: Esc, double Esc, Shift+Tab, Ctrl+O and Ctrl+C.code.claude.com↩
4. Cursor. Agent, overviewread on 8 September 2026.cursor.com↩
5. Anthropic. Platform glossarydefinitions of token and MCP.platform.claude.com↩
6. Claude Code. Manage costs effectivelythe whole conversation travels with every request; model recommendation for getting started.code.claude.com↩
7. Claude Code. Keep Claude working toward a goal/goal syntax, how the condition is evaluated and what clears it.code.claude.com↩
8. Claude Code. Permission modesShift+Tab cycle, status bar text and description of each mode.code.claude.com↩
9. Claude Code. Checkpointinghow checkpoints are created, menu actions and limitations.code.claude.com↩
10. Claude Code. How Claude remembers your projectreading AGENTS.md directly from 2.1.277, imports, recommended size, path rules and hooks.code.claude.com↩
11. Claude Code. Skillslocations, header fields, $ARGUMENTS, injection with !`command` and what loads at start-up.code.claude.com↩
12. Agent Skills. Specificationrequired and optional SKILL.md fields and name constraints.agentskills.io↩
13. Claude Code. Discover and install prebuilt plugins through marketplacesofficial catalogue, install command and the details shown for each plugin.code.claude.com↩
14. Claude Code. Commandsdescriptions of the commands in the table.code.claude.com↩
15. Claude Code. Code intelligence pluginslanguage server, errors after each edit and separate binary install.code.claude.com↩
16. Claude Code. Plugin security and trustcode execution with the user's privileges and the limits of what Anthropic verifies.code.claude.com↩
17. Claude Code. Configure permissionsbypassPermissions warning and who enforces the rules.code.claude.com↩
18. Claude Code. Settings files and precedenceexample deny rules for .env files.code.claude.com↩
19. Cursor. Ignore filesread on 8 September 2026.cursor.com↩
20. Git. git-diffgit-scm.com↩