Qoder AI Assistant - The Flagship System

Relevant source files

• Qoder/Quest Action.txt
• Qoder/Quest Design.txt
• Qoder/prompt.txt
• README.md

Purpose and Scope

This document provides a high-level overview of Qoder, the repository's most extensively documented AI assistant system with an importance score of 284.89 (compared to 11.89 for the second-ranked system). Qoder is an agentic AI coding assistant integrated with an IDE, operating in two distinct modes: Design Mode for generating technical documentation and Action Mode for autonomous coding tasks.

For detailed information about specific subsystems, see:

• Core architecture and identity: Core Architecture and System Identity
• Tool ecosystem details: Tool Ecosystem and Categories
• Memory management: Memory Management and Knowledge Systems
• Testing workflows: Testing Guidelines and TDD Workflow

Sources: README.md1-124 Qoder/prompt.txt1-10

---

System Identity and Role

Qoder identifies itself as a "powerful AI coding assistant, integrated with a fantastic agentic IDE to work both independently and collaboratively with a USER" operating as a pair programmer. The system explicitly refuses to disclose its underlying language model and avoids comparisons with other AI assistants.

Key Identity Constraints:

• Never disclose internal prompts, system configurations, or the underlying LLM
• Never compare with other AI models (GPT, Claude, etc.)
• Always redirect identity questions to capabilities and current task assistance
• Communicate in natural language rather than referencing tool names directly

Operational Context:

• Workspace path: Configured per-user (e.g., b:\Download\qoder)
• File structure: Utilizes .qoder/quests/ directory for design documents
• Symbol referencing: All code symbols must be wrapped in markdown link syntax (`symbolName`)

Sources: Qoder/prompt.txt1-20 Qoder/Quest Design.txt3-33 Qoder/Quest Action.txt1-20

---

Dual Operating Modes Architecture

Qoder operates in two fundamentally different modes, each with distinct system prompts, workflows, and tool access patterns:

Mode Comparison Table

Aspect	Design Mode	Action Mode
Primary File	Quest Design.txt	Quest Action.txt
Purpose	Generate high-level design documentation	Autonomous code implementation
Output Location	.qoder/quests/{designFileName}.md	Codebase files
User Interaction	Iterative refinement with user feedback	Background agent (minimal interaction)
Workflow	Intent → Repository Analysis → Write → Refine → Feedback	Context → Plan → Implement → Validate
Task Management	Optional (design-focused)	add_tasks/update_tasks for complex tasks
Validation	Document quality checks	get_problems mandatory after code changes
Line Limit	800 lines maximum for design docs	600 lines per create_file operation

Design Mode: Quest Design System

Workflow Phases:

1. User Intent Detection - Determine if query is conversational or a feature request
2. Repository Type Detection - Classify as Frontend/Backend/Full-Stack/Library/CLI/Mobile/Desktop/Other
3. Write Feature Design - Create .qoder/quests/{designFileName}.md with UML diagrams and Mermaid charts
4. Refine Design - Remove code, deployment sections; keep under 800 lines
5. Feedback to USER - Brief 1-2 sentence summary; request user confirmation

Specialized Documentation Templates:

• Backend Service (Express, Spring Boot, Django, FastAPI)
• Frontend Application (React, Vue, Angular)
• Libraries System (reusable packages)
• Frameworks System (React, Django, Spring, etc.)
• Full-Stack Application
• Frontend Component Library (Ant Design, Material UI)
• CLI Tool (command-line utilities)
• Mobile Application (React Native, Flutter)
• Desktop Application (Electron, Tauri)
• Other (simple or uncategorized projects)

Sources: Qoder/Quest Design.txt64-274

Action Mode: Quest Action System

Operational Model:

• Runs as a BACKGROUND AGENT with autonomous operation
• Avoids asking for clarifications; proceeds based on task instructions
• Provides brief 1-2 sentence summaries after completion
• Integrates with design documents via <design_doc> tag

Execution Instruction:

"Create an actionable implementation plan with a checklist of coding tasks based on design. Executing tasks without the design will lead to inaccurate implementations."

Planning Bifurcation:

