GSD + Claude-mem = good idea ?

[elvenking]

I came across this interesting Claude Code plugin
thedotmack/claude-mem

I am curious if anybody using GSD + Claude-mem together, how, and if GSD community could benefit out of it.

[davesienkowski]

I was using GSD + Claude-mem for a good bit. Though I felt that Claude-mem was not necessarily needed since GSD was doing well.
I will say it was nice being able to see the summaries and tasks in the dashboard that Claude-mem picked up.

[spectrumsense]

I am trying to use GSD and Openspec as I feel these two are complementary. Created instruction in Claude.md to sync back and forth between these two. Still not progress enough to know if this is useful though.

[LeonVilents]

Could you elaborate on how you use both together?

[AR6420]

i have been using Claude-mem for a while now (since dec). I feel that with the release if inbuilt "memory" (slash command - "/memory"), i dont actually dont see the use of the claude-mem plugin. its only useful when i want to refer to what exactly have i done in the previous sessions, thats it. And i've realised that i have not felt the need to do so.

Also i heard news about an upcoming feature in Claude Code called "Dream" mode that works alongside the "memory", soo i think the "claude-mem" will be irrelevent in about couple of weeks from now.

[AR6420]

My stack:

1. For Complex:

Claude Code + GSD/superpowers (GSD for me* - in solo dev envs) + code-review-graph

2. For Simple:

Claude Code + hail-hydra-cc

[BenRoe]

@AR6420 code-review-graph looks promising.
Does the GSD agent detect/use it by default, or anything needed that they use code-review-graph?

[AR6420]

Yes ALL Agents are able to use it by default. Basically its helpful when crawling the repo, and it makes sure that Claude Code doesn't miss updating connected components.
Keep in mind that code-review-graph is brand new and has a few rough edges.

[trek-e]

@AR6420 — thanks for the real-world perspective. The built-in /memory command (and GSD's own .planning/ files + /gsd:resume-work) cover the session-continuity use case without an external plugin. claude-mem still has value if you want fine-grained per-session recall outside the planning files, but for GSD workflows specifically, the native memory system is the right fit. Marking this handled.

[chilleregeravi]

I have been using GSD with claude-mem by default, its awesome. More integration with prehooks would be really good. I would like to save future improvements and features to memory, so that we can pick up later. It works in a way already, but I need to ask claude to check the memory. Would be good, if we could create future milestones and just keep adding stuff in memory

[trek-e]

@chilleregeravi — a couple of GSD-native approaches that may already cover what you are describing:

For capturing future ideas and improvements: /gsd-note lets you record a note into .planning/NOTES.md during a session so it persists across context resets. For queuing future work, /gsd-plant-seed lets you log ideas as seeds in .planning/SEEDS.md — they show up in /gsd-inbox when you want to act on them.

For future milestones: /gsd-add-backlog adds items to .planning/BACKLOG.md — a lightweight way to capture "do this later" milestones without committing to scheduling them.

If what you want is deeper integration between claude-mem and GSD planning files (e.g., auto-syncing seeds or notes into an external memory store via a prehook), that is a reasonable enhancement idea. The prehook surface is already in place — hooks/gsd-prompt-guard.js and hooks/gsd-read-guard.js fire on tool calls. A memory-sync hook would be a new hook in that same pattern.

If you want that formally considered, open an Enhancement issue with: the problem, what specific prehook trigger you have in mind, and what the expected output/behavior looks like.

[chilleregeravi]

Claude Code in general seems to be in a hurry to implement stuff. So when I add a note, or plant-seed it constraints itself with the information in the files. When a note or a seed is added, in most cases it needs discussion and thought. And hence having notes in memory is much more fluffy so that ideas can be discussed from a feasability point of view rather than implementation.

The discuss option also exists, unfortunately its at the point of implementation.

[trek-e]

@chilleregeravi — that's a sharp observation. /gsd-note and /gsd-plant-seed intentionally bias toward capture, not exploration — they're one-shot writes meant to be revisited later in a dedicated session. The failure mode you describe (Claude latching onto a half-formed note and jumping to implementation) is real and is exactly what /gsd-explore and the standalone brainstorming skills are designed to solve — they hold the conversation in an ideation mode without letting the model resolve prematurely.

If you want an ideation pass over existing notes/seeds specifically — "load all parked ideas and interrogate them for feasibility before any are promoted" — that's a gap today and a reasonable enhancement. The relevant template is Enhancement with: the concrete workflow (which files it reads, what it outputs), the trigger (explicit command vs. hook), and how it plays with /gsd-review-backlog. I'd scope it tightly — "an exploration mode for parked ideas" — rather than extending /gsd-note itself.