安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install engineering-architecture-memory
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 engineering-architecture-memory。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

工程与架构记忆是一套持久的操作原则，供 AI 编码代理在处理代码库、功能设计和代码审查时使用。它会促使代理在采取行动前理解架构、边界、惯例、质量属性和权衡，帮助 Openclaw Skills 用户获得契合系统的变更，而不只是满足狭义的请求。
该技能强调简洁设计、向后兼容性、安全性和可衡量的验证。它还要求代理区分具体的工程风险与个人偏好，严格审查自己的变更，并避免不必要的重写或扩大范围。

应用场景

修改现有代码库之前，用于检查其架构、模式、依赖项和边界。
设计功能时，用于将预期结果、约束和验收标准转化为最简单可行的设计。
代码审查期间，用于识别安全风险、耦合、边界违规、不必要的复杂性以及新增的技术债务。
当变更可能影响可靠性、性能、可扩展性、可维护性、可测试性或其他质量属性时使用。
在做出不确定的架构决策之前，通过有针对性的测试、原型或基准测试验证假设。
当保留现有 API 和行为，或控制变更影响范围十分重要时使用。

工作原理

结合上下文理解任务：检查现有架构、依赖项、惯例、约束和质量要求。
在修改相关代码之前先进行审查；识别既有抽象，并区分具体问题与风格偏好。
明确预期结果和验收标准，包括安全性、性能或可靠性等相关非功能性要求。
选择满足要求的最小设计，尊重组件边界，并优先使用现有基础设施，而不是臆测性地创建抽象。
实施变更，同时保留有效的行为和 API，除非任务另有要求；避免无关重构和不必要的迁移。
检查结果中是否存在安全问题、架构缺陷、模式不一致、过度复杂以及意外副作用。
使用适当证据验证重要属性，例如测试、静态分析、类型检查、依赖项检查、基准测试或安全检查。
如果决策不明显，则通过相关文档完成任务；存在多个可行设计时，明确说明权衡。

配置指南

此技能是一份指导文档，而非 CLI 软件包。其 frontmatter 将其标识为版本为 1.0.0 的 engineering-architecture；源文件未指定安装命令、依赖项或其他配置。按照编码代理的技能加载流程，将该文档提供给代理，并将其加载为代码变更、功能设计和审查的持久操作指南。

提供的 SKILL.md 未指定安装命令。

使用代理支持的常规流程，将此技能添加到其支持的技能目录中。

数据架构

该技能定义指导原则和元数据；它不规定应用程序数据格式，也不会生成项目文件。
元素 详情
技能名称 engineering-architecture
版本 1.0.0
描述 将持久的工程与架构原则应用于代码变更、功能设计和代码审查。
主要内容 十四项操作原则，以及一项聚焦正确性、简洁性、架构完整性和可衡量证据的核心原则。
生成的文件或数据 未指定。
元数据分类 使用 name、description 和 version 的 YAML frontmatter；其余内容为 Markdown 指南。

高级特性

架构优先推理：
在提出实现变更之前，检查依赖项、边界、模式和质量属性。
基于证据的验证：
在可行的情况下，鼓励使用测试、静态分析、类型检查、依赖项检查、性能测量、安全检查和特定于架构的断言。
安全意识审查：
考虑信任边界、授权、验证、数据暴露、机密信息、注入、SSRF、外部集成和权限提升。
受控的变更范围：
在需要时保留现有行为和 API，避免无关重构，并将迁移和兼容性风险控制在最低程度。
权衡分析：
评估复杂性、运营成本、性能、可靠性、可维护性、可扩展性和开发者体验。
降低不确定性：
在决定采用更大规模的架构方案之前，使用最小但有效的实验、原型、基准测试或有针对性的测试。
审查者思维：
检查代理生成的变更中是否存在缺陷和技术债务，同时避免不必要地扩大任务范围。
持久指导：
除非明确的任务指令另有规定，否则在相关任务中应用这些原则，使该技能可在 Openclaw Skills 工作流程中重复使用。

name: engineering-architecture description: Apply persistent engineering and architectural principles to every task. Use this skill whenever you are about to make changes to a codebase, design a new feature, or perform a code review to ensure architectural integrity and quality. version: 1.0.0

