Skip to content

References Folder

The references/ folder contains stable engineering principles that guide your AI agent’s behavior. These are not task-specific requirements - they are durable rules that stay constant across tasks.

References are the “how to think” layer. They tell the agent what good engineering looks like: how to route context, how to write tests, how to handle security, how to style responses, and what decisions remain human-owned.

FilePurpose
README.mdOverview of available references
api-standards.mdAPI design principles and conventions
architecture-principles.mdArchitecture decision guidance
backend-api-standards.mdBackend API implementation standards
backend-principles.mdBackend engineering principles
context-budget.mdContext size management rules
context-principles.mdContext routing and escalation rules
database-standards.mdDatabase design and migration standards
engineering-principles.mdGeneral engineering principles
frontend-principles.mdFrontend engineering principles
response-style.mdResponse formatting and style rules
security-principles.mdSecurity review and implementation rules
testing-principles.mdTest design and validation rules
workflow-modes.mdFull vs lite mode routing rules
Read ThisWhen
ReferencesAt the start of a new task type, when the agent needs general engineering guidance
Task fileFor the specific objective, acceptance criteria, and affected files
PRDWhen the task scope or requirements are unclear
Architecture/ADRWhen technical direction or decisions are unclear
CodeWhen implementing or debugging

Do not dump every reference into context by default. Only read the references relevant to the current task.

Purpose: Lists available references and explains their role in the workflow kit.

When to read: When exploring what references are available.

Related skills/workflows: None - informational only.

Human-owned decisions: None.

Purpose: API design principles including naming, versioning, error handling, and response formats.

When to read: When designing or reviewing API endpoints.

Related skills/workflows: api-contract-design, backend-api-development

Human-owned decisions: API versioning strategy, public vs internal API boundaries.

Purpose: Guidance on architectural decisions, component boundaries, and system design.

When to read: When proposing or reviewing architecture changes.

Related skills/workflows: architecture-design, adr-generator

Human-owned decisions: Technology choices, system boundaries, deployment architecture.

Purpose: Backend-specific API implementation standards including validation, authentication, and error responses.

When to read: When implementing backend API endpoints.

Related skills/workflows: backend-api-development, api-contract-design

Human-owned decisions: Authentication provider, rate limiting strategy, caching approach.

Purpose: General backend engineering principles including error handling, logging, and performance.

When to read: When implementing backend services or infrastructure.

Related skills/workflows: backend-api-development, database-migration

Human-owned decisions: Infrastructure choices, scaling strategy, monitoring approach.

Purpose: Rules for managing context size and preventing context overflow.

When to read: When the agent has too many files open or context is getting large.

Related skills/workflows: context-management, all implementation tasks

Human-owned decisions: None - this is a routing rule, not a product decision.

Purpose: Context routing rules - what to read, when to escalate, how to stay focused.

When to read: At the start of any implementation task.

Related skills/workflows: context-management, all implementation tasks

Human-owned decisions: None - this is a routing rule, not a product decision.

Purpose: Database design standards including schema patterns, naming conventions, and migration safety.

When to read: When designing schemas or planning migrations.

Related skills/workflows: database-migration

Human-owned decisions: Database technology choice, schema ownership, data retention policy.

Purpose: General engineering principles including code quality, maintainability, and simplicity.

When to read: When implementing any code change.

Related skills/workflows: implementation-planner, task-implementation

Human-owned decisions: Code style preferences, tooling choices, refactoring priorities.

Purpose: Frontend engineering principles including component design, state management, and accessibility.

When to read: When implementing frontend features.

Related skills/workflows: ui-ux-design, task-implementation

Human-owned decisions: UI framework choice, component library, design system.

Purpose: Response formatting rules for different contexts (formal vs concise).

When to read: When the agent needs to adjust response style based on integration settings.

Related skills/workflows: caveman integration, all operational communication

Human-owned decisions: None - style rules adapt to integration settings.

Purpose: Security review principles including authentication, authorization, secrets, and input validation.

When to read: When reviewing security-sensitive code or preparing for release.

Related skills/workflows: security-review

Human-owned decisions: Security policy, compliance requirements, threat model.

Purpose: Test design principles including what to test, how to structure tests, and validation evidence.

When to read: When designing tests or reviewing test coverage.

Related skills/workflows: testing, task-implementation

Human-owned decisions: Test coverage targets, testing strategy, quality gates.

Purpose: Routing rules for full mode vs lite mode behavior.

When to read: When the agent needs to adapt behavior based on project configuration.

Related skills/workflows: context-management, all skills

Human-owned decisions: None - mode is determined by project config.

Use this order for most requests:

  1. .aios/config.json for mode, docsRoot, and projectShape
  2. AGENTS.md for agent behavior
  3. <docsRoot>/context/context-map.md for where project knowledge lives
  4. The active PRD, ADR, task, or review document
  5. The relevant reference files for the current task type
  6. Only then inspect source files that need to change

Do not read all references at once. Read only what the current task requires.