Run any Skill in Manus with one click

lightbridge-config

Stars1

Forks0

UpdatedJuly 16, 2026 at 08:23

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Lightbridge-KS

Lightbridge-KS/agent-stuff

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name	lightbridge-config
description	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.
metadata	{"version":"2026-07-16"}

.lightbridge config

.lightbridge is my personal, tool-agnostic config namespace — a stable place my own scripts and hooks read, separate from any agent's dir (.claude/, .codex/, .pi/). Everything is user-level; nothing ever lives inside a repo (the "local scope" model — collaborators never see it, no gitignore needed). One file per project:

~/.lightbridge/projects/<project-key>/config.toml    # namespaced by [section]

resolved by scripts/lightbridge (agent-stuff): project root = git toplevel of cwd, key = root path with separators → -.

The one rule — opt-in by section presence. A feature is on iff its [section] exists; enabled = false disables without deleting.

The same tree holds durable, harness-neutral state: projects/<key>/handoffs/ (the handoff skill), projects/<key>/plans/ (approved plan-mode plans, filed by hooks/plan-capture), and ~/.lightbridge/repos.toml, the personal name→path repo registry.

Full spec (conventions, sections, keys, who reads them): references/catalog.md.

The CLI does the mechanical work

scripts/lightbridge owns creating and auditing a config — don't hand-write one. Linked onto PATH as lightbridge / lb (see its README); otherwise uv run <agent-stuff>/scripts/lightbridge/lightbridge.py <verb>.

lb status                # FIRST MOVE for "what's lightbridge doing here?" — one dashboard
lb init                  # create this project's config; detects docs/ → [docs-index]
lb init research repo-links   # or name sections; --dry-run to preview
lb add repo-links        # extend an existing config (skips sections already there)
lb show [SECTION]        # print the stored config (or one block); --json to parse
lb enable|disable NAME   # flip a section's `enabled` in place (idempotent)
lb sections              # what can go in a config, and who reads it
lb path                  # where this project's config lives (+ exists?)
lb repos list|add|rm     # manage ~/.lightbridge/repos.toml (add never clobbers a name)
lb doctor                # audit the whole tree (stale roots, legacy files)

init never clobbers an existing config (exit 1 — use add), and add / enable / disable are idempotent, so all are safe to re-run. Report back what was written and which reader consumes it.

Explain / "what can go in .lightbridge?"

Read references/catalog.md and answer from it — conventions, sections, keys, opt-in semantics, and the reader behind each. (lb sections gives the one-line version.)

Enable or disable a section

lb add <name> appends a section; lb enable <name> / lb disable <name> toggle one in place (a line edit — comments survive). Never delete a block just to disable it, and don't hand-edit enabled — the CLI owns that key.

Invent a NEW section (how this skill grows)

When the user and I design a new .lightbridge feature, follow references/extending.md: build the reader (resolving config through scripts/lightbridge), register it in catalog.md, add its template block to SECTIONS in scripts/lightbridge/lightbridge.py, sync the one-line brief in agent-instruction/AGENTS.qmd, bump metadata.version, and validate.

Source of truth

This skill is the canonical spec for .lightbridge. Each feature's internals live with its implementation (e.g. the docs-index hook README) and are linked from the catalog — not re-documented here. AGENTS.qmd keeps only the brief plus a pointer to this skill.

More from this repository

same repository

agentic-architecture

Lightbridge-KS/agent-stuff

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.

2026-07-151

ax-interface

Lightbridge-KS/agent-stuff

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").

2026-07-151

codebase-blueprint

Lightbridge-KS/agent-stuff

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.

2026-07-151

data-architecture

Lightbridge-KS/agent-stuff

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.

2026-07-151

explain-as-notebook

Lightbridge-KS/agent-stuff

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.

2026-07-151

surface-architecture

Lightbridge-KS/agent-stuff

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.

2026-07-151

name	lightbridge-config
description	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.
metadata	{"version":"2026-07-16"}

.lightbridge config

~/.lightbridge/projects/<project-key>/config.toml    # namespaced by [section]

resolved by scripts/lightbridge (agent-stuff): project root = git toplevel of cwd, key = root path with separators → -.

The one rule — opt-in by section presence. A feature is on iff its [section] exists; enabled = false disables without deleting.

Full spec (conventions, sections, keys, who reads them): references/catalog.md.

The CLI does the mechanical work

lb status                # FIRST MOVE for "what's lightbridge doing here?" — one dashboard
lb init                  # create this project's config; detects docs/ → [docs-index]
lb init research repo-links   # or name sections; --dry-run to preview
lb add repo-links        # extend an existing config (skips sections already there)
lb show [SECTION]        # print the stored config (or one block); --json to parse
lb enable|disable NAME   # flip a section's `enabled` in place (idempotent)
lb sections              # what can go in a config, and who reads it
lb path                  # where this project's config lives (+ exists?)
lb repos list|add|rm     # manage ~/.lightbridge/repos.toml (add never clobbers a name)
lb doctor                # audit the whole tree (stale roots, legacy files)

init never clobbers an existing config (exit 1 — use add), and add / enable / disable are idempotent, so all are safe to re-run. Report back what was written and which reader consumes it.

Explain / "what can go in .lightbridge?"

Read references/catalog.md and answer from it — conventions, sections, keys, opt-in semantics, and the reader behind each. (lb sections gives the one-line version.)