Skip to main content

principle-foundational-thinking

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.

来源信息

仓库
michael-denyer/pstack-claude
最近来源活动
2026年9月23日 21:23
检测到的 SKILL.md 语言
英语
星标
1,805
分支
194

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
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.
user-invocable
false
# 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.
在 GitHub 查看