Skip to content
linkml-sidecar

References

  • Agent Skills specification checked by automation only, still a draft
    The Agent Skills format both skills follow: a folder with a SKILL.md whose frontmatter carries name, description, license and compatibility, checked in CI with gh skill publish –dry-run.

  • Knowledge Trust Ladder checked by automation only, still a draft
    The Knowledge Trust Ladder (KTL), whose bundle is a .lokf/ folder in the host; beside one, the sidecar’s schema becomes the bundle’s domain schema, and ktl-librarian’s domain-schema page is the authority on what lokf validate expects.

  • LinkML checked by automation only, still a draft
    LinkML, the modelling language the sidecar’s schema is written in; linkml.io is the canonical site for what it means, its schemas and its generators (JSON Schema, Pydantic, OWL, SHACL, TypeScript, docs).

  • linkml-project-copier checked by automation only, still a draft
    The upstream copier template (MIT) that every sidecar is made from, pinned at tag v0.5.0 and verified against the commit the scaffold driver records before it runs with –trust.

  • Portability nobody has checked this yet, still a draft
    Which hosts the linkml sidecar works on and what each one loses: macOS, RHEL 8 and 9, WSL2, Windows with Git for Windows or PowerShell, a company proxy, TLS certificates or package mirror, Codeberg and Forgejo, GitLab, no forge, no git, and the template from a company copy instead of github.com.

  • Publishing a schema others can import checked by automation only, still a draft
    linkml-author’s page on how a schema reaches an importer: two addresses under its id (every module at schema/module.yaml and one merged file with no imports), a tagged release with a checksummed asset, a vendored copy at a tag or an import by persistent identifier and never by a code-host URL, the importmap and the order an import resolves in, and lokf’s adapt for a vocabulary that shares names with yours.

  • Schema design for reuse checked by automation only, still a draft
    linkml-author’s page on designing a LinkML schema that others can import and extend: which names reach the data and how a name defined twice across imports is caught (by the gate’s gen-project, not by lint), attributes before slots with fundamental names kept as attributes, mixins, prefixed class names, a core plus modules as the shape importers can take a slice of, type designators instead of kind enums, typed references, no enum inheritance, minor releases that only add, and when a schema that exists can still be refactored.

  • Template assumptions catalogue nobody has checked this yet, still a draft
    The catalogue, at template v0.5.0, of the twenty things linkml-project-copier assumes of a repository root (just setup, just deploy, nested workflows, the governance files, mkdocs URLs, –trust, just update, config.public.mk, the generators’ settings and more), what the scaffold does about each, and which an upstream layout answer would remove.

  • Where a LinkML schema lives checked by automation only, still a draft
    The rule both skills apply to find a LinkML schema in any repository: copier answers naming linkml-project-copier, a config.public.mk, or a schema file found by content; where the preflight looks; and how –adopt gives a found schema the toolchain in place.