logos-discovery

name	logos-discovery
description	Use when the user needs to discover the right Logos repo, choose a module, inspect a repo before editing, decide on a module shape, plan Basecamp integration, or operate logoscore. This is the single entry skill for Logos orientation, routing, and pre-build decisions.

Logos Discovery

This skill covers discovery, module selection, repo inspection, module shape decisions, Basecamp integration planning, and logoscore operation. Use it before the builder skills.

Quick start

• Read references/repo-entrypoints.md to find the right starting files for the user's question.
• Read references/module-inventory.md when the user needs to choose a module or understand dependencies.
• Read references/module-shapes.md when the user needs to decide between core, ui_qml, or legacy ui.
• Read references/platform-overview.md for Basecamp architecture, logoscore patterns, and known gaps.

When the target project has its own CLAUDE.md (e.g. logos-workspace/CLAUDE.md, logos-basecamp/CLAUDE.md), prefer that file over bundled references for build commands, CLI usage, and architecture details.

Workflow

1. Identify what the user needs:

   • Stack orientation or repo discovery
   • Module or UI surface selection
   • Repo inspection before editing
   • Module shape decision (core / ui_qml / legacy ui)
   • Basecamp vs backend boundary planning
   • Logoscore mode and command selection
   • A documented scenario flow (route to logos-documented-scenarios)

2. For discovery and orientation:

   • Start with references/repo-entrypoints.md for first files to read.
   • Prefer inspected local code and READMEs over bundled snapshots.
   • If a logos-docs page is stubbed, say that explicitly and fall back to local repo sources.

3. For module selection:

   • Use references/module-inventory.md for the module table.
   • Use metadata names (not folder names) when discussing runtime loading.
   • Pair UI repos with their backend dependency before recommending edits.

4. For repo inspection:

   • Read metadata.json first, then README, then build files, then source as needed.
   • Separate facts (from metadata and docs) from inferences (from structure).
   • Recommend validation in increasing cost: static inspection, artifact inspection (lm), runtime inspection (logoscore or Basecamp).

5. For module shape decisions:

   • Backend logic or library wrapper -> core
   • Visible UI calling existing backends -> QML-only ui_qml
   • Visible UI needing typed backend, .rep, or ui-host flow -> backend-backed ui_qml
   • Existing IComponent repo -> legacy ui (only when target repo already uses it)

6. For Basecamp boundary planning:

   • Visible Basecamp screen or tab -> UI app
   • Protocol, storage, network, or shared service logic -> backend module
   • Feature needing both -> design both pieces with an explicit boundary
   • New QML work -> prefer ui_qml over legacy ui

7. For logoscore operation:

   • Long-running runtime with repeated commands -> daemon + client mode
   • Single-process one-off -> inline mode
   • Script or agent output -> prefer --json

8. Route to the right builder skill:

   • core module implementation -> logos-core-module-builder
   • ui_qml implementation -> logos-ui-qml-builder
   • Build, package, install, or debug loop -> logos-module-build-loop
   • Standalone Scaffold/LEZ project -> logos-scaffold-bootstrap
   • Documented operator flow -> logos-documented-scenarios

Source priority

1. Inspected local repo files and code
2. Local repo READMEs and CLAUDE.md files
3. Local logos-docs pages
4. Bundled skill references in this repo
5. External links already referenced by local source material

If code and README disagree, say so and prefer the inspected code for current behavior.

Reference map

• references/repo-entrypoints.md -> starting files for common Logos questions
• references/module-inventory.md -> full module table from logos-modules/*/metadata.json
• references/module-shapes.md -> module type decision tree, minimal file sets, core vs UI distinction
• references/platform-overview.md -> Basecamp architecture, logoscore patterns, known gaps and naming issues

Quality rules

• Prefer the target project's own CLAUDE.md for build commands, CLI usage, and architecture.
• Treat inspected local code as more authoritative than bundled snapshots.
• Do not present stub docs as complete instructions.
• Distinguish Basecamp, logoscore, modules, and Scaffold surfaces.
• Call out naming mismatches (e.g. folder name vs metadata name vs runtime name).
• When a logos-docs page is a stub, say that explicitly.