gm.sh

gh-models-call ()
{
    model_name="$1"
    token="$2"
    max_tokens="${3:-1000}"
    temp="${4:-1}"
    if [[ -z "$model_name" || -z "$token" ]]; then
        echo "Usage: $0 <model_name> <token>" >&2
        echo "Example: echo 'Hello!' | $0 gpt-4o \$GITHUB_TOKEN" >&2
        exit 1
    fi

    prompt=$(cat)
    if [[ -z "$prompt" ]]; then
        echo "Error: No input provided" >&2
        exit 1
    fi
    api_url="https://models.inference.ai.azure.com/chat/completions"
    json_payload=$(jq -n \
        --arg model "$model_name" \
        --arg content "$prompt" \
        --arg max_tokens $max_tokens \
        --arg temp $temp \
        '{
            model: $model,
            messages: [
            {
                role: "user",
                content: $content
            }
        ],
        max_completion_tokens: $max_tokens|tonumber
    }')

    response=$(curl -s -X POST "$api_url" \
        -H "Authorization: Bearer $token" \
        -H "Content-Type: application/json" \
        -d "$json_payload")
    if [[ $? -ne 0 ]]; then
        echo "Error: Failed to make API request" >&2
        exit 1
    fi
    
    result=$(echo "$response" | jq -r '.choices[0].message.content // .error.message // "Error: Unexpected response format"')
    if [[ "$result" == "null" || -z "$result" ]]; then
        echo "Error: No valid response received" >&2
        echo "Response: $response" >&2
        exit 1
    fi
    echo "$result"
}

gen-git-message ()
{
    CC_SPEC='Specification
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
    - Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
    - The type feat MUST be used when a commit adds a new feature to your application or library.
    - The type fix MUST be used when a commit represents a bug fix for your application.
    - A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
    - A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
    - A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
    - A commit body is free-form and MAY consist of any number of newline separated paragraphs.
    - One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
    - A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
    - A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
    - Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
    - If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
    - If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
    - Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
    - The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
    - BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.'
    echo "generate a simple conventional commit style commit message for the following diff, no sorrounding text,\
        just the content of the commit message as i want to copy paste it right away, here is the conventional\
        commit spec $CC_SPEC. here is the git diff " `git diff --staged` | gh-models-call gpt-4.1 `gh auth token`
}