Transcription
Rules, Commands, MCP, Mods, hooks, Skills, Subendance. There is a huge amount of technology, tools, approaches, and practices surrounding development with code agents. But it seems that all of this shouldn't be so complicated. Therefore, in today's video, we will thoroughly break down, piece by piece, where and which tools to apply, and how to make their use truly effective. We will consider a brief retrospective on how code agents have evolved and why certain tools appeared, what tasks or problems they solved. We will examine in detail each of the tools that expand the capabilities of a code agent, and at the end, we will systematize everything and draw practical conclusions on how and what can be tried. We will start, of course, with the evolution of the ecosystem of capabilities in Cursor. When code agents first appeared, language models constantly hallucinated, forgot context, and got confused. The solution was Rules. A simple flat file that was inserted into every dialogue with the agent. This file, of course, grew. Over time, its use became less effective. The solution to this problem was the emergence of Project Rules, which allowed it to be decomposed into several separate ones. At the end of the year, the model context protocol appeared, which code agents supported first and foremost. Code agents evolved and transformed from having artificial intelligence functions into full-fledged agent systems. A demand for automation arose. The answer was reusable prompts in the form of slash commands. Code agents are effective, but how to make their use safe? How to ensure that your passwords don't leak or that the agent doesn't accidentally delete a database or file system? The answer: deterministic verification technology in the form of hooks. At the end of '25, the extremely effective Skills technology appeared. Cursor supported it at the beginning of '26, as well as the technology of sub-agents. Code agents evolved, but one thing remained unchanged. It was the context, which, with a large number of tools and a large number of rules, was constantly filled, leaving no room for truly valuable instructions that solved user problems. And the main thing to understand in terms of context management is that there are tools for static context management. These include, first and foremost, rules and various tools. They are always inserted into the context, making interaction with the agent most predictable, but may not use precious tokens as effectively. Dynamic management, for example, Skills, is a very effective technology in terms of context usage, but it already depends on the capabilities of a particular model. And let's start with the foundation of static context management. It's rules. A rule, essentially, is the constitution of a project. These are instructions that are inserted into every dialogue with the agent. In Cursor, you can see which rules are connected in the form of this kind of plaque with a ruler icon, right? This means that in this dialogue, for one reason or another, these rules are connected. There are four types of rules in Cursor. Command rules, they are available for large team and organization plans. The next and most common type of rules are project rules. There are also user-specific rules, so to speak, personal or global, as well as support for instructions located in an MD file. This is an open standard. Cursor also supports it. It is worth noting that rules can contradict each other, and in case of conflict, earlier ones have priority. The format for describing rules is standard Markdown as interpreted by Cursor, with a small insertion of metadata in YAML format with a certain number of options. Project Rules are located in a special directory, Cursor Rules, and can be decomposed by areas, zones of responsibility, and distributed across folders. All of them will be used. Moreover, Cursor supports not only the MD format but also regular Markdown. Cursor has four ways to connect rules. The first is rules that are always present in the context window. The most expensive. The second is rules that the agent itself decides when to connect; this connection method can be considered static context management with some stretch. Rules that the agent will connect based on file extension patterns. Rules that will be connected only if the user explicitly mentions them in the chat. The next type of rules is user rules, or global rules. In such rules, it is recommended to include recommendations that are not specific to a particular project, but rather user-specific expectations regarding communication style, preferences, for example, concise explanations or, conversely, detailed explanations. Personally, I also use these rules to set the condition not to create any additional documentation without explicit user agreement. Such a rule has to be applied when using models from Anthropic, which try to create some documentation at every step. Agents MD is a standard supported by a huge number of tools. Cursor allows hierarchical connection of these files. This means they can be located anywhere in the project. If you have, for example, a monorepo, frontend, backend, or specific modules, then absolutely all rules from any subdirectory will be loaded and applied. To create rules, there is a special section in the settings where you can specify the application method and generally describe the name, rules, and recommendations that the agent should follow. In principle, there is also a quick command, a "create rules with agent" button, where the agent will help create the rules automatically. Rules will constantly be in context. The main recommendation is to make them concise. And these rules should be easily readable by humans and easy to maintain. The shorter the rules, the better. Recommendation on what not to do: do not copy all necessary information there, all command variations that the agent already knows, or some corner cases, or something that is very rarely used. That is, make this document concise. And when working with static rules, adhere to the simple principle of expanding them only after a certain number of agent errors. Keep these rules in a version control system and share them with the team if necessary. The next capability is called commands, or slash commands. When you type a slash, a menu appears displaying all available commands. Commands are, in essence, just a repeatable instruction, an alternative to a prompt that you would simply copy into a dialogue with a new agent. And most often, it's automation of your daily routine. If you do something repeatedly during the day, you can wrap it in such an instruction and apply it faster in dialogues with the agent. Often, these are tasks related to version control systems, working with GitHub, working with documentation or quality, running tests, running linters, and so on. But in general, such a repeatable instruction can be configured for any activity characteristic of your own workflow. The next extension of agent capabilities or large language model capabilities is the Model Context Protocol, or MCP. This is an open standard, an open protocol developed by Anthropic, which is supported by a huge number of tools. And the essence of this protocol or the problem it solves is that large language models are quite powerful, capable of doing many things, but are completely detached from the real world. They are not integrated with the real systems that users interact with. Yes, they know nothing about GitHub, your databases, or any monitoring systems, and so on. And this protocol solves this problem, giving large language models the ability to interact with the external world. In Cursor, in particular, and similarly in other tools, MCP servers that provide access to various external services are configured using JSON. Cursor has a whole ecosystem of various tools that allow interaction with external services, databases, and possibly the browser. And you can easily add a particular tool directly from the Cursor website. There is also a huge number of MCP tool catalogs, and you can choose a suitable one or write your own and connect it to Cursor. Using MCP servers. Cursor has a number of limitations. And the main limitation is actually related to the number of connected tools. Since the description of tools is quite extensive, and it's a machine-readable format, i.e., JSON that describes functions, connecting just three MCP servers gives us 93 tools in the context, which can significantly affect the performance of working with the language model. And it must be said that, generally speaking, the downside of using MCP servers is inefficient context usage, of course. And Cursor developers have achieved significant improvements in this area, right? Yes, they have implemented the technology of dynamic connection of MCP tools, managing to save context usage by almost 50%. The next tool is modes. This is probably the first tool that you see when working with a code agent. There are four modes in Cursor. Agent, debug, and ask. These modes actually define, let's say, the agent's work profile and what tools it can use. The default mode, Agent, is the most complete autonomous implementation, with all tools available: code base search, file writing, command execution, MCP execution, naturally, provided that you either allow all tools or configure their use in some way. The second mode is the Ask mode, where the agent cannot edit or create anything; it only answers questions. So, it's a chat-only mode. And two modes are particularly effective in software development: Plan mode and Debug mode. Let's focus on them in more detail. Planning mode is a mode in which the agent does not write code. It explores the code base, asks clarifying questions. Its task is to create a detailed plan with architecture, if necessary, with all code examples, with some considerations, with behavioral logic. Once it has created a plan, it awaits your approval, or any remarks for correction of this plan. And specifically in the case of Plan mode, it's not just a functional mode but also a number of small interface conveniences and improvements. Here, we see the result of planning in a dialogue with the agent. That is, the agent has created a plan. It's even a visual widget in the chat that can be opened and viewed as a detailed page. There is also an element that allows saving this plan to the project, making this plan part of the project documentation, which, in principle, Cursor developers recommend doing. And we always follow this recommendation in our practice. It is very useful for understanding in the future, when solving problems and developing the project, what tasks were solved before, what decisions were made, and why. In addition to describing all the steps of detailed implementation, this plan contains a list of tasks that the agent follows, and it can actually perform some of these tasks in parallel. How it can do this, we will discuss closer to the end. The goal of forming a plan is to execute it. And there is a special "Implement" button, by which, of course, the agent begins to execute this plan. Debug mode is designed to investigate some non-obvious behavior and errors that are unclear why they occur and are difficult to investigate. In fact, Cursor developers say that this is a mode for investigating tricky bugs, so to speak, like memory leaks or performance problems, perhaps. But in my experience, even the simplest things like incorrect settings or an unspecified key in a configuration or environment variables are often not so easy to investigate. And this mode works almost like a regular developer would. In this mode, the agent makes several assumptions. That is, it explores the code base, looks at the description of the problem, assumes where the cause of the incorrect behavior might be. After making these two or three assumptions, it instruments the entire call chain with additional logs. That is, it inserts some prints, log entries, browser console entries, possibly. Then it instructs the user on what needs to be done to try to reproduce the error. That is, it suggests reproduction steps. The user follows these instructions, does everything, and the agent, during this time, reads the logs, analyzes what is happening, draws some conclusions, fixes the error, and, accordingly, continues to move in this manner. If the error is fixed, good. If not, it makes new assumptions. Well, and so on, until the problem is solved. The next capability is called hooks. This is probably the only deterministic tool that the agent uses. There are two types of hooks. By default, Command-based hooks are used, which means a specific program or script is launched for a particular action. And Command-based hooks are deterministic behavior. And there is, in fact, a second type of hook, prompt-based hook. And this is the ability to evaluate some data using. And this is, obviously, already non-deterministic behavior, because the interpretation is done using a large language model. Hooks in working with code agents can be applied for completely different tasks. For example, in lifecycle management. We started a session, or we call a tool, or we edit a file, or we finish editing a file, or we launch a sub-agent, or, for example, these are commands that are launched, for example, for security and control. For example, when we run some commands in the terminal, or some MCP tools, perform file operations that can be potentially dangerous. And, of course, everything related to using prompts, context. You can even use hooks when summarizing context. Hooks can be applied not only when working with the agent but also separately for inline autocompletion. To understand what a hook is, it's actually easiest to consider examples. So, imagine that the agent wants to perform some operation. How to guarantee that it won't be an unconditional deletion of all files in the project, God forbid, or all files on the server? Here's a hook that runs before a command is executed in the terminal, and it launches a Python script that will check the input of this command. The Python script could look like checking for malicious options, and the result would be permission or blocking of this operation. Or, for example, we wouldn't want the agent to pass some of our sensitive data to the large language model. Database passwords, or tokens from GitHub, or Telegram, or from OpenAI, for example. Similarly, we will create a command that will be executed before the agent reads a file. And if this file contains any sensitive data, we can mask it, delete it. Do whatever we deem necessary. Or, perhaps, we would want some tasks related to project agreements to be automatically executed. For example, automatic formatting after the agent edits a file. This is probably not the most typical case, because there are a million other ways, but, in general, as an example of one application, it's quite suitable. The next tool is Skills. In the previous video, I drew an analogy between static rules and dynamically connectable skills. A static rule is like a light bulb that is constantly on and constantly consumes electricity or our precious tokens. Skills are like a motion sensor that turns on only when needed. And Skills is a very, very powerful technology, a very good standard that makes the use of agents extremely effective both in terms of context usage and, in fact, in terms of efficiency. A skill is a package of instructions, domain knowledge, plus additional capabilities, including executable scripts, some additional documentation, as well as various templates, for example, configurations, documents, data. Skills in their instructions can use other automation methods, for example, reusable prompts in the form of slash commands, or, for example, hooks. Here's what a skill looks like: it's a regular Markdown file with a small YAML metadata header, a small one in the literal sense. The metadata includes the skill name and a very brief description. Very brief means the standard literally limits the size you can use. And this is done for a reason. When applying skills, a lazy loading process is used. That is, all available skills are placed in the context only in the volume of this header with metadata, i.e., name plus description. And the rest of the body and all necessary additional artifacts, documentation, or scripts are loaded as needed, as the agent decides that a particular skill is suitable for solving the task. In this case, the key role, generally speaking, in the effective use of skills, if we are talking about automatic, implicit use, is, of course, the description. That is, the description should as clearly as possible describe and instruct the agent in which case this skill should be used. And it must be said that this is an open standard supported by various code agents, including the two most popular: Code Llama, Codex. And, for example, if you use such a diverse set of tools in your team, Cursor supports importing rules from other tools. That is, at the project or user level, it allows, for example, importing skills that are intended for Code Llama or Codex. Starting from version 2.4, which introduced support for skills and sub-agents, a command for migrating static rules to a certain extent into dynamically discoverable skills also appeared. And, well, there are a number of limitations: rules created with automatic connection type, when the agent decides itself, are converted into regular skills. And slash commands are essentially commands that you explicitly use in the chat dialogue. They are converted into skills with a special option that carries the same meaning. That is, these are skills that cannot be used automatically, with the option "disable model invocation true" enabled, meaning automatic execution of this skill is disabled. This is necessary for sensitive operations like interacting with the file system, remote servers, and so on. I already mentioned the open standard, but I didn't say that, unlike the MCP protocol, which took half a year or more to get going across the ecosystem of tools, in this case, top players quickly supported it, and as a result, a huge number of literally catalogs with hundreds of thousands of skills appeared. For example, Anthropic has created a number of such packages for working with office document formats. A skill that allows for more unique AI-generated design. And various skills that collect best practices for using a particular technology. Frontend development, database usage, and so on. There are plenty of marketplaces, and there are convenient console utilities for installing skills into your project. But the greatest value, of course, is when you package your own workflows into such skill sets. Considering that executable commands and document templates can be used, this is simply an endless area for automating your processes. And the last technology is called sub-agents. Sub-agents are independent, specialized agents. And sub-agents have a number of features or, let's say, advantages. The first and most important is their own context window. That is, a launched sub-agent will have its own context and will not consume the parent's tokens. A sub-agent can be instructed in a special way, choosing, first, which model it will use to solve its tasks and how. And, of course, sub-agents can be used in parallel, which in a number of tasks allows significantly accelerating the execution of complex, large tasks, and saving the main agent's context and making the result of higher quality. It should be noted that in Cursor, for example, for working with the code base, a separate sub-agent is used for working with the terminal, its own, and also for working with the browser. That is, these are sub-agents that cannot be customized or explicitly used, but it's just important to understand that they are actively used and make working with a specific tool for performing a specific task most effective in terms of both speed and quality. Sub-agents, like skills, are supported not only by Cursor but also by other tools. Cursor, in turn, allows automatically importing and using sub-agents that exist for other tools. The configuration of such a sub-agent is a regular Markdown file again, with a small metadata header. And in this header, in addition to the name and description, there is an option to specify, for example, a specialized model and build the possibility of using it either in the background, or also to limit it in terms of editing capabilities, for example, as some kind of researcher or expert. The second part is the classic instruction on how it should be called, what it should do, how it should act. Creating a sub-agent is most effectively done using the Cursor agent, or there is a quick command "create sub-agent" that will help create all the necessary instructions and YAML metadata correctly, and then develop this matter carefully and sequentially in terms of calling. The main scenario and primary one is the automatic assignment of a sub-agent to solve a specific task. Some sub-agents can be called explicitly, for example. Moreover, we can say that we can ask a certain number of sub-agents to be called in parallel directly in the chat. And then we will discuss in which cases this is generally convenient and effective. And also for tasks that require a long execution time, we can ask the agent to continue, the sub-agent to continue executing the task. There are several conditional patterns, the first two patterns are verifier or orchestrator. The essence is the same: we have, for example, a planning stage where it is more effective to use some smart, expensive model to weigh everything, make the right decision, create a plan, draw an architecture, choose the necessary components, invent verification and debugging methods. Such a model can be, firstly, expensive, like Opus, it can be slow. But in terms of implementation, based on a ready-made plan, there are super-fast, quite good models, for example, composers or some codexes, which work very, very quickly. And, the plan can be made by one agent, and its implementation delegated to other agents. And verification can be delegated to a third. That is, separate verification by a separate sub-agent with its own context window and instructions, it will solve the problem when, for example, the agent says: "I've done everything, but nothing works." Leaving the main context of the main agent cleaner, without any extra noise, and making the task more effective. Or, for example, the third pattern: parallel execution of some tasks. For example, we can say that we would like to run tests, or run some linters, or run some checks on the entire project. And the results of these checks are, for example, some errors, warnings, and so on, which we would like to fix. And it turns out that if these errors and problems are found in different parts of the project, then their execution and correction may differ. And in general, we could, for example, in the main dialogue with the agent say: "run linters and in parallel, using some sub-agent that can effectively solve frontend tasks, fix all these errors." And this scenario makes solving this task many times faster. Or, for example, Cursor developers often talk on Twitter and other social networks about how they use the pattern of a council or multi-agent investigation for some complex task. For example, you can ask different agents with different models to work on the task separately, and then combine a general solution. For example, in Cursor, there is a mode where you can solve one task in parallel using different models, but this is to choose one of the solutions. But if you need to synthesize a general solution based on the opinions of different specialists, so to speak, then this council pattern is well suited here. It should be noted that in Cursor, in planning mode, we saw such a To-do list. And when the agent goes through this list during plan execution, it now delegates all these tasks to sub-agents and performs various actions in parallel. Naturally, the use of sub-agents has great potential in different tasks, in different scenarios, but there is a downside, some overhead, because each sub-agent has its own context, so it needs to be initialized, which takes a little longer. If we solve one task in a council with a number of agents, then it simply consumes many more tokens. And it must be understood that sub-agents should be applied carefully. For simple tasks, there is no point in doing this. It makes sense only if a particular agent is better suited for a particular task and will be more effective, as in the example of planning and implementation. We have, in principle, considered all the concepts, all the tools. Next, we need to practice. Moreover, it is probably necessary to adhere to a small number of basic principles, because there are many tools, and even more examples in the community. And this does not mean, of course, that all of them should be dragged into your project. Describe all recommendations in detail. It must be understood, of course, that agents are very smart, that everything should be developed carefully and evolutionarily, incrementally. One counterintuitive observation. Agents are extremely effective. They can do a lot, know many commands, know all patterns. They search your codebase well and effectively, even the largest ones. Yes, they easily handle projects with hundreds of thousands of files. Therefore, you should not give the agent unnecessary information. Everything that is needed and should be in context at a given moment, they will find themselves. And only in case of problems, some difficulties, errors, if the agent goes in the wrong direction, can you start correcting, can you apply certain practices. And to get acquainted not only with the theory of the full range of tools but also to consolidate their use in practice and build your own effective workflow with code agents, we have several programs, in each of which Cursor is an integral part. And the upcoming program "Eco-coding and Agents" starts this Saturday. This is the fastest and most effective way to dive into development with code agents. And for those who want to delve deeper, we have two in-depth long programs: Driven Fullstack Development for creating full-fledged applications from scratch to deployment in the cloud. In the Cursor Driven Development and Agents program, you will learn to create full-fledged agent and AI systems. I also remind you that we have a Telegram channel where we publish more useful information. Come, subscribe, ask questions, participate in discussions. If it was useful, of course, give it a like, subscribe so you don't miss new videos. And that's all from me. Thank you all. Goodbye.