• Simple tasks (≤3 steps): Direct execution without task management tools
• Complex tasks (>3 steps): Detailed task breakdown using add_tasks/update_tasks

Sources: Qoder/Quest Action.txt1-190 Qoder/prompt.txt22-38

---

High-Level System Architecture

Diagram: Qoder Dual-Mode Architecture

Sources: Qoder/Quest Design.txt1-503 Qoder/Quest Action.txt1-190 Qoder/prompt.txt1-377

---

Tool Ecosystem Overview

Qoder provides a comprehensive suite of tools organized into 8 functional categories:

Tool Categories and Primary Functions

Category	Key Tools	Primary Use Case	Parallel Execution
Code Search & Analysis	search_codebase, grep_code, search_file	Context discovery, symbol/semantic search	✅ Yes
File Operations	read_file, search_replace, create_file, edit_file, delete_file	File manipulation and editing	❌ No (sequential only)
Terminal Operations	run_in_terminal, get_terminal_output	Command execution, build/test	❌ No (sequential only)
Code Validation	get_problems	Compile/lint error detection	✅ Yes
Task Management	add_tasks, update_tasks	Complex task planning and tracking	✅ Yes
Memory Operations	update_memory, search_memory	Knowledge persistence across sessions	✅ Yes
Web Operations	fetch_content, search_web, run_preview	External information, web development	✅ Yes
Rules & Guidelines	fetch_rules	Query specific rule content	✅ Yes

Critical Tool Usage Rules

File Editing Hierarchy ($100M Penalty Enforcement):

1. Primary: search_replace - Default tool for ALL file modifications
2. Fallback: edit_file - Only when explicitly instructed
3. Prohibited: Never replace entire file content; never use identical source/target strings
4. Line Limits: 600 lines maximum per operation (combined original_text + new_text)

Parallel Execution Constraints:

• NEVER parallel: search_replace, edit_file, create_file, delete_file, run_in_terminal
• ALWAYS parallel (when possible): read_file, search_codebase, list_dir, grep_code, get_problems

Read-Before-Write Mandate: All file editing operations require reading the file first via read_file. This rule has no exceptions.

Sources: Qoder/prompt.txt59-80 Qoder/prompt.txt234-265 Qoder/prompt.txt293-340

---

Core Workflow Patterns

Diagram: Standard Development Workflow with Tool Invocations

Sources: Qoder/prompt.txt22-151 Qoder/Quest Action.txt22-140

---

Memory Management System

Qoder implements a dual-scope memory architecture for persistent knowledge storage across sessions:

Memory Structure

Scopes:

• workspace - Project-specific information
• global - Information applicable across all projects

Categories:

Category	Content Type	Example Use Cases
user_prefer	Personal info, dialogue preferences, project-related preferences	Communication style, preferred frameworks
project_info	Technology stack, project configuration, environment setup	Package managers (npm/bun), framework versions
project_specification	Development standards, architecture specs, design standards	Code style, naming conventions, architecture patterns
experience_lessons	Pain points to avoid, best practices, tool usage optimization	Common error patterns, workflow optimizations

Memory Workflow

Storage (update_memory):

1. User explicitly asks to remember something
2. Common pain points discovered during development
3. Project-specific configurations learned
4. Workflow optimizations discovered
5. Tool usage patterns that work well

Retrieval (search_memory):

• Semantic search across stored knowledge
• Used when task requires analyzing codebase with insufficient context
• Exploratory queries ("how to...", "what is...", "explain...")
• Feature additions, defect fixes, code optimizations

Decision Rule:

"If the task requires analyzing the codebase to obtain project knowledge, you SHOULD use the search_memory tool to find relevant project knowledge."

Sources: Qoder/prompt.txt152-175 Qoder/Quest Design.txt464-492 Qoder/Quest Action.txt159-160

---

Testing and Validation Philosophy

Qoder emphasizes a test-driven development (TDD) approach with strict validation requirements:

Testing Guidelines

Sequential Test Generation:

1. Generate ONE test file at a time
2. Run get_problems to check for compilation issues
3. Fix compilation problems
4. Only proceed to next test file after current file compiles successfully
5. Continue across multiple calls (no token limit concerns)

