scalable-thinking 是一项供 AI 在生成或评审代码时参考的架构设计技能，资料将其定位为“AI-consumed reference”，主要服务于 Claude 等 AI 助手在执行任务期间阅读使用；更完整的人类可读说明指向仓库中的 docs/architecture/HIERARCHICAL_PLANNING.md 与 docs/getting-started/ 等文档。
用途与原则 技能的核心原则是“Think Scalable, Build Simple”：在“做什么”（WHAT）上按可扩展的方式思考，在“怎么做”（HOW）上遵循 KISS，保持实现简单。资料用一个对照表说明两者分工：数据模型上追求规范化、带索引，而查询保持简单；API 上采用版本化、RESTful 设计，而操作使用标准 CRUD；代码结构上按功能组织，但层级保持扁平；配置上集中管理，并落在单一文件中。
主要能力与适用位置 资料列出若干具体应用位置。数据模型方面，应把关联数据拆分到合适的表中，而不是塞进 JSON 字符串，以便查询、索引和分区。API 方面，采用带版本的 RESTful 资源路径，例如 /api/v1/users/:userId/processes，便于缓存和演进。数据库方面，使用带外键和索引的规范化表，而不是无法过滤的 JSON 大对象。文件结构方面，按功能组织为 src/features/{feature}/{hooks,components,api}/ 加 src/shared/。
可扩展模式 资料给出的模式包括：列表采用游标分页，例如 ?limit=20&cursor=abc，返回 { nextCursor, hasMore }；配置集中为单一配置对象，并按环境提供取值；错误采用结构化表示，即带 code 与 statusCode 的 AppError。
反模式与检查清单 资料明确反对若干做法，并给出替代方案：不要为假想的百万用户提前构建，先做简单单体；不要预先用 Redis 优化，先用内存缓存，经过测量后再引入 Redis；不要为一个用例做抽象，先直接实现，出现两三个示例后再抽象；不要第一天就上微服务，先单体，待团队或功能增长后再拆分。设计前需自问：数据模型能否支撑 10 倍增长、能否查询所需数据、是否有自然分区键、API 是否版本化、列表是否分页。设计中需自问：是否采用标准模式、是否是最简方案、初级开发者能否看懂、在不足三个示例前是否避免抽象。
扩容时机与限制 资料给出触发增加复杂度的条件：数据库查询超过 2 秒、API p95 超过 500ms、错误率超过 1%、三个月内增长 10 倍、团队规模超过 5 人；在此之前应保持简单并持续度量。资料未提供安装命令、代码示例、收费或价格信息，也未说明具体支持的平台与运行环境，这些事实暂未提供。