Instruction file imported from jalogisch/pixelGroomer (.cursor/rules/005_memory_events.mdc). Copyright stays with the author.

Memory Events System

This rule defines how I should respond to user-reported development events and suggest appropriate memory updates based on these events.

Event Reporting

Since automatic event detection isn't possible within Cursor's environment, I rely on users to report significant events using:

/memory event <event_type> <description>

For example:

/memory event commit "Implemented user authentication flow"

Supported Event Types

I recognize and respond to these event types:

File Events

Build Events

Test Events

Git Events

Session Events

Mode Events

Event Response Protocol

When an event is reported, I will follow this protocol:

1. Acknowledge the event: Confirm that I've understood the reported event

   • "I've noted your report of the [event_type]: [description]"

2. Suggest memory updates: Based on the event type, suggest appropriate memory updates

   • "Based on this event, I suggest updating the following memory files:"

3. Provide update content: Offer specific content to be added to memory files

   • "Here's the content you can add to progress.md:"

4. Confirm implementation: Ask for confirmation when updates are completed

   • "Have you updated the memory files? Let me know when it's done."

5. Action Summary and Next Steps: Provide a structured completion report with options

   • Include completion summary, relevant command options, and suggested next steps

Event-Memory Mappings

Different events should trigger updates to specific memory files:

File Creation:
  → Suggest updates to progress.md with new component information
  → Suggest updates to architecture.md for structural additions
  → Suggest updates to current_context.md if related to active task

File Modification:
  → Suggest updates to current_context.md with latest changes
  → Consider suggesting pattern extraction for repeated modifications
  → Suggest updates to progress.md for significant milestones

Successful Build:
  → Suggest updates to progress.md with build success
  → Consider suggesting updates to current_context.md with next steps
  → Suggest adding build information to session_notes.md

Failed Build:
  → Suggest adding issues to current_context.md
  → Suggest updating session_notes.md with error details
  → Consider suggesting additions to patterns.md for recurring problems

Test Execution:
  → Suggest updates to progress.md with test results
  → Suggest adding testing notes to session_notes.md
  → Consider suggesting pattern updates for test approaches

Git Commit:
  → Suggest updates to progress.md with commit milestone
  → Consider suggesting decision documentation from commit message
  → Suggest updates to current_context.md with next steps

Branch Change:
  → Suggest updates to current_context.md with branch context
  → Suggest loading relevant feature context from long-term memory
  → Consider suggesting context switch in progress.md

Mode Transition:
  → Suggest updates to specific memory files based on mode rules
  → Suggest promoting/consolidating memory based on transition type
  → Suggest updates to current_context.md with mode-specific focus

Session Start:
  → Suggest loading relevant memory context
  → Suggest resuming current_context.md from previous session
  → Suggest updating session_notes.md with session start

Session End:
  → Suggest consolidating session_notes.md
  → Suggest updating progress.md with session accomplishments
  → Suggest promoting important short-term to long-term memory

Annotation Recognition

I recognize code comment annotations and suggest appropriate memory updates:

// @memory:note This approach handles edge cases better than alternatives
→ Suggest adding to session_notes.md

// @memory:decision We're using JWT for authentication
→ Suggest adding to decisions.md

// @memory:pattern This pattern for API routing should be followed
→ Suggest adding to patterns.md

// @memory:architecture This service handles payment processing
→ Suggest adding to architecture.md

// @memory:todo Refactor this component to use the new pattern
→ Suggest adding to current_context.md

// @memory:progress Completed user authentication flow
→ Suggest updating progress.md

When I notice these annotations in code, I'll suggest appropriate memory updates.

Update Content Formatting

When suggesting memory updates, I'll format the content appropriately:

1. Progress Updates: Include timestamp, description, status, and next steps

   ### User Authentication
   **Completed:** 2025-04-14
   **Description:** Implemented basic authentication flow
   **Status:** In progress (70%)
   **Next Steps:** Add password reset functionality

2. Decisions: Include decision, date, rationale, and implications

   ### Authentication Approach
   **Decision:** Use JWT with asymmetric keys
   **Date:** 2025-04-14
   **Rationale:** Better security and support for microservices
   **Implications:**
   - Need to implement key rotation
   - Simplifies cross-service authentication

3. Patterns: Include name, usage, implementation, and example

   ### Repository Pattern
   **Usage:** Data access abstraction
   **Implementation:** Interface + concrete implementation
   **Example:**
   ```typescript
   interface UserRepository {
     findById(id: string): Promise<User>;
   }

Memory Update Suggestions

I'll make memory update suggestions in this format:

MEMORY UPDATE SUGGESTION
FILE: <file_path>
BASED ON: <event_type> - <description>
SUGGESTED CONTENT:

<formatted_content>

Would you like me to provide this update? (You can copy it to the file)

Event Completion Response

After processing any event, I will always conclude with:

## Event Processing Report
- **Event Type:** [Type of event processed]
- **Updates Suggested:** [Files suggested for update]
- **Status:** [Processed/Pending Implementation]

## Related Commands
- `/memory event <type> <details>` - Report another event
- `/memory update <file> <content>` - Make additional updates
- [1-2 contextually relevant commands]

## Recommended Actions
- [Specific follow-up action based on event type]
- [Memory update suggestion if applicable]
- [Mode-specific recommendation]

Integration with Modes

Different operational modes influence how I respond to events:

• THINK Mode: Emphasize research findings and exploration notes
• PLAN Mode: Focus on task breakdown and implementation plans
• IMPLEMENT Mode: Prioritize progress updates and implementation details
• REVIEW Mode: Highlight improvement suggestions and issue tracking
• DOCUMENT Mode: Balance updates across all memory files

I'll adjust my event response based on the current operational mode.