Rules, Configuration & Context Hygiene

Velocity projects use rule and configuration files to encode standards, constraints, and common pitfalls for AI.

You can think of these files as a project-level "system prompt" that both humans and tools read.

What Lives in Rules/Config

Each project should define, in one or a few well-known files:

• Tech stack and boundaries
  Frameworks, languages, target runtimes, and anything that is explicitly in or out of scope.
• Coding standards
  Style rules, preferred patterns, and forbidden constructs.
• Testing expectations
  Minimum testing requirements for different change types (e.g., new endpoints vs. copy updates).
• Directory and module structure
  Where features, components, and services are expected to live.
• Known pitfalls
  Things the AI frequently gets wrong in this codebase and how to avoid them.

These rules should be machine-readable enough that your AI-native IDE can load and respect them. The exact format depends on the tools in use (for example, .cursorrules in Cursor), but the content is conceptually the same.

Ownership and Maintenance

• A pod’s technical lead or AI delivery architect owns the rules over time.
• Engineers are encouraged to propose updates when they see repeated mistakes from AI or humans.
• Changes to rules should be reviewed like code: small, justified, and traceable.

When you notice recurring issues (e.g., wrong library usage, incorrect patterns, unsafe defaults), update the rules/config to teach the system, not just the individual engineer.

Context Hygiene

Configuration is only half of the story. Engineers must also keep context clean in daily use:

• Avoid using a single, endless chat for every task.
• Start fresh contexts for major features or refactors.
• Attach the right files, specs, and rules to each interaction.

The combination of clear rules and disciplined context management is what makes AI assistance predictable instead of chaotic.