GRD — Get eR Done

Meta-prompting, context engineering, and spec-driven development for Claude Code, OpenCode, and Gemini CLI — enhanced with persistent Agent Teams for coordinated multi-agent orchestration.

Solves context rot — the quality degradation that happens as Claude fills its context window.

npx get-er-done-cc@latest

Works on Mac, Windows, and Linux.

"If you know clearly what you want, this WILL build it for you. No bs."

"I've done SpecKit, OpenSpec and Taskmaster — this has produced the best results for me."

"By far the most powerful addition to my Claude Code. Nothing over-engineered. Literally just gets er done."

Trusted by engineers at Amazon, Google, Shopify, and Webflow.

About GRD · How It Works · Commands · Why It Works · Migrating from GSD

About GRD

GRD (Get eR Done) is built on GSD (Get Shit Done), the spec-driven development system created by TÂCHES. GSD established the core philosophy: the complexity belongs in the system, not in your workflow. Behind the scenes, context engineering, XML prompt formatting, subagent orchestration, and state management. What you see: a few commands that just work.

GRD takes that foundation and adds persistent Agent Teams — named agents that join teams, share task boards, communicate directly with each other, and shut down cleanly. Where GSD agents were fire-and-forget (spawn, execute, vanish), GRD agents are coordinated teammates with identity, shared state, and a full lifecycle.

What GRD adds beyond GSD

| Capability | GSD | GRD | |-----------|-----|-----| | Agent model | Fire-and-forget | Persistent teams with named agents | | Coordination | Orchestrator polls sequentially | SendMessage for direct agent-to-agent communication | | Task tracking | Implicit (in orchestrator memory) | TaskCreate / TaskList — shared board survives context resets | | Dependencies | Hardcoded wave ordering | Declarative blockedBy / blocks — agents auto-wait | | Observability | Final output only | Named agents + live task board | | Failure recovery | Re-spawn from scratch | Re-message idle agents with new instructions | | State management | Regex-based markdown parsing | Streamlined grd-tools.js commands — deterministic with test coverage, trimmed to remove overlap with Claude Code's auto-memory | | Plan verification | 6 dimensions | 7 dimensions (adds Context Compliance for user decisions) | | Executor safety | No self-check | Self-check verifies files exist and commits match claims | | Branding | Not suitable for all workplaces | Professional and workplace-friendly |

Credit: The core workflow, context engineering approach, XML prompt formatting, and multi-agent architecture are all from GSD by TÂCHES. GRD builds on that work with Agent Teams integration, quality gates, and deterministic tooling. GSD is an outstanding system — GRD makes it better.

What's New in This Version

GRD now leverages Claude Code's native capabilities instead of reimplementing them. The result: less token overhead, less maintenance, simpler workflows — same power.

| Change | What happened | Why it's better | |--------|---------------|-----------------| | Model configuration | Removed /grd:set-profile and the profile system. Each agent's .md file uses the native model: frontmatter field directly. | One less command. Claude Code reads model: natively — no translation layer needed. | | Todo management | Removed /grd:add-todo and /grd:check-todos. GRD workflows now use native TodoRead/TodoWrite to track deferred work automatically. | Claude Code's built-in tools replace custom commands. The executor captures deferred items; pause, resume, progress, and transition workflows surface them. | | State commands pruned | Removed state add-decision, state add-blocker, state resolve-blocker, state record-session from grd-tools.js. | Claude Code's auto-memory tracks decisions, blockers, and session context natively. The remaining state commands (advance-plan, update-progress, record-metric) handle what auto-memory doesn't. | | Pause/resume simplified | /grd:pause-work saves position to STATE.md and surfaces pending deferred items. /grd:resume-work reads position and displays pending items alongside status. Removed the .continue-here.md handoff template. | Auto-memory preserves full context across sessions. Deferred items surface automatically via native TodoRead. | | STATE.md slimmed | Template reduced from ~100 to ~40 lines. Removed Accumulated Context (Decisions, Blockers) and Pending Todos sections. | Those sections duplicated what auto-memory already tracks. STATE.md now focuses on project position and performance metrics. | | Deferred work tracking | GRD workflows now use native TodoRead/TodoWrite to track deferred decisions, discovered improvements, and cross-phase items. Surfaces automatically in pause, resume, progress, and transition workflows. | Zero-config tracking that survives context window boundaries. The executor captures deferred items; other workflows surface them at the right moments. |

