After starting a new project, the AI automatically switched to execution mode.

[aokihu]

Describe the bug

When I start a new project and provide information about the project, the AI uncontrollably begins to execute tasks such as creating directories, files, and defining functions — even though I have not switched to any specified working mode.

Desktop:

• OS: macOS 15.5
• Cursor
• AI Mode: Claude-4-sonnet

Additional context

I personally suspect that the memory rules are not strict enough. The AI appears to be able to modify the current working mode within memory, thereby bypassing human intervention and overriding the intended workflow protocol.

[johnpeterman72]

I have not gone back to try it with Claude 4. The original prompt was designed to implement guardrails on 3.7. I'll do some testing with C4. Side note, I have only been using the CursorRIPER.Sigma versions, as it has less overhead.

[johnpeterman72]

A, have you tried the CursorRIPER.Sigma version?

[vhbui02]

@johnpeterman72 In GitHub Copilot, many times the memory bank file is not updated, I've to specified them manually. Do you have this issue in Cursor?

[johnpeterman72]

Thank you for the question.

First: You might try out the cursorRiper.Sigma Version. This is the most up-to-date version and has a significantly smaller token footprint. For CoPilot, I would suggest version 1.0.04 and leave out the MCP server part.

The CursorRiper.Sigma-lite Version has the memory bank feature and is even a smaller footprint. This is the version I use the most

To help diagnose your specific issue, I need to gather some key information:

1. CursorRIPER Version

• Which version of CursorRIPER are you currently using? (You can check this in your .claude/project-state.md file)
• When did you install or last update the framework?

2. AI Model Configuration

