agent-stuff

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.

Shared vocabulary for designing deep modules — terms and principles, no document produced. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary. For the pre-code structure and object-model document, use `codebase-blueprint` (which calls this one).

Compact the current conversation into a durable handoff document another agent (any harness, any repo) picks up later — or resume from the latest handoff.

Stateful deep-research sessions with resumable file state under docs/research/. Use when the user says /research, "start a research session", or asks to resume or check on one; also when research needs pluggable backends (PubMed MCP) or state that survives interrupts. NOT for quick one-shot fact-checked answers — use the built-in deep-research skill for those.

Git workflow: after a PR merges, switch to the base branch, pull, and prune the merged branch. Trigger: 'I've merged the PR' or /switch-pull-prune.

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 via its REST API — upload/search/download/anonymize DICOM resources, DICOM networking through Orthanc (C-ECHO/STORE/FIND/MOVE/GET), peers/modalities, changes, jobs, PNG/NumPy decoding. Use whenever a task involves Orthanc, even if only an Orthanc URL (e.g. localhost:8042) is mentioned.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.

Transform requirements or rough ideas into C4 diagrams (C1–C3) via phase-gated Q&A — ASCII inline, Mermaid to disk, light DDD-strategic vocabulary. Use when the user wants to design, architect, diagram, or model a system through dialogue, or mentions C4. For compiling already-formed inputs (PRD, settled ideas) into a design doc without elicitation, use `system-architecture` (design mode) instead.

Git workflow: commit, push, and create/update a draft PR. If a PR exists for the current branch, update its body. Trigger: 'commit push pr' or /commit-push-pr.

How I apply Clean Architecture + DDD — pragmatic, right-sized by complexity tier, reconciled with deep modules. Use when designing, reviewing, or refactoring a codebase's architecture or layering, deciding how much architecture a project needs, or whenever Clean Architecture / DDD / SOLID comes up.

Map the user's relevant unknown unknowns for a task before planning, then help them sharpen the request. Use when the user asks for a "blindspot pass", says they know little about the area they're about to change, or wants to find out what they don't know before prompting or planning.

A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.