Prompt Pipeline

Every user message runs through this pipeline before it reaches the LLM. The extension classifies the question, generates search terms via a secondary LLM, auto-gathers relevant code, budgets it against the active model’s context window, and assembles the final prompt.

Overview

sequenceDiagram participant User participant QC as Classifier participant ST as Search-term generator<br/>(SecondaryLLMService) participant AG as Auto-gather<br/>(AST + Vector) participant SC as SmartContextSelector participant PB as Prompt assembler participant LLM User->>QC: "How does auth work?" QC->>QC: Classify (categories, isCodebase) QC->>ST: Ask for 3–5 search terms ST-->>AG: ["authentication", "auth", "login", "jwt"] AG->>AG: Tree-sitter AST scan (top 5) AG->>AG: Vector DB semantic search AG-->>SC: Auto-gathered snippets SC->>SC: Score, sort, pack within budget SC-->>PB: Selected snippets + truncation flag PB->>LLM: Assembled prompt

Stage 1 — Classification

QuestionClassifierService decides what kind of question this is via keyword + fuzzy + stemmed matching.

Category	Trigger keywords
Authentication	auth, login, jwt, oauth, passport, permissions
API	api, endpoint, routes, controllers, rest, graphql
Database	database, schema, models, migration, orm, prisma
Architecture	architecture, structure, pattern, framework, microservices
Configuration	configuration, env, settings, variables, dotenv
Testing	test, spec, jest, mocha, coverage, e2e
Performance	performance, optimization, cache, memory, profiling
Error handling	error, exception, try-catch, validation, handling
Deployment	deployment, docker, ci/cd, pipeline, kubernetes, aws

Techniques applied in order: direct substring match → fuzzy (Levenshtein ≤ 2) → Porter stemming → negation detection (“not”, “without” flips the sign). Strong indicators (e.g., “jwt” for Authentication) carry a confidence boost.

Stage 2 — Search terms

If the message is codebase-related, EnhancedPromptBuilderService asks SecondaryLLMService (currently Groq) for 3–5 search terms. Capped at 5 to prevent over-fetching.

@-mentioned files short-circuit this — the pipeline extracts keywords directly from the message without an LLM call.

Stage 3 — Auto-gather

Two parallel sources:

• AST analysis — AnalyzeCodeProvider uses the search terms to locate relevant symbols via Tree-sitter.
• Semantic search — ContextRetriever queries the vector DB for chunks semantically similar to the user’s message.

Merged into one autoGatheredCode string.

Stage 4 — Budget + selection

SmartContextSelectorService is the gatekeeper.

Token budgets by model

Model	Budget
Claude 3 Opus / Sonnet	50 000
GPT-4 Turbo / GPT-4o	20 000
Llama 3.3 70B / Llama 4	20 000
Claude 3 Haiku	20 000
GPT-4	6 000
Qwen 2.5 Coder	4 000
CodeLlama	4 000
GPT-3.5 Turbo	4 000
Qwen 2.5 Coder 3B	3 000
Default fallback	4 000

Estimation: 1 token ≈ 4 chars for code.

Scoring

Each snippet gets a 0–1 relevance score.

Factor	Effect
User-selected (@ mention)	Always 1.0 — highest priority
Function/class name match	+0.2 per match
Keyword density	Base = 0.1 + (matches / words × 5)
No keywords available	Default 0.5

Auto-gathered snippets cap at 0.9 so user-selected files always win.

Packing

1. Include user-selected files first (never dropped).
2. Sort remaining by score descending.
3. Greedy-pack until the next snippet would exceed the budget.
4. Report wasTruncated and droppedCount for transparency.

Smart extraction

To fit more inside the budget:

• Function signatures preferred over full bodies when the budget is tight.
• Class declarations preferred over method bodies.
• Import blocks kept for type context.
• Duplicates across sources are removed.

Stage 5 — Assembly

Final prompt in this order:

1. Question-type instructions — pre-built preamble from QUESTION_TYPE_INSTRUCTIONS based on the classified type.
2. Architecture context — PersistentCodebaseUnderstandingService output.
3. Memory context — relevant manage_core_memory entries.
4. Team context — TeamGraphStore data when available.
5. User-selected file contents — verbatim.
6. Auto-gathered snippets — from Stage 4.
7. The user’s message — verbatim.

Everything above passes through sanitizeForLLM() — NFKC normalization + 15+ injection-pattern redaction + 8000-char cap. See Security.

Question-type prompt shapes

Type	Prompt emphasis
Implementation	Concrete code patterns, actionable suggestions
Architectural	Bird’s-eye view, component relationships, trade-offs
Debugging	Stack-trace analysis, root cause
Code explanation	Line-by-line walkthrough, naming rationale, design intent
Feature request	Impact analysis, integration points, where to insert new code

Post-deepagents suffix

After the assembled prompt above, deepagents appends its own BASE_AGENT_PROMPT (concise directives, “understand → act → verify”). CodeBuddy then appends CODEBUDDY_PROMPT_SUFFIX via registerHarnessProfile() — a short closure directive telling the model to stop when the actual request is done, added 2026-07-10 to counter the “keep working” pattern.

Order at the LLM: [our assembly] → [deepagents BASE] → [CodeBuddy suffix].

Rough timing

Stage	Cost
Search-term generation	~200 ms (Secondary LLM call)
AST analysis	50–200 ms (cached after first run)
Semantic search	20–100 ms (vector DB, cached)
Context selection	<10 ms
Total	300–500 ms typical

Related

• Memory — where manage_core_memory entries come from
• Semantic search — vector DB the auto-gather queries
• Security — sanitizer applied to every prompt