In this article I show what that looks like in practice. It is about providing context for the architecture<\/strong>, integrating architecture checks like Sheriff into the AI's feedback loop<\/strong>, and setting all of this up so that it works across multiple platforms<\/strong> such as Cursor AI, Claude Code, Codex (GPT), or Google's Antigravity CLI. We integrate the official Angular Skills<\/strong> and the MCP server of the Angular CLI<\/strong>, account for the NgRx Signal Store<\/strong>, add custom Skills<\/strong>, and in the end also bring in ADRs<\/strong> and other documented decisions.<\/p>\n \ud83d\udcc2 Source Code<\/a> (Branch: Before an AI can adhere to an architecture, we have to define that architecture. Our example structures the application into domains<\/strong>: domains reduce cognitive load, because when working on a feature you only need to care about a manageable slice, and they support team organization, because responsibilities can be cleanly delineated.<\/p>\n The matrix shows the principle. Each column is a domain, each row a layer. A Feature<\/strong> is a business use case, typically with smart components that orchestrate the use case. UI<\/strong> contains reusable, "dumb" components. Data<\/strong> takes care of data access and data models, Util<\/strong> of technical helper functions. Cutting across all of this, there is a Shared<\/strong> domain for code that several domains need.<\/p>\n The permitted accesses are decisive: layers may only access one another from top to bottom ( Building on this, we rely on Feature Slicing<\/strong>. The idea is locality: code that belongs only to one feature also lives in the feature folder \u2013 including feature-local dumb components, stores, and helper functions. This keeps cognitive load low, because related code sits together. The downside is just as real: if local code is suddenly needed elsewhere, it has to be refactored, that is, moved into a more global area. We will see later how exactly this moving can be nicely automated with AI-assisted coding.<\/p>\n The image makes clear that Feature Slicing is not all that far from the pure matrix. It simply additionally allows feature-local UI, Data, and Util building blocks that only move into a deeper, shared layer once they are actually needed by several features.<\/p>\n An architecture that exists only in a presentation does not survive a single sprint. That is why we enforce the matrix with Sheriff<\/a>. Sheriff assigns tags to folders \u2013 such as The message is pleasingly concrete: the module How to set up such an architecture with Sheriff and standalone components in detail is described in the article Modern Architectures with Angular \u2013 Strategic Design with Sheriff<\/a>.<\/p>\n A coding agent is only as good as the context it gets. Without explicit guidance the model guesses \u2013 and when in doubt it guesses the mainstream style from its training data, not our conventions. Context is therefore not a nice-to-have, but the prerequisite for generated code to fit our architecture at all.<\/p>\n Angular itself provides the entry point. The framework generates an Cursor AI reads its guidelines from the The So the full detailed rules should not be duplicated in Docs contain the binding architecture and coding rules. AGENTS.md names the most important red lines and points to the relevant rules. Task-specific context is only pulled in when the task at hand needs it.<\/em><\/p>\n Behind this is a deliberate decision about context size: the more that permanently sits in the prompt, the higher the cost, the distraction, and the risk of context pollution. That is why only short always-on rules belong in In Cursor, rules can apply permanently, take effect via file patterns, be selected by the agent based on their description, or be referenced explicitly. With that, With other tools like Claude Code we achieve the same effect via prompting: in local instruction files we tell the agent what to load when \u2013 for example The full files can be looked up on GitHub if needed: With the architecture rules, the decisive thing is that we capture the tricky spots unambiguously. The most important rules in brief:<\/p>\n The rules for the Signal Store are explicit as well. Among other things, they specify:<\/p>\n Not every guideline can be sensibly expressed through layering and Sheriff. If you tried, the configuration would quickly become unwieldy. That is why we additionally rely on naming conventions that are easy to describe and easy for the model to check.<\/p>\n A good example is access to the store. Only smart components<\/strong> may use a store, and in our project you recognize smart components by the suffixes These conventions are likewise captured in the rules. Especially now that, in modern Angular, components no longer carry the not-very-meaningful default suffix If we put the entire context into the prompt all the time, it would quickly become overloaded, expensive, and unwieldy. With rules we already use case-specific loading in part: in Cursor, for example, via file patterns, descriptions, or explicit references, and with Claude Code via corresponding prompting rules. Skills<\/strong> take this idea further by bundling task-specific knowledge and recurring workflows.<\/p>\n Skills thus encapsulate task-specific knowledge and concrete workflows. Depending on the tool, they can be activated automatically or explicitly. This leads to a clear division of labor:<\/p>\n Docs contain the binding architecture and coding rules. Skills describe how an agent should proceed for specific tasks. AGENTS.md names the most important red lines and points to the relevant rules.<\/em><\/p>\n Skills therefore point to the docs but do not duplicate them: The Angular community provides official Skills that are regularly adapted to the respective current framework version. We install them with the Skills CLI:<\/p>\n This places the Skills This very pattern can be applied to our own rules. For the state-management conventions from By the way, the same pattern can be applied to the architecture rules as well: instead of activating In addition, the MCP server of the Angular CLI<\/strong> is useful. MCP (Model Context Protocol) is an open standard through which a coding agent can access external tools and knowledge sources. Among other things, the Angular MCP server provides the agent with well-curated examples and access to the current documentation \u2013 ideal for hitting best practices even when the model's training data is already somewhat dated.<\/p>\n In Cursor AI we set up the server via the file With that, the Angular MCP server is available to the agent as soon as it needs it.<\/p>\n Up to here we have taught the model a lot. But knowledge alone is not enough \u2013 we need a deterministic safety net that checks every round of the agent. That is exactly what Hooks<\/strong> are for.<\/p>\n In Cursor AI we set up a stop hook<\/strong>. It kicks in when the agent thinks it is done, and beforehand runs a Node script that runs the linter, tests, and build. Sheriff is also integrated via the linter \u2013 so our architecture matrix is checked by machine on every round. The configuration sits in The invoked script If one of these steps fails \u2013 for example because Sheriff reports an architecture violation, a test is red, or the build breaks \u2013 the agent goes into a new round. It receives the error message as input and tries to fix it. The In larger repositories you can stagger the checks: first fast checks like lint and Sheriff, then targeted tests, and only for bigger changes or before the merge the full build. This keeps the safety net in place without making every round unnecessarily expensive.<\/p>\n The fact that it is a Node script<\/strong> is a deliberate decision: this way the same check runs platform-independently on macOS, Linux, and Windows.<\/p>\n A small but important difference in the behavior of the tools: Cursor reports visibly when the script is executed. Claude Code does not \u2013 there you only notice it when an error occurs.<\/p>\n You'll find more on Signal Forms and modern Angular architecture in my new eBook Modern Angular. It covers signals, architecture, testing, AI assistants, and practical solutions for modern business applications.<\/p>\n More about the book \u2192<\/a>\n<\/div>\n<\/p>\n It is not uncommon for developers to be allowed to choose their own tools. And this is exactly where a practical problem lurks: different environments expect Rules, Skills, and MCP servers in different folders and under different file names. With Claude Code, for instance, Rules live in But we want to keep a single source of truth<\/strong> rather than maintaining every guideline multiple times. The solution depends on the respective artifact.<\/p>\n For the Rules<\/strong> we solve it elegantly via references: the In addition, a This is the concrete implementation of the prompting approach mentioned earlier: instead of "always read all architecture rules", we phrase the guidance case-specifically. In effect: use The following image summarizes how Claude Code and Cursor AI obtain their context: both always load their entry rules ( For Skills and MCP configuration<\/strong> this reference trick does not work \u2013 here the files actually have to live in both places. Symlinks would be the obvious choice, but they behave differently between Windows and Linux\/macOS and, in our experience, cause friction. That is why we instead copy the files with a small Node script<\/a>. It mirrors So that no one accidentally edits the generated copies, the script additionally creates two So that the script runs reliably, we hook it into the usual lifecycles: it is executed via npm's Many current coding agents and agent tools now orient themselves around similar conventions: an That is why we treat This is exactly where language models play to their strength: they are remarkably good at adapting our existing setup to the current conventions of additional coding agents. You can simply ask the agent to consult the documentation of the new tool, derive the matching target format, and extend the sync script accordingly \u2013 so connecting another tool itself becomes a task for AI-assisted coding.<\/p>\n Enough theory \u2013 let's see the setup in action. In the coding agent we request that we also want to manage Airports<\/strong> going forward. For simplicity, these are kept directly in memory, in a data-access service named The result is impressive. The two features If the agent were to violate a linting rule such as a Sheriff-based architecture constraint \u2013 or if tests or the build failed \u2013 the IDE would automatically go into a new round thanks to the stop hook, until the checks are green.<\/p>\n It gets exciting when we vary the requirements. If we explicitly state that we want the same store in both features, the coding agent moves the store into the data layer on its own \u2013 exactly as we described it in As long as we stay within the same domain, the agent may refactor the code according to the documented rules \u2013 such as the move of the store into the data layer shown earlier. It gets even more interesting when we also want to reuse the If we decide to move the If we instead choose the API path, the An honest assessment is part of the picture: creating good Rules and Skills is not a one-time act, but an iterative process<\/strong>. If the agent does something you don't want, these files need to be sharpened and made more concrete. By the way, language models and coding agents help excellently with this too \u2013 you can simply ask them to turn an undesired behavior into a more precise rule.<\/p>\n In our experience, it also depends strongly on the model used how strictly and explicitly you have to phrase things. Some models follow even brief hints, others need unambiguous, almost pedantic guidance. It pays off to calibrate the rule set to the model actually in use.<\/p>\n From practice, two more recommendations that can make the difference between frustration and flow. First, I've had good experiences with saved prompts<\/strong> that I pull into the chat when needed. This helps enormously with iterative refinement and especially with analogous follow-up tasks.<\/p>\n Second, I like to first have the agent explicitly plan<\/strong> \u2013 via the plan mode that many IDEs now offer \u2013 and only then release the plan for implementation. This way misunderstandings can be cleared up before a single line of code is written.<\/p>\n Refined prompts can also be developed into custom Skills. We are not limited to generating code here \u2013 we can also use them for recurring tasks such as an architecture review<\/strong>. Our own Skill for this lives under The Skill makes The review is started with a simple prompt:<\/p>\nai-arc<\/code>)<\/p>\nTarget Architecture: Domains and Layers in Angular<\/h2>\n
![\"Architecture](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/matrix.png\")
<\/p>\nfeature \u2192 ui \u2192 data \u2192 util<\/code>), and domains do not access one another directly<\/strong>. Anyone who needs code from another domain either uses the Shared domain or an API that offers targeted access to selected parts of a domain.<\/p>\n![\"Feature](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/feature-slicing2.png\")
<\/p>\nValidating the Architecture Matrix with Sheriff<\/h2>\n
domain:ticketing<\/code> and type:data<\/code> \u2013 and defines rules about which tags may access which. If you don't comply, you get a linting error: right as you type in the IDE and on the console.<\/p>\n![\"Console](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/sheriff.png\")
<\/p>\ndomains\/checkin\/feature-checkin<\/code> may not access domains\/ticketing\/data<\/code>, because domain:checkin<\/code> has no permission for domain:ticketing, type:data<\/code>. It is exactly this precision that is the key to the next step \u2013 because such an error is not only feedback for developers, but also excellent, deterministic feedback for the language model. We will see in a moment how the coding agent picks up this message and corrects its code on its own.<\/p>\nProviding Context: Rules<\/h2>\n
AGENTS.md<\/code> with the most important cornerstones for modern Angular \u2013 signals, standalone components, inject()<\/code>, native control flow, and much more. That is an excellent starting point that we don't have to reinvent.<\/p>\n.cursor\/rules<\/code> folder. So that we don't duplicate rules, our Cursor-specific rule cursor.mdc<\/code> points to AGENTS.md<\/code> as the authoritative source:<\/p>\n---\nalwaysApply: true\n---\n\nAlways follow the guidelines defined in the `AGENTS.md` file in the project root.\nIt is the authoritative source for coding standards, conventions, and best practices.\nIn case of conflicts, the rules in `AGENTS.md` take precedence.<\/code><\/pre>\nalwaysApply: true<\/code> in the frontmatter ensures that this rule applies to every request \u2013 and the actual content only points to AGENTS.md<\/code>. This already brings clear roles for the individual artifacts into focus:<\/p>\n\n
AGENTS.md<\/code> contains the red lines and short references \u2013 not the full detailed rules.<\/li>\ndocs\/architecture-boundaries.md<\/code> is the source of truth for domains, layering, feature slicing, shared code, public APIs, and Sheriff rules.<\/li>\ndocs\/architecture-state-management.md<\/code> is the source of truth for store and state-management conventions.<\/li>\n<\/ul>\nAGENTS.md<\/code>. In short:<\/p>\nAGENTS.md<\/code> or in always-on rules. The detailed rules stay in docs\/architecture-boundaries.md<\/code> and docs\/architecture-state-management.md<\/code> and are read for matching tasks or activated via rules, prompts, or \u2013 later \u2013 Skills. We pick up this idea again in the section on Skills.<\/p>\n.mdc<\/code> files already move toward task-specific context steering: short red lines stay visible at all times, detailed rules are only activated when the task needs them. Concretely, the .mdc<\/code> files under .cursor\/rules<\/code> point to docs\/architecture-boundaries.md<\/code> and docs\/architecture-state-management.md<\/code> and help the agent take them into account for matching tasks.<\/p>\ndocs\/architecture-boundaries.md<\/code> for structural changes and docs\/architecture-state-management.md<\/code> for store tasks. Instead of carrying every detailed rule along permanently, the matching rule is pulled in for the matching task. We'll look at the concrete implementation via CLAUDE.md<\/code> and src\/CLAUDE.md<\/code> further below.<\/p>\narchitecture.mdc<\/code><\/a>, docs\/architecture-boundaries.md<\/code><\/a>, and docs\/architecture-state-management.md<\/code><\/a>.<\/p>\nGeneral Architecture Rules<\/h2>\n
\n
api\/index.ts<\/code> with selected exports in a neighboring domain.<\/li>\nFlightSearch<\/code> and FlightEdit<\/code>). In practice this has proven surprisingly effective.<\/li>\n<\/ul>\nSpecific Rules for State Management<\/h2>\n
\n
withResource<\/code>, withMutations<\/code>, and the dev tools support (withDevtools<\/code>).<\/li>\n<Entity>SearchStore<\/code>), for the entity of a detail view<\/strong> (<Entity>DetailStore<\/code>), for lookup entities<\/strong> or suggestion values (<Feature>LookupStore<\/code>), and for UI state<\/strong>.<\/li>\nNaming Conventions<\/h2>\n
Page<\/code>, Search<\/code>, Detail<\/code>, and Edit<\/code> \u2013 such as FlightSearch<\/code> or FlightEdit<\/code>.<\/p>\nComponent<\/code>, it pays off to use suffixes for such semantics \u2013 for human and machine alike.<\/p>\nContext on Demand: Angular Skills and MCP Servers<\/h2>\n
docs\/architecture-boundaries.md<\/code> and docs\/architecture-state-management.md<\/code> remain the binding detailed rules, while a Skill describes the matching workflow for them.<\/p>\nnpx skills add https:\/\/github.com\/angular\/skills<\/code><\/pre>\nangular-developer<\/code> and angular-new-app<\/code> in the .agents\/skills\/<\/code> folder \u2013 a convention that has established itself across tools. A skills-lock.json<\/code> records which version is installed, so that updates can be applied in a traceable way.<\/p>\ndocs\/architecture-state-management.md<\/code>, a task-specific signal-store<\/code> Skill is a good additional fit. The docs\/architecture-state-management.md<\/code> remains the binding source for store conventions; the Skill points to it and describes the concrete workflow for typical tasks: when a new store makes sense, which store type to choose, where the store should live, which existing stores serve as references, and which checks to run after the change. So the rule itself stays in the project documentation; the Skill describes how the agent should concretely proceed on store tasks.<\/p>\ndocs\/architecture-boundaries.md<\/code> only via file-pattern rules and prompting, a dedicated architecture Skill could just as well take on this job and kick in on structural changes. The role separation remains decisive \u2013 the Skill describes the workflow and points to the docs as the binding source; it does not become the source of truth itself. The rule therefore still lives in docs\/architecture-boundaries.md<\/code>, and the Skill merely points to it.<\/p>\n.cursor\/mcp.json<\/code>:<\/p>\n{\n "mcpServers": {\n "angular-cli": {\n "command": "npx",\n "args": ["-y", "@angular\/cli", "mcp"]\n }\n }\n}<\/code><\/pre>\nBringing Architecture Checks into the AI Feedback Loop via Hooks<\/h2>\n
.cursor\/hooks.json<\/code>:<\/p>\n{\n "version": 1,\n "hooks": {\n "stop": [\n {\n "command": "node scripts\/ci-checks.mjs",\n "timeout": 600,\n "loop_limit": 3\n }\n ]\n }\n}<\/code><\/pre>\nscripts\/ci-checks.mjs<\/code> is deliberately kept simple and runs the three relevant steps one after another:<\/p>\nimport { execSync } from 'node:child_process';\n\nconst steps = [\n 'npx ng lint flights',\n 'npx ng test flights --configuration ci',\n 'npx ng build flights',\n];\n\nfor (const step of steps) {\n console.log(`\\n[ci-checks] ${step}`);\n execSync(step, { stdio: 'inherit' });\n}<\/code><\/pre>\nloop_limit<\/code> of three limits how often this loop repeats, so that the agent doesn't circle endlessly.<\/p>\nModern Angular<\/h3>\n
![\"Modern](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/01\/cover-klein.png\")
<\/a><\/p>\nServing Cursor AI and Claude Code from a Single Source of Truth<\/h2>\n
CLAUDE.md<\/code>, Skills under .claude\/skills\/<\/code>, and MCP servers are configured in .mcp.json<\/code>.<\/p>\nCLAUDE.md<\/code> in the project root essentially consists only of a reference to AGENTS.md<\/code>:<\/p>\n@AGENTS.md<\/code><\/pre>\nsrc\/CLAUDE.md<\/code> points to the architecture documentation. So there is still only one authoritative source that all tools point to.<\/p>\nBefore changing application or library code here, read `docs\/architecture-boundaries.md` and apply the architecture rules.\n\nIf the change touches state management, also read `docs\/architecture-state-management.md` when it exists.\n\nDo not bypass documented domain boundaries. Prefer small, focused changes.<\/code><\/pre>\ndocs\/architecture-boundaries.md<\/code> when you make structural changes \u2013 for example to domains, layers, imports, shared code, public APIs, or Sheriff rules. Use docs\/architecture-state-management.md<\/code> when you create or change stores. This way not every detailed rule sits in the context permanently, but is pulled in for the matching task.<\/p>\nCLAUDE.md<\/code> and cursor.mdc<\/code>, respectively) and thus the AGENTS.md<\/code>, while the detailed docs\/<\/code> files are loaded only on demand.<\/p>\n![\"Context](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/ai-context-loading.svg\")
<\/p>\n.agents\/skills\/<\/code> to .claude\/skills\/<\/code> and .cursor\/mcp.json<\/code> to .mcp.json<\/code>.<\/p>\nDO_NOT_EDIT<\/code> files \u2013 one in the mirrored Skills folder and one for the MCP configuration. They point out unmistakably that changes here will be overwritten on the next sync and must instead be made in the respective source.<\/p>\nprepare<\/code> script (that is, after npm install<\/code>) and additionally triggered via a pre-commit hook as soon as one of the sources has changed. This way the copies stay up to date automatically, without anyone having to think about it.<\/p>\nExtending to GPT, Codex CLI, Google Antigravity, and Beyond<\/h2>\n
AGENTS.md<\/code> describes project-wide instructions, Skills often live in a dedicated Skills directory, and MCP servers are registered via tool-specific configuration files. The details, however, differ from tool to tool \u2013 for example with hooks, local instruction files, or the MCP configuration. For instance, Codex expects the MCP configuration in a TOML file (such as .codex\/config.toml<\/code>), while Antigravity uses a JSON format (such as mcp_config.json<\/code>).<\/p>\nAGENTS.md<\/code>, .agents\/skills\/<\/code>, and our MCP base configuration as central sources and let a small sync script generate the required target formats from them. When another tool is added, usually only this script has to be extended. Since the script is deliberately kept simple, this very adjustment is an excellent fit for AI-assisted coding: the agent can look up the documentation of the new tool, derive the required target format, and extend the sync script accordingly.<\/p>\nAI-assisted Coding in Action: Generating a New Feature<\/h2>\n
AirportClient<\/code>. In addition, we want to be able to select the airports from dropdown fields when maintaining flights.<\/p>\n![\"Architecture](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/arc01.png\")
<\/p>\nairports<\/code> and booking<\/code> each get their own store \u2013 and that is exactly right, because the features have different state. A filter in one feature should not affect the other. (If that were desired after all, we would have to reflect it in architecture-boundaries.md<\/code>.) Both stores, however, use the same AirportClient<\/code> in the data layer.<\/p>\narchitecture-boundaries.md<\/code>. In doing so, it incidentally solves one of the central challenges of Feature Slicing: the refactoring, that is, moving local code into more global areas once it actually becomes necessary.<\/p>\n![\"Architecture](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/arc02.png\")
<\/p>\nAirportClient<\/code> in the checkin<\/code> domain. Now domain boundaries are affected, and exactly then the agent has to ask. The agent confronts us with a question \u2013 and that is intentional. In architecture-boundaries.md<\/code> we specified that in exactly this case consultation is required, because cross-domain access is a deliberate architectural decision. Possible options are then, for example: move the code to shared<\/code>, publish it via a public API of the ticketing<\/code> domain, or cut the requirement differently.<\/p>\n![\"The](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/question-refactoring.png\")
<\/p>\nAirportClient<\/code> into the shared area, the result looks like above: both domains now access the shared code in shared<\/code>.<\/p>\n![\"Architecture](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/arc03.png\")
<\/p>\nAirportClient<\/code> stays in the ticketing<\/code> domain and is published via an api\/index.ts<\/code>. To this end, the agent adjusts the Sheriff configuration so that domain:checkin<\/code> gets access to domain:ticketing\/api<\/code> \u2013 but only to the selected, released elements there:<\/p>\n![\"Architecture](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/06\/api01.png\")
<\/p>\nRefining Rules and Skills Iteratively<\/h2>\n
Saved Prompts and Plan Mode<\/h2>\n
Custom Skills: Running an Architecture Review<\/h2>\n
.agents\/skills\/architecture-review\/SKILL.md<\/code><\/a> and is deliberately compact:<\/p>\n---\nname: architecture-review\ndescription: Review Angular code against the repository architecture rules in docs\/architecture-boundaries.md, including Sheriff boundaries, layering, feature slicing, shared code, and state management conventions.\n---\n\n# Review Angular Architecture\n\nUse this skill when reviewing Angular code for architectural quality.\n\nBefore reviewing, read:\n\n- `docs\/architecture-boundaries.md`\n- `AGENTS.md` if present\n- `docs\/architecture-state-management.md` if state management is involved\n- the relevant Sheriff configuration\n- the changed files and their imports\n\nTreat `docs\/architecture-boundaries.md` as the source of truth.\n...<\/code><\/pre>\ndocs\/architecture-boundaries.md<\/code> the authoritative source, prescribes a clear review process, and describes the desired output format \u2013 from the summary, through findings by severity, to the concrete fix. This turns a vague "have a look" into a reproducible review.<\/p>\n