Agent skill
moonbit
MoonBit language development best practices for AI agents. Use when writing, refactoring, or testing MoonBit code, working with moon tooling (build/check/test/fmt/info), navigating MoonBit projects, or following MoonBit-specific conventions for syntax, testing, and project layout.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/moonbit
SKILL.md
MoonBit Development Guide
Quick Start
MoonBit is an expression-oriented language with garbage collection (no lifetimes/ownership). Key characteristics:
- Expression-oriented:
if,match, loops return values - Block separator: Use
///|between top-level declarations - Error handling: Checked errors with
raisekeyword, automatic propagation - Packages: No
importin code; configure inmoon.pkg/moon.pkg.json
Agent Workflow
Follow this order for reliable task execution:
- Clarify goal - Confirm expected behavior and constraints
- Locate boundaries - Find
moon.mod.json(module root) and relevantmoon.pkgfiles - Discover APIs - Use
moon ide docbefore coding - Refactor semantically - Use
moon ide renamefor symbol renaming - Edit locally - Keep changes package-local with
///|delimiters - Validate - Run
moon checkregularly, then targeted tests - Finalize - Run
moon fmtandmoon infobefore completion
Essential Commands
| Command | Purpose |
|---|---|
moon check |
Fast type check (use frequently) |
moon test |
Run tests |
moon test -u |
Update snapshot tests |
moon test --filter 'glob' |
Run specific tests |
moon fmt |
Format code |
moon info |
Generate .mbti interface files |
moon ide doc "query" |
Discover APIs |
moon ide outline . |
List package symbols |
moon ide rename sym new |
Rename symbol project-wide |
Common Syntax
///|
/// Block separator (///|) required between top-level items
///|
/// Function with type parameter
fn[T] identity(val: T) -> T { val }
///|
/// Error handling with raise
fn parse(s: String) -> Int raise ParseError {
if s.is_empty() { raise ParseError::InvalidEof }
// errors propagate automatically
s.to_int()
}
///|
/// Struct with derive
struct Point {
x: Int
y: Int
} derive(Show, Eq, ToJson)
///|
/// Method syntax
fn Point::distance(self: Point, other: Point) -> Double {
// ...
}
Code Navigation: Prefer moon ide over Read/Grep
# ❌ Avoid: Reading files directly or grep
Read src/parser.mbt
grep -r "fn parse" .
# ✅ Use: Semantic navigation
moon ide peek-def Parser::parse
moon ide outline src/parser.mbt
moon ide find-references parse
moon ide doc "String::*rev*"
Why: moon ide provides semantic search, distinguishes definitions from call sites, and is more accurate than grep (which picks up comments).
Critical Pitfalls to Avoid
See references/pitfalls.md for detailed explanations.
- Variables/functions: lowercase only (uppercase = compilation error)
- Mutability:
mutonly for reassignment, not field mutation (Array push doesn't need it) - Return: Last expression is return value; don't use
returnunnecessarily - Methods: Require
Type::prefix - Operators: No
++/--; usei += 1 - Error propagation: No explicit
tryneeded (unlike Swift) - Async: No
awaitkeyword; just declareasync fn - String indexing: Returns
UInt16, notChar. Uses.get_char(i)forChar?
Project Structure
my_module/
├── moon.mod.json # Module metadata
├── moon.pkg # Root package config (or moon.pkg.json)
├── lib/
│ ├── moon.pkg # Package config
│ └── utils.mbt
├── cmd/main/
│ ├── moon.pkg # {"is_main": true}
│ └── main.mbt
├── lib_test.mbt # Black-box tests
└── lib_wbtest.mbt # White-box tests (access private members)
Key rules:
moon.mod.json= module root (like Go module)moon.pkg/moon.pkg.json= package boundary (each directory = one package)- File names are organizational only; all files in a package share namespace
- Move declarations freely between files in the same package
Testing
Snapshot Tests
///|
test "example" {
let result = compute([1, 2, 3])
inspect(result, content="") // Run `moon test -u` to auto-fill
}
After moon test -u:
inspect(result, content="6")
Use @json.inspect() for complex nested structures.
Test Organization
- Black-box by default (
*_test.mbt) - test public APIs only - White-box when needed (
*_wbtest.mbt) - access private members - Group related checks in one test block
- Panic tests:
test "panic ..." { ignore(panic_fn()) }
References
- Language Fundamentals - Core syntax and types
- Common Pitfalls - Mistakes to avoid
- Build Configuration - moon.mod.json and moon.pkg
- IDE Tools - moon ide commands
- API Discovery - Using moon doc
- Testing Guide - Comprehensive testing patterns
- Refactoring Guide - Safe refactoring workflows
Task Playbooks
Bug Fix (No API Change)
- Reproduce failing behavior
- Locate symbols with
moon ide - Implement minimal fix
- Validate:
moon check,moon test [scope],moon fmt,moon info
Refactor (Behavior Preserving)
- Confirm behavior invariants
- Use
moon ide renamefor semantic refactoring - Keep edits package-local
- Validate: API unchanged in
.mbtifiles
New Feature/Public API
- Discover idioms with
moon ide doc - Add implementation with docstring examples
- Add black-box tests
- Validate:
moon check,moon test,moon fmt,moon info(review.mbtichanges)
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?