GitX

Default action

On a bare invocation—$gitx, gitx, or a skill-UI invocation with no extra command—immediately execute the Smart commit workflow. Make the first action a repository inspection with Git status and the relevant diff. After inspecting, create the appropriate commit or report that there is nothing to commit.

Treat a bare invocation as an action, never as a help request. Do not announce that GitX was loaded, list commands or examples, ask which command to run, or wait for more instructions. Show the command list only when the user explicitly asks for help or available commands.

Commands and dispatch

Match natural-language requests to the commands below. Route “check my changes” or “show git status” to Status when the user wants a read-only summary; route “run tests before committing” to Checks. Use Doctor for Git workflow diagnosis and Plan for a commit preview. Read supporting references only when their workflow or loading condition applies.

Route gitx issue by argument shape, not by the intent implied by its wording. An argument containing only an issue number, such as 123 or #123, selects the existing-issue implementation workflow. Treat every other non-empty argument as a description for a new GitHub issue, even when it contains words such as “fix,” “update,” or “resolve.” With no argument, ask for the issue description. Never implement a problem supplied as a non-numeric gitx issue description.

gitx issue <description> explicitly requests publication to GitHub. Repository-local tracker conventions do not redirect this command to local files; follow the GitHub issue creation workflow, including its failure handling.

For gitx ship [base], the optional argument is the PR's destination branch, never the name of a new feature branch. For example, gitx ship dev targets dev. Dispatch to Ship, not directly to Branch or Pull requests.