# AI use cases for Ripwire (redhat-et/ripwire)

Repo: [redhat-et/ripwire](https://github.com/redhat-et/ripwire) | Use cases: 4 | Page: https://dedupedai.com/use-cases/redhat-et-ripwire/

ripwire is a zero-dependency C++23 command-line tool and optional MCP server that gives coding agents a ranked map of a repository and checks what they changed.

This file holds every use case of this repo. Each one starts with a "## " heading and ends with its URL.

- Find where to change code without reading the repo: https://dedupedai.com/use-cases/redhat-et-ripwire/find-where-to-change-code/
- Check what an edit breaks before calling it done: https://dedupedai.com/use-cases/redhat-et-ripwire/check-blast-radius-before-finishing-edit/
- Find the real callers before changing a behavior: https://dedupedai.com/use-cases/redhat-et-ripwire/find-real-callers-before-changing-behavior/
- Catch quality regressions before a task is marked done: https://dedupedai.com/use-cases/redhat-et-ripwire/gate-code-quality-before-finishing/

## How to find where to change code without reading the repo with Ripwire

Repo: [redhat-et/ripwire](https://github.com/redhat-et/ripwire) | Difficulty: Intermediate | Time: 15 minutes | Basis: From the README

Ask a question about a feature and get a ranked list of the code to touch.

**Who it is for:** A developer or agent starting a task in an unfamiliar codebase who needs the relevant files and functions fast.

**The problem:** Grep and whole-file reads cost many tokens and calls before the right code is found, and the answer is often incomplete.

**The outcome:** A ranked, deterministic answer that names the signatures and call relationships to start from, so the agent reads far fewer files.

### Steps

1. Install Ripwire with the one-line command: `RIPWIRE_REPO=redhat-et/ripwire bash -c "$(curl -fsSL https://raw.githubusercontent.com/redhat-et/ripwire/main/scripts/install.sh)"`
2. Add the install directory to your path: `export PATH="$HOME/.local/bin:$PATH"`
3. Change into the repository you want to explore: `cd your-repo`
4. Ask a specific technical question with the query flag: `ripwire . --for="<your question>"` (inferred, check the README)
5. Read the ranked results and open only the files and symbols they point to.

### Prompt to paste into your agent

```text
Use ripwire on the repo at <path>. Run ripwire . --for="<task description>" and list the top ranked symbols and files it returns. Verify that each named file exists in the repo before you open it.
```

### Caveat

The README says Ripwire shines on specific technical questions, and broad common-word queries can still be answered better by plain grep and read.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/redhat-et-ripwire/find-where-to-change-code/

## How to check what an edit breaks before calling it done with Ripwire

Repo: [redhat-et/ripwire](https://github.com/redhat-et/ripwire) | Difficulty: Intermediate | Time: 15 minutes | Basis: From the README

Run the edit check to see blast radius, tests that reach the change and incompatible call sites.

**Who it is for:** A developer or agent that has just changed a function or public symbol and wants to confirm nothing else silently diverged.

**The problem:** A text search can miss call sites, so a signature change can leave some callers out of date without any test failing.

**The outcome:** A list of the blast radius, the tests that reach the edit and any call sites flagged as incompatible, to fix before merging.

### Steps

1. Install Ripwire and add it to your path, as shown in the first use case.
2. Change into the repository: `cd your-repo`
3. Run the edit check flag, named `--edit-check`, on the file or symbol you changed. Look up its exact arguments in the reference guide before running it.
4. Review the blast radius, the tests that reach the change and any flagged call sites.
5. Verify each flagged call site by compiling, then fix the ones that are truly broken.

### Prompt to paste into your agent

```text
Use ripwire on the repo at <path>. After editing <symbol>, run the --edit-check flag on it and report the blast radius, the tests that reach it and any incompatible call sites. Verify each flagged site by compiling before you change anything.
```

### Caveat

The README warns that the contract checker's arity heuristic over-counts on defaulted trailing parameters, so each flagged site should be confirmed by compiling.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/redhat-et-ripwire/check-blast-radius-before-finishing-edit/

## How to find the real callers before changing a behavior with Ripwire

Repo: [redhat-et/ripwire](https://github.com/redhat-et/ripwire) | Difficulty: Intermediate | Time: 15 minutes | Basis: From the README

Use the callers flag to see whether production code actually reaches a function.

**Who it is for:** A developer or agent assigned to activate or modify a behavior that is believed to be live in production.

**The problem:** A behavior can look wired up in the code while no production path actually calls it, which sends the task in the wrong direction.

**The outcome:** A clear answer on who calls the function, so the work targets the real gap rather than a phantom.

### Steps

1. Install Ripwire and add it to your path, as shown in the first use case.
2. Change into the repository: `cd your-repo`
3. Run the callers flag, named `--callers`, on the function in question. Look up its exact arguments in the reference guide before running it.
4. If the result shows zero production callers, record that and investigate the missing wiring before writing new code.
5. Confirm the finding by reading the call sites Ripwire reports.

### Prompt to paste into your agent

```text
Use ripwire on the repo at <path>. Run the --callers flag on <function name> and report every production caller it finds. Verify the result by opening each reported call site.
```

### Caveat

The README describes this as a lookup of the call graph, so an empty caller list should be checked against the code before drawing conclusions.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/redhat-et-ripwire/find-real-callers-before-changing-behavior/

## How to catch quality regressions before a task is marked done with Ripwire

Repo: [redhat-et/ripwire](https://github.com/redhat-et/ripwire) | Difficulty: Advanced | Time: 15 minutes | Basis: From the README

Run the quality delta check so only what got worse is reported.

**Who it is for:** A developer or orchestrating agent that wants a mechanical quality check at the end of each coding task.

**The problem:** Duplicated routines and quiet extra responsibilities pile up under fast edits, and tests do not catch them.

**The outcome:** A report of only the quality measures that got worse, so each one is fixed or justified in writing before the task closes.

### Steps

1. Install Ripwire and add it to your path, as shown in the first use case.
2. Change into the repository: `cd your-repo`
3. Run the quality delta flag, named `--quality-delta`, after your edits. Look up its exact arguments in the reference guide before running it.
4. Fix each reported regression, or write down a reason for keeping it.
5. Run the tests and the edit check again before closing the task.

### Prompt to paste into your agent

```text
Use ripwire on the repo at <path>. After your changes, run the --quality-delta flag and list every quality kind that got worse. Verify each one by reading the flagged code before you fix it or record a reason to keep it.
```

### Caveat

The README says Ripwire is a floor for honesty and orientation and is not a substitute for measurement design, so it should sit alongside tests rather than replace them.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/redhat-et-ripwire/gate-code-quality-before-finishing/