When Damira Runs (and When It Doesn't)

Damira is a plugin skill set, not a separate chat window — it runs inside the agent session you're already in (Cursor or Claude Code), so "did Damira run?" isn't always obvious from the reply alone. This page covers automatic invocation, forcing it explicitly, confirming it ran, and what to check when it seems to be sitting out.

How it gets invoked automatically

Each Damira skill ships a short description of when it applies — an active fault ("BGP down," pasted show output), a version-to-version upgrade, a config someone wants audited or hardened, or a request to generate a device config. The agent reads those descriptions and decides whether your message matches one, the same way it decides whether to use any other tool available to it. There's no fixed keyword list and no guarantee: a stronger model tends to catch this reliably; a lighter one can occasionally skip straight to answering from its own training instead of reaching for the skill, especially on an ambiguous message.

Some requests are answered directly and correctly without Damira at all — "how does BGP work," or general best-practice guidance — because that's already accurate from training and doesn't need version-specific data. Damira earns its place on things a model can't know on its own: real CVE data, release-note caveats for a specific version, a structured diagnosis workflow, or a pattern-based config audit.

How to force it

If you want a specific skill and don't want to leave it to the automatic match:

• Claude Code — every skill is also a slash command: /damira:troubleshoot, /damira:config-audit, /damira:upgrade-plan, /damira:generate-config, and so on for the rest.
• Cursor — the four most-used skills have their own explicit command: /troubleshoot, /upgrade-plan, /config-audit, /generate-config.
• Either host — say "use Damira to..." or name the skill in plain language ("run a config audit on this," "use the troubleshoot skill for this outage"). Naming the skill or the specific check you want is a stronger match than a vague description of the problem.
• Either host — mention a specific capability by name if you know it (vendor docs lookup, CVE lookup, release-note lookup) and the agent will reach for the skill that owns it.

How to confirm it ran

• The response includes detail that isn't general knowledge — a specific CVE ID, a release-note bug number, an exact remediation command for a named platform and version. That level of specificity is the practical signal that a lookup happened rather than the model answering from memory.
• A config audit that reads as more thorough than a quick manual skim — several findings with severity and line references — indicates the pattern-based audit ran rather than a visual read of the config.
• Local usage stats (damira stats from a terminal, if you have the CLI installed) record every damira validate run — the generate-then-validate loop the automation and config generators run locally — independent of the chat transcript. It doesn't cover a troubleshoot, upgrade-plan, or config-audit call, which reach the agent directly, so it's evidence the validate loop ran rather than proof any specific skill fired.

The prompt hint (Claude Code)

Claude Code's package includes a small, local check that runs before each message reaches the agent: if the message looks like a device config — pasted, with or without audit language — show/log output, active-fault language, a named-platform upgrade, or a config-generation request, it adds one line naming the matching skill. A bare config paste with no instruction at all ("here's r1's config") is enough on its own; no audit verb is required. It runs entirely as pattern matching on your machine, adds a single line of context for the agent (visible only in verbose or transcript views), never blocks or changes your message, and never repeats your message back. It exists specifically to help lighter models catch cases they'd otherwise miss — if you never want it, set DAMIRA_PROMPT_HINTS=0 in your environment.

This check isn't available in the Cursor package today — Cursor's equivalent hook can only allow or block a message, not add context to it — so Cursor relies on the always-on guidance the plugin loads into every session instead.

Troubleshooting: it isn't triggering

1. Is the plugin enabled? Claude Code: check /plugin. Cursor: check the plugin panel in Settings.
2. Is a key configured, or are you on the shared demo key? A missing key doesn't stop skills from working, but you're on a shared daily limit until you add your own from your dashboard's API Keys page.
3. Is the connection live? Claude Code: run /mcp and look for damira listed with its tools. If it shows a connection error, a skill falls back to a CLI command instead of the MCP tool call — that still reaches the gateway for a live vendor-doc, CVE, or release-note lookup, it just runs one layer further from the model.
4. Are the skills actually listed? If the plugin didn't install cleanly, /plugin (Claude Code) or the plugin panel (Cursor) won't show any of Damira's skills at all — that's a different problem from a skill not triggering.
5. Try forcing it. If the explicit form (/damira:config-audit in Claude Code, or naming the skill directly in either host) works but your original, more casual message didn't, that's a routing gap on that specific phrasing — report the exact wording that didn't match, since that's what improves the next version.