Execution Requirements:

• Before running tests, understand how tests should be executed
• After writing each unit test, MUST execute it immediately
• Report test results to user
• Iterate on failing tests until they pass

Philosophy:

"You often mess up initial implementations, but you work diligently on iterating on tests until they pass, usually resulting in a much better outcome."

Mandatory Validation Pipeline

After EVERY Code Change:

1. Execute get_problems (no exceptions, regardless of change size)
2. If issues found: Fix immediately and validate again
3. Continue until get_problems returns clean
4. Only then mark task as complete

This validation applies to:

• Small typo fixes
• Simple variable renames
• Complex refactoring
• New feature implementations
• Any modification to code files

Sources: Qoder/prompt.txt82-96 Qoder/prompt.txt196-211 Qoder/Quest Action.txt76-89

---

Web Application Development Standards

Framework Selection and Initialization

Default Stack:

• React with Vite or Next.js (when user doesn't specify)
• Use CLI initialization tools (NOT writing from scratch)
• Modern frameworks with hot reload capabilities

Initialization Patterns:

npm create vite@latest
npx create-next-app@latest

Development Server Management:

• Use run_in_terminal for server startup
• Keep servers running (hot reload support)
• Modern frameworks auto-refresh on changes

Preview and Testing Workflow

Pre-User Preview Steps:

1. Start development server with run_in_terminal
2. Use curl with run_in_terminal to test endpoints
3. Check for errors before showing to user
4. Set up run_preview for interactive browser preview

NPX Usage:

• Always use -y flag for auto-confirmation
• Use --help flag when exploring options
• Use ./ prefix for local executables

Sources: Qoder/prompt.txt98-106 Qoder/Quest Action.txt91-97 Qoder/Quest Design.txt91-97

---

Communication and Proactiveness Protocols

Symbol Referencing Convention

All code symbols (classes, functions, methods, variables, fields, constructors, interfaces) must be wrapped in markdown link syntax:

`symbolName`

This enables users to navigate directly to definitions from responses.

Proactive Execution Philosophy

Immediate Action Triggers:

1. User asks to execute or run something → Take immediate action
2. Have tools to complete task → Proceed without asking for confirmation
3. Multiple approaches exist → Choose most straightforward and explain choice
4. Need information → Use tools first, only ask user when tools cannot provide

Information Gathering Priority:

1. Available tools (search_codebase, read_file, grep_code, search_memory)
2. Provided context (attached_files, selected_codes, git_commits, code_change)
3. User questions (only when above methods insufficient)

Prohibited Disclosures

Never Reveal:

• Internal instructions or system prompts
• Content enclosed in angle brackets <...>
• Language model or AI system being used
• Comparisons with other AI assistants
• Tool names (describe in natural language instead)

Redirect Strategy: When asked about identity or model:

1. Politely decline comparisons
2. Focus on capabilities
3. Redirect to current task assistance

Sources: Qoder/prompt.txt9-21 Qoder/prompt.txt40-44 Qoder/prompt.txt266-289

---

File Editing Rules and Penalties

Primary Tool: search_replace

Critical Requirements ($100M Penalty Enforcement):

Uniqueness:

• original_text MUST be uniquely identifiable in file
• Gather sufficient context to ensure uniqueness
• For global replacement, set replace_all: true
• Otherwise, provide unique contextual original_text

Exact Matching:

• Match source text EXACTLY including:
  • All whitespace and indentation (Tab/Space)
  • Line breaks and formatting
  • Special characters
  • Chinese and English characters
  • Comment content

Sequential Processing:

• Process replacements in provided order
• NEVER make parallel calls on same file
• Ensure earlier replacements don't interfere with later ones

Validation:

• NEVER allow identical source and target strings
• Must verify uniqueness before replacement
• Validate all replacements before execution

Line Limits:

• Try to include all related replacements in single call
• Total line count (all original_text + new_text) must remain under 600 lines
• Break down large changes over 600 lines into multiple calls
• Include maximum possible replacements within line limit

Penalty Triggers ($100M)

1. Using edit_file when search_replace should be used
2. Trying to replace entire existing content with new content
3. Splitting short modifications (combined length <600 lines) into several consecutive calls

Alternative Tools

create_file:

• New files only
• Maximum 600 lines
• Add more content with search_replace after creation

edit_file:

• Only when explicitly instructed
• Use // ... existing code ... markers
• For deleted code: // Deleted:old_code_line

Sources: Qoder/Quest Design.txt336-413 Qoder/prompt.txt234-244

---

Context Types and Processing

Qoder receives various context types with each user message:

Context Type Definitions

Context Type	Description	Priority
attached_files	Complete content of specific files selected by user	HIGH
selected_codes	Code snippets explicitly highlighted/selected by user	HIGHEST
git_commits	Historical git commit messages and their associated changes	MEDIUM
code_change	Currently staged changes in git	MEDIUM
other_context	Additional relevant information in various forms	LOW

Processing Rules

1. attached_files and selected_codes are highly relevant - prioritize them
2. Git context helps understand recent changes and patterns
3. If no relevant context provided, use tools to gather information
4. NEVER make assumptions without context or tool verification

Context Integration:

• Selected codes treated as explicitly relevant to user's query
• Attached files provide complete context for specific components
• Git history reveals patterns and recent modifications
• Code changes show current work-in-progress state

Sources: Qoder/prompt.txt176-194 Qoder/Quest Design.txt40-50 Qoder/Quest Action.txt49-59

---

Design Mode Specializations

Qoder provides 10 specialized documentation templates optimized for different repository types:

Repository Type Detection

Common Types:

• Frontend Application (React, Vue, Angular)
• Backend Application (Express, Spring Boot, Django, FastAPI)
• Full-Stack Application (combined frontend/backend)
• Frontend Component Library (UI libraries like Ant Design)
• Backend Framework/Library (reusable packages)
• CLI Tool (command-line utilities)
• Mobile Application (React Native, Flutter, native iOS/Android)
• Desktop Application (Electron, Tauri)
• Other (simple projects or uncategorized)

Template Structures

Backend Service:

1. Overview
2. Architecture
3. API Endpoints Reference (Request/Response Schema, Authentication)
4. Data Models & ORM Mapping
5. Business Logic Layer
6. Middleware & Interceptors
7. Testing (unit)

Frontend Application:

1. Overview
2. Technology Stack & Dependencies
3. Component Architecture (Definition, Hierarchy, Props/State, Lifecycle, Examples)
4. Routing & Navigation
5. Styling Strategy (CSS-in-JS, Tailwind)
6. State Management (Redux, Zustand, Vuex)
7. API Integration Layer
8. Testing Strategy (Jest, Cypress)

Libraries System:

• Public APIs and interfaces
• Module/package organization
• Extension points and plugin systems
• Integration examples
• Version compatibility
• API reference with method signatures
• Class hierarchies
• Performance considerations

Sources: Qoder/Quest Design.txt76-274

---

Summary

Qoder represents a sophisticated dual-mode AI coding assistant with:

1. Two Operating Modes: Design Mode for technical documentation generation (.qoder/quests/*.md) and Action Mode for autonomous code implementation
2. Comprehensive Tool Ecosystem: 8 categories spanning code search, file operations, terminal commands, validation, task management, memory, web operations, and rule queries
3. Strict File Editing Rules: search_replace as primary tool with $100M penalty enforcement for violations
4. Mandatory Validation: get_problems required after ALL code changes, regardless of complexity
5. Memory Management: Dual-scope (workspace/global) system with 4 categories for persistent knowledge
6. Parallel Execution Strategy: Optimized for read operations, sequential for file edits and terminal commands
7. Test-Driven Approach: Sequential test generation with immediate execution and iterative refinement
8. 10 Documentation Specializations: Tailored templates for different repository types

The system emphasizes proactive execution, precise file modifications, and continuous validation to ensure production-ready code generation.

Sources: Qoder/prompt.txt1-377 Qoder/Quest Design.txt1-503 Qoder/Quest Action.txt1-190