Q: Best Practices for activeContext.md and progress.md Usage in Large Teams

[uriklar]

Hi!
We’re using the CursorRIPER Framework on a large project with multiple teams and many parallel feature streams. I’d like to clarify the intended best practices for maintaining the activeContext.md and progress.md memory bank files in this context.

Specifically:
activeContext.md:
The documentation describes this as a place for “current work focus and next steps.”
In a large project, there are many simultaneous features and sub-teams, each with their own priorities and tasks.
Should activeContext.md be used only for high-level, project-wide context (e.g., major milestones, recent architectural changes, and the next big priorities)?
Or is it intended to track more granular, day-to-day or per-developer work?

If it’s project-level only, do you recommend any patterns for tracking per-feature or per-team context?

progress.md:
This file appears to be for summarizing what works, what’s in progress, what’s left to build, known issues, and milestones.
Should it also remain high-level, focusing on major project components and milestones, rather than detailed ticket or feature tracking?

How do you recommend keeping this file useful and up-to-date in a fast-moving, multi-team environment?

Additional Questions:
Should both files always be committed to version control, or are there scenarios where they should be kept local or per-developer?

Any tips for keeping these files relevant and not redundant with issue trackers or project management tools?

Thank you for your time and work 🙏

[johnpeterman72]

Currently, the framework is more geared towards a single developer. Your usage is interesting. Can you tell me more about how you are deploying the framework within the team environment so I can think about your issues?

[uriklar]

Thanks for the quick reply! So we have a pretty big monolith which mainly serves one big app, but is starting to be broken down to different apps using module federation. I just recently integrated CursorRIPER after it was recommended to us.
The main benefit I see in it is the clear division into the different modes, which as I see it really helps rein in the AI.
We've finished the start phase, but I think it's pretty hard to map out all the different patterns and architecture across the code base.. I'm also a bit concerned about how the whole memory bank plays with Cursor rules..

So basically still trying to figure out how CursorRIPER fits in our workflow. But since we have many developers working on different features, I was thinking that maybe we don't have to commit activeContext and progress, and have them be personal for each person's work.

Sorry for the context dump...

[johnpeterman72]

Here are my thoughts: You've identified a critical challenge. CursorRIPER was initially designed for a single project, single-developer context.

Scaling CursorRIPER for Large Multi-Team Projects

Recommended Best Practices for Your Scenario

1. activeContext.md - Personal/Team-Level Approach

Given your multi-team environment, I strongly recommend:

• Keep it personal or team-scoped: Each developer/team maintains their own activeContext.md
• Use it for: Current feature work, immediate tasks, local architectural decisions
• Don't commit: Keep it in .gitignore for personal use

Alternative pattern for teams:

/memory-bank/
    activeContext-{team-name}.md    # Team-specific contexts
    activeContext-{feature-name}.md # Feature-specific contexts
    activeContext-personal.md       # Developer's personal context

2. progress.md - Hybrid Approach

For progress tracking:

• Project-wide version: Commit a high-level progress.md tracking major milestones, architectural changes, and cross-team dependencies
• Personal versions: Each developer maintains progress-personal.md for their specific work

/memory-bank/
    progress.md           # Committed, project-wide
    progress-personal.md  # Gitignored, developer-specific

Addressing Your Specific Concerns

Memory Bank vs Cursor Rules

The memory bank and Cursor rules serve different purposes:

• Cursor rules: Define how the AI should behave (coding standards, patterns)
• Memory bank: Provides context about current work and project state

They're complementary, not competing. In fact, you could reference memory bank files in your Cursor rules:

# In .cursor/rules/***.mdc
When working on features, always check:
- @activeContext-personal.md for current focus
- @progress.md for project-wide status

Module Federation Challenge

For your monolith-to-module-federation transition:

1. Create module-specific contexts:

   /memory-bank/modules/
     module-auth/activeContext.md
     module-payments/activeContext.md
     module-shared/activeContext.md
   

