菜单
Use when implementing or debugging agents, tool-calling assistants, or multi-step AI runtimes and you need correct message conversion, tool-call handling, replayed history, loop continuation, or provider/API compatibility across SDKs, proxies, or direct upstream model APIs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when removing dead code, renaming symbols, or refactoring — any change with no external consumers. Triggers on deprecating dead code, wrapper shims, compatibility aliases, TODO-future-cleanup, or refactors that patch structure instead of simplifying.
Use when configuring custom providers for OpenCode.
Use when writing new React components that involve state derived from props, event-driven side effects, or external subscriptions. Also use when auditing existing code for unnecessary useEffect calls, reviewing useEffect-heavy components, or refactoring to eliminate cascading renders. Applies to React 18+ codebases.
Use when about to make git commits, when tempted to bundle unrelated changes behind a single message, or when commit history needs to support git bisect, revert, and cherry-pick workflows. Also use when reviewing a branch before creating a PR. If you are writing a plan, specify that the executor must load this skill before start working.
Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories has produced excessive noise.
Use when a user provides examples prefixed by "for example", "such as", "e.g.", "like", or ends a list with "etc." / "and so on". For architecture/design tasks, abstract first to identify the concept, then enumerate. For research/clarification tasks, enumerate first — the concept organizes the output but the list is the deliverable.
| name | developing-agents |
| description | Use when implementing or debugging agents, tool-calling assistants, or multi-step AI runtimes and you need correct message conversion, tool-call handling, replayed history, loop continuation, or provider/API compatibility across SDKs, proxies, or direct upstream model APIs. |
| license | CC-BY-NC-4.0 |
Use this skill when the hard part is no longer “call a model once”, but “make the runtime behave correctly across multiple steps”.
Focus on implementation, not product design. The main failure modes are almost always:
Do not use this skill for simple one-shot text generation with no tools and no replayed history.
Before writing adapters, read the actual provider message format instead of guessing.
messages, assistant tool_calls, tool messages with tool_call_id, streaming deltas, finish reasonsmessages array with structured content blockstool_use, tool_result, block-based content instead of plain assistant/tool strings“OpenAI-compatible” and “Anthropic-compatible” usually mean partially compatible until proven otherwise. Verify the exact fields you depend on:
Keep these separate at all times:
If any of these collapse into one field, replay turns will eventually break.
Also preserve this invariant:
A tool result is not just something to display. It is input to the next model step.
Do not pass user-facing message shapes directly into the SDK unless the SDK explicitly accepts them.
You usually need explicit conversion for:
Good:
Bad:
A tool integration is not correct when the model requests a tool once.
It is correct when this full path works:
Your runtime should have one authoritative source for:
Everything else should map back to that registry.
If your system has more than one boundary, verify all of these conversions explicitly:
Fixing one direction does not fix the others.
Streaming and non-streaming should agree on:
If the streamed path emits logically different events than the non-streamed path, you have two incompatible runtimes.
The minimal correct loop is:
Good stop conditions:
Bad stop conditions:
Replay bugs are the most common real-world agent bugs.
Always distinguish:
These are often related, but they are not always identical.
For replayed turns, verify all of these:
Typical conversions you may need:
tool_calls → SDK tool-call partstool_call_id → SDK tool-result partsTypical conversions you may need:
tool_use blocks → runtime tool-call recordstool_result blocks → runtime tool-result recordsNever convert by field name alone. Convert by meaning:
When tool calling or continuation breaks, inspect these in order:
At each step, ask:
Do not jump directly from final symptom to upstream blame.
Before claiming the integration works, verify all of these:
| Case | Must pass |
|---|---|
| Plain text, no tools | Assistant returns normal output |
| First-turn tool call | Correct tool name, id, and input |
| Tool result replay | Assistant continues correctly on next turn |
| Resumed/persisted history | Replayed tool call + result still work |
| Streaming tool path | Same semantics as non-streaming |
| Tool error path | Correct error propagation and loop behavior |
| Multi-tool environment | No synthetic id/name confusion |
If you only verified first-turn tool calling, you did not verify the agent.
If the symptom is:
Common pitfalls from real debugging:
tool_calls and tool result messages into SDK-native message partstoolu_* leak into the tool name field → keep toolCallId and toolName separate; recover the real tool name from the registry or schema match, not from display outputDo not consider the implementation correct unless all of these are true: