midnight-tooling:midnight-compatibility
Use when checking Midnight version compatibility, understanding pragma language_version, verifying compiler and runtime version relationships, or troubleshooting version mismatch errors between Midnight components.
Best use case
midnight-tooling:midnight-compatibility is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when checking Midnight version compatibility, understanding pragma language_version, verifying compiler and runtime version relationships, or troubleshooting version mismatch errors between Midnight components.
Teams using midnight-tooling:midnight-compatibility should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/midnight-tooling-midnight-compatibility/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How midnight-tooling:midnight-compatibility Compares
| Feature / Agent | midnight-tooling:midnight-compatibility | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when checking Midnight version compatibility, understanding pragma language_version, verifying compiler and runtime version relationships, or troubleshooting version mismatch errors between Midnight components.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Midnight Version Compatibility
Understanding version relationships between Midnight components.
## Component Overview
Midnight development involves multiple versioned components:
| Component | Purpose | Version Check |
|-----------|---------|---------------|
| Compact Developer Tools | CLI for managing compilers | `compact --version` |
| Compact Compiler | Compiles .compact to ZK circuits | `compact compile --version` |
| compact-runtime | JavaScript runtime library | `npm list @midnight-ntwrk/compact-runtime` |
| ledger | Core ledger types | `npm list @midnight-ntwrk/ledger` |
| midnight.js | JavaScript SDK | `npm list @midnight-ntwrk/midnight.js` |
| Proof Server | ZK proof generation | Docker image tag |
## Version Relationships
```
Language Version (in pragma)
│
▼
┌─────────────────────────┐
│ Compact Compiler │ ──── Produces ───▶ Contract Artifacts
│ (e.g., 0.26.0) │
└─────────────────────────┘
│
│ Must match
▼
┌─────────────────────────┐
│ compact-runtime │
│ (e.g., 0.9.0) │
└─────────────────────────┘
│
│ Compatible with
▼
┌─────────────────────────┐
│ ledger, midnight.js │
│ Proof Server │
└─────────────────────────┘
```
## Checking Current Compatibility Matrix
The authoritative source is the support matrix in Midnight release notes.
To check current recommended versions:
```bash
/midnight:versions
```
Or parse directly:
```bash
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/parse-support-matrix.py
```
## Pragma Language Version
Every Compact contract must declare its language version:
```compact
pragma language_version 0.18;
ledger {
// ...
}
```
### Pragma Rules
1. **Must match compiler capability**: The compiler must support the declared version
2. **Consistency**: All contracts in a project should use the same pragma
3. **Update on upgrade**: When upgrading compiler, update pragma if language version changed
### Finding Language Version for Compiler
The compiler version (e.g., 0.26.0) maps to a language version (e.g., 0.18.0):
```bash
# Check release notes for mapping
/midnight:changelog compact
```
Recent mappings (verify with release notes):
- Compiler 0.26.0 → Language 0.18.0 (Minokawa)
- Compiler 0.25.0 → Language 0.17.0
## Package Version Guidelines
### Use Exact Versions
In `package.json`, always use exact versions:
```json
{
"dependencies": {
"@midnight-ntwrk/compact-runtime": "0.9.0",
"@midnight-ntwrk/ledger": "4.0.0",
"@midnight-ntwrk/midnight.js": "2.1.0"
}
}
```
**Never use**:
- `^0.9.0` (allows minor updates)
- `~0.9.0` (allows patch updates)
- `>=0.9.0` (allows any newer version)
### Why Exact Versions Matter
Midnight components have strict compatibility requirements. A minor version bump in one component may require updates to others. Using ranges can lead to:
- Silent incompatibilities
- Works-on-my-machine issues
- CI failures with different lockfiles
## Using npm ci
For reproducible builds, use `npm ci` instead of `npm install`:
```bash
# npm ci uses exact versions from package-lock.json
npm ci
# npm install may update within semver ranges
npm install # Avoid for production
```
## Compiler Version Management
### List Available Versions
```bash
compact list
```
### List Installed Versions
```bash
compact list --installed
```
### Switch Default Version
```bash
# Update to latest
compact update
# Switch to specific version
compact update 0.25.0
```
### Use Specific Version for One Compilation
```bash
# Prefix with +version
compact compile +0.25.0 src/contract.compact contract/
```
This is useful for:
- Testing against multiple compiler versions
- Maintaining older contracts while developing new ones
- Gradual migration
## Proof Server Versions
The proof server must be compatible with your contracts:
```bash
# Check available tags
docker search midnightnetwork/proof-server
# Pull specific version
docker pull midnightnetwork/proof-server:4.0.0
# Run specific version
docker run -p 6300:6300 midnightnetwork/proof-server:4.0.0 -- midnight-proof-server --network testnet
```
## Breaking Changes Between Versions
When upgrading, check release notes for breaking changes:
```bash
/midnight:changelog compact
```
Common breaking changes include:
- New reserved keywords (e.g., `slice` in 0.18.0)
- Runtime function renames
- Type system changes
- New pragma requirements
## Version Upgrade Workflow
1. **Check current versions**: `/midnight:versions`
2. **Check target versions**: Review compatibility matrix
3. **Read release notes**: `/midnight:changelog <component>`
4. **Update package.json**: Use exact versions
5. **Update compiler**: `compact update <version>`
6. **Update pragma**: If language version changed
7. **Clean install**: `rm -rf node_modules && npm ci`
8. **Recompile**: `compact compile src/*.compact contract/`
9. **Test**: Run your test suite
## Additional Resources
- **`references/compatibility-matrix.md`** - Detailed version compatibility table
- **`references/pragma-guide.md`** - Pragma declaration guide
For troubleshooting version issues, see the `midnight-debugging` skill.Related Skills
windows-compatibility
Guidelines for working on Windows with Git Bash. Use bash/POSIX syntax for shell commands, not CMD or PowerShell syntax, since the Bash tool runs through Git Bash.
tooling
Python development tooling configuration and best practices
monorepo-and-tooling
Outlines the monorepo structure and tooling conventions, emphasizing the use of Taskfile.yml, and proper handling of environment variables.
midnight-tooling:midnight-setup
Use when setting up Midnight development environment, installing Compact compiler and developer tools, configuring proof server, verifying prerequisites, or getting started with Midnight development.
cox-tooling-excellence
Write Go code in the style of Russ Cox, Go tech lead. Emphasizes tooling, module design, correctness, and backward compatibility. Use when designing packages, modules, or tools that others will depend on.
agent-tooling-engineer
Expert tooling engineer specializing in developer tool creation, CLI development, and productivity enhancement. Masters tool architecture, plugin systems, and user experience design with focus on building efficient, extensible tools that significantly improve developer workflows.
midnight-dapp:testing-patterns
Use when writing unit tests for Midnight contract interaction code, integration testing without ZK proofs, E2E testing with Playwright or Cypress, or setting up CI/CD pipelines for Midnight DApps.
pcf-tooling
Get Microsoft Power Platform CLI tooling for Power Apps Component Framework Triggers on: **/*.{ts,tsx,js,json,xml,pcfproj,csproj}
angular-tooling
Use Angular CLI and development tools effectively in Angular v20+ projects. Use for project setup, code generation, building, testing, and configuration. Triggers on creating new projects, generating components/services/modules, configuring builds, running tests, or optimizing production builds.
ado-windows-git-bash-compatibility
Windows and Git Bash compatibility guidance for Azure Pipelines. Covers path conversion issues, shell detection in pipeline scripts, MINGW/MSYS path handling, Windows agent configuration, cross-platform script patterns, and troubleshooting common Windows-specific pipeline failures.
bgo
Automated Blender build-go workflow. Automatically builds, removes old version, installs, enables, and launches Blender with your extension/add-on. Use when you want to quickly test changes, execute complete build-to-launch cycle, or run custom packaging scripts with automatic Blender launch.
maintenance
Cleans up and organizes project files. Use when user mentions '整理', 'cleanup', 'アーカイブ', 'archive', '肥大化', 'Plans.md', 'session-log', or asks to clean up old tasks, archive completed items, or organize files. Do NOT load for: 実装作業, レビュー, 新機能開発, デプロイ.