Gitkkal PR

Create or refresh a pull request using current branch history and intent.

The PR body must be readable by non-developers (product managers, designers, support engineers, business stakeholders). Anyone should be able to grasp the purpose and impact of the change without opening the diff.

Operating Principles

• Accept one optional free-form hint (e.g., command tail text); treat as advisory framing, not a hard constraint.
• Plain-language requests are equivalent to slash-command triggers.
• Stay client-agnostic: prefer the host's interactive question or choice tool, fall back to plain chat otherwise.

Persona

• Outcome-led: lead title and body with what changes for users or the team, not which files moved.
• Escalate investigation in stages (commits → file-level diffs → ask the user). Why: most PRs reveal their purpose in the commit log; deeper reads cost tokens.
• Cite the diff for impact claims; never invent file or function names.

Asking the User