Command examples

CCGM ships slash commands as Markdown files inside modules. Each example below shows one command, what it does, and the output it produces. Every block names the module file it comes from, and every attribution links straight to that file so you can check it.

How to read the provenance labels

Verbatim from the module docs
Quoted byte-for-byte from the module file named beneath it. A unit test re-checks each quoted block against the ingested file on every build, so a block that drifts from its source fails the build.
Illustrative -- authored for this page
Written for this page, not captured from a real run. Sample values (paths, branch names, counts) are made up; every line shape is traced to a documented output string in the files named beneath it, listed line by line. Nothing here claims a flag, step, or output the module does not document.

No example on this page shows a flag, a step, or an output line that its module does not document. Where a real run would print data we do not have, the block is labelled illustrative and every line of it is anchored to a documented output string, listed under the block.

6 commands, 14 blocks: 10 quoted verbatim from module docs, 4 authored and labelled illustrative.

/gs

One screen of repository state: branch, sync, recent commits, open PRs, and what to do next.

Ships in commands-core

The command hands its whole workflow to a sub-agent on a cheaper model, which runs a single gather script that emits structured "=== SECTION ===" blocks, then formats those blocks into the dashboard below. Sections with no data are omitted rather than printed empty.

The last line is a suggestion, picked from a table in the command doc that maps repository state to a next step -- uncommitted changes on a feature branch suggests /commit, committed changes with no PR suggests /pr.

Invocation

Illustrative -- authored for this page 

/gs

Source: Core Commands / commands/gs.md

What each line rests on (1)
  • # /gs - Git Status Dashboard The command name, which the doc carries in its heading rather than as a written-out invocation line.

The dashboard it prints

Verbatim from the module docs 

Repository: {name from REPO section}
Branch: {branch} -> {upstream}
Status: {clean / N files changed based on STATUS section}

Sync:
  Main: {ahead_behind from SYNC main: line - format as "N ahead, N behind"}
  Remote: {ahead_behind from SYNC upstream: line - format as "N unpushed, N to pull"}

Recent Commits:
  {LOG section content}

Open PRs:
  {PRS section content, highlight any from current branch}

Sibling Sessions (same repo):
  {SESSIONS content, or omit if empty}

Changes:
  {DIFF section content - summarize staged/unstaged/untracked}

Suggested: {recommended next action per table below}

Source: Core Commands / commands/gs.md

/ship-ready

A read-only pre-merge dashboard: what is blocking this branch, in one screen.

Ships in ship-readiness

Sections print in a fixed order: branch context, failing tests, open PRs, stale branches, outdated dependencies, merge velocity, review freshness, and unresolved risks pulled from prior learnings. The command never runs tests, linters, or installers; where a signal needs a running process it reports the last known result and how to refresh it.

Review freshness is the section that sets this apart from a generic status read-out. It reads the JSON envelopes /ce-review leaves in .context/ce-review/, resolves the commit each review ran against, and counts the commits that have landed since -- so a review that has gone stale is visible as staleness rather than as a green tick.

A single gate line closes the dashboard. Only a failing CI run, a P0 finding in the latest review, or a branch behind its base count as hard blockers; stale reviews and outdated dependencies are informational.

Usage

Verbatim from the module docs 

/ship-ready                   # Dashboard for the current branch
/ship-ready base:origin/main  # Override the base ref for diffs and review lookup (default: origin/main)
/ship-ready mode:strict       # Exit non-zero if any gate is red; for CI or for blocking /cpm

Source: Ship Readiness Dashboard / commands/ship-ready.md

Section 1 of the dashboard: branch context

Verbatim from the module docs 

Branch: {branch}  @  {head_sha}
Base:   {base_ref}  (ahead: {ahead}, behind: {behind})
Files changed on branch: {diff_files}

Source: Ship Readiness Dashboard / commands/ship-ready.md

Section 7: review freshness

Verbatim from the module docs 

Reviews vs {base_ref}:
  /ce-review  ran {relative-age}  on {head_sha_short}
              commits since review: {N}  ({STATUS})
              findings: P0:{n}  P1:{n}  P2:{n}  P3:{n}
              auto-fixed: {n}   needs input: {n}   red-team: {n}

Source: Ship Readiness Dashboard / commands/ship-ready.md

The gate line, printed last

Verbatim from the module docs 

GATE: {STATUS}   ({reason})

Source: Ship Readiness Dashboard / commands/ship-ready.md

/retro

A retrospective built from git history over a window, not from one session's memory.

Ships in self-improving

The window is resolved to an absolute date anchored at local midnight before any git query runs, so "last 7 days" means the same thing at 9am and at 11pm. The command then walks the log for commit counts, per-author line counts, hotspot files, a test-to-prod ratio, referenced issue numbers, and session boundaries inferred from gaps between commits.

The result is a short note, not a data dump. If any pattern looks like a reusable learning, the command offers to capture it through /reflect -- it never writes to the learnings store itself.

Usage

Verbatim from the module docs 

/retro                     # Last 7 days, this repo
/retro [N]d                # Last N days (e.g. /retro 14d)
/retro [YYYY-MM-DD]        # From that date through today
/retro global              # Aggregate across ALL repos under the code directory
/retro global [window]     # Global + windowed

