# Light System Design

Design or modernize a software system from an evidence-backed current-state inventory...

- Repository: https://github.com/Light0305/Light-skills (845 stars)
- Category: Design
- License: MIT
- Last updated: 2026-07-06
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add Light0305/Light-skills --skill light-system-design -g -a claude-code -y`
Codex: `npx skills add Light0305/Light-skills --skill light-system-design -g -a codex -y`
Cursor: `npx skills add Light0305/Light-skills --skill light-system-design -g -a cursor -y`
Gemini CLI: `npx skills add Light0305/Light-skills --skill light-system-design -g -a gemini-cli -y`

## Description

Design or modernize a software system from an evidence-backed current-state inventory through quality attributes, architecture options, API and schema contracts, migration/rollback plans, ADRs, and verification. Use for greenfield or existing monoliths, modular monoliths, services, system/API/ database design, schema migration review, data-flow reliability, tenant/PII controls, or architecture evolution. Existing systems stay read-only until the user selects an option and authorizes exact mutations. Unknown facts stay UNKNOWN. This is an off-DAG engineering skill: do not emit findings or invent STAGE_GATES, ROUTES, stages, or back-edges.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# System design lifecycle

Own system boundaries, runtime interfaces, operational data stores, system
migrations, and architecture decisions. Do not equate a diagram, SQL file, or
OpenAPI document with a working, safe, or scalable system.

Read
[`references/system-design-resource-map.md`](references/system-design-resource-map.md)
before any existing-system task. It defines the lifecycle, artifact contract,
decision stop, evidence states, access tiers, and cross-skill ownership. Read
[`references.md`](references.md) only for the database/API/reliability branch
that applies to the selected system.

## Non-negotiable boundary

1. Treat repository, configuration, schema, API, dependency, and deployment
   intake as read-only access. It is not authorization to rewrite them.
2. Preserve absent facts as `UNKNOWN`. Do not infer traffic, SLOs, consistency,
   budget, compliance, migration windows, or team capability from the phrase
   “system design.”
3. Present at least a recommendation, a viable alternative, and explicit
   rejection/exit conditions. Stop before choosing the database, topology,
   compatibility policy, or migration strategy for the user.
4. Bind any later mutation to a user-selected option and exact authorized
   action IDs. Keep before/after locators, SHA-256, verification, and rollback.
5. Never mutate a production database or configuration. Apply only to a
   disposable environment explicitly placed in scope; otherwise deliver a
   reviewed plan and scripts.
6. Describe `schema_lint.py` as a lexical heuristic. It is not a SQL parser,
   query planner, lock simulator, schema diff engine, or zero-downtime proof.
7. Keep `VERIFIED` for checks that actually ran and retain their command,
   return code, locator, and hash. Use `PLANNED`, `UNKNOWN`, or `UNAVAILABLE`
   otherwise.
8. Keep this skill off the research DAG. Emit no `light.findings.v1`; add no
   `STAGE_GATES`, `ROUTES`, stage number, or back-edge; do not attach `_shared`.

## Choose the mode

The rest: https://github.com/Light0305/Light-skills/blob/HEAD/skills/light-system-design/SKILL.md