메뉴
Single entry point for all MoonBit skills. Routes to the right specialist based on what you need: code quality, trait design, extensibility, performance, FFI, repo maintenance, etc. Use /moonbit <what you need> instead of remembering individual skill names.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Error handling conventions for MoonBit projects. Use when designing error types, choosing between abort/fail/raise, writing catch blocks, defining FFI boundaries, or reviewing error handling patterns. Triggers on: error handling, abort, fail, raise, catch, Result, error types, fallible functions, boundary safety, error recovery.
Use when reviewing a MoonBit/Canopy change or pull request before merge and multiple independent review perspectives are useful
Use when writing or reviewing MoonBit code against the `dowdiness/incr` reactive library (v0.14.x+) — building Inputs/Deriveds/ReachableDeriveds, attaching long-lived derived cells with `Watch`/`Observer`, adding microbenchmarks, or wrapping a reactive pipeline in a struct. Catches recurring idiom misses (inside-vs-outside read semantics, GC-anchor `Watch`/`Observer`, `Type::Type` constructor naming, defensive copies).
Use when creating or editing a GitHub PR/issue body, comment, or commit message from a shell, or when writing a grep/rg search pattern — especially if the Markdown or pattern contains backticks, `$()`, `>`, or other shell metacharacters that could be expanded before the tool sees them.
Use when creating, removing, or working across git worktrees or submodules — before force-pushing, before deleting a worktree, after `git worktree add`, when merging or deleting branches with `gh pr merge`/`gh pr close`, when bumping a submodule pointer, when merging a stack of dependent PRs, or when another agent/process may be operating on the same checkout concurrently.
Use when writing MoonBit code involving derive(Debug) on container fields, a trait method whose name matches a callable field, JS-target-only public APIs or JS numeric formatting, `guard` early-exit syntax, package visibility (`pub` vs `pub(all)`) on mutable-container fields, or `moon fmt` touching a comment-only or multi-line closure body — silent-failure compiler/formatter behaviors that `moon check` and `moon fmt` don't flag.
SOC 직업 분류 기준
| name | moonbit |
| description | Single entry point for all MoonBit skills. Routes to the right specialist based on what you need: code quality, trait design, extensibility, performance, FFI, repo maintenance, etc. Use /moonbit <what you need> instead of remembering individual skill names. |
Single entry point: /moonbit <what you need>
Read the user's request and invoke the matching skill(s) below. If multiple skills apply, invoke them in order.
| User intent | Invoke skill | Examples |
|---|---|---|
| Code smells, idiomatic code, refactoring, deprecated syntax | moonbit-refactoring | "is this idiomatic?", "code smell", "clean up", "deprecated?" |
| Error handling, abort vs fail vs raise, error types, boundaries | moonbit-error-handling | "should I abort or raise?", "error type design", "FFI error boundary" |
| Trait design, trait patterns, newtypes, opaque types | moonbit-traits | "should I use a trait?", "type-safe wrapper", "hide internals" |
| Extensibility, expression problem | moonbit-expression-problem | "add new variant", "finally tagless", "extensible data" |
| Performance investigation | moonbit-perf-investigation | "optimize", "slow", "bottleneck", "speed up" |
| C FFI bindings | moonbit-c-binding | "C library", "extern c", "native FFI" |
| Repo maintenance, lint, sync | moonbit-housekeeping | "clean up repo", "lint", "before PR" |
| Pre-commit quality checklist | moonbit-verification | "check before commit", "verify code" |
| Skill | Purpose | When loaded |
|---|---|---|
moonbit-deprecated-syntax | Full deprecated syntax reference table | Embedded in moonbit-refactoring; standalone for detailed lookup |
moonbit-settings | Claude Code config for MoonBit projects | Only on explicit "set up settings" requests |
moonbit:moonbit-agent-guide | General MoonBit workflow/tooling | Only on explicit "how to use moon" requests |
moonbit-opaque-types merged into moonbit-traits (opaque types = newtype implementation detail)moonbit-deprecated-syntax merged into moonbit-refactoring (deprecated syntax = part of "write idiomatic code")If the user's intent doesn't clearly match one skill, ask:
What aspect are you looking at?
- Code quality / idioms
- Type design (traits, newtypes, extensibility)
- Performance
- FFI / bindings
- Repo maintenance
Some requests need multiple skills:
moonbit-refactoring + moonbit-verificationmoonbit-traitsmoonbit-traits + moonbit-expression-problemmoonbit-perf-investigationmoonbit-error-handlingmoonbit-error-handling