Contributing to SKaiNET — Audience and Scope

Audience: SKaiNET maintainers and contributors. These pages document how the project is built, measured, and released. If you are consuming SKaiNET as a library — pulling artifacts from a BOM, calling ctx.ops.matmul, loading a GGUF model — you do not need to read anything in this section. The Tutorials, How-to, Reference, and Explanation sections cover everything a library user needs.

What this section covers

The Contributing section is for the engineer who:

Builds SKaiNET from source.
Runs or extends the official benchmark suite.
Maintains the CI workflows (smoke runs on ubuntu-latest, full publishable runs on the self-hosted lane).
Adds or replaces kernels in the CPU backend (scalar, Panama Vector, the native FFM provider).
Operates the self-hosted runner that publishes benchmark results.
Picks up a first task from the skill-labelled issue backlog, or files one for others to pick up.
Takes a feature through the DARC workflow (Document / Assess / Research / Code).
Drafts or reviews durable API and architecture proposals in the SKEEP proposal track.

Concretely:

Page What it answers

Page	What it answers
Getting started as a contributor	Start here. The two workflows (DARC for features, SKEEP for design decisions), when each applies, how work is split into skill lanes, and how to find and claim a first task.
DARC: advanced contribution workflow	The four phases, when DARC applies, the operator-documentation specialisation and the `@DarcValidated` badge.
Worked example: F1Score via DARC	One feature taken through all four phases and decomposed into lane sub-issues, including where it hands a question over to SKEEP.
Issue taxonomy	Every label, title prefix, and issue template, plus the `gh` commands to decompose a feature into sub-issues.
Build from source	How to clone, build, and run the test suite locally.
Engine benchmark program	The Phoronix Test Suite / OpenBenchmarking publication path: methodology, manifest, lanes, CI workflow, replay, and the gated steps to actually publish a run to OpenBenchmarking.org.
Reading the matmul benchmark	What the published numbers mean — scalar vs. Panama vs. quantized regimes, roofline reasoning, and a checklist for interpreting any new measurement.
Register a self-hosted bench runner	The one-time operator setup that lights up the full-publish CI lane on a Linux x86 box.
SKEEP proposal track	How SKaiNET records long-lived API, DSL, runtime, compiler, storage, and compatibility proposals.

Getting started as a contributor

Start here. The two workflows (DARC for features, SKEEP for design decisions), when each applies, how work is split into skill lanes, and how to find and claim a first task.

DARC: advanced contribution workflow

The four phases, when DARC applies, the operator-documentation specialisation and the @DarcValidated badge.

Worked example: F1Score via DARC

One feature taken through all four phases and decomposed into lane sub-issues, including where it hands a question over to SKEEP.

Issue taxonomy

Every label, title prefix, and issue template, plus the gh commands to decompose a feature into sub-issues.

Build from source

How to clone, build, and run the test suite locally.

Engine benchmark program

The Phoronix Test Suite / OpenBenchmarking publication path: methodology, manifest, lanes, CI workflow, replay, and the gated steps to actually publish a run to OpenBenchmarking.org.

Reading the matmul benchmark

What the published numbers mean — scalar vs. Panama vs. quantized regimes, roofline reasoning, and a checklist for interpreting any new measurement.

The one-time operator setup that lights up the full-publish CI lane on a Linux x86 box.

SKEEP proposal track

How SKaiNET records long-lived API, DSL, runtime, compiler, storage, and compatibility proposals.

What this section deliberately does not cover

How to call SKaiNET from your code. See the Tutorials and How-to sections (Java getting started, Load models, Train a model from Java).
What an operator does or how the public DSL works. See Operator reference and the Explanation pages.
Branch policy, commit conventions, or the detailed SKEEP authoring procedure. Those live in repo-root files: CONTRIBUTING.md, GITFLOW.adoc, CHANGELOG.md, FAQ.md. The published docs site intentionally does not duplicate them; they belong with the code. (CONTRIBUTING.md carries a short summary of the DARC/SKEEP split and the issue taxonomy and links back here for the full text.)

Conventions used in this section

Every Contributing page opens with an Audience admonition so readers landing from a search hit immediately know whether the content is for them. Commands assume a POSIX shell and the SKaiNET repo as the current working directory. Code paths in the running text are file-relative from the repo root (for example scripts/run_engine_benchmarks.sh, not absolute paths).