Back to Details

engineering-philosophy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Engineering Philosophy

工程哲学

Use this skill when

适用场景

Use this Skill as an explicit engineering governance and routing entrypoint when:
  • the user asks for an overall engineering analysis;
  • it is unclear which specialist Skill owns the decision;
  • one request genuinely crosses several engineering concerns;
  • a rule may belong in global philosophy rather than project-local guidance; or
  • the process should be made lighter or heavier based on risk.
Most normal requests should activate the focused specialist directly. Do not make this Skill a mandatory prelude to architecture, domain modeling, testing, debugging, review, Git, or CI work.
Do not use it as a replacement for a project rule file, a framework manual, a detailed language guide, or a specialist Skill that already owns the primary decision.
在以下场景中，将本Skill作为明确的工程治理与路由入口使用：
  • 用户请求进行整体工程分析；
  • 无法确定应由哪个专业Skill负责决策；
  • 某一请求确实涉及多个工程领域；
  • 某条规则可能属于全局准则而非项目本地指导；或者
  • 需要根据风险调整流程的繁简程度。
大多数常规请求应直接调用对应的专业Skill。请勿将本Skill作为架构设计、领域建模、测试、调试、评审、Git或CI工作的强制前置环节。
请勿将其用作项目规则文件、框架手册、详细语言指南或已负责核心决策的专业Skill的替代品。

Core principle

核心原则

Prefer the simplest architecture that preserves meaningful boundaries.
Treat a boundary as meaningful only when it protects a real business responsibility, substitution point, independent test, protocol, deployment unit, ownership boundary, or source of change. Do not create abstractions merely because a type, function, service, or repository exists.
优先选择能保留有意义边界的最简架构。
只有当边界能保护真实的业务职责、替换点、独立测试、协议、部署单元、所有权边界或变更源时，才认为该边界是有意义的。请勿仅因存在某一类型、函数、服务或仓库就创建抽象层。

Rule levels

规则层级

Use these levels consistently:
  • MUST: a stable engineering constraint. Violating it requires an explicit, high-quality reason.
  • SHOULD: the default practice. A project may deviate when the reason, cost, and alternative are stated.
  • CONDITIONAL: apply only when its trigger conditions are present. Never introduce a pattern by name alone.
For every important rule, explain:
  1. Rule
  2. Why
  3. Do
  4. Do not
  5. Verification
请统一使用以下规则层级：
  • MUST：稳定的工程约束。违反该规则需提供明确且充分的理由。
  • SHOULD：默认实践。若项目能说明偏离的理由、成本及替代方案，则可偏离该规则。
  • CONDITIONAL：仅在触发条件满足时适用。切勿仅因模式名称就引入该模式。
对于每条重要规则，需说明以下内容：
  1. 规则内容
  2. 制定原因
  3. 正确做法
  4. 禁止行为
  5. 验证方式

Global versus project rules

全局规则与项目规则

Keep cross-project principles here. Keep project-specific facts in the project:
  • language or framework versions;
  • database, message broker, or cloud provider choices;
  • repository layout and team naming conventions;
  • GitLab or other hosting workflow;
  • domain-specific aggregates and terminology;
  • mandatory test libraries and CI commands.
When a project rule conflicts with a global SHOULD, follow the explicit project rule and record the trade-off. Do not silently convert a local convention into a universal principle.
跨项目原则统一在此处维护。项目特定信息请保留在项目内部：
  • 语言或框架版本；
  • 数据库、消息中间件或云服务商选择；
  • 仓库结构及团队命名规范；
  • GitLab或其他代码托管平台的工作流程；
  • 领域特定的聚合体及术语；
  • 强制使用的测试库及CI命令。
当项目规则与全局SHOULD规则冲突时，遵循明确的项目规则并记录权衡过程。请勿将本地惯例默认为通用原则。

Decision workflow

决策流程

  1. Clarify the user-visible outcome and constraints.
  2. Identify the smallest meaningful boundary or feedback loop involved.
  3. Choose the focused Skill that owns the decision.
  4. Prefer the simplest design that preserves the boundary.
  5. Make dependencies, assumptions, and verification evidence explicit.
  6. Separate observed facts from hypotheses and preferences.
  7. Before changing a global rule, check whether the lesson is repeated and generalizable.
Use this delivery chain when it fits the request:
spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → git-workflow-and-versioning → ci-cd-and-automation
Route any observed failure to systematic-debugging. Route architecture and domain modeling questions to architecture-boundaries and ddd-lite respectively; those two Skills are peers, not layers of one mandatory architecture.
  1. 明确用户可见的结果及约束条件。
  2. 确定涉及的最小有意义边界或反馈循环。
  3. 选择负责该决策的专业Skill。
  4. 优先选择能保留边界的最简设计。
  5. 明确说明依赖关系、假设条件及验证依据。
  6. 将观察到的事实与假设、偏好区分开。
  7. 在修改全局规则前，确认该经验是否具有重复性和普适性。
当请求符合以下情况时，使用该交付链：
spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → git-workflow-and-versioning → ci-cd-and-automation
任何已发现的问题均路由至systematic-debugging处理。架构设计问题路由至architecture-boundaries，领域建模问题路由至ddd-lite；这两个Skill是同级关系，并非某一强制架构的分层。

Routing behavior

路由行为

Select the smallest set of Skills needed for the current decision. Use routing-matrix.md for signal-to-owner guidance, secondary collaboration rules, and negative routing cases. The matrix is a decision aid, not a mandatory workflow: a tiny explicit change may need no planning Skill, and a cross-cutting request may need one primary plus one or two focused secondary Skills.
选择当前决策所需的最少Skill集合。使用routing-matrix.md获取信号归属指导、次要协作规则及反向路由案例。该矩阵仅为决策辅助工具，并非强制工作流：微小的明确变更可能无需调用规划类Skill，跨领域请求可能需要一个主Skill搭配一到两个辅助专业Skill。

Rule promotion

规则升级

Do not promote an isolated workaround into global doctrine. Follow:
Observation → Repeated Pattern → Candidate Rule → Eval Case → Real-project Validation → Global Rule
A rule may be promoted when at least one of these is true:
  • the same pattern appears in two independent projects;
  • a high-cost incident yields a clear, general safeguard;
  • repeated reviews identify the same failure mode.
Otherwise keep it as a project rule, ADR, or observation note.
Read rule-lifecycle.md when changing the philosophy or promoting a rule. Read global-vs-project.md when deciding where a rule belongs.
请勿将孤立的临时解决方案升级为全局准则。请遵循以下流程：
Observation → Repeated Pattern → Candidate Rule → Eval Case → Real-project Validation → Global Rule
满足以下任一条件时，规则可升级：
  • 同一模式出现在两个独立项目中；
  • 高成本事件催生了明确且通用的防护措施；
  • 多次评审发现同一失效模式。
否则，请将其保留为项目规则、ADR或观察记录。
修改准则或升级规则时，请阅读rule-lifecycle.md。确定规则归属时，请阅读global-vs-project.md。

Verification

验证环节

Before declaring work complete, identify the evidence that supports the claim: test output, reproduction steps, review findings, build result, deployment check, or an explicit statement of remaining uncertainty.
Never claim that a design is correct merely because it compiles, follows a familiar pattern name, or resembles a diagram.
在宣布工作完成前，需明确支持该结论的依据：测试输出、复现步骤、评审结果、构建结果、部署检查或对剩余不确定性的明确说明。
切勿仅因设计可编译、遵循熟悉的模式名称或与某张图表相似，就断言该设计是正确的。