Instruction Files as Architecture Documents

← Back to Blog & Articles

An instruction file tells an agent how your Angular workspace works. Written well, it doubles as living architecture documentation.

What to put in it

  • Commands to build, serve, test, and lint.
  • Workspace layout: apps, libraries, and their responsibilities.
  • Conventions: standalone components, signals for state, file naming, and style.
  • Boundaries: which libraries may import which others.
  • Prohibitions: generated files, protected configuration, and risky commands.

Be concrete

"Use signals for local component state and do not use any" is clear. "Follow best practices" is not. Add a short example for patterns that are easy to get wrong.

Keep it small

The file shares the context window with the code. Concise guidance is more likely to be followed. Link to longer documents rather than pasting them.

Make rules checkable

Where possible, enforce rules with lint configuration or tests so violations fail fast. The file explains the rule, and tooling enforces it.

Treat it like code

Review changes, keep it in version control, and update it when conventions change. Stale instructions mislead agents and new teammates alike.

Takeaway

If the file is useful to a new engineer, it will usually be useful to an agent as well.

Continue with the book

Explore the full treatment, worked examples, and exercises in Local AI Agents for Angular Teams.


Adapted from Local AI Agents for Angular Teams, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

Scroll to Top