Thanks for your interest in lathe. Contributions are licensed under the Apache License 2.0.
git clone https://github.com/lathe-cli/lathe.git
cd lathe
make check # fmt-check, vet, lint, test — the full quality gateRequires Go (version in go.mod) and golangci-lint. No other tooling needed.
To follow the end-to-end generated CLI workflow, see:
- CLI Usage for the exact
go mod init->lathe bootstrap->go buildpath. examples/petstore,examples/richapi, andexamples/graphqlfor the in-repo generation paths.
Benchmarks live beside the code they measure as *_bench_test.go and cover the
codegen pipeline (spec parsing, normalization) and the generated-CLI runtime
(command building, catalog, search, output rendering).
make bench # go test -bench=. ./...CI runs the same benchmarks on CodSpeed
and reports the performance impact of a pull request against main.
- Fork the repo, create a feature branch off
main. - Keep the change small and focused. Split unrelated work into separate PRs.
- Run
make checkbefore opening the PR. Add focused tests when they protect a stable behavior or regression boundary. - Sign off every commit with
-s:git commit -s -m "...". This attests to the Developer Certificate of Origin (developercertificate.org). - Open a PR describing the problem, the fix, and how you verified it. Link any related issue.
- In scope: codegen accuracy, runtime correctness, spec backend improvements (Swagger 2.0, OpenAPI 3, proto, policy-curated GraphQL), application initialization, bundled Skill installation, test coverage, docs,
Authenticator/Formatterextensions, overlay ergonomics,cli.yamlschema. - Out of scope: new spec formats beyond the supported backends, generic scaffolders, plugin loaders, GUI/TUI. These can ship as sibling projects on top of lathe.
- Commit messages follow Conventional Commits (
feat:,fix:,refactor:,docs:,chore:). Scope is optional. - Error wrapping uses
fmt.Errorf("...: %w", err); never drop context. - Don't commit generated code (
internal/generated/) or upstream clones (.cache/). - For anything data-driven (auth endpoints, CLI identity, spec sources), prefer extending
cli.yaml/specs/sources.yamlover hard-coding.
For system boundaries, package ownership, runtime flow, and capability composition, see docs/architecture.md.
Open an issue with a minimal reproduction: the spec (or its shape), the command you ran, and what you expected vs. what happened. Logs from --debug and -o raw are usually more useful than -o table.
See SECURITY.md for vulnerability reporting.