manage-rules

Manage Rules

Rules are loaded into the assistant's prompt context on every response. They shape how findings are interpreted — what to de-prioritize, what to highlight, and how to frame expected behavior versus actionable risk.

When to use

• Assistant responses are technically correct but operationally noisy
• Known infrastructure churn keeps dominating investigations
• Important application issues are buried in platform noise
• Severity language is inconsistent across investigations
• User asks to "tune", "adjust", or "configure" the assistant's behavior

Key concepts

Scoping

Scope	Effect	scope_type	scope_id
Workspace	All assistants in the workspace see the rule	workspace	workspace name (e.g. my-workspace)
Persona (assistant)	Only a specific assistant sees the rule	persona	persona name
Platform	All workspaces in the organization	platform	null

Most rules should be workspace-scoped. Use persona scope only when different assistants need different interpretation behavior.

Rule anatomy

Good rules are short, explicit instructions with clear priority direction:

Acknowledge that GKE node preemptions are expected in this cluster.
Do not treat preemptions as root cause unless clearly correlated with
user-reported symptoms.

Bad rules are vague or too broad:

Be better at analyzing Kubernetes issues.

Workflow

1. Audit existing rules

list_chat_rules(scope_type="workspace", scope_id="my-workspace")

2. Identify noise patterns

Use workspace_chat(workspace_name="my-workspace", message="...") to run a baseline prompt your team asks often. Note which findings are repeated noise vs actual issues. Common noise sources:

• Node preemptions / spot instance recycling
• CNI flapping in shared clusters
• Resource pressure on non-critical namespaces
• Platform controller reconciliation events
• Expected CronJob failures in dev/test