Software Design Philosophy — скилл

software-design-philosophy-skill

Скилл по книге Оустерхаута о проектировании ПО: глубокие модули, сокрытие информации и красные флаги для ревью кода и архитектуры

  • 355 ★ репозитория
  • Последний коммит
  • MIT
Скилл

Минимальный доступ

Почему такой уровень

  • Один файл с текстом принципов: скилл ничего не запускает и никуда не обращается
Все причины и проверки

luoling8192/software-design-philosophy-skill

Установка

Работает в

В терминале, через SkillFoxx CLI

npx skillfoxx add skills/software-design-philosophy-skill

Определит агенты на машине, покажет уровень доступа и зафиксирует версию.

Другие способы установки

Доступ и проверки

Как мы проверяем

Минимальный доступИнструмент ничего не запускает и не ходит в сеть.

  • Один файл с текстом принципов: скилл ничего не запускает и никуда не обращается

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

Что делает

Скилл `software-design-philosophy` пересказывает в виде справочника книгу Джона Оустерхаута «A Philosophy of Software Design» и подключается, когда агенту надо оценить качество дизайна. Главная мысль книги: задача проектирования состоит в управлении сложностью. Файл разбит на пятнадцать разделов: признаки и причины сложности, стратегическое и тактическое программирование, глубокие и мелкие модули, сокрытие информации и утечка, универсальные и специальные модули, слои абстракции, перенос сложности вниз. Дальше идут определение ошибок из существования, привычка «спроектируй дважды», философия комментариев, имена, согласованность и очевидность кода. Для ревью есть сводка красных флагов: утечка информации, метод-пустышка, переменная, которая только пробрасывается через слои, неочевидный код. Скилл срабатывает на фразы вроде «код слишком сложный», «как разбить модули», «как снизить связанность».

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

Подходит, если

  • Агент ревьюит `pull` `request`, и важно получить замечания о дизайне, а не только о стиле
  • Модуль разрастается, и надо решить, как поделить его на части с простыми интерфейсами
  • Интерфейс API или класса проектируется с нуля, и нужны два варианта на выбор
  • Код читается тяжело, и хочется понять, виноваты имена, пробрасывающие слои или утечка деталей
  • Обработка ошибок разрослась, и нужно проверить, можно ли часть из них исключить самим дизайном

Не подходит, если

  • Нужна проверка линтером или форматирование: скилл дает принципы, а не правила стиля конкретного языка
  • Нужен разбор книги целиком с примерами: файл сжат до выжимки
  • Правка срочная и локальная: рассуждения о дизайне замедлят ее без пользы

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

Проверь этот модуль по принципам Оустерхаута: где интерфейс мелкий, где утекают детали реализации и что можно упростить

Ограничения

Скилл состоит из одного файла SKILL.md и пересказывает книгу своими словами, оригинальных примеров кода и глав в нем нет. Он дает принципы и красные флаги, но не инструменты: нет скриптов, проверок и автоматического анализа кода. Скилл сам код не проверяет: выводы делает агент по тексту. Раздел «Usage Guide» в конце файла дает правила на шесть случаев: ревью, проектирование интерфейсов, деление на модули, ошибки, рефакторинг, имена и комментарии. Материал написан по-английски. Последний коммит в репозитории датирован июлем 2026 года.

Как отключить. Удалите папку скилла `software-design-philosophy` из папки скиллов вашего агента, например из ~/.claude/skills/, и перезапустите сессию.

Частые вопросы

Как поставить скилл в Claude Code?

В README для Claude Code указана команда claude install-skill luoling8192/software-design-philosophy-skill. Подойдет и общий вариант npx skills add luoling8192/software-design-philosophy-skill.

Нужно ли читать книгу, если есть скилл?

Выжимка принципов с красными флагами нужна агенту для ревью, а примеры и рассуждения Оустерхаута остаются в книге, и читать ее полностью по-прежнему полезно.

Какие красные флаги в нем есть?

Утечка информации, метод-пустышка, переменная, которая только пробрасывается через слои, неочевидный код и ряд других. Они собраны в раздел «Красные флаги» с краткой справкой.

В каких случаях он срабатывает?

При ревью кода, обсуждении архитектуры, проектировании API, делении на модули, рефакторинге, выборе имен и стратегии обработки ошибок. Описание перечисляет и триггер-фразы вроде «код слишком сложный» и «как снизить связанность».

Работает ли он в Codex?

Да. В README для Codex указана команда codex skills add luoling8192/software-design-philosophy-skill, а в репозитории лежит отдельный файл codex-skill.md.

Обсуждение

Вопросов и отзывов пока нет.

Скиллы

Скилл помогает разобраться в кодовой базе через вопросы: пользователь сам восстанавливает причины архитектурных решений.

СкиллРасширенный доступ408Звезды репозитория

Скилл для ревью кода по многим языкам и фреймворкам: архитектура, производительность, безопасность, антипаттерны и типичные ошибки

СкиллМинимальный доступ2,2 тыс.Звезды репозитория

Одиннадцать скиллов, которые ведут идею через требования, спецификацию и план к проверенному pull request с независимым ревью

СкиллРасширенный доступ427Звезды репозитория

lencx skills

lencx-skills

Два скилла для Claude Code и Codex: keel решает вопросы архитектуры, coding-protocol держит правки кода в границах задачи

СкиллМинимальный доступ198Звезды репозитория

Скилл разработки под доказательства: агент окружает код спецификацией и набором проверок, чтобы построчное ревью стало необязательным

СкиллРасширенный доступ754Звезды репозитория

Скилл для разбора и аудита кода: объясняет, что и почему делает код, вместо того чтобы просто принять его

СкиллРасширенный доступ1,1 тыс.Звезды репозитория

Коротко о README

Короткая страница: назначение скилла, список ситуаций, в которых он нужен (ревью, архитектура, API, модули, рефакторинг, имена, обработка ошибок), три команды установки для Claude Code, Codex и Skills.sh и лицензия MIT.

Бейдж для README

Исходный SKILL.md

---
name: software-design-philosophy
description: >
  Software design philosophy guide based on John Ousterhout's "A Philosophy of Software Design."
  Use this skill during: code reviews, architecture discussions, API design, module decomposition decisions,
  refactoring guidance, complexity analysis, naming and commenting improvements, error handling strategy design.
  Trigger when the user mentions "code is too complex", "how to split modules", "interface design",
  "reduce coupling", "deep/shallow modules", "information leakage", "error handling", "code readability",
  "design philosophy", "pull complexity down", "define errors out of existence", or similar topics.
  Also trigger for any code review where design quality feedback is requested.
---

# A Philosophy of Software Design — Distilled Guide

> Source: John Ousterhout, *A Philosophy of Software Design*
> Central thesis: **The core challenge of software design is managing complexity.**

---

## I. Complexity: Know the Enemy

### Definition

Complexity is anything related to the structure of a software system that makes it **hard to understand and modify**. Complexity is not the same as system size — a small system can be complex, and a large well-designed system can be manageable.

### Three Symptoms of Complexity

1. **Change Amplification**: A seemingly simple change requires code modifications in many different places.
2. **Cognitive Load**: Developers must absorb a large amount of information to complete a task safely. Note: fewer lines of code ≠ simpler — sometimes more code is actually simpler because it reduces cognitive load.
3. **Unknown Unknowns**: It's unclear which code must be modified or what information is needed to complete a task. This is the most dangerous symptom.

### Two Root Causes

1. **Dependencies**: A piece of code cannot be understood or modified in isolation; it relates to other code that must also be considered.
2. **Obscurity**: Important information is not obvious — vague names, missing docs, implicit conventions, hidden constraints.

### Key Insight

- **Complexity is incremental**: It's not caused by a single catastrophic error; it accumulates through thousands of small decisions.
- Therefore you must adopt a **zero-tolerance** mindset — every bit of "minor" complexity matters.

---

## II. Strategic vs. Tactical Programming

### Tactical Programming (Anti-pattern)
- Goal: get features working as quickly as possible.
- Mindset: "Just make it work", "We'll refactor later."
- Result: complexity accumulates fast, tech debt spirals out of control.

Сообщить о проблеме

Foxx AISoftware Design Philosophy
Foxx AI

Я Foxx AI и уже разобрал этот инструмент. Спросите про установку, настройку или что угодно еще, отвечу простыми словами.