Introduction

As projects grow, consistency becomes a real problem, especially around commit messages and Pull Request descriptions. Different styles, missing context, or unclear intent slow down reviews and make project history harder to understand over time.

Cursor AI provides several ways to guide how the assistant behaves, but not all of them fit well into everyday development workflows. Some approaches are better suited for persistent guidance, while others work best when applied intentionally and only when needed.

This post describes a simple and manual workflow using Cursor AI rules to generate standardized commit messages and clear, reviewable Pull Request descriptions, without automating Git or integrating directly with GitHub.

Without automating Git or integrating directly with GitHub.

Ways to Guide Cursor AI (and Why Rules Work Best Here)

Cursor gives you a few options to influence how the AI behaves:

1. Cursor Skills

Skills are great for:

• Repetitive transformations
• Always-on behavior
• Quick shortcuts

But they tend to be:

• Implicit
• Automatically applied
• Less contextual to when you want them

For commit and PR generation, this can be a downside — you don’t always want the AI making assumptions.

2. AGENT.md (Agent Instructions)

An AGENT.md file is useful when:

• You want a persistent coding assistant
• You want consistent architectural guidance
• The agent should always follow certain rules

However, commit messages and PR descriptions are not always-on concerns. You don’t want the agent thinking about PR structure while refactoring code or debugging.

3. Why Rules Are a Better Fit

Rules are:

• Explicit
• Opt-in
• Called manually

They behave more like checklists than background automation.

You decide:

• When they apply
• Which rule to use
• What input the agent should analyze

That makes them perfect for:

• Commits
• Issues
• Pull Requests

Rules offer a different balance. They are explicit, opt-in, and can be manually invoked. Nothing happens unless you ask for it. This makes rules ideal for tasks that should happen at specific moments in the workflow, such as preparing a commit or opening a Pull Request.

Use Case 1: Standardized Commit Messages

The Problem

Even experienced developers still end up with commits like:

fix stuff
update logic
changes

They’re fast, but they destroy long-term clarity.

The Rule

You define a commit rule, for example:

@git-commit-msg-rule.mdc

This rule defines how commit messages should be structured. This can include format conventions, tone, scope expectations, and guidance on when to include additional context.

The important detail is that the rule is not applied automatically. It only runs when you explicitly call it.

Golden Prompt: Commit Message Generation

Golden Prompt

Based on the staged changes, use git diff and create a commit message
that can be copy and pasted.
Follow the rules defined in @git-commit-msg-rule.mdc

When you run this prompt, Cursor analyzes the staged diff and generates a commit message that follows the defined rule. You review it, copy it, and commit manually. There are no hooks, no enforcement, and no surprises.

Result

Cursor will:

• Inspect git diff --staged
• Infer intent
• Generate a clean, standardized commit message

You:

• Review it
• Copy & paste
• Commit manually

No hooks. No enforcement. No surprises.

Use Case 2: Pull Request Message Generation

The Problem

PR descriptions often:

• Miss the “why”
• Dump raw change lists
• Require rewriting during review

The Rule

You define a PR rule, for example:

@git-pr-template-rule.mdc

This rule defines the expected structure of a PR description. This usually includes a clear summary, references to related issues, a description of the changes, testing notes, and any relevant warnings or breaking changes.

As with commit rules, this rule is only applied when you explicitly ask for it.

Golden Prompt: Pull Request Description

Golden Prompt

According to the commits in this branch, use git diff or any better
command or approach you consider to create a Pull Request message
that can be copy and pasted.
Follow the rules defined in @git-pr-template-rule.mdc

Cursor analyzes the commits and differences between branches, then generates a GitHub-ready Pull Request description in Markdown. You remain fully in control of when this happens and what gets published.

Result

Cursor will:

• Analyze commits in the branch
• Compare against the base branch
• Generate a GitHub-ready PR description in Markdown

You stay in control of when and how it’s used.

Development Advice: Git Practices That Improve AI Results

AI is only as good as the signals you give it. These Git practices significantly improve both human reviews and AI-generated commits/PRs.

1. Avoid “Big Bang” Commits

Try not to commit:

• Too many unrelated changes
• Large refactors mixed with bug fixes
• Dozens of files in a single commit

Smaller, focused commits help the AI:

• Understand intent more accurately
• Generate clearer summaries
• Avoid vague or misleading messages

If the change feels hard to describe in one sentence, it’s probably too big.

2. Stage Changes Intentionally

Instead of:

git add .

Prefer:

• Staging related files together
• Creating multiple commits for different concerns

This gives git diff --staged a clean narrative, which directly improves AI output.

3. Always Track Client-Reported Issues Properly

When a client reports a bug or request:

1. Create a GitHub issue

   • Even if the fix is simple
   • Even if it’s “urgent”

2. Create a dedicated branch

   fix/issue-123-sensor-timeout

3. Implement the fix in isolation

4. Open a Pull Request

   • Reference the issue
   • Target develop or the last stable branch
   • Use the PR rule to generate the description

This workflow:

• Preserves traceability
• Helps the AI connect commits to intent
• Keeps production branches clean

4. Merge via Pull Requests, Not Direct Pushes

Even in small teams:

• PRs act as documentation
• AI-generated descriptions become long-term project memory
• Reviews catch context mismatches early

Rules shine the most when changes flow through PRs.

Why This Manual Approach Scales Better

This setup:

• Avoids hidden AI behavior
• Keeps responsibility with the developer
• Works across teams and repositories
• Can evolve rule-by-rule

Rules act as opt-in contracts, not background noise.

Final Thoughts

This workflow reflects what currently works for me, based on my own coding habits and the way I like to work day to day.

Cursor Skills and AGENT.md are powerful tools, especially when you want behavior to be persistent and always active. I still use them in other contexts. But for commits and Pull Requests, I’ve found that explicit, manually-invoked rules fit my style better.

For commits and PRs, I care about:

• Precision
• Intent
• Control

Rules combined with golden prompts give me exactly that, without introducing hidden behavior or over-automation.

Of course, tools evolve and workflows should evolve with them. What works today in Cursor might look different tomorrow, or you might prefer a similar approach using another AI tool entirely.

If this setup inspires you to:

• Adjust the rules
• Automate more (or less)
• Or adapt the idea to your own tooling

Then it’s already doing its job.

The goal isn’t to follow a “correct” workflow, it’s to build one that supports how you think, code, and ship software.