principle-foundational-thinking
cursor/plugins
Design data structures and core types before writing logic to make downstream code obvious.
What is principle-foundational-thinking?
Foundational Thinking is a design principle for planning code architecture before implementation. Apply it to choose core data structures, sequence scaffold work before features, and identify shared state between concurrent actors—ensuring structural decisions protect option value and simplify later code.
- Define core types and data structures early, tracing access patterns to match dominant code paths
- Sequence scaffold work (CI, linting, tests, shared types) before features to maximize option value
- Identify concurrent state sharing and isolate when modifications by multiple actors would cause issues
- Prefer explicit, simple code over premature abstractions—three similar statements beat one clever function
- Keep commits small and single-purpose, landing coherent abstractions incrementally
- Remove dead code before laying new foundations
How to install principle-foundational-thinking
npx skills add https://github.com/cursor/plugins --skill principle-foundational-thinkingHow to use principle-foundational-thinking
- 1.Before writing any logic, identify the core data structures and types your system needs
- 2.Map out the dominant access patterns and choose structures that support them efficiently
- 3.Sequence your work: remove dead code, set up scaffold (tests, CI, linting, shared types), then build features
- 4.For concurrent systems, explicitly ask which state is shared between actors and isolate mutable state
- 5.Keep each commit focused on one coherent abstraction; avoid spreading new capabilities across multiple callers as special-case coordination
Use cases
- Planning a new service or module: define the data model and type hierarchy before writing business logic
- Refactoring a codebase: set up shared types and test infrastructure first, then incrementally improve features
- Designing concurrent systems: identify which state is shared between actors and isolate mutable state appropriately
- Onboarding a team: establish scaffold (linting, CI, test patterns) so all subsequent work follows consistent structure
- Evaluating architectural options: choose data structures that support the most common access patterns, reducing downstream complexity
- Software architects planning new systems or major refactors
- Backend engineers designing concurrent or distributed systems
- Team leads establishing coding standards and project structure
- Full-stack developers making structural decisions before feature work
principle-foundational-thinking FAQ
Apply it at the start of any new system, major refactor, or when designing concurrent components. Ask structural questions before writing logic.
No. Get the shape right early through exploration, but you can refine types as you trace access patterns. The goal is avoiding structural rework later.
If three similar statements exist, that's not yet a signal to abstract. Prefer explicit code. Abstract only when a pattern is clear and repeated across the codebase.
Anything that benefits every subsequent phase: CI/CD pipelines, linting rules, test infrastructure, shared type definitions, and shared utilities. Do these before features.
Before sharing state between actors, ask 'what if another actor modifies this simultaneously?' If the answer is not 'nothing', isolate that state to prevent race conditions.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-foundational-thinking description: "Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious." disable-model-invocation: true
Foundational Thinking
Structural decisions protect option value. Code-level decisions protect simplicity.
Data structures first. Get the data shape right before writing logic. Define core types early, trace every access pattern, and choose structures that match the dominant paths.
At code level, DRY the structure, not every line. Types and data models should converge. Three similar statements still beat a premature abstraction. Prefer explicit over clever. Test behavior and edge cases, not line counts.
Concurrency corollary. Before sharing state between actors, ask "what happens if another actor modifies this concurrently?" If not "nothing", isolate.
Scaffold first. If something helps every later phase, do it first. Ask "does every subsequent phase benefit from this existing?" CI, linting, test infrastructure, and shared types are scaffold. Sequence for option value: setup before features, tests before fixes. Keep commits small and single-purpose.
Each increment should land a coherent abstraction or deepen one that exists. Do not spread a new capability across callers as special-case coordination.
Subtraction comes before scaffolding. Remove dead code first, then lay foundations.
Related skills
More from cursor/plugins and the wider catalog.
principle-guard-the-context-window
Manage finite context by routing bulk data to subagents and keeping summaries in the main thread.
principle-laziness-protocol
Bias toward deletion and minimal changes—apply when refactoring, evaluating diffs, or tempted by abstractions.
principle-make-operations-idempotent
Design operations to converge to correct state regardless of crashes, restarts, or retries.
principle-migrate-callers-then-delete-legacy-apis
Migrate callers and delete legacy APIs in one refactor wave instead of maintaining compatibility layers.
principle-minimize-reader-load
Reduce code complexity by minimizing reader cognitive load—collapse unnecessary layers and shrink mutable state.
principle-model-the-domain
Encode domain logic in structures instead of scattered conditionals and repeated assumptions.