Last updated July 24, 2026
Insights
Insights are analyses that run against your boards to surface what you'd otherwise hunt for by hand — security gaps, performance bottlenecks, coupling risks, compliance issues. Think of them as automated architecture reviews.
How insights work
Every insight comes from an insight skill — a reusable analysis definition that says what to look for and how to report it. Run a skill against a board and it produces structured findings: element-level insights, traced paths through your architecture, and suggested graph changes.
Two things can run a skill. /insights in a coding session runs it locally through Cdx Code and needs no model provider; chat runs it in the portal and does. Either way the findings land on the same board. Authoring skills, the categories they fall into, and what a run produces in detail all live in Insight Skills.
The Insights Bar
Each board has an Insights Bar at the bottom — a configurable strip that shows which insight skills are active for that board. Click a chip to see its latest results, or run a fresh analysis.
Running your first insight
- Open a board with at least a few nodes and edges
- Click the Insights Bar at the bottom of the board
- Select an insight skill (start with "Architecture Health" for a general overview)
- Click Run and wait for analysis to complete
- Review findings — check signals, priorities, and affected elements
- Explore any suggested graph changes before accepting them
Insight signals
Every finding carries a signal that classifies its nature:
| Signal | Visual | Meaning |
|---|---|---|
| Risk | Red, alert triangle | Something that could go wrong — a vulnerability, a single point of failure, a missing fallback |
| Strength | Green, check circle | Something that's working well — good separation of concerns, proper auth, solid caching |
These are the most common signals. Risks demand attention; strengths confirm good decisions.
Each finding also has a priority: critical, high, medium, or low. A finding can additionally carry a measurement — a quantitative 0–1 score (a coupling score, a dependency depth, a blast-radius size) that drives its visual weight on the board. A measurement rides on a finding alongside its signal; it isn't a signal of its own.
What an analysis produces
A run can return four kinds of result, and most return two or three: element insights (the findings themselves), affected elements (which nodes to emphasize and how), insight paths (traced routes — a request flow, a blast radius), and graph suggestions (proposed structural changes with a rationale). A security scan leans on the first two; a dependency analysis leans on paths. Insight Skills breaks down each one.
Insights aren't just pretty reports — they produce actionable graph suggestions. Found a missing cache layer? The suggestion tells you exactly which node to add and where. You review, accept, and your board evolves.
From finding to intent
On an app board, findings don't stop at being read. Review a finding or a graph suggestion and create an intent from it — a work item that flows to a developer through the plugin's /intents command, carrying the original finding along with it. From there the chain stays linked end to end: the signal that triggered it, the analysis, the released intent, and the commit that closed it. The full flow lives in Intents.