AzentAzent

Custom Skills

Skills are reusable instructions that teach Azent about your project's specific patterns, conventions, and workflows. They are injected into the agent's system prompt on every run.

How skills work

Each skill is a Markdown document stored in your workspace. When the agent starts a run, all skills are concatenated and added to the prompt. This means the agent always has access to your custom instructions, without you having to repeat them in every comment.

Default skill

Every workspace starts with a built-in azent-default skill that covers the agent's standard operating procedures:

  • •How to create branches, implement features, and open PRs
  • •How to review PRs and leave actionable comments
  • •How to fix PR review feedback
  • •How to run and respond to validation pipelines
  • •How to break down work items
  • •General best practices (read before writing, minimal changes, deduplication)

Skills page

The Dashboard Skills page lists every skill in the workspace. Skills are global — every run sees every active skill, so keep them short and focused.

Skills page
  • •Each skill has an ID (used to reference it), a name, and free-form Markdown content.
  • •Click a row to expand it and edit the content inline. Use New skill to add one; the trash icon deletes it.

Creating a custom skill

In the Dashboard, go to Skills and click Create Skill. Each skill has an ID and a Markdown body with frontmatter:

---

name: "Angular conventions"

description: "Frontend coding standards for our Angular project"

---

# Angular conventions

- Use standalone components, not NgModules

- Use signals for state management

- Place reusable components in src/app/components/

- Place page-level components in src/app/pages/

- Use Tailwind CSS for styling, no component SCSS

Skill ID rules

  • •Only lowercase letters, digits, and hyphens
  • •Maximum 64 characters
  • •Examples: angular-conventions, api-patterns, testing-guidelines

Best practices

  • •Keep skills focused — one skill per topic (e.g. one for coding conventions, another for deployment patterns)
  • •Be specific — "use inject() instead of constructor injection" is better than "follow best practices"
  • •Include examples when the pattern is non-obvious
  • •Update skills as your codebase evolves — stale instructions can mislead the agent
  • •Don't duplicate information that's already in the codebase (e.g. linter rules) — the agent reads the code too