gmc

IRON LAW: ALL WORKTREE OPERATIONS MUST USE gmc wt <subcommand>. NEVER INVENT gmc add, gmc rm, gmc prune, gmc clone, OR OTHER TOP-LEVEL WORKTREE COMMANDS.

gmc

Use $ARGUMENTS and the user's words to route into exactly one mode.

Copy this checklist and check off items as you complete them:

• Step 0: Parse intent [BLOCKING]
  • Classify the request as commit, wt add, wt prune, wt share, wt sync, wt rm, wt ls, wt dup, wt pr-review, or tag
  • If the intent is unclear, ask one focused question before running commands
• Step 1: Validate context [BLOCKING]
  • Confirm gmc exists
  • Confirm the current directory is a git repo when the command needs repo context
  • If the action depends on GitHub state, confirm gh works first
• Step 2: Preview plan [REQUIRED]
  • Show the exact command you plan to run
  • For destructive or bulk actions, prefer --dry-run first
• Step 3: Execute exactly one workflow
  • commit
  • wt add
  • wt prune
  • wt share
  • other gmc wt subcommand or tag
• Step 4: Report result
  • State the exact command run
  • Report the created path, cleaned worktrees, synced resources, or generated message
  • State what was not run

Routing

• commit uses top-level gmc
• Any worktree action uses gmc wt <subcommand>
• If the user says gmc add, translate it to gmc wt add and say so
• If the user wants generic git help without gmc, do not use this skill

Common commands

• gmc
• gmc -y
• gmc -a -y
• gmc -a -y -p "context"
• gmc --dry-run
• gmc wt add <name>
• gmc wt add <name> --sync
• gmc wt add <name> -b <branch>
• gmc wt ls
• gmc wt rm <name>
• gmc wt rm -D <name>
• gmc wt prune
• gmc wt sync
• gmc wt share ls
• gmc wt share add <path> --strategy copy
• gmc wt share add <path> --strategy link
• gmc wt share sync
• gmc tag

Workflow: commit mode

• Use top-level gmc, not gmc wt
• Default to interactive gmc unless the user explicitly wants automation
• Ask before gmc -a -y because it stages all files and auto-confirms
• Use gmc --dry-run when the user wants a suggested message without committing