Migrating from a previous version? No action needed for most changes — auto-memory and native todos activate automatically. For model configuration, edit the model: field in agent files under agents/ instead of using the removed /grd:set-profile command.

Vibecoding has a bad reputation. You describe what you want, AI generates code, and you get inconsistent garbage that falls apart at scale.

GRD fixes that. It's the context engineering layer that makes Claude Code reliable. Describe your idea, let the system extract everything it needs to know, and let Claude Code get to work.

Who This Is For

People who want to describe what they want and have it built correctly — without pretending they're running a 50-person engineering org.

Getting Started

npx get-er-done-cc@latest

The installer prompts you to choose:

1. Runtime — Claude Code, OpenCode, Gemini, or all
2. Location — Global (all projects) or local (current project only)

Verify with /grd:help inside your chosen runtime.

Staying Updated

GRD evolves fast. Update periodically:

npx get-er-done-cc@latest

# Claude Code
npx get-er-done-cc --claude --global   # Install to ~/.claude/
npx get-er-done-cc --claude --local    # Install to ./.claude/

# OpenCode (open source, free models)
npx get-er-done-cc --opencode --global # Install to ~/.config/opencode/

# Gemini CLI
npx get-er-done-cc --gemini --global   # Install to ~/.gemini/

# All runtimes
npx get-er-done-cc --all --global      # Install to all directories

Use --global (-g) or --local (-l) to skip the location prompt. Use --claude, --opencode, --gemini, or --all to skip the runtime prompt.

Clone the repository and run the installer locally:

git clone https://github.com/glittercowboy/get-er-done.git
cd get-er-done
node bin/install.js --claude --local

Installs to ./.claude/ for testing modifications before contributing.

Recommended: Skip Permissions Mode

GRD is designed for frictionless automation. Run Claude Code with:

claude --dangerously-skip-permissions

[!TIP] This is how GRD is intended to be used — stopping to approve date and git commit 50 times defeats the purpose.

If you prefer not to use that flag, add this to your project's .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(date:*)",
      "Bash(echo:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(wc:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(sort:*)",
      "Bash(grep:*)",
      "Bash(tr:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git tag:*)"
    ]
  }
}

How It Works

Already have code? Run /grd:map-codebase first. It spawns parallel agents to analyze your stack, architecture, conventions, and concerns. Then /grd:new-project knows your codebase — questions focus on what you're adding, and planning automatically loads your patterns.

1. Initialize Project

/grd:new-project

One command, one flow. The system:

1. Questions — Asks until it understands your idea completely (goals, constraints, tech preferences, edge cases)
2. Research — Spawns parallel agents to investigate the domain (optional but recommended)
3. Requirements — Extracts what's v1, v2, and out of scope
4. Roadmap — Creates phases mapped to requirements

You approve the roadmap. Now you're ready to build.

Creates: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, .planning/research/

2. Discuss Phase

/grd:discuss-phase 1

This is where you shape the implementation.

Your roadmap has a sentence or two per phase. That's not enough context to build something the way you imagine it. This step captures your preferences before anything gets researched or planned.

The system analyzes the phase and identifies gray areas based on what's being built:

• Visual features → Layout, density, interactions, empty states
• APIs/CLIs → Response format, flags, error handling, verbosity
• Content systems → Structure, tone, depth, flow
• Organization tasks → Grouping criteria, naming, duplicates, exceptions

For each area you select, it asks until you're satisfied. The output — CONTEXT.md — feeds directly into the next two steps:

1. Researcher reads it — Knows what patterns to investigate ("user wants card layout" → research card component libraries)
2. Planner reads it — Knows what decisions are locked ("infinite scroll decided" → plan includes scroll handling)

The deeper you go here, the more the system builds what you actually want. Skip it and you get reasonable defaults. Use it and you get your vision.

Creates: {phase}-CONTEXT.md

3. Plan Phase

