mcpField
T
The Standard Core

The Standard Core

github.com/hassanhabib开发2073 次安装13 周前更新
代码仓库

关于 The Standard Core

The Standard Core 是技术无关的技能，为其他 Standard 技能规定原则与运作模式。它通过目的、建模和模拟指导工程师与 Agent，强调易理解、自主且可重写的系统。

主要功能

  1. 01目的、依赖、暴露三重设计视角
  2. 02目的—建模—模拟工程顺序
  3. 03数据载体与操作模型指导
  4. 04简化与自主性原则
  5. 05Agent 行为明确规范

适用场景

  1. 01实现前规划系统架构
  2. 02依据 The Standard 评审设计决策
  3. 03指导 Agent 处理软件相关工作

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/hassanhabib/the-standard-skills --skill the-standard-core

安装后在 Claude Code 中输入/the-standard-core确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

manifest.json
contracts/
contracts.json
examples/bad/
example_bad_modeling.md
example_bad_purposing.md
examples/good/
example_purposing.md
example_modeling.md
rules/
rules.json
rules.md
templates/
system_design_template.md
validations/
anti-patterns.md
checklist.md

详细介绍

The Standard 核心

此技能的用途

此技能是所有其他 Standard 技能的指导层。 它定义了理论、运作模式和核心价值观，这些内容必须指导所有设计、实现、测试、评审和规划决策。

The Standard 与技术无关。 无论语言、框架、运行时或托管模式如何，都应遵循它。 C# 和 .NET 示例仅用于将理论具体化，而非代表理论本身。

明确的覆盖范围

此技能明确涵盖 The Standard 的基础内容：

    1. Introduction
  • 0.0 The Theory
    • 0.0.0 Introduction
    • 0.0.1 Finding Answers
    • 0.0.2 Tri-Nature
    • 0.0.2.0 Purpose
    • 0.0.2.1 Dependency
    • 0.0.2.2 Exposure
    • 0.0.3 Everything is Connected
    • 0.0.4 Fractal Pattern
    • 0.0.5 Systems Design & Architecture
    • 0.0.6 Conclusion
  • 0.1 Purposing, Modeling, and Simulation
    • 0.1.0 Introduction
    • 0.1.1 Purposing
    • 0.1.1.0 Observation
    • 0.1.1.1 Articulation
    • 0.1.1.2 Solutioning
    • 0.1.2 Modeling
    • 0.1.2.0 Model Types
    • 0.1.2.0.0 Data Carrier Models
    • 0.1.2.0.0.0 Primary Models
    • 0.1.2.0.0.1 Secondary Models
    • 0.1.2.0.0.2 Relational Models
    • 0.1.2.0.0.3 Hybrid Models
    • 0.1.2.0.1 Operational Models
    • 0.1.2.0.1.0 Integration Models (Brokers)
    • 0.1.2.0.1.1 Processing Models (Services)
    • 0.1.2.0.1.2 Exposure Models (Exposers)
    • 0.1.2.0.2 Configuration Models
    • 0.1.3 Simulation
    • 0.1.4 Summary
  • 0.2 Principles
    • 0.2.0 People-First
    • 0.2.0.0 Simplicity
    • 0.2.0.0.0 Excessive Inheritance
    • 0.2.0.0.1 Entanglement
    • 0.2.0.0.1.0 Horizontal Entanglement
    • 0.2.0.0.1.1 Vertical Entanglement
    • 0.2.0.0.2 Autonomous Components
    • 0.2.0.0.2.0 No Magic
    • 0.2.1 Rewritability
    • 0.2.2 Mono-Micro
    • 0.2.3 Level 0
    • 0.2.4 Open Code
    • 0.2.5 Airplane Mode (Cloud-Foreign)
    • 0.2.6 No Toasters
    • 0.2.7 Pass Forward
    • 0.2.8 All-In/All-Out
    • 0.2.9 Readability over Optimization
    • 0.2.10 Last Day

何时使用

只要出现任何与软件相关的请求，就始终使用此技能。 在架构设计、编码、测试、规划和评审之前，都应先使用它。 如果适用其他 Standard 技能，请先启用此技能，并由它指导其余工作。

身份与理论

  1. 每个系统都受理论指导，无论这种理论是显性的还是隐性的。
  2. The Standard 以 Tri-Nature 理论为基础。
  3. 必须从三个视角理解每个系统：
    • 目的
    • 依赖
    • 暴露
  4. Tri-Nature 具有分形特性。
    • 相同的模式会在系统、子系统、服务、验证和暴露层级重复出现。
  5. 万物相连。
    • 设计每个部分时，都要意识到它会成为他人的依赖或暴露。

强制工程流程

有意识地遵循以下顺序：

  1. 目的定义
  2. 建模
  3. 仿真

在启动阶段必须遵循此顺序。 之后允许迭代，但不要跳过目的定义，直接开始编写代码。

目的定义规则

  1. 从观察开始。
    • 找出真正的障碍、约束或未满足的需求。
  2. 清晰地阐述问题。
    • 在有帮助时使用文字、图表或图示。
    • 把问题描述清楚，就等于解决了一半。
  3. 将方案设计纳入目的。
    • 不要把通往目标的路径视为理所当然。
    • 方案还必须兼顾可读性、可配置性、长期可用性、优化和可维护性。
  4. 绝不可走捷径来达成目标。
    • 以错误方式达成目标属于违规。
  5. 始终让目的清晰可见。
    • 如果目的不明确，请先停下并澄清，再进行建模或实现。

建模规则

  1. 只对目的所需的内容建模。
  2. 不要将无关属性引入模型。
  3. 将模型视为仅表达问题所需数据的类。
  4. 优先使用最通用且仍符合问题范围的名称。
