Agent Skills by Addy Osmani

Install

npx skills add addyosmani/agent-skills

This is third-party code. Review the repository files before installing.

What it does

The skills encode the workflows and quality gates senior engineers use, so the agent follows them consistently. Nine slash commands, including /spec, /plan, /build, /test, /review and /ship, map to lifecycle phases and activate the right skills. Each skill has steps, checkpoints and a table of common agent excuses with counter-arguments. They draw on practices from Software Engineering at Google.

Who it is for. Developers and tech leads who want the agent to stop skipping specs, tests and reviews.

Example request

/spec add CSV export for reports, then /plan and /build

Limitations

A per-skill npx install copies only that skill folder without shared checklists from references, so those paths break. For Cursor and Windsurf skills are set up manually following the docs.

How to disable. Remove the agent-skills plugin in Claude Code or delete the skill folders from the agent's skills directory.

Security check

• Skills are markdown instructions

README in short

A set of production engineering skills for agents, organized from defining work to shipping it. The README covers installation for Claude Code, Cursor, Antigravity, Gemini CLI, Windsurf, OpenCode, Copilot, Kiro, Codex and Command Code. It describes review personas, reference checklists and principles: process over prose, mandatory verification, progressive disclosure. A comparison with Superpowers and Matt Pocock's skills is linked.

SKILL.md

---
name: api-and-interface-design
description: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
---

# API and Interface Design

## Overview

Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.

## When to Use

- Designing new API endpoints
- Defining module boundaries or contracts between teams
- Creating component prop interfaces
- Establishing database schema that informs API shape
- Changing existing public interfaces

## Core Principles

### Hyrum's Law

> With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.

This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:

- **Be intentional about what you expose.** Every observable behavior is a potential commitment.
- **Don't leak implementation details.** If users can observe it, they will depend on it.
- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.
- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.

### The One-Version Rule

Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.

### 1. Contract First

Define the interface before implementing it. The contract is the spec — implementation follows.

```typescript
// Define the contract first
interface TaskAPI {
  // Creates a task and returns the created task with server-generated fields
  createTask(input: CreateTaskInput): Promise<Task>;

  // Returns paginated tasks matching filters
  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;

  // Returns a single task or throws NotFoundError
  getTask(id: string): Promise<Task>;

  // Partial update — only provided fields change
  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;

  // Idempotent delete — succeeds even if already deleted
  deleteTask(id: string): Promise<void>;
}
```

Related