Shaz M

Quick question for the experienced folks here. I'm brand new to claude code and GSD, used cursor and n8n a bunch 12 months ago, built a little business and then shut it down. I'm using GSD workflow and built a post-planning hook that verifies implementation patterns in my plans against Context7 documentation before execution. What it does: After /gsd:plan-phase completes, it extracts patterns from the PLAN.md files (install commands, config setups, import statements, API usage) and checks each one against current Context7 docs. Example check: - Plan says: ConvexProvider wraps BrowserRouter - Context7 query: "Is this still the correct provider hierarchy?" - Result: ✅ Current or ⚠️ Pattern changed Why I built it: I'm new to this and paranoid about executing plans with outdated patterns. The planner agent might be using stale knowledge, and I'd rather catch API changes before running code. My concern: Am I creating unnecessary overhead? Is this actually useful, or am I solving a problem that doesn't exist? More experienced users - do you verify plans before execution, or do you just trust the planner and fix issues as they come up?

New comment 1d ago

Shaz M

1 like • 14d

Sure, actually I created a meta system on top of this for GSD, which automates my skills at specific points in GSD workflows. Here is the skill : --- name: planning-qa description: Verify implementation patterns in GSD plans against current Context7 documentation --- # Planning Quality Assurance Verify that implementation patterns in PLAN.md files match current best practices from Context7 documentation. ## What It Does After GSD planning completes, this skill: 1. **Reads PLAN.md files** for the specified phase 2. **Extracts implementation patterns**: - Installation commands (`npm install ...`) - Configuration patterns (vite.config, tsconfig, etc.) - Import statements and provider setup - Code examples (schema definitions, hooks, etc.) - API usage patterns 3. **Queries Context7** for each pattern's current documentation 4. **Reports discrepancies** between plans and current best practices ## Why This Matters - ✅ Research might be current, but plans could use outdated patterns - ✅ Catches API changes the planner didn't know about - ✅ Verifies specific code examples, not just library versions - ✅ Prevents executing plans with deprecated patterns --- ## ⚠️ CRITICAL: No Deviation Allowed **This skill ONLY succeeds by querying Context7 for patterns.** If you do not follow this workflow exactly, you will fail the skill. ### ❌ DO NOT: - Read and analyze plan files yourself - Give your own opinions about phase scope, risks, or "understanding" - Present "assumptions" or phase analysis - Summarize what the plans say or what you think they mean - Skip to execution without verifying patterns ### ✅ DO ONLY THIS: - Extract implementation patterns from PLAN.md files - Query Context7 for EACH pattern (one at a time) - Report Context7 findings ONLY (no your own analysis) - If Context7 can't verify a pattern, mark as "⊘ Unknown" - Follow the workflow checkpoints - stop and verify after each step ## Usage

Shaz M

1 like • 14d

Here is link to my wrapper system : https://www.skool.com/gsd/built-a-skill-to-stop-gsd-updates-from-wiping-my-custom-scripts-is-there-a-better-way?p=e26d3077

Shaz M

22d •

General discussion

Built a skill to stop GSD updates from wiping my custom scripts — is there a better way?

I'm working on my first project with Claude Code and GSD. I needed a script to auto-archive a file during /gsd:complete-milestone. I put it in ~/.claude/get-shit-done/bin/, modified the workflow to call it, and it worked perfectly. Then I ran /gsd:update. Script gone. Workflow modification gone. I moved the script to ~/.claude/skills/ (safe from updates) and used /gsd:reapply-patches for the workflow change. That fixed it, but I realized I'd probably make the same mistake again next time I wanted to automate something. So I built /gsd-wrapper, a skill that handles this pattern: What it does: - Keeps a manifest (~/.claude/gsd-wrappers/manifest.json) tracking what custom automation runs, when, and against which workflow - Places scripts in a safe directory that GSD updates don't touch - Patches workflows with a generic block that reads the manifest at runtime — so adding new wrappers never requires new patches - Skill-based wrappers (ones that need Claude's reasoning) run as Task agents so they can't derail the parent workflow if they fail Commands: /gsd-wrapper create — walks through creating a new wrapper /gsd-wrapper list — shows what's registered /gsd-wrapper remove — cleans up manifest, scripts, and dead patches /gsd-wrapper reapply — restores patches after GSD updates What I learned: - Claude will put files wherever makes sense to it. I had to add explicit rules to CLAUDE.md saying "never put custom files in get-shit-done/" or it happens again. - Hooks (~/.claude/hooks/) and wrappers are different things. Mixing up the terminology caused confusion during development. - One generic patch per lifecycle point beats one patch per wrapper. The manifest handles the rest. I've tested create, list, and remove. It's working for my use case but I'm new to all of this. Questions for the community: 1. Is there a built-in GSD mechanism for this that I missed? 2. Does the manifest approach make sense, or is there a simpler pattern? 3. Anyone else running into the same update-wipes-my-stuff problem?

Stephan Ralescu

29d •

General discussion

Claude Code Memory

Anyone try this yet? https://docs.claude-mem.ai/introduction Seems like it could further reduce context. Had a context surge recently. Memory would solve the core problem and not require further engineering of the state.md files.

New comment 28d ago

Shaz M

0 likes • 28d

Bump. Im also curious if this will be useful.