القائمة
Retrieve and review protected Kazusa LLM trace evidence for generated dialog, starting from visible dialog text, message identifiers, delivery tracking ids, or trace ids.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Pull read-only diagnostic data from the Kazusa MongoDB database into JSON files. Use this skill whenever the user asks to export, inspect, dump, pull, or retrieve chat history, user profiles, user image, persistent user memories, shared memory, character state, or arbitrary MongoDB collection rows from this repo. Prefer the bundled project scripts and .env settings over ad hoc database queries.
Create human-readable quality evaluation artifacts for LLM debug, prompt testing, prompt comparison, model routing, RAG/cognition/consolidation/debug-channel behavior, and regression review. Use whenever a task asks to test, debug, inspect, evaluate, compare, or validate LLM output quality; when running live/local LLM calls; when changing prompts; or when reviewing possible LLM regressions.
Use when planning, modifying, debugging, testing, or validating the Kazusa web control console frontend, including static HTML/CSS/JS pages, FastAPI control-console routes, cognition/prompt debug views, UI placement, Playwright or browser validation, screenshot signoff, stale Chrome in-memory JavaScript/cache issues, and control-console framework rules.
Write, refactor, and run tests in this repo using the project testing contract. Use this skill whenever adding or changing pytest tests, refactoring test style, deciding between real LLM tests and patched unit tests, testing graph/subgraph behavior, or running tests. It covers both how tests should be written and how regular versus real LLM tests must be executed and inspected.
Use this skill whenever the user asks architectural questions about LLM systems, especially prompt design, agent/subagent responsibility boundaries, routing, retrieval planning, tool/capability design, reliability, latency, or how to divide work between an initializer/planner and specialized agents. This skill is particularly important for this repo because the target runtime uses a local/weaker LLM with finite context and chatbot latency constraints; invoke it even when the user does not explicitly mention local LLMs. When modifying an existing LLM pipeline, use this skill to audit existing contracts and minimize blast radius before editing.
Enforce and review Python coding style for this project. PEP 8 is the baseline, with the project's explicit positive and negative constraints applied on top. Use this skill whenever you are writing new Python code, reviewing existing Python files, or responding to feedback about code quality. Trigger on any task that involves creating or modifying .py files, reviewing a function or class, or when the user asks about code style, best practices, or refactoring. Always apply these rules proactively -- don't wait for the user to ask.
| name | llm-trace-debug |
| description | Retrieve and review protected Kazusa LLM trace evidence for generated dialog, starting from visible dialog text, message identifiers, delivery tracking ids, or trace ids. |
Use this skill when investigating why a generated dialog was produced, when a user gives visible dialog text and asks for the LLM handoff trail, or when you need prompt/output evidence for a specific chat turn.
The sanitized event log is an audit index only. It does not contain raw prompts, raw model outputs, parsed model output, final dialog text, evidence text, or adapter wire payloads.
LLM decision evidence lives in the protected trace collections:
llm_trace_runsllm_trace_stepsConversation rows and audit rows link to the trace by llm_trace_id.
If you have a trace id, export it directly:
venv\Scripts\python -m scripts.export_llm_trace --trace-id <llm_trace_id>
If you only have visible dialog text, resolve the trace from
conversation_history:
venv\Scripts\python -m scripts.export_llm_trace --dialog-text "<visible dialog>"
If you have delivery or platform metadata, prefer the stable identifiers:
venv\Scripts\python -m scripts.export_llm_trace --delivery-tracking-id <id>
venv\Scripts\python -m scripts.export_llm_trace --platform-message-id <id>
To create compact review input for LLM debug review:
venv\Scripts\python -m scripts.export_dialog_trace_review_input --dialog-text "<visible dialog>"
Read the export in this order:
conversation_history: confirm visible input/output, timestamps, and
llm_trace_id.event_log_events: confirm pipeline stages, statuses, and sanitized timing.llm_trace_steps: inspect stage order, prompt/output hashes, parse status,
output state fields, and raw payloads if full capture was enabled.LLM_TRACE_CAPTURE_MODE=metadata is the default. Metadata mode stores counts,
hashes, stage names, parser status, state handoff fields, timing, and model
metadata, but raw prompt/output fields are empty.
LLM_TRACE_CAPTURE_MODE=full stores raw prompt messages, raw response text, and
parsed output in protected trace collections.
LLM_TRACE_CAPTURE_MODE=off skips trace row writes. In that mode, use
event_log_events and conversation_history only.
Logging retention is controlled by two shared settings:
AUDIT_LOG_TTL_DAYS covers sanitized audit/event-log data.DEBUG_LOG_TTL_DAYS covers protected debug trace data.Do not introduce per-collection TTL settings for trace debugging.