Skip to content
Back to skills

Principle Redesign From First Principles

ASecurity

Use when a new requirement has to fit into an existing design. Rework the design as though the requirement had been there from the beginning, and carry it into every type, doc, and example, instead of attaching it at the side.

  • 1,531 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 7, 2026
ai-agentsdocumentation

Security analysis

A100/100

Scanned November 7, 2026

npx -y skills add hashgraph-online/awesome-codex-plugins --skill principle-redesign-from-first-principles --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Principle Redesign From First Principles?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Principle Redesign From First Principles
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hashgraph-online-principle-redesign-from-first-principles/badge)](https://www.skillsdirectory.com/skills/hashgraph-online-principle-redesign-from-first-principles)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: principle-redesign-from-first-principles
description: Use when a new requirement has to fit into an existing design. Rework the design as though the requirement had been there from the beginning, and carry it into every type, doc, and example, instead of attaching it at the side.
disable-model-invocation: true
---

# Redesign from first principles

Rework the design so that a new requirement looks like it was there from day one. Bolting it onto the side of the existing structure is the failure this principle prevents.

## When it applies

Fitting a new requirement into a design that already exists. Compare [principle-attack-the-premise](../principle-attack-the-premise/SKILL.md), which challenges a factual belief behind a string of failed fixes.

## What to do

1. Read every affected file and understand the current design before changing it.
2. Ask what you would build from scratch if this requirement had been there on day one.
3. Carry the change into everything that refers to the old design: types, documentation, examples, and the rationale sections explaining why the design looks the way it does.
4. Plan the complete redesign, then deliver it in verifiable increments ([principle-sequence-verifiable-units](../principle-sequence-verifiable-units/SKILL.md)).

An example. A single-tenant agent platform gains a requirement for multi-tenancy. Bolting it on means adding a `tenant_id` parameter to the functions that happened to break, and every query that was missed becomes a cross-tenant data leak. Redesigning means asking how the system would look if tenants had existed from the start: a tenant is part of every request context, storage is scoped by tenant at the data access layer, and no query can be written without one. The second design makes the leak impossible to write. The first only makes it less common.

## The failure it prevents

Features bolted on in ways that distort the design, and docs and examples that still describe the old world.

## Done when

The design reads as if the requirement was always there.

Related: [principle-foundational-thinking](../principle-foundational-thinking/SKILL.md), [principle-attack-the-premise](../principle-attack-the-premise/SKILL.md), [principle-sequence-verifiable-units](../principle-sequence-verifiable-units/SKILL.md).

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.