Integrate Long-Term Memory Skills with Coding Agent

Environment detection and configuration loading

When a user triggers a Skill, it detects the current IDE type through environment variables (QODER_AGENT or VSCODE_BRAND identifies the Qoder environment). It then reads the adbpgmem.conf configuration file from the .qoder/ directory to obtain the API endpoint, authentication token, and user identifier.

Memory operation execution

Based on the triggered Skill type, the corresponding operation calls the AnalyticDB for PostgreSQL long-term memory service REST API:

• Write knowledge (POST /v3/memories/add/): Write structured development knowledge to the remote memory store.

• Semantic retrieval (POST /v3/memories/search/): Search historical memories by semantic similarity.

• Memory list (POST /v3/memories/?page=X&page_size=Y): Retrieve the user's memory list with pagination.

• Update memory (PUT /v1/memories/{id}/): Modify the content of an existing memory.

• Delete memory (DELETE /v1/memories/{id}/): Remove expired or obsolete memories.

Result processing and presentation

Results from the API are processed by the AI and presented in a structured format, including write summaries, ranked retrieval results, health statistics, and cleanup recommendations.

Key design principles:

• Automatic IDE detection: The current IDE is automatically identified through environment variables. Configuration files are stored in the corresponding directory without manual specification.

• Project-level configuration: Each project has its own adbpgmem.conf, so different projects can use different API endpoints and user identifiers.

• REST API communication: All memory operations are performed through HTTP APIs, supporting semantic search, intelligent deduplication, and paginated retrieval.

Step 1: Run the configuration command

Type the following in an AI IDE conversation:

/adbpgmem-setup

Or say "configure memory" or "set up adbpgmem".

Step 2: Enter configuration information

The AI asks for three configuration items in sequence:

If a configuration already exists, you can select "keep unchanged" to retain the existing values or enter new values to overwrite them.

Step 3: Connectivity test

After configuration, an automatic connectivity test runs (up to 2 retries):

• HTTP 200: Connection successful, configuration saved.

• HTTP 401/403: Token invalid, re-enter required.

• Timeout/Connection failure: URL is incorrect or the service is unavailable.

Step 4: Confirm completion

After successful configuration, the configuration file is written to the project's corresponding IDE directory:

# Configuration file path example
Qoder:     .qoder/adbpgmem.conf

Example configuration file content:

# ============================================================
# adbpgmem x AI IDE Integration Configuration
# File permissions: chmod 600 (contains API Token)
# ============================================================

# ── Connection ──
ADBPGMEM_API_URL="http://192.168.1.100:8000"
ADBPGMEM_API_TOKEN="your-api-token-here"

# ── User Identifier (user_id, username only, not project name) ──
# Priority: this value > whoami
ADBPGMEM_USER_ID="zhangsan"

Update and delete configuration

• Reconfigure: Run /adbpgmem-setup and select "reconfigure" to modify some or all parameters.

• Delete configuration: Run /adbpgmem-setup and select "delete" to remove the configuration file.

Knowledge recording (record)

Trigger methods (choose any):

• Slash command: /adbpgmem-record

• Natural language: "remember this", "record this", "don't forget this pitfall", "this experience is important", "don't make this mistake again"

• AI proactive suggestion: The AI proactively suggests recording when high-value knowledge emerges during a conversation.

Workflow:

1. Identify knowledge: Identify high-value knowledge from the current conversation and structure it into three key elements.

2. Automatic deduplication: Checks for highly similar existing memories through semantic search (score > 0.85). If found, updates the existing entry; otherwise, creates a new one.

3. Write to memory store: Uses jq to safely construct JSON, preventing write failures caused by special characters.

4. Output summary: Displays the write results.

Knowledge categories:

Output example:

Wrote 2 memories to adbpgmem (user: zhangsan)
1. Kafka offset commit uses manual mode to avoid duplicate consumption
2. Reason for adjusting order service timeout threshold from 3s to 5s

Notes:

• Up to 5 memories can be captured at a time. If there are more, the user is asked to select the most important ones.

• If the current conversation does not contain high-value knowledge worth recording, the user is informed and the process ends.

• Do not record passwords, API keys, tokens, personally identifiable information, or production environment IPs.

• Content wrapped in <private> tags is automatically discarded.

Knowledge retrieval (recall)

Trigger methods:

• Slash command: /adbpgmem-recall

• Natural language: "how did we solve this last time", "encountered a similar issue before", "any related experience", "we hit this pitfall before"

• AI proactive suggestion: When the AI determines that the current problem may have historical precedents.

Workflow:

1. Understand intent: Extracts the search topic, keywords, time range, and project scope from the user's question.