/grd:plan-phase 1

The system:

1. Researches — Investigates how to implement this phase, guided by your CONTEXT.md decisions
2. Plans — Creates 2-3 atomic task plans with XML structure
3. Verifies — Checks plans against requirements, loops until they pass

Each plan is small enough to execute in a fresh context window. No degradation, no "I'll be more concise now."

Creates: {phase}-RESEARCH.md, {phase}-{N}-PLAN.md

4. Execute Phase

/grd:execute-phase 1

The system:

1. Runs plans in waves — Parallel where possible, sequential when dependent
2. Fresh context per plan — 200k tokens purely for implementation, zero accumulated garbage
3. Commits per task — Every task gets its own atomic commit
4. Verifies against goals — Checks the codebase delivers what the phase promised

Walk away, come back to completed work with clean git history.

Creates: {phase}-{N}-SUMMARY.md, {phase}-VERIFICATION.md

5. Verify Work

/grd:verify-work 1

This is where you confirm it actually works.

Automated verification checks that code exists and tests pass. But does the feature work the way you expected? This is your chance to use it.

The system:

1. Extracts testable deliverables — What you should be able to do now
2. Walks you through one at a time — "Can you log in with email?" Yes/no, or describe what's wrong
3. Diagnoses failures automatically — Spawns debug agents to find root causes
4. Creates verified fix plans — Ready for immediate re-execution

If everything passes, you move on. If something's broken, you don't manually debug — you just run /grd:execute-phase again with the fix plans it created.

Creates: {phase}-UAT.md, fix plans if issues found

6. Repeat → Complete → Next Milestone

/grd:discuss-phase 2
/grd:plan-phase 2
/grd:execute-phase 2
/grd:verify-work 2
...
/grd:complete-milestone
/grd:new-milestone

Loop discuss → plan → execute → verify until milestone complete.

Each phase gets your input (discuss), proper research (plan), clean execution (execute), and human verification (verify). Context stays fresh. Quality stays high.

When all phases are done, /grd:complete-milestone archives the milestone and tags the release.

Then /grd:new-milestone starts the next version — same flow as new-project but for your existing codebase. You describe what you want to build next, the system researches the domain, you scope requirements, and it creates a fresh roadmap. Each milestone is a clean cycle: define → build → ship.

Quick Mode

/grd:quick

For ad-hoc tasks that don't need full planning.

Quick mode gives you GRD guarantees (atomic commits, state tracking) with a faster path:

• Same agents — Planner + executor, same quality
• Skips optional steps — No research, no plan checker, no verifier
• Separate tracking — Lives in .planning/quick/, not phases

Use for: bug fixes, small features, config changes, one-off tasks.

/grd:quick
> What do you want to do? "Add dark mode toggle to settings"

Creates: .planning/quick/001-add-dark-mode-toggle/PLAN.md, SUMMARY.md

Why It Works

Context Engineering

Claude Code is incredibly powerful if you give it the context it needs. Most people don't.

GRD handles it for you:

| File | What it does | |------|--------------| | PROJECT.md | Project vision, always loaded | | research/ | Ecosystem knowledge (stack, features, architecture, pitfalls) | | REQUIREMENTS.md | Scoped v1/v2 requirements with phase traceability | | ROADMAP.md | Where you're going, what's done | | STATE.md | ~40-line file tracking current position, performance metrics, and session timestamp | | PLAN.md | Atomic task with XML structure, verification steps | | SUMMARY.md | What happened, what changed, committed to history |

Size limits based on where Claude's quality degrades. Stay under, get consistent excellence.

XML Prompt Formatting

Every plan is structured XML optimized for Claude:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Precise instructions. No guessing. Verification built in.

Multi-Agent Orchestration

Every stage uses the same pattern: a thin orchestrator spawns specialized agents, collects results, and routes to the next step.

| Stage | Orchestrator does | Agents do | |-------|------------------|-----------| | Research | Coordinates, presents findings | 4 parallel researchers investigate stack, features, architecture, pitfalls | | Planning | Validates, manages iteration | Planner creates plans, checker verifies, loop until pass | | Execution | Groups into waves, tracks progress | Executors implement in parallel, each with fresh 200k context | | Verification | Presents results, routes next | Verifier checks codebase against goals, debuggers diagnose failures |

