• Treat the human as the judge. Select, summarize, organize, and compile evidence; never turn an agent suggestion into a human label.
• Preserve durable Kitaru state. Re-read existing objects before creating replacements, and carry exact agent, session, investigation, investigation-session, annotation, cohort-version, evaluator, and evaluator-version identifiers forward.
• Separate observed behavior from desired behavior. A trace records what happened, not what should have happened or whether the external outcome was correct.
• Distinguish agent behavior, external dependency behavior, product purpose, and independent outcome evidence.
• Use open observations before proposing a taxonomy. Deterministic signals may select sessions; they do not judge them.
• Explain remote writes and paid or live execution before running them. Ask for one proportional confirmation at the point of action.
• Prefer native Kitaru MCP operations when available. CLI-only operation is supported; use the structured CLI for local files, built-in wait behavior, or an operation MCP does not expose.
• Run every Kitaru CLI command and SDK script with

  KITARU_ACTIVE_SKILL=kitaru-investigation

  set so the server attributes the resulting activity to this skill.
• Start or restart a user-controlled worker with

  --concurrency 10

  . Use

  KITARU_WORKER_CONCURRENCY=10

  only when the launch surface exposes worker settings through environment variables instead of CLI options.
• Stop at a useful durable checkpoint when a required source, payload, permission, worker, product contract, or UI capability is unavailable.

• Lead with the current state and one next useful action.
• Use ordinary language for user decisions. Keep internal labels such as

  trace-first

  ,

  cold-start

  , question keys, and selectors out of the lead.
• Ask for one meaningful judgment at a time. Do not turn setup into a long questionnaire.
• Prefer short prose during active review. Use a table only when the user must compare repeated fields or several candidates.
• Summarize structured output instead of dumping JSON. Preserve exact IDs, versions, warnings, and missing evidence in a compact checkpoint.
• Show which claims came from the repository, traces, user, or agent reasoning.

1. Observe: turn recorded traces into Kitaru sessions and inspect what happened.
2. Judge: let a human record what should have happened beside the evidence.
3. Define: express one accepted behavior as an evaluator over a reviewed cohort.
4. Replay: run one changed agent against the same situations under an explicit tool policy.
5. Compare: decide whether the bounded evidence improved, regressed, traded off, or remained inconclusive.

kitaru-guided-tour

Do you want to learn the review flow on one run, debug a specific behavior, or explore several runs to discover recurring problems?

• Read references/investigation-method.md before mapping the agent, selecting sessions, conducting review, or synthesizing behaviors.
• Read references/kitaru-operations.md before checking setup or calling Kitaru CLI or MCP operations. Verify the installed schemas when they differ from the reference.
• Read references/starter-template.md when frontend context names the starter or the checkout contains the public template's stable root contents. Use its guarded, README-led demo route before generic setup or trace-source questions.
• Read references/deterministic-evaluators.md after the user accepts one behavior and cohort, or when they directly request evaluator selection.
• Read references/evaluator-authoring.md only after checking the installed catalog. Continue there when no installed evaluator expresses the accepted criterion, or when the user declines a relevant match and requests custom authoring with equivalent reviewed evidence.

1. Resolve a reachable project root. For a frontend starter or

   template

   handoff, inspect the opened checkout before relying on its directory name or origin URL. Route to the starter-template reference when the root contains

   pyproject.toml

   ,

   returns_agent/

   , and

   traces/langfuse-traces.jsonl

   ; renamed clones and forks can still be the public template. If no checkout is reachable, report the incomplete handoff and stop before readiness checks, registration, or investigation. For already imported sessions or an explicit trace-only investigation, continue without source code and mark repository context as unresolved in every context brief and checkpoint that depends on it.
2. Inventory the discovered Kitaru MCP tool names and capability mode, and independently inventory whether the project Kitaru CLI is available. For MCP, distinguish absent tools or host configuration, read-only mode,

   standard

   mode,

   destructive

   mode, and a host that has not restarted since configuration. Modes are cumulative: a

   destructive

   -mode server also exposes every

   standard

   write tool. Do not treat a missing CLI as a blocker while MCP covers the next operation.
3. Choose one transport that can complete the next operation and its required handoff. Prefer a discovered MCP tool in at least

   standard

   mode; a

   destructive

   -mode server may perform ordinary writes, while destructive actions still require an explicit user request. Use the structured CLI for a local file import, built-in wait behavior, an operation MCP does not expose, or investigation creation immediately followed by frontend review when the CLI is already available, because its structured result can return the product-owned review link. When the CLI is absent but MCP can create the investigation, create it once through MCP and resolve the compatibility URL from the verified

   dashboard_url

   ; do not install the CLI or recreate the investigation solely to obtain a link. Enter installation guidance only when no available transport can complete the next operation and handoff. Before using the CLI, check the selected server with

   kitaru status

   and inspect the installed command schema before giving exact syntax. Explain and obtain approval before changing the project environment. If MCP setup requires a host restart, return a resume checkpoint first.