Source: Self-Improving Agent / commands/retro.md

The retro it renders

Verbatim from the module docs 

# Retro: {REPO_NAME}  ({SINCE} - today)

**Sessions**: {N}   **Commits**: {N}   **PRs referenced**: #{a}, #{b}, ...

## Shipped

- {merged PRs / closed issues, 1 line each}

## Hotspots

- {path}  ({N} changes)  - {one-line observation}
- ...

## Per-author activity

| Author | Commits | LOC (+/-) | Files |
|--------|---------|-----------|-------|
| ...

## Patterns worth noting

- {any 3+ time topic, or test-ratio flag, or repeated-attempt pattern}

## Context from notes

{If ~/.claude/retro-context.md exists, 3-5 line summary of relevant bits.}

## Suggested follow-ups

- {1-3 concrete actions the user could take next - an issue to open, a
  refactor to plan, a pattern to capture via /reflect}

Source: Self-Improving Agent / commands/retro.md

/worktree-sweep

Remove the worktrees a parallel agent run left behind, and preserve every one with unsaved work.

Ships in git-worktrees

The command runs an installed shell script that walks every worktree of the current repository and classifies each one. Anything with uncommitted tracked changes, untracked non-ignored files, a paused rebase or merge, a lock, or a detached HEAD carrying commits no ref reaches is preserved. Clean worktrees in the managed directories are removed with a non-force git worktree remove, which is itself the last safety gate: git refuses the removal if the classification missed something.

A removed worktree never costs you commits -- they survive on the branch ref. The script deletes a branch only after verifying the default branch already contains its work, either as an ancestor or as a patch-equivalent squash merge; a branch that passes neither test is kept, and the report prints the git worktree add line that restores its checkout.

--dry-run classifies and reports without changing anything.

Usage

Verbatim from the module docs 

/worktree-sweep [--dry-run] [--conservative] [--all]
                [--worktree <path>] [--keep-branches] [--merged-branches]

Source: Git Worktrees / commands/worktree-sweep.md

A --dry-run over three worktrees

Illustrative -- authored for this page 

=== worktree-sweep (DRY RUN - nothing removed) ===
default branch: origin/main

REMOVED (2, ~18 MB reclaimed):
  - /Users/dev/code/acme/.claude/worktrees/fix-471  [fix/471-null-session] -> WOULD REMOVE, ~12 MB (branch fix/471-null-session WOULD BE DELETED: already on origin/main)
  - /Users/dev/code/acme/.claude/worktrees/docs-api  [docs/api-reference] -> WOULD REMOVE, ~6 MB (branch docs/api-reference KEPT: work not on origin/main - nothing discarded; restore with 'git worktree add /Users/dev/code/acme/.claude/worktrees/docs-api docs/api-reference')

PRESERVED (1, unsaved work / in-progress / locked):
  - /Users/dev/code/acme/.claude/worktrees/feat-auth  [feature/auth-refresh] -> PRESERVE (uncommitted or untracked changes)

Done. 2 removed, 1 preserved, 0 skipped, 1 branch(es) deleted.

Source: Git Worktrees / lib/worktree-sweep.sh, Git Worktrees / commands/worktree-sweep.md