The orchestrator never does heavy lifting. It spawns agents, waits, integrates results.

The result: You can run an entire phase — deep research, multiple plans created and verified, thousands of lines of code written across parallel executors, automated verification against goals — and your main context window stays at 30-40%. The work happens in fresh subagent contexts. Your session stays fast and responsive.

Agent Teams

GRD enhances four core workflows with Claude Code Agent Teams:

| Team | Workflow | Agents | |------|----------|--------| | Execution Team | execute-phase | executor-01, executor-02, ..., grd-verifier | | Research Team | new-project | stack-researcher, features-researcher, architecture-researcher, pitfalls-researcher, synthesizer | | Planning Pipeline | plan-phase | phase-researcher, planner, plan-checker | | Mapping Team | map-codebase | tech-mapper, arch-mapper, quality-mapper, concerns-mapper |

Every team follows the same lifecycle: TeamCreate → TaskCreate (define work) → Spawn (launch teammates) → SendMessage (coordinate) → TaskUpdate (track progress) → TeamDelete (clean up).

Team Briefing — Before agents launch, the orchestrator displays a composition table so you know exactly what's being assembled:

◆ Assembling team: grd-project-research — 4 agents

| # | Role                    | Produces                              | Focus                                         |
|---|-------------------------|---------------------------------------|-----------------------------------------------|
| 1 | Stack Researcher        | .planning/research/STACK.md           | Languages, frameworks, dependencies, versions |
| 2 | Feature Researcher      | .planning/research/FEATURES.md        | Table stakes vs differentiators, complexity   |
| 3 | Architecture Researcher | .planning/research/ARCHITECTURE.md    | Component boundaries, data flow, build order  |
| 4 | Pitfalls Researcher     | .planning/research/PITFALLS.md        | Common mistakes, warning signs, prevention    |

Spawning 4 agents in parallel...

For single-agent stages (research, planning, verification), a lighter inline format is used:

◆ Spawning researcher — produces 01-RESEARCH.md
  Focus: How to implement Phase 1: Core Authentication

Key benefits:

• Transparent composition — see every agent's role, output, and focus before work begins
• Persistent teams — agents stay warm between waves, no re-spawn overhead
• Shared task board — TaskList() shows who's doing what, in real-time
• Direct communication — agents message each other, not just through the orchestrator
• Declarative dependencies — blockedBy replaces hardcoded wave sequencing
• Clean lifecycle — every team gets graceful shutdown and cleanup, no orphaned agents

Quality Engineering

GRD introduces quality gates at every stage that reduce cascading errors across multi-phase projects:

• Context Compliance — Plan-checker has a 7th verification dimension that checks plans honor user decisions from CONTEXT.md before execution begins
• Deterministic state — Agents use grd-tools.js state commands (advance-plan, update-progress, record-metric) for atomic, test-covered writes — complementing Claude Code's auto-memory for decisions/blockers and native TodoRead/TodoWrite for deferred work tracking
• Executor self-check — After writing SUMMARY.md, the executor verifies each claimed file exists on disk and each commit hash exists in git log before proceeding
• Condensed prompts — Agent instructions are ~48% smaller, leaving more of the context window for actual work
• Structured history — grd-tools.js history-digest compiles summaries into scored JSON for better-informed planning
• Safer git operations — Stages specific files individually (never git add -A), preventing accidental commits of unrelated changes

System Architecture

GRD is organized in four layers, each with a clear responsibility:

Commands (21)     /grd:new-project, /grd:plan-phase, /grd:execute-phase, ...
    ↓
Workflows (30+)   new-project.md, plan-phase.md, execute-phase.md, ...
    ↓
Agents (11)       grd-planner, grd-executor, grd-verifier, grd-debugger, ...
    ↓
Tools (20+)       grd-tools.js — state, commit, validate, history-digest, ...

Commands are thin entry points. Workflows orchestrate. Agents do the heavy lifting in fresh context windows. Tools handle atomic operations deterministically.

Atomic Git Commits

