Claude-Codex Skills

Install

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

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

What it does

Thirty-one skills are split across eight plugins in lifecycle order. Each skill has one bounded outcome, a step-by-step checklist, a self-check and the same five-field report. They include building requirements and interaction design, recording architecture decisions and diagrams, delivery plans and test strategy, scoped implementation, dependency upgrades and performance tuning, audits of code, tests, docs and persistence, release publishing and deployment, and incident investigation. Skills are independent: any one can run alone if the needed evidence exists.

Who it is for. For developers and team leads who want to take an agent through development stages with strict checklists.

Example request

Review this implementation plan for missing decisions and risks before we start

Limitations

Checklists are detailed and use a noticeable share of context, so the authors suggest installing only needed plugins. Delivery suite skills commit, push, publish releases and deploy, and should run only with explicit permission. Repository validation scripts are PowerShell.

How to disable. Remove unneeded plugins via /plugin in Claude Code or codex plugin in Codex.

Security check

• Delivery skills commit, push, publish releases and deploy
• Implementation skills change project code and dependencies

README in short

The README shows a seven-stage lifecycle plus a suite for maintaining the skills themselves, with a table of skills and purposes per suite. It includes migration notes from the previous catalog, install commands for Claude Code and Codex, token efficiency advice and authoring rules. Repository validation is described separately. MIT licensed.

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.

Related