principle-redesign-from-first-principles
Apply when integrating a new requirement into an existing design, during a planned rewrite or migration, or when a new internal API replaces one that still has callers.
- License 许可
- MIT
- 最近更新
- 2026-11-03
- Stars
- ★ 10
- Forks
- 2
01 前言 Front Matter
- name
- principle-redesign-from-first-principles
- description
- Apply when integrating a new requirement into an existing design, during a planned rewrite or migration, or when a new internal API replaces one that still has callers.
- user-invokable
- false
- disable-model-invocation
- false
03 SKILL.md 正文
Redesign From First Principles
When integrating a change, don't bolt it onto the existing design. Redesign as if the requirement had been a foundational assumption from the start, then converge on that design without keeping the old one alive.
Design the end state.
- Read all affected files and understand the current design.
- Ask: "if we were writing this from scratch with this new requirement, what would we build?"
- Size the change by the end state, per the Laziness Protocol: the code that remains, not the lines the diff touches.
Converge on it. Temporary compatibility code becomes long-lived debt, and old and new paths side by side make the codebase append-only.
- Propagate the change through every reference: types, docs, examples, rationale sections.
- When a new internal API replaces an old one, inventory the callers, migrate them, and delete the old API in the same wave. Do not keep a legacy path only because internal callers still exist.
- Treat a temporary adapter as exceptional and time-boxed, never as default architecture.
- Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details.
- Migrating and deleting in one wave applies when no external users depend on backward compatibility and the project can absorb a coordinated breaking change.
- Persisted data and published names are the exception. A schema change is the riskiest migration because the data is the one thing you cannot roll back by reverting a deploy. Additive first, destructive last and alone. Adds (new nullable column, new table, new index) are safe in any deploy; drops and renames get their own deploy after no code references the old shape.
Deliver it in green units. Think about the whole redesign, then deliver it incrementally, each unit ending in a passing check per Sequence Verifiable Units. Run the full static and runtime verification when the redesign is complete.
This is the method for preserving option value when integrating changes into an existing design.
04 同仓库更多 Skills
changelog
Write the changelog entry for a pull request. Use when a PR changes behavior that users, operators, or integrators can notice.
writing-good-tickets
Write, file, or update an issue or ticket that an agent or a developer can take to one PR. Use when filing a bug or feature, updating an issue, or breaking a plan into tickets.
writing-good-prs
Write or update a pull request title and body that a reviewer can trust and own. Use when opening a PR or editing its description.
writing-good-commits
Write or reword a git commit message and size the commit it describes. Use when committing, or when reshaping commits during a rebase.
writing-for-agents
Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.
wizard
Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.