How do I install the Kubit Designing API skill?

Run npx skillmds@latest add tomevault-io/kubit-designing-api in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Kubit Designing API safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Kubit Designing API?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Kubit Designing API free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Kubit Designing API?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Kubit Designing API by tomevault-io

Name: Kubit Designing API
Author: tomevault-io

File contents

Designing Kubit APIs

Overview

Design APIs by starting with ideal usage in skeleton/, then codifying as types in packages/core/, then documenting in SPEC.md.

When to Use

Adding new method, decorator, or export to framework
Modifying existing API signatures
Defining types in packages/core/*.d.ts
User asks "how should this API look?"

API Design Flow

digraph api_flow {
  "Write usage in skeleton/" -> "Add types to packages/core/" -> "Document in SPEC.md" -> "Verify tsc passes";
}

Usage First: Write the ideal developer experience in skeleton/
Types Second: Add ambient types to make it compile
Spec Third: Document with TypeScript signatures
Verify: Run tsc --noEmit in skeleton/

Design Principles

Principle	Application
DX First	How does this feel to use? Start from skeleton.
Type Safety	Can TypeScript catch mistakes at compile time?
Conventions	Follow Laravel/Rails patterns where sensible
Minimal API	Smallest surface that solves the problem
Extensibility	Can users extend without modifying core?

Patterns in Use

Decorators: @column(), @before(), @property(), @use() - metadata on classes/properties

Method Chaining: router.get('/').name('home') - fluent API for configuration

Controller Tuples: [Controller, 'method'] - type-safe handler references

Lazy Relations: @hasMany(() => Post) - arrow function to avoid circular deps

Static Dispatch: Job.dispatch({}), Mailable.send({}) - class-level entry points

Type Definition Location

All public types go in packages/core/:

File	Contents
`kubit.d.ts`	`defineConfig`, `env`, `use`
`router.d.ts`	`router` object, handler types
`orm.d.ts`	`Model`, column decorators, relations
`queue.d.ts`	`Job`, `@property`
`mail.d.ts`	`Mailable`
`db.d.ts`	`Migration`, `schema`
`inertia.d.ts`	`view()`
`http.d.ts`	`HttpContext`
`hash.d.ts`	`hash()`

Checklist Before Adding API

Usage example exists in skeleton/
Types added to packages/core/
tsc --noEmit passes in skeleton/
SPEC.md updated with TypeScript signature
Follows existing patterns (decorators, chaining, etc.)

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: kubit-designing-apidescription: Use when adding new API surface, modifying existing APIs, or defining TypeScript types for framework features. Use when discussing method signatures, return types, decorator APIs, or module exports.---# Designing Kubit APIs## OverviewDesign APIs by starting with ideal usage in skeleton/, then codifying as types in packages/core/, then documenting in SPEC.md.## When to Use- Adding new method, decorator, or export to framework- Modifying existing API signatures- Defining types in packages/core/*.d.ts- User asks "how should this API look?"## API Design Flow```dotdigraph api_flow { "Write usage in skeleton/" -> "Add types to packages/core/" -> "Document in SPEC.md" -> "Verify tsc passes";}```1. **Usage First**: Write the ideal developer experience in skeleton/2. **Types Second**: Add ambient types to make it compile3. **Spec Third**: Document with TypeScript signatures4. **Verify**: Run `tsc --noEmit` in skeleton/## Design Principles| Principle | Application ||-----------|-------------|| DX First | How does this feel to use? Start from skeleton. || Type Safety | Can TypeScript catch mistakes at compile time? || Conventions | Follow Laravel/Rails patterns where sensible || Minimal API | Smallest surface that solves the problem || Extensibility | Can users extend without modifying core? |## Patterns in Use**Decorators:** `@column()`, `@before()`, `@property()`, `@use()` - metadata on classes/properties**Method Chaining:** `router.get('/').name('home')` - fluent API for configuration**Controller Tuples:** `[Controller, 'method']` - type-safe handler references**Lazy Relations:** `@hasMany(() => Post)` - arrow function to avoid circular deps**Static Dispatch:** `Job.dispatch({})`, `Mailable.send({})` - class-level entry points## Type Definition LocationAll public types go in `packages/core/`:| File | Contents ||------|----------|| `kubit.d.ts` | `defineConfig`, `env`, `use` || `router.d.ts` | `router` object, handler types || `orm.d.ts` | `Model`, column decorators, relations || `queue.d.ts` | `Job`, `@property` || `mail.d.ts` | `Mailable` || `db.d.ts` | `Migration`, `schema` || `inertia.d.ts` | `view()` || `http.d.ts` | `HttpContext` || `hash.d.ts` | `hash()` |## Checklist Before Adding API- [ ] Usage example exists in skeleton/- [ ] Types added to packages/core/- [ ] `tsc --noEmit` passes in skeleton/- [ ] SPEC.md updated with TypeScript signature- [ ] Follows existing patterns (decorators, chaining, etc.)---> Converted and distributed by [TomeVault](https://tomevault.io/claim/aniftyco) — claim your Tome and manage your conversions.

Frequently asked questions

Kubit Designing API