VyreVYRE

Rules

Rules are persistent instructions that are automatically included in every agent session. They let you define coding standards, project conventions, and behavioral constraints without repeating yourself in every prompt.

Think of rules as your project's CONTRIBUTING.md for the AI — a set of norms it should always follow without being told.

Types of rules

Project Rules

Stored in .vyre/rules/ inside your repository. Apply only to agents working on that specific project. Committed to git so the whole team shares them.

Global Rules

Stored in your Vyre settings and apply to every project. Use these for personal preferences like preferred variable naming or comment style.

URL Rules

Point to a URL and Vyre will fetch the content and inject it as a rule. Useful for linking to your team's internal wiki or style guide.

File Rules

Reference any file in your project as a rule. Vyre reads it fresh on each session, so it always uses the latest version.

Project rules

Create project rules by adding markdown files to .vyre/rules/ in your repository:

code
.vyre/
  rules/
    coding-style.md
    testing.md
    architecture.md

Each file is a separate rule. Vyre loads all rules from this directory at the start of every agent session.

Commit your .vyre/rules/ directory to git. This ensures every developer on your team benefits from the same rules automatically.

Global rules

Set global rules in Settings → Rules → Global Rules. These apply across all your projects.

markdown
# My Global Rules

Always use TypeScript.
Prefer functional components over class components.
Write descriptive variable names — never use single letters except for loop indices.
Always add JSDoc comments to exported functions.

Rule syntax

Rules are written in plain markdown. No special syntax required. A few conventions that work well:

  • Use # headings to organize rules into sections.
  • Use bullet lists for individual constraints.
  • Be specific and concrete — "use 2-space indentation" not "follow good formatting."
  • Include examples using code blocks.
markdown
# API Conventions

- All API routes live in `src/app/api/`
- Use Zod schemas for all request/response validation
- Return errors as `{ error: string, code: string }` — never throw

# Component Conventions

- Component files use PascalCase: `UserProfile.tsx`
- Always co-locate component tests: `UserProfile.test.tsx`
- Use Tailwind for styling. Do not write raw CSS unless there's no Tailwind equivalent.

Example rules

Testing standards
markdown
# Testing

- Write unit tests for all utility functions
- Use React Testing Library for component tests — no Enzyme
- Mock external API calls in tests — never hit real endpoints
- Test descriptions use the format: "should [behavior] when [condition]"
- Aim for 80% coverage on critical paths
Git commit standards
markdown
# Git Commits

- Use conventional commits: feat, fix, chore, refactor, docs, test
- Subject line: imperative mood, no period, under 72 chars
- Reference Jira tickets: "feat: add user auth (#PROJ-123)"
- Never commit .env files or secrets
Error handling
markdown
# Error Handling

- Never use generic catch-all error handlers
- Always log errors with context: who was the user, what were they doing
- User-facing errors must be friendly: no stack traces in the UI
- All async operations must handle both success and failure cases
Previous
Plugins
Customize
Next
Skills
Customize