principle-foundational-thinking

Guides structural decisions on data structures, sequencing, and concurrency before writing code.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/squidllee/skills --skill principle-foundational-thinking-squidllee
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-foundational-thinking
Source: https://github.com/squidllee/skills/tree/main/principle-foundational-thinking
Command: npx skills add https://github.com/squidllee/skills --skill principle-foundational-thinking-squidllee

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers often jump into writing logic before settling core data structures, leading to premature abstractions, late-stage rewrites, and concurrency bugs. This Skill provides a decision framework for getting foundations right before implementation begins. ## Core Features & Use Cases - Data Structures First: Prompts you to define core types early, trace access patterns, and choose structures matching dominant code paths. - Scaffold Sequencing: Helps order work so CI, linting, test infrastructure, and shared types land before features, keeping commits small and single-purpose. - Concurrency Check: Asks what happens when multiple actors modify shared state, and isolates state when the answer is not "nothing". - Use Case: Before starting a new service, apply this Skill to decide the core data model, sequence setup work ahead of features, and identify shared state that needs isolation. ## Quick Start Apply foundational thinking to review my planned data structures and work sequencing before I start implementing this feature.

Frequently Asked Questions about principle-foundational-thinking

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose the right data structure before writing code?▼

Define core types early and trace every access pattern the code will perform. Choose structures matching the dominant paths, since a data-structure change late in a project becomes a rewrite while early it is often a one-line diff.

What work should I do before building features?▼

Land scaffold first: CI, linting, test infrastructure, and shared types. If something benefits every later phase, do it first, and remove dead weight before laying new foundations.

When should I avoid creating an abstraction?▼

Avoid abstraction when it is premature. Three similar statements still beat a premature abstraction; DRY the structure and data models rather than every line, and prefer explicit code over clever code.

How do I decide if state can be shared between concurrent actors?▼

Ask what happens if another actor modifies the state concurrently. If the answer is not "nothing", isolate the state instead of sharing it.

When does foundational thinking not apply?▼

It adds little value for trivial one-off scripts or throwaway prototypes where no downstream code depends on the data shape. Its payoff scales with how much later work builds on the early decisions.