القائمة
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 ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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: