Claude-Codex Skills

Установка

/plugin marketplace add levnikolaevich/claude-code-skills
/plugin install delivery-planning-suite@levnikolaevich-skills-marketplace
/reload-plugins

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

Что делает

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

Для кого. Для разработчиков и тимлидов, которые хотят проводить агента через этапы разработки по строгим чек-листам.

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

Проверь этот план реализации на пропущенные решения и риски перед тем, как начинать

Ограничения

Чек-листы подробные и расходуют заметную часть контекста, поэтому авторы советуют ставить только нужные плагины. Скиллы из пакета поставки коммитят, пушат, публикуют релизы и деплоят, их стоит запускать только с явным разрешением. Проверочные скрипты репозитория написаны на PowerShell.

Как отключить. Удалите ненужные плагины через /plugin в Claude Code или codex plugin в Codex.

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

• Скиллы поставки коммитят, пушат, публикуют релизы и выполняют деплой
• Скиллы реализации меняют код и зависимости проекта

Коротко о README

README показывает жизненный цикл из семи этапов и отдельный пакет для сопровождения самих скиллов, с таблицей скиллов и их назначением в каждом пакете. Есть раздел о миграции с прошлого каталога, команды установки для Claude Code и Codex, советы по экономии токенов и правила написания скиллов. Отдельно описана проверка репозитория. Лицензия MIT.

SKILL.md

---
name: ln-21-system-design-baseline-builder
description: "Defines measurable architecture drivers and constraints before system design; edits architecture docs only."
---

# System Design Baseline Builder

**Goal:** Create or update one durable source of truth for the project's architecture-driving requirements and constraints. Change only the approved architecture document; do not design the solution, review a plan, audit implementation, edit product code, or invent missing targets.

**Execution contract:** The ordered checkboxes are the Definition of Done. Track every item internally as `PENDING`, `PROVEN` with concrete evidence, `CLEARED` with evidence that its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all `PENDING` and count only `PROVEN` and `CLEARED`; apply the skill's verdict and approval rules to every gap.
Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.

## Tool Routing

| Need | Preferred capability | Fallback |
|---|---|---|
| Repository rules and document conventions | Native file reads plus focused search | User-provided convention with an explicit limitation |
| Existing requirements and architecture artifacts | Narrow repository search and direct reads | Conversation evidence marked with its source |
| Current workload or service evidence | Metrics, dashboards, logs, manifests, or checked-in reports | Mark `UNKNOWN`; never manufacture production numbers |
| Current external limits or standards | Official documentation or specifications | Mark the claim `UNVERIFIED` |
| Document mutation | Minimal patch to the approved Markdown artifact | Return `BLOCKED` if no safe writable path is authorized |

## Artifact Rules

- Prefer an existing unambiguous architecture-requirements document.
- Otherwise use `docs/architecture/system-design-baseline.md`.
- Read before writing, preserve unrelated content, and update facts in place instead of creating parallel truth.
- Classify applicability separately as `APPLICABLE` or `NOT_APPLICABLE`, with evidence for exclusions.
- Rank each applicable item as `DRIVER`, `SUPPORTING`, or `INFORMATIONAL`.
- Classify evidence separately as `CONFIRMED`, `ASSUMED`, or `UNKNOWN`.

## Checklist

### 1. Establish Scope and Destination

- [ ] Resolve the project, business outcome, intended readers, approved documentation scope, and language.
- [ ] Read applicable repository instructions and inspect Git state so unrelated changes remain untouched.
- [ ] Search for existing requirement, architecture, SLO, recovery, security, cost, and ownership documents.

Похожие