Use when implementing OpenAI tool or function calling from an approved ai-architecture.md tool surface. Produces tool schemas, provider SDK wiring, execution adapters, authorization checks, idempotency rules, audit logging, tool failure handling, and tests for allowed, denied, failed, and retried tool calls. Do not use for AI architecture, generic chat, RAG, structured extraction without tools, or agent framework orchestration.
Use when implementing OpenAI tool or function calling from an approved ai-architecture.md tool surface. Produces tool schemas, provider SDK wiring, execution adapters, authorization checks, idempotency rules, audit logging, tool failure handling, and tests for allowed, denied, failed, and retried tool calls. Do not use for AI architecture, generic chat, RAG, structured extraction without tools, or agent framework orchestration.
OpenAI Tool Calling Runtime
When to use
Invoke when ai-architecture.md defines a tool surface and OpenAI is the chosen
provider for tool-calling behavior.
Do not use when the tool surface has not been approved, when actions have
unresolved side effects, or when the user is asking for framework-level agent
orchestration.
Inputs
Required:
Approved ai-architecture.md.
Tool names, schemas, side-effect classes, and authorization scopes.
Target application language and framework.
Audit and logging requirements.
Optional:
Existing service interfaces for tool execution.
Idempotency keys or correlation-id strategy.
Rate limits and retry budgets.
Human-in-the-loop requirements.
Operating rules
Implement only tools approved in ai-architecture.md. An unlisted tool is a defect, not an enhancement.
Every tool has a side-effect class, authorization scope, and idempotency rule defined before code is written. Any missing → refuse and raise an ADR candidate.
Authorization and input validation precede side effects, always. The model proposing a call is never sufficient justification to execute it.
Side-effecting tools are idempotent or guarded by an idempotency key or correlation id supplied by the caller, not the model.
Tool failures are explicit states. Timeout, denied-authorization, malformed-arguments, and downstream-failure each have defined handling and a defined model-visible result.
Audit before mutate. Tool name, actor, correlation id, redacted arguments, outcome, and side-effect class are recorded before the side effect commits.
No secret or PII leakage through tool arguments, results, or logs.
Output contract
The implementation MUST conform to:
api-standards — tool schemas are a contract surface; argument shape and versioning policy apply.
security-standards — authorization enforced before side effects, audit trail, no credential or PII leakage, provider and downstream credentials injected at deploy time.
observability-standards — audit logs, per-tool metrics, and trace propagation across the tool-call boundary.
deployment-standards — tool endpoints and credentials are deploy-time configuration, never baked into prompts or code.
naming-conventions — tool names and audit field names follow project rules.
Upstream contract: ai-architecture.md is the source of truth for the tool surface, schemas, side-effect classes, authorization scopes, and idempotency rules; architecture/security is the source of truth for the authorization model. If either is silent, this skill pauses and raises an ADR candidate rather than inventing the decision.
Process
Load ai-architecture.md and identify each approved tool, schema, side-effect class, and authorization scope.
Refuse to implement tools with undefined side effects, missing auth scope, or missing idempotency behavior.