2. Semantic search: Retrieves related memories through the AnalyticDB for PostgreSQL semantic search API (default top_k=5).

3. Filter and rank: Filters out results with score < 0.5 and sorts by relevance in descending order.

4. Structured presentation: Displays results in the format of type tag + content + relevance score.

Cross-project retrieval: To search across projects, remove the user_id filter to broaden the scope (top_k=10).

Output example:

Found 3 related historical memories:

1. [solution] Kafka offset commit uses manual mode to avoid duplicate consumption (relevance: 0.92)
   Details: In auto-commit mode, when a consumer crashes and restarts, it starts from the last committed offset...
   Recorded: 2025-05-15

2. [debug] Kafka consumer group rebalance causes message loss (relevance: 0.75)
   Details: max.poll.interval.ms set too low, processing time exceeding this value triggers rebalance...
   Recorded: 2025-04-20

3. [pattern] Message queue consumers uniformly use @KafkaListener annotation (relevance: 0.65)
   Recorded: 2025-03-10

Notes:

• Search queries are truncated to 500 characters to stay within API limits.

• A maximum of 10 results are returned per search.

• If no matches are found, try different keywords or use /adbpgmem-record to record the current experience.

Memory maintenance (review)

Trigger methods:

• Slash command: /adbpgmem-review

• Natural language: "clean up memories", "what have I recorded", "how many memories do I have", "review memories"

Recommended frequency: Once per month or after every 50 new memories are accumulated.

Workflow:

1. Fetch memories: Retrieves memories through the list API with pagination (200 entries maximum by default).

2. Statistics dashboard: Generates a health report by type and time dimensions.

3. Identify issues: Flags memories with four types of issues: expired, low-quality, duplicate, and orphaned.

4. Present recommendations: Displays the issue list and recommended actions, then waits for user confirmation on each item.

5. Execute cleanup: Performs updates or deletions based on the user's confirmed decisions.

6. Promotion suggestions: Identifies high-value memories (architecture/pattern types) and recommends syncing them to AGENTS.md.

7. Output summary: Displays operation statistics and the current total number of memories.

Issue identification criteria:

Output example:

=== Memory Store Health Report ===
Project: my-project
Total memories: 83 (83 analyzed)

Distribution by type:
  architecture (architectural decisions): 8
  solution (solutions): 15
  pattern (coding patterns): 12
  debug (debugging experiences): 9
  context (project context): 3
  uncategorized: 36

Issues requiring attention:

[expired] (2 entries)
  1. "Test environment database address is 10.0.0.5" -> Recommend: delete

[duplicate] (1 group)
  1. "Kafka offset manual commit" and "Kafka consumer offset management" -> Recommend: merge

Cleanup complete: 1 updated, 2 deleted, 1 group merged
Promotion suggestion: 2 architectural decisions recommended for syncing to AGENTS.md
Current total memories: 44
========================

Notes:

• The list API supports pagination (50 entries per page), with a maximum of 200 entries retrieved by default.

• Update and delete operations require user confirmation for each item and are not batch-executed automatically.

• The total length of an updated memory must not exceed 2,000 tokens. If it does, the content is summarized and compressed first.

Scenario 1: Bug troubleshooting loop

Developer: The order API response time spiked from 200ms to 5s. Help me investigate.
AI: (Investigation... found N+1 query issue) Fixed by adding JOIN FETCH in OrderRepository.
Developer: Record this pitfall.
AI: -> Triggers /adbpgmem-record, writes [debug] type memory

Next time a similar issue occurs:

Developer: The user list API is slow again. Any similar experience from before?
AI: -> Triggers /adbpgmem-recall
AI: Based on historical memories, the last order API slowness was also an N+1 query issue,
    resolved by adding JOIN FETCH in Repository. Recommend checking SQL logs first.

Scenario 2: Team knowledge sharing

New member joins the project:
Developer: Any development experience or tips for this project?
AI: -> Triggers /adbpgmem-recall (cross-project retrieval mode)
AI: Found 12 team historical memories:
    1. [architecture] Chose PostgreSQL over MySQL because JSONB support is needed
    2. [pattern] All REST APIs must return a unified ApiResponse wrapper class
    3. [debug] KEYS command blocks in Redis cluster mode, must use SCAN
    ...

Scenario 3: Multi-IDE collaborative development

Configure in Qoder (auto-detects .qoder/ directory):
/adbpgmem-setup  -> Config written to .qoder/adbpgmem.conf

Configure the same service in Cursor (auto-detects CURSOR_AGENT environment variable):
/adbpgmem-setup  -> Config written to .cursor/adbpgmem.conf

Both IDEs share the same long-term memory service and User ID, with synchronized memories.
Knowledge recorded in Qoder can also be retrieved in Cursor.