writing-motoko

Write and review Motoko canister code with mo:core v2.0.0+ conventions.

588|127|Updated May 11, 2018
One-click install
npx skills add https://github.com/caffeinelabs/motoko --skill writing-motoko
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing-motoko
Source: https://github.com/caffeinelabs/motoko/tree/main/.agents/skills/writing-motoko
Command: npx skills add https://github.com/caffeinelabs/motoko --skill writing-motoko

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

writing-motoko helps you produce modern Motoko that compiles cleanly and matches best-practice patterns for canister development, especially around persistence, upgrades, and maintainable multi-file architecture.

Core Features & Use Cases

  • Modern persistence & upgrades: Uses enhanced orthogonal persistence conventions and avoids unnecessary stable/upgrade hooks.
  • Safe, consistent coding style: Enforces dot-notation for self-parameter functions, contextual dot calls for core types, and avoids common compiler error patterns.
  • Principled canister architecture: Recommends a types.mo / lib/ / mixins/ / main.mo layout with mixins for service composition.
  • Upgrade/migration readiness: Provides guidance for enhanced migration constraints and where to load migrating-motoko variants.
  • API boundary correctness: Encourages shared types for public functions and conversions from internal mutable containers.

Quick Start

Use the writing-motoko skill when editing your canister .mo files by asking the AI to refactor your code to match the skill’s Motoko conventions for mo:core, dot notation, enhanced persistence, and a types/lib/mixins/main architecture.

Frequently Asked Questions about writing-motoko

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I use enhanced orthogonal persistence in Motoko canister development?

Enhanced orthogonal persistence in Motoko canister development is applied by following specific conventions that avoid unnecessary stable variables and upgrade hooks. This approach maintains state automatically across actor upgrades without manual serialization code.

What is the best way to structure a multi-file Motoko canister project?

The best way to structure a multi-file Motoko canister project is using a types.mo, lib/, mixins/, and main.mo layout. This architecture separates shared types, internal libraries, and composable service mixins for maintainable code.

Why does my Motoko code fail when calling core type functions without dot notation?

Motoko code fails when calling core type functions without dot notation because consistent contextual dot calls for mo:core types are required. Enforcing dot-notation for self-parameter functions prevents common compiler error patterns.

Do I need shared types for public function boundaries in Motoko actors?

Yes, you need shared types for public function boundaries in Motoko actors. Converting from internal mutable containers to shared types ensures safe API boundaries and correct public interactions across your canister code.

How do I handle actor upgrades and migration constraints in Motoko?

To handle actor upgrades and migration constraints in Motoko, follow enhanced migration guidelines and load migrating-motoko variants where needed. This ensures state compatibility and correct persistence during canister upgrades.