Complete Guide to Qoder’s .qoder Configuration Directory

What is the .qoder directory?

The .qoder folder is the project‑level configuration directory for Qoder (formerly CodiumAI), an AI‑assisted programming tool. It supplies two kinds of context to the AI: manually defined rules (the "law") and an automatically generated repowiki knowledge base (the "encyclopedia").

Directory layout

.qoder/
├── rules/                 ← manually maintained rule files
│   ├── product.md         ← product/business background
│   ├── structure.md       ← project structure and conventions
│   └── tech.md            ← technology stack and toolchain
└── repowiki/              ← AI‑generated project knowledge base
    └── {lang}/            ← language partitions (e.g., zh, en)
        ├── content/       ← structured documents (quick‑start, API, business logic, data model, architecture, core modules, development guide, troubleshooting)
        └── meta/          ← repowiki‑metadata.json (code‑snippet index)

rules/ directory details

Purpose

Equivalent to Kiro’s .kiro/steering/, Cursor’s .cursorrules, and Copilot’s .github/copilot-instructions.md, the rules/ folder tells the AI what to do by providing project‑specific rules and background.

File categories

product.md

– business background and product positioning (e.g., “what the product is, who it serves, core business domain”). structure.md – code‑structure and architectural conventions (directory layout, package naming, layering, URL standards). tech.md – technology stack and toolchain (language version, frameworks, build system, data layer, messaging, testing, CI/CD, common commands).

Activation

When the Qodo plugin starts, it automatically scans all .md files under .qoder/rules/ and injects their content into the AI conversation context—no manual import required.

repowiki/ directory details

Purpose

Qodo’s repository‑knowledge‑base feature automatically scans source code, extracts structural information, and produces Markdown documentation, effectively giving the AI a full “reading‑comprehension” of the project.

Workflow

Analyze entry classes, configuration files, API interfaces, service layer, entity classes, etc.

Generate Markdown documents grouped by theme.

Annotate each document with source file path and line range for traceability.

Store a meta/repowiki-metadata.json index of code snippets for incremental updates.

metadata.json example

{
  "code_snippets": [
    {
      "id": "uniqueID",
      "path": "src/main/java/com/example/Application.java",
      "line_range": "1-29",
      "gmt_create": "2026-06-08T15:53:26",
      "gmt_modified": "2026-06-08T15:53:26"
    }
  ]
}

The index enables bidirectional links between documentation and code, incremental regeneration after changes, and avoidance of duplicate analysis.

Example: a generic Spring Boot project

product.md

# Product Overview

This workspace contains a **SaaS multi‑tenant order management platform** — a suite of Java microservices for e‑commerce order lifecycle management.

## Core Business Domains
- **Order**: creation, modification, cancellation, lifecycle tracking
- **Inventory**: real‑time stock availability, reservation, release
- **Payment**: gateway integration, refund processing
- **Shipping**: logistics provider integration, tracking, delivery confirmation
- **Customer**: profiles, addresses, preferences

## Key Capabilities
- Multi‑tenant data isolation via schema‑per‑tenant strategy
- Event‑driven architecture with eventual consistency
- Real‑time inventory synchronization across channels
- Distributed transaction management (Saga pattern)
- Integration with third‑party logistics and payment providers

## Platform Context
- Target users: mid‑size e‑commerce merchants
- Deployment: Kubernetes on AWS EKS
- Traffic: ~5000 orders/minute at peak

structure.md

# Project Structure

## Workspace Layout
This is a multi‑module Maven project with domain‑driven package structure.

| Module            | Description                | Package                |
|-------------------|----------------------------|------------------------|
| order-service     | Order lifecycle management | `com.example.order`    |
| inventory-service | Stock management           | `com.example.inventory`|
| payment-service   | Payment processing         | `com.example.payment` |
| shipping-service  | Logistics integration      | `com.example.shipping`|
| common-lib        | Shared utilities and DTOs  | `com.example.common` |

## Service Internal Structure
(omitted for brevity)

tech.md

# Tech Stack

## Language & Runtime
- **Java 17** (LTS)
- **Lombok** (`@Data`, `@Builder`, `@Slf4j`, `@RequiredArgsConstructor`)

## Frameworks
- **Spring Boot 3.2.x**
- **Spring Cloud 2023.x** with Alibaba Nacos for discovery and config
- **Spring Cloud OpenFeign** for inter‑service HTTP calls
- **Spring Cloud Gateway** as API gateway

## Build System
- **Maven** with multi‑module structure; parent POM manages dependency versions via BOM

## Data Layer
- **MySQL 8.0** as primary database
- **MyBatis‑Plus** for ORM
- **Flyway** for migrations
- **Spring Data Redis** for caching and distributed locks
- **ShardingSphere** for read‑write splitting

## Messaging
- **Apache Kafka** for event‑driven communication
- **RocketMQ** for transactional messages

## API Documentation
- **SpringDoc OpenAPI 3** with Knife4j UI

## Testing
- **JUnit 5** (Jupiter)
- **Mockito** + **MockMvc**
- **Testcontainers** for integration tests

## Code Quality
- **Checkstyle** with Google style
- **SpotBugs** for static analysis
- **JaCoCo** for coverage (minimum 70%)

## CI/CD
- **GitHub Actions** (build → test → sonar → deploy)
- **Docker** + **Kubernetes** for containerized deployment
- **Helm** charts for environment configuration

## Common Commands
```bash
# Build all modules
mvn clean install -DskipTests

# Run a specific service
mvn spring-boot:run -pl order-service

# Run tests
mvn test

# Run checkstyle
mvn checkstyle:check

# Generate API docs
mvn springdoc-openapi:generate
```

Comparison with other AI‑tool configurations

Rule files : Qodo uses rules/*.md; Kiro uses steering/*.md; Copilot uses .github/copilot-instructions.md; Cursor uses .cursorrules.

Knowledge base : Only Qodo provides an auto‑generated repowiki/; the others have none.

Runtime interception : Qodo – none; Kiro – hooks/*.kiro.hook; Copilot – none; Cursor – none.

File reference syntax : Qodo – none; Kiro – #[[file:]]; Cursor – @file.

Activation method : Qodo – plugin auto‑load; Kiro – auto/manual/conditional; Copilot – auto; Cursor – auto.

Multi‑file rule support : Qodo and Kiro support; Copilot and Cursor support only single‑file rules.

Best practices

Writing rules/ files

Keep them concise and focused on a single topic.

Use tables and lists; AI parses structured content more accurately than plain text.

Provide positive and negative examples to tell the AI what to do and what to avoid.

Update them whenever the tech stack or architecture changes.

Maintaining repowiki/

Trigger regeneration regularly to keep documentation in sync with code.

Commit generated docs to Git for team reference.

If documentation is incorrect, fix the source code and regenerate (do not edit the generated files directly).

Cross‑tool rule reuse

You can treat the content of rules/ as a single source of truth and copy it to other tools:

# Merge .qoder/rules/* into Copilot instructions
cat .qoder/rules/product.md .qoder/rules/structure.md .qoder/rules/tech.md \
  > .github/copilot-instructions.md

# Copy to Cursor
cp .github/copilot-instructions.md .cursorrules

Conclusion

The rules folder acts as the "law" that constrains AI behavior, while the repowiki folder serves as the "encyclopedia" that supplies background knowledge. Together they enable the AI to generate code that truly matches the project's reality.