Engineering & Architecture Memory

These are persistent operating principles. Apply them to every task unless the current task explicitly overrides them.

1. Think Beyond the Task

Do not treat a task as isolated code generation.

Before making changes, understand:

the existing architecture
relevant boundaries and dependencies
established patterns and conventions
quality attributes and non-functional requirements
constraints and trade-offs
likely architectural impact of the change Prefer improving the system as a whole over producing locally correct but architecturally harmful code. 2. Audit Before Changing

When working in an existing codebase:

inspect the relevant implementation first
identify existing abstractions and patterns before introducing new ones
look for architectural smells, unnecessary coupling, duplication, boundary violations, and inconsistent patterns
distinguish real problems from merely different preferences Do not rewrite or redesign working architecture without evidence that it is necessary. 3. Requirements Include Quality Attributes

Do not optimize only for functional correctness.

Consider relevant quality attributes such as:

maintainability
reliability
security
performance
scalability
observability
testability
portability
simplicity When these attributes matter, make them explicit in implementation and verification. 4. Respect Boundaries

Treat architectural boundaries as first-class constraints.

Do not introduce:

forbidden dependencies
layer violations
cross-domain state access
accidental coupling
duplicated ownership of business logic
shortcuts that bypass established interfaces Prefer explicit, stable interfaces between components. 5. Prefer Constraints Over Prescriptions

When solving a problem, reason from:

desired outcome
constraints
quality requirements
acceptance criteria Do not blindly follow an imagined implementation.

Choose the simplest design that satisfies the requirements and constraints.

6. Minimize Architectural Complexity

Do not over-engineer.

Prefer:

the smallest viable architecture
the smallest useful abstraction
existing infrastructure over new infrastructure
simple solutions over speculative flexibility Introduce additional layers, services, abstractions, or dependencies only when they solve a demonstrated problem. 7. Verify Architecture With Evidence

Do not assume that an architecture is good because it looks good.

Whenever practical, verify important architectural properties through:

tests
static analysis
type checks
dependency checks
performance measurements
security checks
integration tests
architecture-specific assertions Prefer measurable evidence over subjective confidence. 8. Treat Agents as Reviewers, Not Only Implementers

While implementing a task, actively inspect for:

architectural flaws
security vulnerabilities
unnecessary complexity
inconsistent patterns
technical debt introduced by the change
violations of project conventions Surface meaningful issues even when they are outside the immediate task, but do not expand scope unnecessarily. 9. Separate Facts From Preferences

Do not label something as an architectural problem merely because it is different from your preferred style.

Distinguish between:

actual defects
measurable risks
maintainability concerns
architectural violations
reasonable alternative designs
personal preferences Only recommend changes when there is a concrete engineering reason. 10. Security Is an Architectural Concern

Consider security at the architecture and implementation levels.

Check relevant:

trust boundaries
authentication and authorization
input validation
data exposure
secrets handling

SSRF and injection risks

unsafe external integrations
privilege escalation paths Never assume security is someone else's responsibility. 11. Preserve Existing Behavior

Unless a change explicitly requires otherwise:

preserve public behavior
preserve valid existing APIs
avoid unnecessary migrations
avoid unrelated refactors
maintain backward compatibility where required Every architectural change should have a clear reason and controlled blast radius. 12. Make Trade-offs Explicit

When multiple viable designs exist, reason about the trade-offs.

Consider:

complexity
operational cost
performance
reliability
maintainability
scalability
developer experience Do not optimize one dimension while silently degrading important others. 13. Use the Smallest Proof

For uncertain architectural decisions, prefer a small experiment, prototype, benchmark, or focused test that can validate the assumption before committing to a large implementation.

Reduce uncertainty with evidence before increasing complexity.

14. Definition of Done

A task is not complete merely because the code compiles.

When relevant, completion should include:

implementation
appropriate tests
validation of important architectural constraints
verification of quality attributes
review for unintended side effects
documentation when the architectural decision is non-obvious

Core Principle

Optimize for:

Correctness + Simplicity + Architectural Integrity + Measurable Evidence

not merely:

"The requested feature works."

公共职位看板
伊朗金融市场监测器