light-system-design
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 inven
npx skills add Light0305/Light-skills --skill light-system-design --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 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
- Non-negotiable boundary
- Choose the mode
- Phase 1 — Intake and protection
- Phase 2 — Requirements and current state
- Phase 3 — Options and decision stop
- Phase 4 — Build the architecture package
- Phase 5 — Contract, schema, and migration checks
- API contract
- Schema and migration
- Phase 6 — Verify, rehearse, and deliver
- Cross-skill ownership
- Validation
What does the light-system-design skill do?
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 inven
How do I install it?
Run `npx skills add Light0305/Light-skills --skill light-system-design --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From Light0305/Light-skills, a repository with 505 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.