nim-api-design

Review Nim proc and template interfaces for contract and error-surface design.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/planetis-m/skills_experiment --skill nim-api-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nim-api-design
Source: https://github.com/planetis-m/skills_experiment/tree/main/original_skills/nim-api-design
Command: npx skills add https://github.com/planetis-m/skills_experiment --skill nim-api-design

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Nim public APIs often end up with unclear contracts, inconsistent error behavior, and leaky data-model decisions that make callers misuse or require defensive boilerplate.

Core Features & Use Cases

  • Clear contract-first API design: Keeps proc/template contracts strong and consistent without weakening types, then compensating with ad-hoc runtime checks.
  • Coherent data-model choices: Prefers named object types for semantic data and uses tuples only for tiny local values.
  • Strict accessor error behavior: Designs accessors so invalid or missing required data raises ValueError via a shared helper for consistency, while using lent and var overloads appropriately.

Quick Start

Ask an AI to review your Nim API draft and rewrite the procs, objects, and accessors to follow strict contract rules and consistent ValueError behavior.

Frequently Asked Questions about nim-api-design

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

FAQPage Schema
How do I design Nim APIs with clear contracts and strict error handling?

Design Nim APIs with clear contracts by enforcing strong types in proc and template interfaces, avoiding redundant runtime checks. Route accessor failures through a shared noinline noreturn ValueError helper for consistent error handling.

What's the best way to handle errors in Nim data accessors?

Handle Nim data accessor errors by routing invalid or missing required data through a shared noinline noreturn ValueError helper. Use lent and var overloads appropriately to maintain strict, consistent error behavior.

When should I use named object types versus tuples for data modeling in Nim?

Prefer named object types in Nim for semantic data to preserve type meaning across domain-specific libraries. Use tuples only for tiny local values to maintain coherent data model choices.

How do I review an existing Nim API draft for contract consistency?

Review a Nim API draft by evaluating procs, objects, and accessors against strict contract rules. Ensure interfaces avoid ad-hoc runtime checks at non-boundary levels and use consistent ValueError behavior.

Does using lent and var overloads improve Nim API accessor behavior?

Using lent and var overloads appropriately in Nim APIs ensures predictable accessor behavior without weakening types. This maintains strict contracts while routing failures consistently through ValueError.