Engineering 技能审查
- 作者仓库星标 0
- 作者仓库 skills-registry
Recommended model: Opus — This skill involves deep reasoning, architecture decisions, or code review.
Opinionated, language-agnostic engineering methodology. Before applying any topic, read its reference file in reference/.
Topics
| Topic | When to Use | Reference |
|---|---|---|
| TDD | Writing unit tests, e2e tests, fixing failing tests | reference/tdd.md |
| Domain Modeling | Implementing rich domain models with business rules, state transitions | reference/domain-model.md |
| Code Review | Reviewing PRs, validating code quality, self-review | reference/code-review.md |
| Requirements | Gathering requirements, clarifying business logic, defining scope | reference/requirements.md |
| Architecture Planning | Planning features, making architectural decisions, designing solutions | reference/architecture.md |
| Deep Modules | Judging interface-vs-implementation ratio, choosing where to draw module boundaries, classifying dependencies | reference/deep-modules.md |
| ADR Writing | Documenting significant architectural decisions | reference/adr.md |
Gotchas
Claude-specific failure modes in engineering methodology:
- Hardcoding dates in tests — Claude's most persistent bad habit. Always use dynamic date generation (
new Date(), relative offsets). Never'2024-01-15'. - Modifying existing tests to make them pass — When a test fails, Claude's instinct is to "fix" the test. Fix the application code instead. Only modify tests if the requirements changed.
- Mocking internal modules in e2e tests — Claude mocks everything for convenience. In e2e tests, only mock external services (payment APIs, auth providers). Internal services, handlers, guards, and repositories must be real.
- One giant PR with no intermediate commits — Claude builds everything then commits once. Commit after each TDD Green phase.
- Designing from scratch when patterns exist — Claude invents new architectures instead of finding the closest existing implementation in the codebase. Always search for similar code first.
- Presenting only one option — Architecture planning requires 2-3 options with trade-offs. Claude tends to present its preferred approach as the only option.
- ADRs with no "Rejected Alternatives" — Claude writes ADRs that only describe the chosen approach. The rejected alternatives section is the most valuable part.
- Skipping the "what's out of scope" section — Requirements must explicitly define what is NOT being built. Claude omits this, leading to scope creep.
General Principles
| Principle | What to Do |
|---|---|
| Clarify Constraints | Scale? Budget? Existing systems? Timeline? MVP or production? |
| Prioritize Simplicity | Simplest solution that works. "The best code is no code." |
| Security by Design | Least privilege, encryption, input validation, parameterized queries |
| Present Options | 2-3 options with trade-offs. Then recommend one. |
Quick Decision Guide
Need to write/fix tests?
-> Read reference/tdd.md
Need to design a domain model?
-> Read reference/domain-model.md
Need to review code?
-> Read reference/code-review.md
Need to gather or clarify requirements?
-> Read reference/requirements.md
Need to plan a feature or make architecture decisions?
-> Read reference/architecture.md
Need to judge a module boundary, or decide if something is "too shallow"?
-> Read reference/deep-modules.md
Need to document a significant decision?
-> Read reference/adr.md<!-- tomevault:4.0:skill_md:2026-05-22 -->Source: anpham1925/claude-marketplace — distributed by TomeVault.
- 流狐分类
- 写作
- 作者声明 Agent
- 未找到明确声明；不据此推断已兼容或已测试
- 静态检查
- 88 / 100 · 启发式扫描，不代表运行安全
- 作者 / 版本 / 许可
- @tomevault-io · 未声明 license
- 流狐 Token 估算
- 低消耗
- 流狐接入估算
- 即装即用
- 是否需要外部 API Key
- 未发现要求
- 检测到的系统要求
- 未声明
- 底层运行要求
- 未声明
- 检测到的文件与系统行为
-
- 只读
- 允许写入 / 修改
- 检测到的网络行为
- 仅限本地
- 安装命令数
- 无（仅作为资料）
档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
作者没有在当前 SKILL.md 中定义固定输出样例。 Topics
Topic · When to Use · Reference TDD · Writing unit tests, e2e tests, fixing failing tests · reference/tdd.md Domain Modeling · Implementing rich domain models with business rules, state transitions · reference/domain-model.md
Gotchas
Claude-specific failure modes in engineering methodology: Hardcoding dates in tests — Claude's most persistent bad habit. Always use dynamic date generation (new Date(), relative offsets). Never '2024-01-15'. Modifying existing tests to make them pass — When a…
General Principles
Principle · What to Do Clarify Constraints · Scale? Budget? Existing systems? Timeline? MVP or production? Prioritize Simplicity · Simplest solution that works. "The best code is no code."
Quick Decision Guide
Source: anpham1925/claude-marketplace — distributed by TomeVault. <!-- tomevault:4.0:skillmd:2026-05-22 -->
> **Recommended model: Opus** — This skill involves deep reasoning, architecture decisions, or code review.
Opinionated, language-agnostic engineering methodology. Before applying any topic, read its reference file in `reference/`.
## Topics
| Topic | When to Use | Reference |
|---|---|---|
| **TDD** | Writing unit tests, e2e tests, fixing failing tests | `reference/tdd.md` |
| **Domain Modeling** | Implementing rich domain models with business rules, state transitions | `reference/domain-model.md` |
| **Code Review** | Reviewing PRs, validating code quality, self-review | `reference/code-review.md` |
| **Requirements** | Gathering requirements, clarifying business logic, defining scope | `reference/requirements.md` |
| **Architecture Planning** | Planning features, making architectural decisions, designing solutions | `reference/architecture.md` |
| **Deep Modules** | Judging interface-vs-implementation ratio, choosing where to draw module boundaries, classifying dependencies | `reference/deep-modules.md` |
| **ADR Writing** | Documenting significant architectural decisions | `reference/adr.md` |
## Gotchas
Claude-specific failure modes in engineering methodology:
- **Hardcoding dates in tests** — Claude's most persistent bad habit. Always use dynamic date generation (`new Date()`, relative offsets). Never `'2024-01-15'`.
- **Modifying existing tests to make them pass** — When a test fails, Claude's instinct is to "fix" the test. Fix the application code instead. Only modify tests if the requirements changed.
- **Mocking internal modules in e2e tests** — Claude mocks everything for convenience. In e2e tests, only mock external services (payment APIs, auth providers). Internal services, handlers, guards, and repositories must be real.
… 证据边界与执行链路
作者原文负责流程事实；流狐只索引当前章节、要点、文件与命令。
章节 -> Topics → Gotchas → General Principles → Quick Decision Guide
要点 -> Recommended model: Opus · TDD · Domain Modeling · Code Review · Requirements · Architecture Planning · Deep Modules · ADR Writing
文件/命令 -> reference/ · reference/tdd.md · reference/domain-model.md · reference/code-review.md · reference/requirements.md · reference/architecture.md · reference/deep-modules.md · reference/adr.md
内容 SHA-256 -> a36bbbecb282
原文结构
适用与边界
原文中的明确线索
reference/、reference/tdd.md、reference/domain-model.md、reference/code-review.md、reference/requirements.md、reference/architecture.md、reference/deep-modules.md、reference/adr.md