Each task gets its own commit immediately after completion:

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

[!NOTE] Benefits: Git bisect finds exact failing task. Each task independently revertable. Clear history for Claude in future sessions. Better observability in AI-automated workflow.

Every commit is surgical, traceable, and meaningful.

Modular by Design

• Add phases to current milestone
• Insert urgent work between phases
• Complete milestones and start fresh
• Adjust plans without rebuilding everything

You're never locked in. The system adapts.

Commands

Core Workflow

| Command | What it does | |---------|--------------| | /grd:new-project [--auto] | Full initialization: questions → research → requirements → roadmap | | /grd:discuss-phase [N] | Capture implementation decisions before planning | | /grd:plan-phase [N] | Research + plan + verify for a phase | | /grd:execute-phase <N> | Execute all plans in parallel waves, verify when complete | | /grd:verify-work [N] | Manual user acceptance testing ¹ | | /grd:audit-milestone | Verify milestone achieved its definition of done | | /grd:complete-milestone | Archive milestone, tag release | | /grd:new-milestone [name] | Start next version: questions → research → requirements → roadmap |

Navigation

| Command | What it does | |---------|--------------| | /grd:progress | Where am I? What's next? | | /grd:help | Show all commands and usage guide | | /grd:update | Update GRD with changelog preview | | /grd:join-discord | Join the GRD Discord community |

Phase Management

| Command | What it does | |---------|--------------| | /grd:add-phase | Append phase to roadmap | | /grd:insert-phase [N] | Insert urgent work between phases | | /grd:remove-phase [N] | Remove future phase, renumber | | /grd:list-phase-assumptions [N] | See Claude's intended approach before planning | | /grd:plan-milestone-gaps | Create phases to close gaps from audit |

Session

| Command | What it does | |---------|--------------| | /grd:pause-work | Save position when stopping mid-phase | | /grd:resume-work | Show project position and suggest next steps |

Utilities

| Command | What it does | |---------|--------------| | /grd:settings | Configure workflow agents and execution settings | | /grd:debug [desc] | Systematic debugging with persistent state | | /grd:quick | Execute ad-hoc task with GRD guarantees | | /grd:research-phase [N] | Standalone phase research (usually use plan-phase instead) | | /grd:map-codebase | Analyze existing codebase before new-project |

¹ Contributed by reddit user OracleGreyBeard

Configuration

GRD stores project settings in .planning/config.json. Configure during /grd:new-project or update later with /grd:settings.

Core Settings

| Setting | Options | Default | What it controls | |---------|---------|---------|------------------| | mode | yolo, interactive | interactive | Auto-approve vs confirm at each step | | depth | quick, standard, comprehensive | standard | Planning thoroughness (phases × plans) |

Model Assignment

Each agent specifies its Claude model via the native model: frontmatter field in its agent .md file under agents/. The defaults balance quality against token spend:

| Role | Model | Agent files | |------|-------|-------------| | Planning | claude-opus-4-5 | grd-planner.md | | Execution & verification | claude-sonnet-4-5 | grd-executor.md, grd-verifier.md, and most others | | Codebase mapping | claude-haiku-4-5 | grd-codebase-mapper.md |

To change an agent's model, edit the model: field directly in its file. No command needed — Claude Code reads the frontmatter natively.

Workflow Agents

These spawn additional agents during planning/execution. They improve quality but add tokens and time.

| Setting | Default | What it does | |---------|---------|--------------| | workflow.research | true | Researches domain before planning each phase | | workflow.plan_check | true | Verifies plans achieve phase goals before execution | | workflow.verifier | true | Confirms must-haves were delivered after execution |

Use /grd:settings to toggle these, or override per-invocation:

• /grd:plan-phase --skip-research
• /grd:plan-phase --skip-verify

Execution

| Setting | Default | What it controls | |---------|---------|------------------| | parallelization.enabled | true | Run independent plans simultaneously | | planning.commit_docs | true | Track .planning/ in git |

Git Branching

Control how GRD handles branches during execution.

