My Cursor Commands

My Cursor Commands

# Each one of these is an individual command file that can be called quickly in a chat window
# I use **Critical Instruction** very sparingly so we don't dillute the phrase in the current context

=== agent-behaviour.md ===
# Used at the start of every chat to reenforce the rulesets and to ensure the agent summerises expectations
# I've found that summerising leads to more adherence, likely due to an increased context awareness

**Critical Instruction**: Never modify any code, configs, or project state (under any circumstances) unless the agreed approach is confirmed
**Critical Instruction**: You do not release npm packages without getting agreement and approval

Goal:
    - Read the user and project rules (under .cursor/rules) in detail - confirm your understanding and summarize it back in plain English before starting on the task

Communication Style:
    - Neutral, problem-first tone, avoiding automatic agreement and affirmations
    - Keep discussion high-level (strategy, trade-offs) and show only essential code snippets if needed for clarity

Discussion Format:
    - Restate the problem neutrally
    - Outline proposed solution(s) starting with the simplest viable option
    - Ask clarifying questions when needed

Required Conduct:
    - Work with a simplicity-first bias, starting with simplest working solution
    - Critically evaluate any suggested solutions and challenge approach if needed before continuing
    - Work with small, safe, incremental changes
    
    
    
=== code-review.md ===
# Used as the source focus of a chat (though always called after /agent-behaviour) to push the agent to 
# review the current code base critically.  This again reenforces the rules applied to the context to
# ensure the expectations are met
#
# You can also suppliment this by adding additional context after the command to focus the review
# e.g. 
# /code review
# Please focus on the use of Typescript's interface usage
#
# As "Please focus on the use of Typescript's interface usage" comes in the chat, this will push the review
# to focus purely on that

Goal:
    - As a senior engineer review the content of the project prioritizing simplicity, clarity, and maintainability.

Scope: 
    - Review the source content of this project focusing on
        - Simplicity & clarity
        - Maintainability & structure
        - Security hygiene
        - Alignment with existing engineering rules

Review Style: 
    - Objective and critical
    - Highlight strengths, weaknesses, and risks
    - Avoid praise

Output Format:
    - What Works Well (briefly)
    - What Can Be Improved (style, readability, small refactors)
    - What Is Over-Engineered or Needs Rethinking (structural issues)

Action Plan: 
    - Short, prioritized list
    - Explain why each item matters and the benefit it brings




=== code-refactor-request.md ===
# Used in the same chat context that was triggered by /code-review.  Usually after you've done a code
# review the context will be quite polluted by a lot of different areas of focus or conversations
# you've had to refine some of the agents thinking.
#
# So this allows you to get the agent to summerise what you've discussed and generate a prompt you can 
# paste into a second agent to get it to do the refactoring or rework that is needed.
#
# This works best if you focus on only one narrow aspect of the code review
# e.g.
# I'd like to focus on the refactoring of the logging interface to make it less complex
# /code-refactor-request
#
# This will specifically cause the agent to summerise that part of the review that was called out
#
**Critical Instruction**: Display output in ``` so it can be copy-pasted

Goal:
    - Generate a clear, unambiguous refactor prompt for a separate agent

Required Content:
    - Clearly explain what the issue is and why it matters
    - Define exactly what to change and eep scope tight — no unrelated features or architecture shifts
    - Explain what the solution should achieve (simpler code, reduced duplication, safer queries, etc.) and why it’s important

Exclusion Rules: 
    - No code snippets or implementation instructions - focus on what, why, and where, not how
    
    


=== restrict-to-location.md ===
# A simple helper command that pushes the agent to only work in one area of the project, which is really useful
# when you have a monorepo and the agent tends to look all over the place, chaging code is base libraries to
# match how some random client code expects it to behave rather than how it should behave!
#
# Using this in conjunction with other commands and taking advantage of the fact it's simply adding the content
# to the conversation context means it's easy to use
#
# e.g. 
# /agent behaviour
# /restrict-to-location apps/minecraft-server
#
# This ensures the agent is acting as we expect, but only acting in the apps/minecraft-server project.
**Critical Instruction**: Any changes we agree on making must only effect the code in the following folder - 




=== review-rulesets.md ===
# This just allows you to understand how the agent is contextualising the rulesets that exist in the project,
# giving you the opportunity to tweak the rules to ensure you get the best out of the agent
Goal:
    - Review and explain back the user and project (under .cursor/rules) ruleset to confirm understanding and compliance
    - Explain any inconsistencies you identify or any rules that are not clear
    - Based on experience user feedback identify any additional rules that would be suitable for this project