system-design-rules

Review architectures, ADRs, and design proposals against a 100-rule checklist before implementation.

7|5|Updated Jul 22, 2025
One-click install
npx skills add https://github.com/nebius/nebius-ps-services --skill system-design-rules-nebius
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: system-design-rules
Source: https://github.com/nebius/nebius-ps-services/tree/main/skills/system-design-rules
Command: npx skills add https://github.com/nebius/nebius-ps-services --skill system-design-rules-nebius

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Design decisions made without structured review lead to hidden coupling, unclear ownership, missing failure handling, and costly rework after implementation. This Skill applies a refined 100-rule system design checklist to architecture proposals, ADRs, API contracts, and data models before code is written, scaling review depth to the decision's risk and blast radius. ## Core Features & Use Cases - Risk-scaled design review: Applies light, standard, or deep review depth based on reversibility, blast radius, and uncertainty instead of forcing all 100 rules onto every change. - Trade-off-driven option comparison: Compares design options by what each improves, worsens, costs, and when to revisit, covering data ownership, APIs, reliability, security, observability, and cost. - Structured decision output: Produces a decision summary, checklist findings, recommended design, validation plan, and open questions. - Use Case: Before committing to an event-driven architecture for an order system, use this Skill to evaluate consistency requirements, idempotency, schema evolution, and team ownership, then receive a concrete recommendation with risks and validation steps. ## Quick Start Use $system-design-rules to review my proposed architecture for the new billing service and compare it against a synchronous API approach.

Frequently Asked Questions about system-design-rules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a system design before implementation?

Provide the design proposal, ADR, or architecture question along with known constraints such as scale, budget, and team ownership. The Skill restates the decision, applies relevant checklist categories at the appropriate depth, and returns a recommendation with trade-offs, risks, and a validation plan.

What does the 100-rule design checklist cover?

The checklist covers ten categories: business intent, domain modeling, modularity, data design, API and integration design, reliability, performance and cost, security and privacy, operability, and team delivery. Rules are applied selectively based on risk rather than all at once.

When should I not use a design review checklist?

Skip it for implementation, debugging, code review, Terraform or Helm work, and small low-risk changes where a full review adds ceremony. For early open-ended ideation, use a brainstorming skill instead; this Skill evaluates concrete design decisions.

Can this Skill compare two architecture options?

Yes. It compares options by what each improves and worsens, operational and migration cost, reversibility, and revisit conditions. It recommends the simplest design satisfying current and near-future requirements rather than declaring universal winners.

Does the design review make changes to my codebase?

No. The Skill is analysis and design guidance only and makes no live external changes. It reads project docs and context to ground recommendations, but implementation requires explicitly switching to an implementation workflow.