Commit and PR Writer

Reviewers often read the commit message and PR body before the diff, yet these are typically written in a hurry from memory. This leads to vague descriptions like "fix stuff" and unrelated changes being crammed into single commits, making code reviews difficult and rollbacks impossible. This skill enforces a disciplined git workflow that prioritizes the reviewer's needs and ensures every change is documented with technical precision.

What it does

• Diff analysis extracts file counts, insertions, deletions, and structural changes directly from git before writing begins.
• Concern splitting analyzes staged paths by area to suggest separate commits for unrelated changes, ensuring clean history.
• Message drafting generates imperative subjects under 72 characters and structured bodies covering the "why," impact, and verification.
• Automated linting validates messages for length, mood, vagueness, and mandatory verification commands to prevent low-quality logs.
• PR assembly builds reviewer-first pull request bodies including risk assessments, rollback plans, and grouped commit summaries.

How it works

1. Analyze: Run facts to get a data-driven report of what actually changed in the staged files or commit range.
2. Organize: Use split to group changes by logical area and generate the specific git add commands needed for atomic commits.
3. Draft: Execute draft to produce a subject line and body scaffold based on the largest functional changes detected.
4. Validate: Pipe the written message through lint to check for vagueness, missing verification commands, or subject line errors.

Frameworks & tools

The core logic is contained in a Python script using the standard library. It interacts directly with git CLI via subcommands like facts, split, draft, pr, and lint. It requires no external dependencies or network access.

Why this beats prompting it yourself

Generic AI prompts often guess what changed based on filenames alone and produce "hallucinated" summaries of the logic. This skill uses a Python-backed analysis of the actual git diff to ground every claim in data, ensuring the "Verified" and "Risk" sections reflect real code impact rather than polite filler.

Use cases

• Splitting a large, messy "work in progress" stash into a clean series of atomic commits.
• Generating a professional PR description for a complex branch with multiple contributors.
• Enforcing commit message standards across a team to ensure "fix stuff" never hits the main branch.
• Validating that every commit includes a repeatable verification command and output log.

Known limitations

It requires a local git environment and Python 3. The lint command needs access to the repository to validate diff-related claims; without it, only basic subject and body formatting checks are performed.