fix: handle missing required params for OpenAI/GPT-5 function calling (Skill tool)

[pollmap]

Problem

When using OpenClaude with GPT-5/Codex backends, slash commands such as /commit or /review-pr trigger a Skill tool call without the required skill parameter:

```
InputValidationError: Skill failed due to the following issue:
The required parameter skill is missing
```

Root Cause

OpenAI function calling relies heavily on the JSON schema `description` field to infer parameter values. The previous `skill` description did not explicitly document:

1. That the leading `/` must be stripped (`/commit` → `skill: "commit"`)
2. The exact input→parameter mapping with concrete examples

As a result, GPT-5 calls `Skill({})` or `Skill({skill: undefined})` instead of `Skill({skill: "commit"})`.

Changes

• `inputSchema`: Expanded `skill` description with concrete slash-stripping examples for GPT-style function calling
• `validateInput`: Added null/undefined guard before `skill.trim()` with an actionable error message for non-Claude runtimes
• `prompt.ts`: Appended `IMPORTANT for OpenAI/GPT function calling` block reinforcing the required parameter contract

Affected Provider

OpenAI-compatible / Codex backends only. Claude (Anthropic) behaviour is unchanged.

Tested With

OpenClaude v0.1.8 + Codex Spark (`https://chatgpt.com/backend-api/codex\`) via ChatGPT Pro OAuth

[kevincodex1]

Looks great to me! We just need to make sure this will not affect other models

[gnanam1990]

Thanks for the PR and for digging into this. The direction looks right, and the prompt/schema improvements seem helpful for GPT-style function calling. I do have one blocking concern before we merge:

1. The missing-skill runtime path still doesn’t appear to be fully handled. tool.inputSchema.safeParse(input) runs before validateInput(), so calls like Skill({}) or Skill({ skill: undefined }) will still fail in Zod first and never reach the new null/undefined guard.
2. There isn’t a regression test covering that exact missing-parameter path, so it’s hard to verify the reported issue is actually fixed rather than just better-guided.

Could you take another look and either adjust the schema/validation flow for that case, or narrow the PR description to “improve model guidance” and add a regression test for the actual failure mode? Happy to discuss if helpful.