2. Use the RIPER modes to manage complexity:

   • Research mode: Understand existing monolith patterns
   • Plan mode: Design module boundaries
   • Execute mode: Implement with strict scope control

Practical Workflow Suggestions

1. Personal Memory Bank Pattern:

   # In your .gitignore
   /memory-bank/*-personal.md
   /memory-bank/activeContext.md
   
   # Committed files
   /memory-bank/progress.md        # Project-wide
   /memory-bank/architecture.md    # Shared decisions
   

2. Team Synchronization:

   • Weekly sync meetings to update project-wide progress.md
   • Each team maintains its own context files
   • Use PR descriptions to bridge personal context to project history

3. Integration with Existing Tools:

   • Keep memory banks lightweight - they're for AI context, not project management
   • Reference ticket numbers in memory banks rather than duplicating
   • Use memory banks for "why" and "how", use PM tools for "what" and "when"

Additional Recommendations

1. Start Small: Begin with personal memory banks, then gradually introduce team-level files as patterns emerge

2. Version Control Strategy:

   Commit:
   - /memory-bank/progress.md (project-wide)
   - /memory-bank/architecture.md
   - /memory-bank/patterns.md
   
   Don't Commit:
   - /memory-bank/activeContext*.md
   - /memory-bank/*-personal.md
   - /memory-bank/modules/*/activeContext.md
   

3. Mode Enforcement: The RIPER modes remain valuable even at scale - they prevent the AI from making unintended changes across module boundaries

The framework's real value in your scenario is indeed the RIPER mode structure, which helps control AI behavior - the memory bank can be adapted to your needs.

I have been working only on the Sigma version of Ripper, so I'll have to backtrack to this version if you want me to take a deeper dive into making changes for the team-based approach.

[johnpeterman72]

A real quick possible solution or path forward:

Standardized Session Initialization Pattern

Create a Mandatory Session Init Protocol

Implementation that requires these four pieces of information (whatever the number is) at the start of every AI Chat session:

1. Cursor Rules for Session Init

# .cursor/rules/session_initialization.mdc
session_initialization:
  mandatory_context:
    - project_name
    - developer_name  
    - team_name
    - module_name
  
  initialization_sequence:
    step_1:
      prompt: "Welcome to CursorRIPER! Please provide your session context:"
      required_format: |
        Project: [project-name]
        Developer: [your-name]
        Team: [team-name]
        Module: [module-name]
    
    step_2:
      action: "Validate provided context"
      checks:
        - Directory exists: /memory-bank/projects/{project_name}/
        - Developer folder exists: /memory-bank/developers/{developer_name}/
        - Team folder exists: /memory-bank/teams/{team_name}/
        - Module config exists: /modules/{module_name}/config.yml
    
    step_3:
      action: "Set session context"
      creates_variables:
        - SESSION_PROJECT
        - SESSION_DEVELOPER
        - SESSION_TEAM
        - SESSION_MODULE
        - SESSION_TIMESTAMP
    
    step_4:
      action: "Display context confirmation"
      template: |
        ✅ Session initialized:
        - Project: ${SESSION_PROJECT}
        - Developer: ${SESSION_DEVELOPER}
        - Team: ${SESSION_TEAM}
        - Module: ${SESSION_MODULE}
        - Memory Bank: /memory-bank/developers/${SESSION_DEVELOPER}/
        - Team Context: /memory-bank/teams/${SESSION_TEAM}/
        - Module Config: /modules/${SESSION_MODULE}/

