一键在 Manus 中运行任何 Skill

api-surface-care

星标89

分支8

更新时间2026年7月7日 13:11

Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

adamentwistle

adamentwistle/fable-skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

api-surface-care

Private code has one consumer: the repo. Public surface has consumers you can't grep. Before changing one:

Know which surface you're on. Exported from the package, reachable over HTTP, parsed from a config file, stored in a DB, emitted onto a queue → contract. Renaming an internal helper is free; renaming a JSON field is a breaking change for every client.
Grep every in-repo caller of the thing you're changing — and remember external consumers don't show up in grep. For libraries, published CLIs, and APIs, assume unseen callers exist.
Prefer additive evolution: new optional parameter with a default, new field, new endpoint version. Widening what you accept and narrowing what you emit is safe; the reverse breaks people.
Breaking changes need a path, not just a diff: deprecate with a warning first where the ecosystem supports it, or version the surface (v2 endpoint, config version: key). Document the migration in the same change.
Watch the semantic breaks that look additive: changing a default value, tightening validation on previously-accepted input, reordering enum values something serializes by index, changing error types/codes callers match on.
Serialization is forever. Anything persisted (DB rows, cached blobs, queued messages) written in the old shape will be read by the new code — handle both shapes or migrate the data (see the migration checklist if one exists).

Exit check: "could code I cannot see be depending on the exact behavior I just changed?" If yes, the change needs a compatibility story, and the report must call it out.

同仓库更多 Skills

同仓库

ambiguity-commit

adamentwistle/fable-skills

Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).

2026-07-0789

calibrated-recommendation

adamentwistle/fable-skills

When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.

2026-07-0789

codebase-orientation

adamentwistle/fable-skills

Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.

2026-07-0789

concurrency-reasoning

adamentwistle/fable-skills

Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.

2026-07-0789

context-checkpoint

adamentwistle/fable-skills

Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.

2026-07-0789

cross-platform-care

adamentwistle/fable-skills

Write scripts and file handling that survive the machine they didn't develop on — path separators, shell dialects, line endings, case-sensitivity, missing tools. Use when writing shell scripts, CI steps, path manipulation, file I/O, or install/setup instructions others will run.

2026-07-0789

name	api-surface-care
description	Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.

api-surface-care

Private code has one consumer: the repo. Public surface has consumers you can't grep. Before changing one:

Know which surface you're on. Exported from the package, reachable over HTTP, parsed from a config file, stored in a DB, emitted onto a queue → contract. Renaming an internal helper is free; renaming a JSON field is a breaking change for every client.
Grep every in-repo caller of the thing you're changing — and remember external consumers don't show up in grep. For libraries, published CLIs, and APIs, assume unseen callers exist.
Prefer additive evolution: new optional parameter with a default, new field, new endpoint version. Widening what you accept and narrowing what you emit is safe; the reverse breaks people.
Breaking changes need a path, not just a diff: deprecate with a warning first where the ecosystem supports it, or version the surface (v2 endpoint, config version: key). Document the migration in the same change.
Watch the semantic breaks that look additive: changing a default value, tightening validation on previously-accepted input, reordering enum values something serializes by index, changing error types/codes callers match on.
Serialization is forever. Anything persisted (DB rows, cached blobs, queued messages) written in the old shape will be read by the new code — handle both shapes or migrate the data (see the migration checklist if one exists).

Exit check: "could code I cannot see be depending on the exact behavior I just changed?" If yes, the change needs a compatibility story, and the report must call it out.