用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/tomevault-io/skills-registry --skill galahad命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | galahad |
| description | How to approach tests, types, lints, and coverage Use when this capability is needed. |
| metadata | {"author":"ad-sdl"} |
Based on Jonathan Lange's "The Galahad Principle": https://jml.io/galahad-principle/
Core idea: getting to 100% yields disproportionate value—especially simplicity and trust. When checks are truly "all green", any new failure is a strong, unambiguous signal; "absence of evidence becomes evidence of absence".
Before enforcing these rules strictly, understand the context:
tsconfig.json, pyproject.toml, .eslintrc, setup.cfg, mypy.ini for existing standardsany types, don't block progress on fixing all of themWhen working in a codebase that doesn't meet these standards:
TypeScript: Check tsconfig.json for strict, noImplicitAny, strictNullChecks. Match existing settings.
Python: Check for mypy.ini, pyproject.toml [tool.mypy], pyrightconfig.json. Note the strictness level.
General: Look at existing test files for patterns, existing code for style. When in doubt, match what's there.
Treat type errors, test failures, pre-commit hooks, lint errors, and coverage warnings as helpful feedback. Fix root causes.
any, sketchy unknown laundering, unchecked casts, as any, @ts-ignore, disabling strict mode, weakening compiler flags# type: ignore, # pyright: ignore, # mypy: ignore-errors, cast() without justification, Any in public APIs, disabling type checkersnoqa, pragma comments to silence legitimate warnings/* istanbul ignore */, /* c8 ignore */, artificial exclusions in config# pragma: no cover, # coverage: skip, excluding entire modules from coverage configIf the user explicitly asks for a type escape, to skip tests, or similar:
any here—this will need cleanup before the type system can catch errors in this area."The user owns the codebase. Your job is to inform, not obstruct.
Type safety is part of correctness and outranks tests.
When tradeoffs exist, prioritize in this order:
Breaking changes are acceptable when they improve verifiability and simplify the system, but:
Goal: a repo where "all green" is normal, and any new red is a loud, trustworthy signal.
✅ Meaningful tests:
❌ Not meaningful:
The test: "If this test failed, would I learn something useful about a real bug?"
Coverage comes from exercising real behavior, not from exclusion comments.
If a test is genuinely flaky:
If something is hard to test or hard to type, treat it as a design smell.
Refactor towards:
Record<string, any>dict[str, Any]Avoid injecting mocks via monkeypatching or replacing system utilities by default.
Preferred approach:
Examples:
TypeScript:
// ❌ Bad: hard-coded dependency, requires monkeypatching to test
function processOrder(orderId: string) {
const now = new Date();
const order = database.getOrder(orderId);
// ...
}
// ✅ Good: explicit dependencies
function processOrder(
orderId: string,
deps: { getTime: () => Date; getOrder: (id: string) => Order }
) {
const now = deps.getTime();
const order = deps.getOrder(orderId);
// ...
}
Python:
# ❌ Bad: hard-coded dependency, requires monkeypatching to test
def process_order(order_id: str) -> OrderResult:
now = datetime.now()
order = database.get_order(order_id)
# ...
# ✅ Good: explicit dependencies
def process_order(
order_id: str,
*,
get_time: Callable[[], datetime] = datetime.now,
get_order: Callable[[str], Order] = database.get_order,
) -> OrderResult:
now = get_time()
order = get_order(order_id)
# ...
Converted and distributed by TomeVault — claim your Tome and manage your conversions.