memory_bank_rules:
  allowed_paths:
    - /memory-bank/developers/${SESSION_DEVELOPER}/**
    - /memory-bank/teams/${SESSION_TEAM}/**
    - /memory-bank/projects/${SESSION_PROJECT}/**
    - /modules/${SESSION_MODULE}/**
  
  forbidden_operations:
    - "NEVER modify files outside session context paths"
    - "NEVER access other developers' memory banks"
    - "NEVER modify other teams' contexts"
    - "NEVER work on modules outside SESSION_MODULE"

operation_guards:
  before_any_modification:
    - "Verify file is within allowed_paths"
    - "Display: 'Modifying as ${SESSION_DEVELOPER} on ${SESSION_MODULE}'"
    - "Confirm path: ${full_file_path}"

2. Directory Structure

  session-init/
    templates/
      welcome.md
      context-required.md
    
  memory-bank/
    projects/
      {project-name}/
        architecture.md
        progress.md
    
    developers/
      {developer-name}/
        activeContext.md
        progress.md
        modules/
          {module-name}/
            context.md
    
    teams/
      {team-name}/
        activeContext.md
        progress.md
        modules/
          {module-name}/
            context.md
  
  modules/
    {module-name}/
      config.yml
      boundaries.md
      dependencies.md

3. Quick Start Templates

Create shortcuts for common contexts:

/quickstart/john-payments.md:

Project: main-app
Developer: john
Team: payments  
Module: payment-gateway

Then developers can start with:

"Initialize session with @/quickstart/john-payments.md"

4. Enhanced Conversation Flow

Here's how sessions would work:

AI: "Welcome to CursorRIPER! I need your session context to proceed safely.
Please provide:
- Project name
- Developer name
- Team name
- Module name"

Developer: "Project: ecommerce
Developer: alice
Team: checkout
Module: cart-service"

AI: "Session initialized! ✅
- Working as: alice
- Team: checkout
- Module: cart-service
- Personal memory: /memory-bank/developers/alice/
- Team context: /memory-bank/teams/checkout/

What would you like to work on in the cart-service module?"

5. Context Persistence Within Session

The AI maintains this context throughout:

# Later in conversation
Developer: "Update my context with the new cart logic"

AI: "Updating alice's context for cart-service module in:
/memory-bank/developers/alice/modules/cart-service/context.md

[Shows the update]

This change is isolated to your personal cart-service context."

6. Safety Mechanisms

# Additional .cursor/rules entries
context_safety:
  cross_boundary_prevention:
    - "If operation affects files outside SESSION_MODULE, require explicit confirmation"
    - "If accessing team files, show: 'Accessing ${SESSION_TEAM} team files'"
    - "Block access to other teams/developers even if explicitly requested"
  
  session_confusion_handling:
    - "If context unclear, re-request: 'Please confirm your session context'"
    - "Show current context before any destructive operation"
    - "Require re-initialization if session seems corrupted"

module_boundaries:
  enforcement:
    - "Module: ${SESSION_MODULE} can only import from allowed dependencies"
    - "Prevent modifications to other modules without explicit module switch"
    - "Warn when referencing code outside current module"

7. Module Switching Within Session (not recommended)

If needed to switch modules:

Developer: "I need to switch to the auth-service module"

AI: "Module switch requested. Please confirm:
Current: cart-service
Target: auth-service
Team: checkout (unchanged)

This will:
- Save the current cart-service context
- Load auth-service context
- Update allowed paths

Proceed? (yes/no)"

8. Session Summary on Exit

At the end of each session:

AI: "Session summary for alice (checkout team):
- Worked on: cart-service module  
- Files modified:
  - /memory-bank/developers/alice/activeContext.md
  - /memory-bank/teams/checkout/modules/cart-service/progress.md
- Key decisions: [listed]

Would you like me to update the team progress before ending?"

This standardized initialization ensures:

1. Clear context boundaries
2. No accidental cross-contamination
3. Module-level isolation
4. Team collaboration without conflicts
5. Personal work protection

Issues: Typos on the initialization creating additional memory-bank/ files

[uriklar]

Thank you so much for your deep dive into this issue 🙏
As we get more into Cursor and RIPER i'll definitely look into these ideas and report back if I have anything good to share.

[johnpeterman72]

Have you tried the CursorRIPER.Sigma version?