# Fold a new requirement into a design as if it was always there

When a rule changes, it redesigns the type model or module from the start instead of adding another special case.

Free, to use and to change. What it can see: only the chat you add it to.

Its short name: first-principles. [Source on GitHub](https://github.com/mbsi-labs/skills/tree/main/plugins/first-principles/skills/first-principles).

## Who it helps

> **Helps:** "Every fix needs one more special case."

> **Does not help:** A one-line bug fix with nothing to redesign.

## Install

Pick the one you use.

### Claude Code

> **Tested:** This install worked when we tried it.

```
/plugin marketplace add mbsi-labs/skills
/plugin install first-principles@skills
```


## Changelog

- 2026-10-28 (c6d1e92): Updated.
- 2026-10-16 (6f94f8b): Start mbsi-skills with five short-name skills adapted from pstack

Licence: MIT.

## The skill itself

Don't bolt a change onto the current design. Redesign as if the new requirement had been an assumption from day one.

1. Read every affected file, type and rule. Know the current design before you change it.
2. Ask: "Writing this from scratch with this requirement, what would we build?" Answer in types and a state machine first, before any code.
3. Propagate the change everywhere it reaches: types, states, events, errors catalogue, docs, rules, examples. A leftover old name is a bug.
4. Design the whole redesign, then deliver it in small verifiable steps.

Signs you bolted it on: a new optional field or flag beside an old one, a `special case` branch, a comment explaining why two paths exist.

---

First published 2026-10-16, updated 2026-10-28. Web page: https://www.mackenziebowes.com/skills/first-principles Part of [Skills](https://www.mackenziebowes.com/skills).
