Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.joggr.ai/llms.txt

Use this file to discover all available pages before exploring further.

Guided Generative Workflows (also called Workflows) turns a vague idea into working code through a structured pipeline: describe what you want, discuss the details, research the codebase, plan the work, execute it, and verify the results.
For small, well-scoped changes (a bug fix, a rename, adding a config option), use /gg-task instead — it runs the same discuss-research-plan-execute-verify pipeline in a single session without project scaffolding.

​
Prerequisites

Complete Setup Workflows before starting — it covers CLI install, authentication, repo initialization, and codebase doc generation.

​
1. Start a New Project

In Claude Code or Cursor, run: 
/gg-new
Describe what you want to build. Be specific — the more context you provide upfront, the better the planning and research phases will be. If you’re working from a ticket, paste the description directly into your prompt. 
I want to add a dark mode toggle to the settings page. It should persist
the user's preference in localStorage, apply a .dark class to the document
root, and respect the system preference as the default. The toggle should
be a switch component in the existing settings layout.
/gg-new echoes back your description and asks you to confirm a project slug (e.g., dark-mode-toggle). After confirmation, it scaffolds the project files under .joggr/.gg/projects/dark-mode-toggle/ and offers to checkpoint (commit) the scaffold.
You can pass a description directly to skip the prompt: /gg-new add dark mode toggle to settings page. It uses it as-is and continues to the slug confirmation step.

​
2. Discuss Requirements

/gg-discuss
/gg-discuss runs a structured interview covering five areas: goals, constraints, preferences, edge cases, and acceptance criteria. It asks 2-4 questions at a time and tracks which areas have been covered. What to expect:
  • Questions about your goals (“What does success look like?”)
  • Questions about constraints (“Does this need to work without JavaScript?”)
  • Questions about preferences (“Do you have an existing toggle component?”)
  • A coverage tracker showing which areas are complete
You can exit the discussion early by saying “move on” or “done” — it will save your progress and suggest the next step.

​
3. Research the Codebase

/gg-research
/gg-research analyzes your repository to find patterns, files, and dependencies relevant to your project. It reads your codebase docs (generated by /gg-codebase) and digs into the specific areas your project will touch. What to expect:
  • A research.md file with findings organized by architecture, dependencies, existing patterns, and risks
  • File paths and code patterns relevant to your feature
  • An offer to checkpoint the research findings

​
4. Review and Approve the Plan

/gg-plan
/gg-plan creates a phased implementation plan with task breakdowns, file targets, and acceptance criteria for each task. It presents the plan for your review before proceeding. What to expect:
  • A plan.md with phases, each containing numbered tasks
  • Each task lists the files it will create or modify
  • Acceptance criteria that define when each task is done
  • A prompt asking you to approve, request changes, or reject the plan
Read the plan carefully. This is your last chance to adjust scope before execution begins. If a task targets the wrong files or the scope is too broad, say so — it will revise the plan.

​
5. Execute the Plan

/gg-execute
/gg-execute implements the plan phase by phase. It groups non-conflicting tasks into waves and runs them in parallel, checkpointing after each wave. What to expect:
  • A wave grouping showing which tasks run together
  • Progress updates as each task completes
  • Checkpoint prompts after each wave
  • If a task fails, it asks whether to retry, skip, or abort
For large phases, it may suggest clearing the context window between waves to keep the AI focused.

​
6. Verify the Work

/gg-verify
/gg-verify checks every acceptance criterion from the plan against the actual code changes. It reports which criteria pass, which fail, and suggests next steps. What to expect:
  • A pass/fail report for each acceptance criterion
  • If everything passes, the phase is marked complete
  • If some criteria fail, it offers to fix and re-verify, accept as-is, or go back to execution
Run /gg-status at any point during the workflow to see where you are, which phases are complete, and what the next step is.

​
7. Address PR Feedback

Once your PR is open and you’ve received review feedback, run /gg-pr-fix-review to address it. 
/gg-pr-fix-review
/gg-pr-fix-review reads the open review threads on your pull request, categorizes them as fixable or invalid, and works through each one. It resolves threads as it goes and leaves a summary comment when done. What to expect:
  • A list of unresolved threads and their classification (fixable vs. invalid)
  • Code changes applied for each requested change
  • Threads marked resolved after each fix
  • A final summary comment on the PR describing what was addressed
The command supports two modes: ask (confirms each fix with you before applying) and auto (runs end to end without prompts). Pass the mode as an argument: 
/gg-pr-fix-review ask
/gg-pr-fix-review auto
Use ask mode for important PRs where you want to review each fix before it lands. Use auto for routine feedback or bot reviews (CodeRabbit, Reviewdog, etc.) where the changes are mechanical and low-risk.

​
Troubleshooting

You need to create a project before running other commands. Run /gg-new first to scaffold a project.
Workflows needs codebase documentation to research, plan, and execute effectively. Run /gg-codebase in Claude Code or Cursor to generate it. This only needs to be done once per repository (re-run if your codebase structure changes significantly).
This is expected behavior with AI-powered workflows. See the Troubleshooting guide for how to recognize when it’s off-track and how to course-correct using CLI commands.
Each command requires phases to be in a specific state. Run /gg-status to see which step each phase is on, then run the appropriate command for that step. For example, a phase at plan/done is ready for /gg-execute, not /gg-verify.