• Which AI model are you using? (I don't use CoPilot)
• Are you using the default built-in AI features or a custom model configuration?

3. Exact Prompt Structure

• What exact prompts are you using when you expect the memory bank to update?
• Are you explicitly using the RIPER modes (/Research, /Innovate, /Plan, /Execute, /Review)?
• Do your prompts include memory bank update commands like Update memory bank with: [content]?

4. Specific Failure Scenarios

• Can you provide an example of when the memory bank should have been updated but wasn't?
• Are you seeing any error messages, or is it failing silently?
• Does the memory bank ever update automatically, or does it always require manual specification?

5. File Locations

• Are your memory bank files in the correct location (./memory-bank/)?

This information will help me determine if this is a configuration issue, a version-specific bug, or if there's a difference in how (Cursor) Claude 3.7 - 4.0 handles file updates compared to GitHub Copilot.

[vhbui02]

1. Ah sorry, I'm actually using CursorRIPER.sigma right now, the latest version (v1.0.5). I just updated it yesterday.
2. I'm using Claude 4 from GitHub Copilot. I'm using the custom chat mode feature: I created a Markdown file called riper5.chatmode.md and paste the v1.0.5 rule file into it. I had to make some changes to the Context Reference System:

...

Γ = [FILES, FOLDERS, CODE, DOCS, RULES, GIT, NOTEPADS]

Γ_symbols = {
  Γ₁: 📄 #file: ,
  Γ₂: 📁 #file: ,
  Γ₃: 💻 #codebase,
  Γ₄: 📚 #fetch use context7,
  Γ₅: 📏 #file: .github/instructions ,
  Γ₆: 🔄 #githubRepo,
  Γ₇: 📝 #file: .memory-bank/,
}

...

3. • Exact prompts? Here is my RIPER-5 Workflow when implementing the Pagination feature for Decap CMS.

/research

Change current file context to Collection.js
Analyze packages/decap-cms-core/src directory inside decap-cms-core repo, especially the logic flow, state management, etc. of all of the components inside packages/decap-cms-core/src/components/Collection directory.

!ckp
!sp Research
!vm read_files
!ad packages/decap-cms-core/src
!ad packages/decap-cms-core/src/components/Collection
!af packages/decap-cms-core/src/components/Collection/Collection.js

=> Only activeContext.md is updated.

---

/research

Change current file context to Collection.js
Analyze packages/decap-cms-core/src directory inside decap-cms-core repo, especially the logic flow, state management, etc. of all of the components inside packages/decap-cms-core/src/components/Collection directory.

!ckp
!sp Research
!vm read_files
!ad packages/decap-cms-core/src
!ad packages/decap-cms-core/src/components/Collection
!af packages/decap-cms-core/src/components/Collection/Collection.js

---

=> Only activeContext.md is updated.

/research

Analyze all of the components that are imported in Collection.js

!af packages/decap-cms-core/src/components/Collection/Collection.js

=> Nothing is updated. Not even activeContext.md

---

/innovate

Look at the implementation of packages/decap-cms-core/src/components/Collection/CollectionControls.js, I can see there are some control components for 3 features: group, filter and sort. Analyze the logic flow of the components of all three components to use them as reference for the implementation of a new feature whose UI will be placed in the same CollectionControls.js file: pagination.

!ac PaginationControl
!af packages/decap-cms-core/src/components/Collection/CollectionControls.js
!af packages/decap-cms-core/src/components/Collection/FilterControl.js
!af packages/decap-cms-core/src/components/Collection/GroupControl.js
!af packages/decap-cms-core/src/components/Collection/SortControl.js
!af packages/decap-cms-core/src/components/Collection/ViewStyleControl.js

=> Only activeContext.md is updated.

---

/plan

Ditch the cursor actions append_next for infinite scroll and the Waypoint components.
Create a detail implementation plan for the new pagination feature: Set the number of entries per page to 8 when they get rendered in EntryListing.js. Remember to not put everything inside a single file, leverage the current files inside reducers and actions directories.
!ckp
!pm write_code
!sp Plan
!vm write_code
!af packages/decap-cms-core/src/components/Collection/Entries/EntryListing.js
!af packages/decap-cms-core/src/components/Collection/*Control.js
!ad packages/decap-cms-core/src/reducers
!ad packages/decap-cms-core/src/actions
!an progress.md

=> Nothing is updated. Not even activeContext.md

---

/plan

Add the necessary types from page-based pagination feature into redux.ts.
Make sure the page-based pagination UI is placed left-most, in the same line as Filter, Group, Sort elements. And the UI only contains 3 elements: 2 buttons, left and right and a pagination info. Ditch the page number.
Write the final implementation plan inside the progress.md file inside Memory Bank.

!af packages/decap-cms-core/src/types/redux.ts
!af progress.md

=> Only progress.md is updated.

---

/execute

Execute phase 1-5 of the Pagination feature implementation plan.

!af progress.md

=> Only progress.md is updated.

---

/review

The current total number of entries is not correct. It only shows 10 entries when in fact there are 23 entries inside the collection. I suggest you check the current behavior of passing totalEntries into PaginationControl component from paginationInfo which is passed from CollectionControl.js, then from Collection.js
Also change the previous and next button which are currently using Icon component Chevron type to unicode character: ← for previous button and → for next button.
Remember to update activeContext.md and progress.md

!af packages/decap-cms-core/src/components/Collection/Collection.js
!af packages/decap-cms-core/src/components/Collection/CollectionControl.js
!af packages/decap-cms-core/src/components/Collection/PaginationControl.js
!ac PaginationControl
!ac totalEntries
!ac PageInfo
!ac paginationInfo

=> Only progress.md is updated.

---

/review

The bug still happens. Get the total count from the current page data doesn't seem to be working, I want you to implement Option 1: get the total count from the backend response.

!af packages/decap-cms-core/src/actions/entries.ts
!ac entries()

=> Only progress.md is updated.

---

/review

No, no, no, using the backend pagination is correct. Don't try to fetch all of the entries then paginate them like the frontend pagination would do since it will be a massive overload if there are thousands of entries. It's my mistake to not explain clearly about the 10 entries/request.
There isn't such a behavior of fetching 10 entries/page right now. This is the current behavior: the first page load, the backend pagination fetch 10 entries. 8 entries are rendered inside the first page. Now user go into the second page, the backend pagination didn't fetch new entries, and the only remaining 2 entries are rendered inside the second page. When users go inside third page, fourth page, the page is blank.

I want you to look into the current backend pagination fetching logic, fix it so it fetch 8 entries when user go into the first page, fetch the next 8 entries when user go into the second page and so on.

!af packages/decap-cms-core/src/reducers/entries.ts
!af packages/decap-cms-core/src/actions/entries.ts
!af packages/decap-cms-core/src/backend.ts

=> Only progress.md is updated.

---

• Yes I'm explicitly writing the full RIPER mode (i don't use the abbrv) into my prompt /research, /innovate.
• And no, I didn't include memory bank update commands like you said. I thought it has to be automatic.

• Example? Yea later when I dive into the chat history.
• Error message? no.
• Update automatically? Automatically, the activeContext always update, sometimes the progress.md update, the rest are stayed the same through out the full RIPER workflow. Of course, if explicit specification is written manually, memory bank files are always updated.

• I change the memory bank files slightly different by adding a dot, i.e. .memory-bank

[vhbui02]

P/s: RIPER-5 Sigma is incredible. I think I will finish implementing the Pagination feature of Decap CMS that was issued 5 years ago decaporg/decap-cms#3714

[johnpeterman72]

Follow-up question: Were you using version 1.0.4 prior, and did it have the same issues?

[vhbui02]

I didn't use version 1.0.4 very much, may be once or twice. All of them stop at /innovate mode (since RIPER-5 is actually very time-consuming, one must be patience enough to use it all the way @@)

[johnpeterman72]

As you know, it was originally developed to work within Cursor. Some of the underlying functions are based on the Cursor back end. I know this might be a pain, but could you give the Sigma-Lite version a test? It has most of the "Cursor" functions stripped out.

[vhbui02]

As you know, it was originally developed to work within Cursor. Some of the underlying functions are based on the Cursor back end. I know this might be a pain, but could you give the Sigma-Lite version a test? It has most of the "Cursor" functions stripped out.

Yeah I was about to do it as well.

[vhbui02]

It's better. But it creates new memory file sometimes instead of write into the current memory files.

[johnpeterman72]

I have made a new version. Riper.Sigma.Copilot Give it a try and let me know if it works better in the Copilot environment.

[vhbui02]

That was fast :o thank you I will surely to test it. My first impression is that it's a little more verbose.