---
name: askcielara
description: Ask Cielara about the system — ingested knowledge (agent memory) and the live workload/service topology. Use for "why did we decide X", "what does the doc say", or "what services/dependencies/deployments exist".
metadata:
  short-description: Ask Cielara
---

# Ask Cielara

Cielara answers across two substrates. Route the question to the right one (or both):

1. **Agent memory** (MCP) — ingested documents: design docs, ADRs, runbooks,
   meeting notes, decisions. Served by the `cielara` MCP server.
2. **Workload topology** (the `workload-topology` skill) — the live map of the
   system's services/workloads, their outbound dependencies, deploy config, and
   linked wiki/jira/pagerduty. Served by `cielara-code workloads …` commands.
   This skill is **generated dynamically by the cielara-code sidecar** and is only
   present once the topology has been synced — see "Availability" below.

## Input

The user's question is in `$ARGUMENTS`. If empty, ask the user what they want to know.

## Routing

| The question is about… | Use | Examples |
|---|---|---|
| Services, workloads, dependencies, deployments, K8s pods/clusters/namespaces, outbound calls, host targets, Postgres/Notion/GitHub/PagerDuty/Jira links, "topology of the system", live/runtime state | **`workload-topology` skill** → `cielara-code workloads ls / find / grep / read / schema` | "which services call PostgreSQL?", "what does agent-fabric depend on?" |
| Why something was decided, what a doc/ADR/runbook/note says, recalling ingested knowledge | **memory tools** | "why did we pick X?", "what does the onboarding doc say?" |

### When to use the workload-topology skill — important
For anything about workloads / services / dependencies / deployments / "the
system's topology", **defer to the `workload-topology` skill and run
`cielara-code workloads …` — do NOT `ls`/`find`/`grep` the local filesystem.**
The topology lives in the sidecar daemon's in-memory FS, not in the current repo.
`cielara-code workloads ls` is the source of truth; only fall back to filesystem
inspection if it errors or returns empty.

### Memory tools
| Signal | Tool |
|--------|------|
| "Why did we decide X", "what does the doc say about X" — wants a synthesized answer | `mcp__cielara__ask_memories` |
| Keyword / phrase lookup, "find docs about X", "where is X mentioned" | `mcp__cielara__search_memories` |
| "What collections exist", memory inventory, scoping a search | `mcp__cielara__list_memory_collections` |

Rules:
- A question spanning both substrates (e.g. "why is service X deployed this way")
  → query the topology for the *what* and memory for the *why*, then synthesize.
- Don't fabricate — if a substrate returns nothing relevant, say so.

## Availability

The `workload-topology` skill exists only when the sidecar has generated it
(after `cielara enable` + a topology sync). The daemon starts serving before its
topology finishes loading, so a first `ls` on a cold machine can come back empty
even though the topology is fine — this is a warm-up race, not a missing
substrate. **Never report the topology unavailable on the first empty result.**
To check before relying on it:
```
cielara-code workloads ls
```
- Returns workloads → topology is available; use it.
- Exits with "no schema loaded" / empty → this is the expected cold-start race.
  **Always** run `cielara-code workloads sync` (a synchronous topology load), then
  retry `workloads ls` once. The sync forces the load the daemon was doing in the
  background, so the retry normally succeeds.
- Only if `sync` itself errors is the topology source actually unconfigured /
  unreachable — note it as unavailable then, and answer from memory (or
  filesystem) instead.

## Error handling

- **Memory** results starting with "Error":
  - "timed out" → Agent Memory API slow; suggest retrying.
  - "connection refused" / "not reachable" → service down or `MEMORY_API_URL` misconfigured.
  - "not configured" / auth error → suggest `cielara login`.
- **Topology** (`cielara-code workloads …` non-zero exit):
  - "no schema loaded" / empty → cold-start race; **always** `cielara-code workloads sync`, then retry once before concluding anything.
  - persistent failure *after* a sync attempt → topology source unreachable; note it as unavailable.
- Report errors briefly; don't dump raw tracebacks.

## Output

Present a direct answer to the question:
- The answer, drawn from the substrate(s) queried; synthesize if both contributed.
- Note which substrate(s) it came from (e.g. "from topology" / "from memory").
- Suggested follow-up questions if a tool returned them.
- If nothing relevant was found, say so plainly.
