CLI tour

Informative guide. This Book page explains Beskid but does not define the standard. For normative requirements, use the Beskid Standard.

The CLI is the ground truth. Editors are a pretty face on the same pipeline.

Global behavior

• Response files: @file expansion (Rust argfile convention).
• Failures: diagnostic report (miette) + non-zero exit unless noted.
• Corelib: materialized on launch; override with BESKID_CORELIB_SOURCE.

Full tables: CLI command reference. The optional grouped discovery aliases are documented once on the beskid dev page.

Commands you will actually press

Command	Why you care
parse / tree	”Did the parser see my file?”
analyze	Semantic diagnostics before you blame codegen
format	Stop formatting debates
fetch / lock / update	Dependencies and reproducibility
build / run	Ship something executable
test	Run test items in the project
new	Templates for projects/workspaces/items
doc	api.json + markdown API output
corelib	Materialize embedded corelib template
pckg	Registry client when you publish packages

accTitle: Concise CLI workflow
accDescr: File commands inspect source, then project commands prepare dependencies before build, run, and test.
flowchart TD
  subgraph day1 [Day one]
    P[parse/tree] --> A[analyze]
    A --> F[format]
  end
  subgraph project [With App.bproj]
    A --> Fetch[fetch/lock]
    Fetch --> B[build/run/test]
  end

Text equivalent: Use parse, tree, analyze, and format for source checks. In a project, use fetch or lock before build, run, or test.

Project-scoped flags

When a manifest exists, prefer explicit roots while learning:

beskid analyze --project ./App.bproj --target App

--frozen / --locked participate in resolution policy—see fetch and lock.

Next

Logging and debug flags