数据载体模型规则
  1. 主模型是自足的。
    • 它们在物理上不依赖其他模型而存在。
  2. 次级模型依赖主模型。
    • 它们通常引用另一个模型，或嵌套在其中。
  3. 关系模型连接两个主模型。
    • 它们用于实现多对多关系。
    • 它们应保存引用，而非无关的详细信息。
  4. 仅在必要时允许使用混合模型。
    • 它们将关系行为与关系的其他详细信息结合起来。
    • 优先保持纯粹；只有业务流程确实需要时才使用混合模型。
操作模型规则
  1. 集成模型是中介。
  2. 处理模型是服务。
  3. 暴露模型负责对外暴露。
  4. 配置模型是启动、组合、中间件或入口点模型。

仿真规则

  1. 仿真是模型交互的方式。
  2. 模型可以对另一个模型采取行动。
  3. 模型可以被另一个模型作用。
  4. 模型可以对自身采取行动。
  5. 函数、方法和例程是仿真机制。
  6. 仿真应保持在模型的用途和边界之内。

核心原则与不可妥协项

以人为本
  1. 同时为用户和未来的维护者构建。
  2. 优先考虑人的理解，而非炫技。
  3. 优先采用主流工程师能够负责、演进和重写的系统。
简洁
  1. 简洁是强制要求，不是可选项。
  2. 简洁让重写变得容易。
  3. 简洁倾向于模块化单体和清晰的分解。
过度继承
  1. 继承层级不得超过一层。
  2. 超过一层即属过度继承，禁止使用；除非流程的垂直版本管理绝对需要这样做。
耦合
  1. 避免横向耦合。
    • 不使用 Utils。
    • 不使用 Commons。
    • 不使用那些自称能简化一切的 Helpers。
    • 独立流程之间不共享模型。
    • 无关流程之间不共享异常或验证规则。
  2. 避免纵向耦合。
    • 不使用本地基础组件，除非它们是原生或外部组件。
    • 不使用会造成隐式耦合的本地继承链。
  3. 如果重复能够保留自主性，则优先重复，而非跨流程耦合。
自主组件
  1. 每个组件都应自足。
  2. 每个组件都应在其某个维度中拥有自己的验证、工具和实用程序。
  3. 组件可以依赖注入的依赖项，但不能依赖隐藏的辅助工具。
  4. 如果重复能够保留所有权和自主性，则允许重复。
杜绝魔法
  1. 所见即所得。
  2. 不使用隐藏例程。
  3. 不使用需要追踪引用的魔法扩展。
  4. 不使用让系统难以理解的运行时技巧。
  5. 将验证、异常处理、跟踪、安全、本地化和行为清楚地展现出来。
可重写性
  1. 每个系统都必须易于理解、修改和彻底重写。
  2. 符合 Standard 的系统应易于分叉、克隆、构建和测试，且不会带来意外。
  3. 不使用隐藏依赖项。
  4. 不设置未知的前置条件。
  5. 不注入会掩盖行为的例程。
Mono-Micro
  1. 以微服务思维构建单体。
  2. 每个流程都应足够自主，以便日后提取。
  3. 积极模块化，但不要过早拆分。
Level 0
  1. 代码必须让入门级工程师也能理解。
  2. Level 0 的理解能力是衡量成功的标准。
  3. 如果新工程师无法理解系统，说明系统过于复杂。
开放代码
  1. 优先采用可见且易于访问的代码、工具、平台和模式。
  2. 不要仅为个人或组织利益而将源代码设为专有。
  3. 只有在安全、保障或合同义务要求时才允许例外。
飞行模式（远离云端）
  1. 系统应可在本地运行，不强制依赖云端。
  2. 开发可将云资源连接到本地替代方案的工具。
  3. 优先考虑本地测试、本地开发和模拟外部系统。
不要烤面包机
  1. 不要将风格检查工具或分析器作为强制符合 Standard 的主要手段。
  2. 通过人与人之间的交流传授 Standard。
  3. 重视信念与理解，而非强迫。
  4. 可以使用 AI 辅助编码（包括“氛围编码”）， 前提是人类始终积极参与，并对最终代码承担全部责任。
  5. 可以使用 AI 进行代码审查并提供建议，但审批和合并决策的最终决定权 必须始终由人类掌握。
传承下去
  1. 应免费传授 Standard。
  2. 不要通过传授 Standard 谋利。
  3. 不要利用 Standard 贬低他人。
  4. 自由地传承下去。
全盘接受或全盘拒绝
  1. 必须全盘接受或全盘拒绝 Standard。
  2. 部分采用不算标准化。
  3. 过时的部分遵循不足以声称系统已标准化。
可读性优先于优化
  1. 如有疑问，选择可读性。
  2. 不可读的“最优”软件并非真正最优。
最后一天
  1. 每天工作时，都要像这可能是你在项目上的最后一天。
  2. 每个工程工作日都应在一个良好的停顿点结束。
  3. 确保其他工程师第二天可以无缝接手工作。
  4. 将此原则应用于设计、开发、文档和自动化。

Agent 必须遵守的行为准则

  1. 绝不跳过目的。
  2. 目的或模型不明确时，绝不开始实施。
  3. 绝不以牺牲可读性为代价进行优化。
  4. 绝不将隐藏的共享抽象作为首选方案。
  5. 绝不建议用分析器或“烤面包机”取代理解。
  6. 拒绝模糊或混乱的设计。
  7. 优先选择明确性、自主性和可重写性。
  8. 始终如一地使用 The Standard 的术语。
  9. 如果通用惯例与 The Standard 冲突，以 The Standard 为准。

评论

支持 Markdown