home / skills / zpankz / mcp-skillset / api-design

api-design skill

/api-design

This skill helps you design robust APIs using a 5-tier parameter system, audit-first refactoring, and automated quality gates to ensure consistency.

npx playbooks add skill zpankz/mcp-skillset --skill api-design

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
9.6 KB
---
name: API Design
description: Systematic API design methodology with 6 validated patterns covering parameter categorization, safe refactoring, audit-first approach, automated validation, quality gates, and example-driven documentation. Use when designing new APIs, improving API consistency, implementing breaking change policies, or building API quality enforcement. Provides deterministic decision trees (5-tier parameter system), validation tool architecture, pre-commit hook patterns. Validated with 82.5% cross-domain transferability, 37.5% efficiency gains through audit-first refactoring.
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
---

# API Design

**Systematic API design with validated patterns and automated quality enforcement.**

> Good APIs are designed, not discovered. 82.5% of patterns transfer across domains.

---

## When to Use This Skill

Use this skill when:
- ๐ŸŽฏ **Designing new API**: Need systematic parameter organization and naming conventions
- ๐Ÿ”„ **Refactoring existing API**: Improving consistency without breaking changes
- ๐Ÿ“Š **API quality enforcement**: Building validation tools and quality gates
- ๐Ÿ“ **API documentation**: Writing clear, example-driven documentation
- ๐Ÿš€ **API evolution**: Implementing versioning, deprecation, and migration policies
- ๐Ÿ” **API consistency**: Standardizing conventions across multiple endpoints

**Don't use when**:
- โŒ API has <5 endpoints (overhead not justified)
- โŒ No team collaboration (conventions only valuable for teams)
- โŒ Prototype/throwaway code (skip formalization)
- โŒ Non-REST/non-JSON APIs without adaptation (patterns assume JSON-based APIs)

---

## Prerequisites

### Tools
- **API framework** (language-specific): Go, Python, TypeScript, etc.
- **Validation tools** (optional): Linters, schema validators
- **Version control**: Git (for pre-commit hooks)

### Concepts
- **REST principles**: Resource-based design, HTTP methods
- **JSON specification**: Object property ordering (unordered), schema design
- **Semantic Versioning**: Major.Minor.Patch versioning (if using Pattern 1)
- **Pre-commit hooks**: Git hooks for quality gates

### Background Knowledge
- API design basics (endpoints, parameters, responses)
- Backward compatibility principles
- Testing strategies (integration tests, contract tests)

---

## Quick Start (30 minutes)

This skill was extracted using systematic knowledge extraction methodology from Bootstrap-006 experiment.

**Status**: PARTIAL EXTRACTION (demonstration of methodology, not complete skill)

**Note**: This is a minimal viable skill created to validate the knowledge extraction methodology. A complete skill would include:
- Detailed pattern descriptions with code examples
- Step-by-step walkthroughs for each pattern
- Templates for API specifications
- Scripts for validation and quality gates
- Comprehensive reference documentation

**Extraction Evidence**:
- Source experiment: Bootstrap-006 (V_instance=0.87, V_meta=0.786)
- Patterns extracted: 6/6 identified (not yet fully documented here)
- Principles extracted: 8/8 identified (not yet fully documented here)
- Extraction time: 30 minutes (partial, demonstration only)

---

## Patterns Overview

### Pattern 1: Deterministic Parameter Categorization

**Context**: When designing or refactoring API parameters, categorization decisions must be consistent and unambiguous.