What each line rests on (12)
  • echo "=== worktree-sweep (DRY RUN - nothing removed) ===" The banner line, printed instead of the plain one whenever --dry-run is passed.
  • echo "default branch: $DEFAULT_REF" The "default branch: origin/main" line under the banner.
  • echo "REMOVED ($REMOVED, ~$((RECLAIMED_KB/1024)) MB reclaimed):" The REMOVED section header, its count, and the reclaimed-megabyte total.
  • - $label -> WOULD REMOVE, ~$((kb/1024)) MB${BRANCH_NOTE} Each removal line under --dry-run: two-space indent, the label, the arrow, the size, then the branch note.
  • label="$label [$CUR_BRANCH]" The "<path> [<branch>]" label shape, with two spaces before the bracket.
  • BRANCH_NOTE=" (branch $b WOULD BE DELETED: already on $DEFAULT_REF)" The note on fix/471-null-session, whose work the default branch already contains.
  • BRANCH_NOTE=" (branch $b KEPT: work not on ${DEFAULT_REF:-<unknown default>} - nothing discarded)" The note on docs/api-reference, whose work is not on the default branch and so is kept.
  • BRANCH_NOTE="${BRANCH_NOTE%)}; restore with 'git worktree add $1 $CUR_BRANCH')" The restore hint appended inside that note, before its closing parenthesis.
  • echo "PRESERVED ($PRESERVED, unsaved work / in-progress / locked):" The PRESERVED section header and its parenthetical.
  • - $label -> PRESERVE (uncommitted or untracked changes) The preserve line for feat-auth, the dirty worktree.
  • echo "Done. $REMOVED removed, $PRESERVED preserved, $SKIPPED skipped, $BRANCHES_DELETED branch(es) deleted." The closing tally line and its exact wording, including "branch(es)".
  • */.claude/worktrees/*|*/.worktrees/*) return 0 ;; The .claude/worktrees/ paths in the sample: only these two locations are swept without --all.

/recall

Search Claude Code session history across every clone of a repository.

Ships in session-history

The command runs a Python script that reads Claude Code's own JSONL transcripts directly. There is no separate index or database -- the transcripts are the source of truth, read on demand. Sessions from every clone of the repository are unified into one list, matched by the canonical repository name plus a known clone suffix.

With no query it prints a summary of the last seven days: one line per session, most recent first. With a query it prints the matching turns instead, filtered by a case-insensitive regular expression.

Examples

Verbatim from the module docs 

/recall                       # What have I been doing in this repo this week?
/recall migration             # What did I try with that migration?
/recall --days 30 auth        # Broader lookback on auth work
/recall --repo other-repo     # Switch to another repo's sessions
/recall --session 65b57a04    # Read a specific session

Source: Session History / commands/recall.md

Summary output for a bare /recall

Illustrative -- authored for this page 

Recent activity: acme (last 7 days, 3 clones, 5 sessions) — summary
2026-08-19  acme-w0-c1      65b57a04   42 turns  rebase the auth branch and rerun the migration
2026-08-19  acme-w0-c0      7f0c1d33   18 turns  why does /ship-ready say the review is stale?
2026-08-18  acme-w0-c2      a91e4b6d    9 turns  add the 375px viewport case to the theme suite
2026-08-17  acme-w0-c1      1c8d0e52   77 turns  port the ingest script off the old schema
2026-08-15  acme-w0-c0      3b2a9f70    5 turns  quick look at the failing headers test

Source: Session History / scripts/recall.py, Session History / scripts/repo_detect.py

What each line rests on (9)
  • print(f"Recent activity: {repo} (last {days} days{suffix}, {count} sessions) — {mode}") The header line, including the em dash before the mode name.
  • suffix = f", {len(clones)} clones" if len(clones) > 1 else "" The ", 3 clones" fragment, which only appears when more than one clone contributed sessions.
  • mode = "summary" The word "summary" as the mode, which is what a bare /recall selects.
  • DEFAULT_DAYS = 7 The "last 7 days" window in the header when no --days is passed.
  • f"{_fmt_date(s.mtime)} {s.clone:<14} {s.session_id[:8]} " The first half of each row: date, two spaces, clone padded to 14 columns, two spaces, an 8-character session id.
  • f"{s.turn_count:>3} turns {_truncate(s.last_user_msg, 60)}" The second half of each row: the turn count right-aligned in 3 columns, the word "turns", then the last user message capped at 60 characters.
  • return time.strftime("%Y-%m-%d", time.localtime(mtime)) The YYYY-MM-DD date format in the first column.
  • sessions.sort(key=lambda s: s.mtime, reverse=True) Most-recent-first ordering of the rows.
  • repo='ccgm', -home-alice-code-ccgm-workspaces-ccgm-w0-c2 → 'ccgm-w0-c2' The "acme-w0-c1" clone-label shape: the repository name plus its workspace and clone numbers.

/pressure-test

Attack a candidate rule with adversarial scenarios, then harden it with what got through.

Ships in rule-authoring

The command reads a rule file, pulls out its one-sentence rule statement, and generates five to seven adversarial scenarios that each combine three or more pressure vectors. It dispatches sub-agents against those scenarios twice -- once without the rule loaded to establish a baseline, once with it -- and records where the rule held and where an agent talked its way past it.

The rationalizations it captures are added to the rule's Rationalizations Table and the red flags to its Red Flags list. The run then re-tests against fresh scenarios to check the hardening held, and the report closes on one of three recommendations: ship as-is, iterate further, or sharpen the rule statement.

Invocation

Illustrative -- authored for this page 

/pressure-test modules/verification/rules/verification.md

Source: Rule Authoring / commands/pressure-test.md

What each line rests on (3)
  • # /pressure-test - Pressure-Test a Candidate Rule The command name.
  • argument-hint: <path-to-rule-file-or-draft> That the single argument is a path to a rule file.
  • `modules/verification/rules/verification.md` The specific path shown, which the command doc itself offers as the example path to pass.

The report it produces

Verbatim from the module docs 

## Pressure-Test Report: {rule-name}

**Rule file:** {path}
**Rule:** {extracted rule statement}

### Baseline (RED) compliance: {N/total}
### After rule loaded (GREEN) compliance: {N/total}
### After hardening (adversarial GREEN) compliance: {N/total}

### Scenarios run
1. {scenario-title} - RED: BYPASS, GREEN: COMPLY
2. {scenario-title} - RED: BYPASS, GREEN: BYPASS (loophole identified, added)
...

### Rationalizations captured (added to table)
- "It's a trivial test case..." -> "Follow-up PR is how untested code becomes permanent..."
- ...

### Red Flags captured (added to list)
- "It's just a trivial case"
- ...

### Outstanding concerns
{any scenarios where the rule still fails, or any DONE_WITH_CONCERNS the agent raised}

### Recommendation
{one of: ship as-is | iterate further | rule statement needs sharpening}

Source: Rule Authoring / commands/pressure-test.md