Zeabur RAG Curate

RAG — Curate

Interactive curation loop for the knowledge base. This skill orchestrates other skills (triage, inspect, edit, learn, search) plus a few inline admin API calls to walk the user through fixing pending issues one by one.

This is NOT an API wrapper. It's a workflow guide. Follow the steps below as a conversation with the user.

Base URL: $ZEABUR_RAG_URL Auth: Authorization: Bearer $RAG_API_KEY — admin scope required

Loop

1. Call zeabur-rag-triage to get the pending items list.
2. Present results as a numbered list grouped by category (🔴 Reports, 🟡 Unverified, 🟠 Low-score, 🔵 Negative feedback, ⚪ Needs-frontmatter). Show counts.
3. If all categories are empty: tell the user "The knowledge base has no pending items — looks healthy ✅" and stop.
4. Wait for user to pick an item by number or description.
5. Run the decision tree for that item type (see below).
6. After each action, echo the result and ask "Next?" to return to the list.
7. User says stop → end the loop.

Decision trees

🔴 Open report

1. If chunk_id is null (type=missing) → skip to step 3.
2. Call zeabur-rag-inspect on the referenced chunk. Show the chunk content + report detail side by side.
3. Classify:

4. Every action requires explicit user confirmation before execution.

🟡 Unverified learned chunk

1. Call zeabur-rag-inspect on the chunk. Show full content, tags, text_content.
2. Classify:

🟠 Low-score signal

1. Call zeabur-rag-search with the original query to confirm the gap.
2. Classify:

🔵 Negative feedback signal

1. Call zeabur-rag-inspect on each chunk in top_chunk_ids. If top_chunk_ids is null or empty, skip to step 3.
2. Identify which chunk(s) caused the bad result.
3. Classify:

⚪ Needs-frontmatter

A chunk was ingested from a source file without the stable metadata expected by its adapter. Fix the source file and re-ingest it rather than treating the generated chunk as the canonical record.

1. Call zeabur-rag-inspect to show the chunk's url and content.
2. Identify the origin file and the adapter that produced it.
3. Add the stable ID and other frontmatter required by that adapter.
4. Re-run the same adapter against the corrected source.
5. Confirm that the stable-ID chunk replaced the temporary result before closing the item.

Inline commands

These actions don't have dedicated skills. Execute them as direct API calls:

Verify a learned chunk

curl -s -X POST "$ZEABUR_RAG_URL/api/admin/learned/<id>/verify" \
  -H "Authorization: Bearer $RAG_API_KEY"

Returns {"success": true}. The chunk now ranks at full weight in search (unverified learned chunks are downranked to ×0.7 score).

Reject a learned chunk (soft delete)

curl -s -X DELETE "$ZEABUR_RAG_URL/api/admin/learned/<id>" \
  -H "Authorization: Bearer $RAG_API_KEY"

Returns {"success": true}. Sets status='rejected', excluded from all search.

Reject any non-learned chunk (soft delete via PATCH)

curl -s -X PATCH "$ZEABUR_RAG_URL/api/admin/chunks/<id>" \
  -H "Authorization: Bearer $RAG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status":"rejected"}'

Returns {"success": true, ...}. For docs/forum chunks, this rejection survives pipeline rebuilds.

Close a report

curl -s -X POST "$ZEABUR_RAG_URL/api/admin/reports/<id>/close" \
  -H "Authorization: Bearer $RAG_API_KEY"

Returns {"success": true}. Closing an already-closed report is treated as success.

Rules

• Never auto-execute mutations. Every edit, verify, reject, learn, or close requires the user to explicitly confirm (e.g. "ok", "verify", "reject", "close").
• Always inspect before edit. You need the existing text_content to construct a new one. The edit endpoint returns 400 if you change title/question/answer without providing text_content.
• Echo results after every action. Show the audit_id, new status, or error message so the user knows what happened.
• Don't retry failed mutations. Surface the error and let the user decide.
• One item at a time. Process triage items sequentially. Don't batch.