4. Resolve the registered agent and exact agent version when possible.
5. Resolve the trace source: already imported sessions, a local provider or JSONL export, or a new recorded run. Ask which source to use only when it is not clear from the request or repository.
6. Explain that importing converts trace records into Kitaru sessions. Use the CLI for a local file, wait through the supported mechanism, inspect the job, and verify the resulting sessions before starting an investigation. Import through MCP only when the payload already exists as a Kitaru blob.
7. Look for an exact investigation ID in the request, structured output, or Kitaru state. Re-read any matching investigation, ordered sessions, questions, answers, and verdicts before deciding what comes next.

sessions ready, no investigation
  -> map context and choose a bounded review path

investigation pending or in progress
  -> resume its worklist and report answer and verdict coverage

investigation completed
  -> synthesize persisted evidence or create a bounded follow-up

accepted behavior, no cohort version
  -> confirm exact membership and create a cohort version

cohort version ready, no evaluator version
  -> select an installed evaluator or author one narrow custom evaluator

evaluator version ready
  -> offer one bounded replay experiment

• Continue with the

  kitaru-importer-builder

  skill when existing traces use an provider or export shape that the installed catalog does not support. Carry the provider, export shape, target agent and version, current import state, and investigation goal.
• Continue with the

  kitaru-adapter-builder

  skill when the user needs in-process recording but no supported adapter covers the installed framework and invocation mode. Carry the repository, entrypoint, language, installed versions, required recording fidelity, target agent and version, and goal.

• what the agent does;
• its external environment and important side effects;
• the user job and successful or prohibited outcomes;
• the repository, trace, test, feedback, or external evidence supporting each claim.

1. Resolve the exact seed session and read its complete nodes and payloads.
2. Ask for the suspected behavior in ordinary language if it is not clear.
3. When comparable sessions exist, select a small worklist containing the seed, plausible related sessions, and one deliberately dissimilar counterexample.
4. Treat the suspicion as a search direction, not a label.

1. Define the eligible session population, time and version bounds, exclusions, payload availability, and pagination coverage.
2. Derive explicitly named selection signals directly from the bounded session and node data, such as cost, latency, error nodes, loops, repeated calls, node count, and tool patterns. Use them to find varied or unusual sessions, not to judge them. This selection step does not start evaluator jobs; consider evaluators only after the user accepts a behavior and exact cohort.
3. Start with four to six diverse sessions for one review block, combining coverage-oriented and seeded-random examples. Expand toward a larger pilot only after the first synthesis and the user's agreement.
4. Record the population, seed, selection method revision, and selection reason for every session.
5. Describe the batch as discovery, not evidence of prevalence or saturation.

observation

• the agent and review goal;
• the session count and why this size fits the goal;
• the question the user will answer;
• that creating the investigation writes remote state.

links.review

links.review

1. Use

   links.review

   from the structured

   kitaru investigation create

   result when it exists. Do not reconstruct or rewrite that product-owned URL.
2. Otherwise use only the compatibility route documented from

   dashboard_url

   , the exact agent ID, and exact investigation ID in references/kitaru-operations.md.

OPEN_STATUS

I opened the page.

OPEN_STATUS

Open the link manually.

1. Show the proposed positive session IDs and reviewed counterexamples excluded from membership.
2. Ask once: "Create this versioned cohort with this exact membership?"
3. Create the cohort and immutable first version through a supported operation.
4. Re-read it and retain the exact cohort and cohort-version IDs.

kitaru-replay-experiment

• the accepted behavior and intended use;
• exact cohort-version ID;
• evaluator-version IDs and parameters;
• factual checks, evidence, and limitations;
• candidate agent-version ID when known;
• one proposed override;
• explicit tool policy;
• any user-defined gate.

• If the review URL fails, preserve the investigation and report the broken product handoff; do not fall back to in-chat review.
• If agent source cannot be resolved safely, stop before presenting a code-grounded context brief.
• If full trace payloads are unavailable, identify the missing evidence and do not silently summarize truncated input.
• If a worker is unavailable, do not imply analyses or evaluations completed.
• If a mutating response is dropped, read current state before retrying because general request idempotency is not guaranteed.
• If the user abandons an investigation, leave it incomplete. Do not invent an

  uncertain

  verdict as a skip state or use destructive deletion as cancellation.
• If label isolation is not server-enforced, do not claim blinded evaluator validation.