**Solution**: Use 5-tier decision tree system:
- **Tier 1**: Required parameters (can't execute without)
- **Tier 2**: Filtering parameters (affect WHAT is returned)
- **Tier 3**: Range parameters (define bounds/thresholds)
- **Tier 4**: Output control parameters (affect HOW MUCH is returned)
- **Tier 5**: Standard parameters (cross-cutting concerns, framework-applied)

**Evidence**: 100% determinism across 8 tools, 37.5% efficiency gain through pre-audit

**Transferability**: โœ… Universal to all query-based APIs (REST, GraphQL, CLI)

---

### Pattern 2: Safe API Refactoring via JSON Property

**Context**: Need to improve API schema readability without breaking existing clients.

**Solution**: Leverage JSON specification guarantee that object properties are unordered. Parameter order in schema definition is documentation only.

**Evidence**: 60 lines changed, 100% test pass rate, zero compatibility issues

**Transferability**: โœ… Universal to all JSON-based APIs

---

### Pattern 3: Audit-First Refactoring

**Context**: Need to refactor multiple targets (tools, parameters, schemas) for consistency.

**Solution**: Systematic audit process before making changes:
1. List all targets to audit
2. Define compliance criteria
3. Assess each target (compliant vs. non-compliant)
4. Categorize and prioritize
5. Execute changes on non-compliant targets only
6. Verify compliant targets (no changes)

**Evidence**: 37.5% unnecessary work avoided (3 of 8 tools already compliant)

**Transferability**: โœ… Universal to any refactoring effort (not API-specific)

---

### Patterns 4-6

**Note**: Patterns 4-6 (Automated Consistency Validation, Automated Quality Gates, Example-Driven Documentation) are documented in the source experiment (Bootstrap-006) but not yet extracted here due to time constraints in this validation iteration.

**Source**: See `experiments/bootstrap-006-api-design/results.md` lines 616-733 for full descriptions.

---

## Core Principles

### 1. Specifications Alone are Insufficient

**Statement**: Methodology extraction requires observing execution, not just reading design documents.

**Evidence**: Bootstrap-006 Iterations 0-3 produced 0 patterns (specifications only), Iterations 4-6 extracted 6 patterns (execution observed).

**Application**: Always combine design work with implementation to enable pattern extraction.

---

### 2. Operational Quality > Design Quality

**Statement**: Operational implementation scores higher than design quality when verification is rigorous.

**Evidence**: Design V_consistency = 0.87, Operational V_consistency = 0.94 (+0.07).

**Application**: Be conservative with design estimates. Reserve high scores (0.90+) for operational verification.

---

### 3-8. Additional Principles

**Note**: Principles 3-8 are documented in source experiment but not yet extracted here due to time constraints.

---

## Success Metrics

**Instance Layer** (Task Quality):
- API usability: 0.83
- API consistency: 0.97
- API completeness: 0.76
- API evolvability: 0.88
- **Overall**: V_instance = 0.87 (exceeds 0.80 threshold by +8.75%)

**Meta Layer** (Methodology Quality):
- Methodology completeness: 0.85
- Methodology effectiveness: 0.66
- Methodology reusability: 0.825
- **Overall**: V_meta = 0.786 (approaches 0.80 threshold, gap -1.4%)

**Validation**: Transfer test across domains achieved 82.5% average pattern transferability (empirically validated).

---

## Transferability

**Language Independence**: โœ… HIGH (75-85%)
- Patterns focus on decision-making processes, not language features
- Tested primarily in Go, but applicable to Python, TypeScript, Rust, Java

**Domain Independence**: โœ… HIGH (82.5% empirically validated)
- Patterns transfer from MCP Tools API to Slash Command Capabilities with minor adaptation
- Universal patterns (3, 4, 5, 6): 67% of methodology
- Domain-specific patterns (1, 2): Require adaptation for different parameter models

**Codebase Generality**: โœ… MODERATE (60-75%)
- Validated on meta-cc (16 MCP tools, moderate scale)
- Application to very large APIs (100+ tools) unvalidated
- Principles scale-independent, but tooling may need adaptation

---

## Limitations and Gaps

### Known Limitations

1. **Single domain validation**: Patterns extracted from API design only, need validation in non-API contexts
2. **JSON-specific**: Pattern 2 (Safe Refactoring) assumes JSON-based APIs
3. **Moderate scale**: Validated on 16-tool API, not tested on 100+ tool systems
4. **Conservative effectiveness**: No control group study (ad-hoc vs. methodology comparison)

### Skill Completeness

**Current Status**: PARTIAL EXTRACTION (30% complete)

**Completed**:
- โœ… Frontmatter (name, description, allowed-tools)
- โœ… When to Use / Prerequisites
- โœ… Patterns 1-3 documented (summaries)
- โœ… Principles 1-2 documented
- โœ… Success Metrics / Transferability / Limitations

**Missing** (to be completed in future iterations):
- โŒ Patterns 4-6 detailed documentation
- โŒ Principles 3-8 documentation
- โŒ Step-by-step walkthroughs (examples/)
- โŒ Templates directory (API specification templates)
- โŒ Scripts directory (validation tools, quality gates)
- โŒ Reference documentation (comprehensive pattern catalog)

**Reason for Incompleteness**: This skill created as validation of knowledge extraction methodology, not as production-ready artifact. Demonstrates methodology viability but requires additional 60-90 minutes for completion.

---

## Related Skills

- **Testing Strategy**: API testing patterns, integration tests, contract tests
- **Error Recovery**: API error handling, error taxonomy
- **CI/CD Optimization**: Pre-commit hooks, automated quality gates (overlaps with Pattern 5)

---

## Quick Reference

**5-Tier Parameter System**:
1. Required (must have)
2. Filtering (WHAT is returned)
3. Range (bounds/thresholds)
4. Output control (HOW MUCH)
5. Standard (cross-cutting)

**Audit-First Efficiency**: 37.5% work avoided (3/8 tools already compliant)

**Transferability**: 82.5% average (empirical validation across domains)

**Convergence**: V_instance = 0.87, V_meta = 0.786

---

**Skill Status**: DEMONSTRATION / PARTIAL EXTRACTION
**Extraction Source**: Bootstrap-006-api-design
**Extraction Date**: 2025-10-19
**Extraction Time**: 30 minutes (partial)
**Next Steps**: Complete Patterns 4-6, add examples, create templates and scripts

Overview

This skill codifies a systematic API design methodology with six validated patterns for parameter categorization, safe refactoring, audit-first workflows, automated validation, quality gates, and example-driven documentation. Itโ€™s designed to help teams design new APIs, refactor existing ones safely, and enforce quality gates with deterministic decision trees and pre-commit patterns. The content is partially extracted and focuses on practical, transferable patterns and measurable benefits.

How this skill works

The skill inspects API parameter usage and schema definitions, then applies a deterministic 5-tier parameter decision tree to categorize parameters (required, filtering, range, output control, standard). It prescribes an audit-first refactoring workflow to avoid unnecessary changes, and outlines architecture for automated validation and pre-commit quality gates. Patterns include safe JSON-based refactoring techniques and example-driven documentation practices to improve clarity and compatibility.

When to use it

  • Designing a new JSON/REST or query-based API and standardizing parameter naming and roles
  • Refactoring an existing API to improve consistency without breaking clients
  • Building automated API quality enforcement: validators, linters, and pre-commit hooks
  • Implementing versioning, deprecation, or migration policies across endpoints
  • Standardizing conventions across multiple endpoints or teams

Best practices

  • Apply the 5-tier parameter system consistently across endpoints to reduce ambiguity
  • Run an audit-first assessment before any refactor to avoid redundant work
  • Treat JSON object property ordering as documentationโ€”use schema changes for clarity, not behavioral changes
  • Automate validation and quality gates in CI with pre-commit hooks and schema checks
  • Document examples for common flows so consumers and tests align with intended usage

Example use cases

  • Onboarding a new microservice: map all parameters into the 5-tier system and generate consistent docs
  • Large-scale refactor: audit endpoints, prioritize non-compliant targets, then apply safe JSON refactors
  • CI integration: add schema validation and a pre-commit hook to block breaking changes
  • API evolution: define deprecation pathways and migrations using audit results and versioning rules
  • Cross-team standardization: enforce output control and filtering conventions across services

FAQ

Is this methodology language-specific?

No. The patterns focus on decision processes and JSON-based APIs; they transfer across languages like JavaScript, Go, Python, and TypeScript.

When is the methodology not worth the overhead?

Avoid formalizing this approach for tiny APIs under five endpoints, single-developer throwaway prototypes, or non-JSON protocols without adaptation.