Agent Skills от Эдди Османи

Установка

npx skills add addyosmani/agent-skills

Это чужой код. Посмотрите файлы в репозитории перед установкой.

Что делает

Скиллы описывают процессы и критерии качества, которые применяют опытные инженеры, чтобы агент следовал им последовательно. Девять слеш-команд, включая /spec, /plan, /build, /test, /review и /ship, соответствуют этапам разработки и включают нужные скиллы. Каждый скилл состоит из шагов, контрольных точек и таблицы типичных отговорок агента с контраргументами. В основе лежат практики из книги Software Engineering at Google.

Для кого. Разработчики и техлиды, которые хотят, чтобы агент не пропускал спецификации, тесты и ревью.

Пример запроса к агенту

/spec добавить экспорт отчетов в CSV, затем /plan и /build

Ограничения

При установке одного скилла через npx копируется только его папка без общих чек-листов из references, пути к ним не работают. Для Cursor и Windsurf скиллы переносятся вручную по инструкциям из docs.

Как отключить. Удалите плагин agent-skills в Claude Code или папки скиллов из каталога скиллов агента.

Проверка безопасности

• Скиллы состоят из markdown-инструкций

Коротко о README

Набор производственных инженерных скиллов для агентов, разбитый на этапы от определения задачи до выпуска. README дает установку для Claude Code, Cursor, Antigravity, Gemini CLI, Windsurf, OpenCode, Copilot, Kiro, Codex и Command Code. Описаны агенты-персоны для ревью, справочные чек-листы и принципы: процесс вместо прозы, обязательная проверка, постепенная загрузка. Есть сравнение с Superpowers и скиллами Мэтта Покока.

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>;
}
```

Похожие