Lightbridge-KS

Bootstrap and manage the personal .lightbridge namespace — per-project config at ~/.lightbridge/projects/<project-key>/config.toml (docs-index, repo-links, research, plans, …) and the rest of the user-level ~/.lightbridge/ tree (handoffs, plans, repos.toml). Use when setting up lightbridge config for a repo, enabling or adding a config section, asking what .lightbridge supports, wiring a new config feature, or locating user-level lightbridge state.

Explain an existing agentic system — a codebase where an AI agent is the central "CPU" surrounded by agent-native organs (reasoning loop, memory, context, tools, skills, MCP, subagents, hooks) — or design one from requirements. Covers agent runtimes/harnesses and capability/steering packs. Use when the user invokes it by name (`agentic-architecture`) or near-match.

The agent-experience ("AX") lens for any interface an AI agent drives — a CLI, MCP server, HTTP/REST API, or library/SDK. Judge an existing surface against the AX principles and prescribe prioritized fixes, or apply the principles while designing a new agent-facing surface. For a descriptive whole-surface doc across all audiences (end user / developer / agent), use `surface-architecture` instead. Use when the user invokes it by name (`ax-interface`) or near-match ("AX analysis", "agent experience of …", "agent-friendly interface").

The reconciliation pass between a settled design and the first line of code. Read the design docs, hunt the places they disagree with each other and with the chosen framework, then compile the object model that must satisfy all of them at once — turning prose rules into machine-checked invariants and amending upstream docs it contradicts. Use when design is settled and you are about to build, or when the user invokes it by name (`codebase-blueprint`) or near-match.

Explain an existing codebase's data architecture — where data rests (stores, schema) and how it moves (dataflow, lineage) — or design one from requirements. One Markdown doc with Mermaid diagrams. Use when the user invokes it by name (`data-architecture`) or near-match.

Decompose a function, method, class, or module of an existing codebase into a runnable notebook that explains it top-down — each piece executed on concrete inputs with real output shown inline. Use when the user invokes it by name (`explain-as-notebook`) or near-match mentioning.

Explain an existing codebase's user-facing surface — UX/DX/API as seen from outside the boundary, whether the "user" is an end user, developer, or agent — or design that surface from requirements. One Markdown doc with Mermaid diagrams. For a deep agent-only audit against AX principles, use `ax-interface` instead. Use when the user invokes it by name (`surface-architecture`) or near-match.

Explain an existing codebase's system architecture, or design one from a PRD or rough ideas — either way one C4-style Markdown doc with Mermaid diagrams. Use when the user invokes it by name (`system-architecture`) or near-match. For fuzzy requirements needing interactive elicitation, use `c4-architect` instead.

Decompose a piece of an existing codebase — a function, method, class, or module — into a runnable notebook that explains it top-down: a call-graph map, then each piece defined and executed on concrete mock inputs with its real output shown inline. Turns code you didn't write (or have forgotten) into an interactive, line-by-line walkthrough. Use this skill only when the user explicitly invokes it by name (`explain-as-notebook`) or near-match mentioning.

Analyze the agent experience ("AX") of an interface an AI agent drives — a CLI, MCP server, HTTP/REST API, or library/SDK — against the principles of what makes a system easy for a reasoning-loop agent to use, and prescribe prioritized fixes. Use this skill only when the user explicitly invokes it by name (`ax-interface-analysis`) or near-match mentioning.

Reverse-engineer and document the user-facing API and UX/DX of an existing or cloned codebase — the system as seen from outside the boundary, whether the "user" is an end user or a developer. Use this skill only when the user explicitly invokes it by name (`explain-ux-dx-design`) or near-match mentioning.

Reverse-engineer and document the data architecture of an existing or cloned codebase — where data rests (stores, schema) and how it moves (dataflow, lineage). Use this skill only when the user explicitly invokes it by name (`explain-data-architecture`) or near-match mentioning.

Reverse-engineer and document the architecture of an existing or cloned codebase. Use this skill only when the user explicitly invokes it by name (`explain-system-architecture`) or near-match mentioning.

Reference for the DCMTK (OFFIS DICOM Toolkit) command-line tools — the canonical CLI for working with DICOM files and DIMSE network services. Use when converting, dumping, anonymizing, or validating DICOM files, or running DIMSE services (C-ECHO/STORE/FIND/MOVE/GET), worklists, or structured reports from the terminal.

Reference for driving an Orthanc DICOM server through its REST API. Use this skill whenever a task involves Orthanc — uploading, browsing, searching, downloading, anonymizing, or modifying DICOM resources (patients/studies/series/instances) on a local or remote Orthanc; performing DICOM network operations through Orthanc such as C-ECHO, C-STORE, C-MOVE, C-GET, or Query/Retrieve (C-FIND) against remote modalities/PACS; configuring Orthanc peers or modalities; tracking changes; decoding instances to PNG/NumPy for AI pipelines; or running asynchronous Orthanc jobs. Trigger this even when the user only mentions an Orthanc URL (e.g. localhost:8042), 'the Orthanc REST API', or building a script/tool/pipeline that talks to Orthanc, even if no specific endpoint is named.

Drive 3D Slicer (medical imaging app) over HTTP via the slicer-cli tool. Use when the user mentions Slicer, MRML, DICOM viewing/loading from a Slicer scene, or asks to render a slice/3D view from a volume they have loaded in Slicer.

Drive 3D Slicer (medical imaging app) over HTTP via the slicer-cli tool. Use when the user mentions Slicer, MRML, DICOM viewing/loading from a Slicer scene, or asks to render a slice/3D view from a volume they have loaded in Slicer.

Use these tools whenever the user asks to read, modify, or clean up Jupyter notebooks (.ipynb files).

Transform project requirements, problems, user stories, or rough ideas into Simon Brown's C4 architecture diagrams — System Context (C1), Containers (C2), and Components (C3). Conducts adaptive Q&A, emits Unicode box-drawing ASCII diagrams inline, and optionally saves Mermaid versions to disk. Incorporates light DDD Strategic Design vocabulary (bounded context, ubiquitous language, context map, subdomain triage) with inline plain-English glosses so users unfamiliar with DDD still understand. Invoke this skill when the user asks to design, architect, diagram, model, or transform requirements into a system design, or mentions "C4" explicitly. Stops deliberately at each phase boundary for user confirmation. Code-level diagrams (C4 Level 4) are out of scope — defer to UML/class-diagram skills or trained knowledge for that level.

Extra documentation for `assistant-ui`. Use this to find offline resources about `assistant-ui`.

taurinext-shadcn template reference doc. Use this when to find in-depth information about this template.