api-design
FreeBest practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.
The English summary is being prepared. Showing the original description.
Guide for regenerating Axone contract schemas and rendered Markdown docs. Use when contract APIs or metadata change, when checking generated-doc drift, or when preparing documentation commits.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Generated docs come from Rust API types and schema metadata:
Rust messages/types + metadata.json
↓
contracts/*/schema/*
↓
docs/*.md
In this repository, the canonical command is:
cargo make docs
Do not treat docs/*.md as hand-edited source files. The Rust types and metadata are the source of truth.
cargo make docs really doescargo make docs already depends on:
npx, awk, perl, jq)cargo make schemaThat means one docs refresh can update both:
contracts/*/schema/*docs/*.mdcargo make docs
git status --short
git diff -- docs contracts
If the change is documentation generation only, prefer a message such as:
docs(gov): regenerate documentation
docs(vc): regenerate documentation
docs: regenerate generated documentation
Avoid vague subjects such as docs: update generated documentation.
Refresh generated docs whenever you change:
msg.rsmetadata.jsonsrc/bin/schema.rsMakefile.tomlAfter regeneration, review and commit all relevant generated artifacts:
docs/*.mdcontracts/*/schema/*Even if CI only reports drift on docs/*.md, schema files are still generated source artifacts in this repo and should stay in sync with the code.
cargo make docs is the preferred entrypoint; it already triggers schema generation.@fadroma/schema, jq, awk, perl, and prettier through Makefile.toml.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Best practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.
The English summary is being prepared. Showing the original description.
Guide for writing Rust doc comments that produce accurate generated contract documentation. Use when editing Instantiate/Execute/Query/Response types or any public schema-facing API.
The English summary is being prepared. Showing the original description.
Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.
The English summary is being prepared. Showing the original description.
Axone contract structure and Abstract SDK patterns. Use when scaffolding or refactoring contracts, deciding layer boundaries, wiring AppContract entrypoints, or adding module metadata and replies.
The English summary is being prepared. Showing the original description.
Axone deployment workflows with cargo-make, cw-orch, and Abstract. Use when publishing modules, installing them on accounts, running local chain tasks, or inspecting deployments.
The English summary is being prepared. Showing the original description.
Domain-driven modeling patterns for Axone contracts. Use when introducing domain concepts, encoding invariants, or deciding boundaries between domain, handlers, services, gateways, queries, and state.
The English summary is being prepared. Showing the original description.