| Setting | Options | Default | What it does | |---------|---------|---------|--------------| | git.branching_strategy | none, phase, milestone | none | Branch creation strategy | | git.phase_branch_template | string | grd/phase-{phase}-{slug} | Template for phase branches | | git.milestone_branch_template | string | grd/{milestone}-{slug} | Template for milestone branches |

Strategies:

• none — Commits to current branch (default GRD behavior)
• phase — Creates a branch per phase, merges at phase completion
• milestone — Creates one branch for entire milestone, merges at completion

At milestone completion, GRD offers squash merge (recommended) or merge with history.

Security

Protecting Sensitive Files

GRD's codebase mapping and analysis commands read files to understand your project. Protect files containing secrets by adding them to Claude Code's deny list:

1. Open Claude Code settings (.claude/settings.json or global)
2. Add sensitive file patterns to the deny list:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/*)",
      "Read(**/*credential*)",
      "Read(**/*.pem)",
      "Read(**/*.key)"
    ]
  }
}

This prevents Claude from reading these files entirely, regardless of what commands you run.

[!IMPORTANT] GRD includes built-in protections against committing secrets, but defense-in-depth is best practice. Deny read access to sensitive files as a first line of defense.

Migrating from GSD

Already have a project built with GSD? A migration helper updates your .planning/ files. Agent Teams enhancements activate automatically — they live in GRD's workflow layer, not in your project data.

Steps

1. Install GRD — GSD and GRD coexist (different install paths):

   npx get-er-done-cc@latest

2. Preview changes — Dry-run to see what will change without modifying anything:

   node /path/to/get-er-done/bin/migrate.js --dry-run

3. Run migration — A full backup of .planning/ is created automatically:

   node /path/to/get-er-done/bin/migrate.js

4. Verify — Run /grd:progress to see your project through GRD and pick up where you left off.

What Changes

| Category | Before | After | |----------|--------|-------| | Commands | /gsd:plan-phase | /grd:plan-phase | | Agents | gsd-planner, gsd-executor | grd-planner, grd-executor | | Paths | get-shit-done/ | get-er-done/ | | Branches | gsd/phase-* | grd/phase-* | | Branding | GSD labels | GRD labels |

Your .planning/ data files (STATE.md, ROADMAP.md, PLANs, config.json) are unchanged structurally. The migration updates references only. Agent Teams activate the moment you use /grd:execute-phase instead of /gsd:execute-phase — zero changes to your existing project files required.

Troubleshooting

Commands not found after install?

• Restart Claude Code to reload slash commands
• Verify files exist in ~/.claude/commands/grd/ (global) or ./.claude/commands/grd/ (local)

Commands not working as expected?

• Run /grd:help to verify installation
• Re-run npx get-er-done-cc to reinstall

Updating to the latest version?

npx get-er-done-cc@latest

Using Docker or containerized environments?

If file reads fail with tilde paths (~/.claude/...), set CLAUDE_CONFIG_DIR before installing:

CLAUDE_CONFIG_DIR=/home/youruser/.claude npx get-er-done-cc --global

This ensures absolute paths are used instead of ~ which may not expand correctly in containers.

Uninstalling

To remove GRD completely:

# Global installs
npx get-er-done-cc --claude --global --uninstall
npx get-er-done-cc --opencode --global --uninstall

# Local installs (current project)
npx get-er-done-cc --claude --local --uninstall
npx get-er-done-cc --opencode --local --uninstall

This removes all GRD commands, agents, hooks, and settings while preserving your other configurations.

Credits & Community

GRD is built on GSD (Get Shit Done) by TÂCHES — the original spec-driven development system for Claude Code. The core workflow, context engineering architecture, XML prompt formatting, and multi-agent orchestration are all from GSD. GRD extends that foundation with Agent Teams, quality gates, and deterministic tooling.

OpenCode and Gemini CLI are now natively supported via npx get-er-done-cc.

These community ports pioneered multi-runtime support:

| Project | Platform | Description | |---------|----------|-------------| | grd-opencode | OpenCode | Original OpenCode adaptation | | grd-gemini (archived) | Gemini CLI | Original Gemini adaptation by uberfuzzy |

Star History

License

MIT License. See LICENSE for details.

GSD laid the foundation. GRD takes it further. Claude Code does the rest.