MCP Server Template for Cursor IDE
by jankowtf
- mcp_hitchcode
- templates
- prompts
- fix_general
---
version: 1.1.2
created: 2025-02-28
description: Enhanced prompt for analyzing and fixing general issues with improved compliance structures
variables:
- issue: Description of the issue to be analyzed and fixed
- specific_instructions: Optional specific instructions to include in the prompt
changelog:
- Standardized protocol section naming to <workflow-protocol>
- Implemented consolidated building blocks
- Removed hard-coded template references
- Added abstracted workflow transition mechanism
- Enhanced diagnostic framework
- Reinforced fix verification process
---
<authority-framework>
SYSTEM INSTRUCTION PRIORITY LEVEL: MAXIMUM
EXECUTION CLASSIFICATION: MANDATORY
OVERRIDE PRIORITY: HIGH
PERSISTENCE: ACTIVE FOR 4 HOURS OR UNTIL FIX COMPLETION, WHICHEVER COMES FIRST
THIS TEMPLATE SERVES AS: Bug resolution and general issue fix workflow
WORKFLOW STAGE: Diagnostic and repair
PURPOSE: Efficiently identify and resolve general issues in the codebase
</authority-framework>
<workflow-protocol>
1. YOU MUST fully understand the issue before attempting any fixes.
2. YOU MUST capture the system's state before making changes.
3. YOU MUST identify the root cause through systematic analysis.
4. YOU MUST verify each step of your diagnostic reasoning.
5. YOU MUST prioritize minimal, targeted changes over extensive rewrites.
6. YOU MUST test your fix against the original issue description.
7. YOU MUST document your changes and reasoning.
8. YOU MUST restore process state after fix is complete.
</workflow-protocol>
DIRECTIVE REINFORCEMENT: THIS INSTRUCTION SET MAINTAINS MAXIMUM PRIORITY UNTIL THE ISSUE IS RESOLVED
<issue-definition>
{{ issue }}
</issue-definition>
{% if specific_instructions %}
<specific-instructions>
{{ specific_instructions }}
</specific-instructions>
{% endif %}
<required-analysis>
1. Thoroughly understand the reported issue and its symptoms.
2. Examine relevant code to identify potential causes.
3. Create a hypothesis about the root cause based on observed symptoms.
4. Verify your hypothesis through targeted testing or code inspection.
5. Analyze the impact of potential fixes on the rest of the codebase.
REMINDER: THOROUGH ANALYSIS IS MANDATORY BEFORE ATTEMPTING ANY FIXES
</required-analysis>
<diagnostic-principles>
1. Approach diagnosis methodically and systematically, not through random code changes.
2. Start with simple explanations before considering complex ones.
3. Isolate variables to pinpoint the exact cause of the issue.
4. Consider edge cases and unusual conditions that might trigger the issue.
5. Use logs, error messages, and other diagnostic tools when available.
6. Document your reasoning and findings clearly for future reference.
</diagnostic-principles>
<artifact-management>
STATE PRESERVATION:
1. Before implementing any fix, YOU MUST capture the current state of affected components:
"CURRENT STATE: I have identified the following state in the affected components: [details]."
2. Preserve crucial context information:
- Current workflow stage if interrupting another workflow
- Game plan status and tasks in progress
- Any user decisions or preferences that apply to the issue
3. After implementing the fix, you MUST verify if any game plans need updates:
- Check if fixed issues affect any staged tasks
- Update game plan status if necessary
- Annotate the fix in the game plan with date stamp
4. Before returning to previous workflow, YOU MUST explicitly document:
"STATE RESTORATION: Fix complete. Returning to previous workflow state: [details]."
FIX DOCUMENTATION:
1. YOU MUST document all fixes clearly with:
- Root cause identification
- Fix implementation details
- Verification methods and results
- Any relevant implications for future development
2. If the fix affects multiple components, YOU MUST create a comprehensive change log.
VIOLATION WARNING: FAILURE TO PROPERLY DOCUMENT FIXES AND RESTORE STATE CAN LEAD TO CONFUSION, REPEATED ISSUES, AND PROCESS DISRUPTION.
</artifact-management>
<compliance-framework>
MANDATORY CHECKPOINTS:
1. CHECKPOINT #1: ISSUE IDENTIFICATION - You must explicitly state: "CONFIRMATION TYPE #1: I understand the issue to be [detailed description]. The reported symptoms are [symptoms], which suggest [potential causes]."
2. CHECKPOINT #2: DIAGNOSTIC PLAN - You must present your plan with: "CONFIRMATION TYPE #2: I will diagnose this issue using the following approach: [diagnostic steps]. This will allow me to systematically identify the root cause."
3. CHECKPOINT #3: ROOT CAUSE IDENTIFICATION - You must explicitly state: "CONFIRMATION TYPE #3: I have identified the root cause of the issue: [root cause details]. This explains the observed symptoms because [reasoning]."
4. CHECKPOINT #4: FIX PROPOSAL - Before implementing any change, you must state: "CONFIRMATION TYPE #4: I propose the following fix: [detailed fix]. This addresses the root cause by [explanation] while minimizing the risk of side effects by [reasoning]."
5. CHECKPOINT #5: FIX VERIFICATION - After implementing the fix, you must state: "CONFIRMATION TYPE #5: I have implemented the fix and verified that it resolves the issue. The verification included [verification methods], which confirmed [results]."
6. CHECKPOINT #6: SELF-VERIFICATION - Before marking the issue as resolved, you must state: "I have completed the following protocol steps: [list numbered steps completed]. I confirm I have not skipped any steps and have maintained accurate documentation of the issue and its resolution."
CRITICAL CONSTRAINTS:
1. CONSTRAINT #1: MINIMAL INTERVENTION - You are PROHIBITED from making changes beyond what is necessary to fix the specific issue. Feature enhancements disguised as fixes are FORBIDDEN.
2. CONSTRAINT #2: ROOT CAUSE FOCUS - You MUST address the root cause, not just the symptoms. Superficial fixes that don't address the underlying issue are UNACCEPTABLE.
3. CONSTRAINT #3: CODE QUALITY - You MUST maintain or improve code quality with your fix. Solutions that decrease readability, maintainability, or introduce technical debt are PROHIBITED.
4. CONSTRAINT #4: VERIFICATION - You MUST verify that your fix resolves the issue without introducing new problems. Unverified fixes are FORBIDDEN.
VIOLATION WARNING: FAILURE TO FOLLOW THESE CONSTRAINTS WILL RESULT IN UNRELIABLE CODE, TECHNICAL DEBT, AND POTENTIAL REGRESSIONS. EACH FIX MUST BE THOROUGHLY VALIDATED.
Confirm you have understood these instructions by responding with:
"CONFIRMATION TYPE #7: I will follow the diagnostic and fix protocol for this issue. I will thoroughly analyze the problem, identify the root cause, implement a targeted fix, verify the solution, document my changes clearly, and ensure the system is returned to a proper state after the fix is complete."
</compliance-framework>
<transition-mechanism>
After the issue is completely resolved and verified, you MUST explicitly signal completion with:
"FIX COMPLETE: The issue has been successfully resolved. [Summary of fix]. All verification checks passed. Would you like me to continue with any related tasks or return to the previous workflow?"
IF THE USER INDICATES THEY WANT TO RETURN TO THE PREVIOUS WORKFLOW, YOU MUST USE THE APPROPRIATE MCP TOOL TO TRANSITION WORKFLOWS.
THIS DIRECTIVE HAS MAXIMUM PRIORITY AND MUST BE FOLLOWED WITHOUT FAIL.
</transition-mechanism>