---
name: ghidra-re
description: "Inspect or improve an existing Ghidra Program through structured decompilation, listing, p-code, search, raw references, native analysis, and atomic saved edits. Use for binary and firmware reverse engineering when the answer or durable improvement belongs in Ghidra's Program database."
---

# Work in Ghidra

Start from the user's question and use Ghidra as the working model.

## Select the Program

Call `select_program` once with an explicit absolute project path. Selection retains only the locator; each operation opens and releases the Program.

## Investigate

Use the highest representation that answers the question:

- Start with `search_program`, `decompile`, and `inspect_function`.
- Use `inspect_address`, `read_listing`, or `trace_value` when exact widths, storage, flow, instruction semantics, or suspicious decompiler output matter.
- Use `references` for Ghidra's raw incoming and outgoing references. Interpret control-flow meaning from listing, p-code, and function context rather than relying on connector-owned classifications.
- Give `trace_value` an exact value ID returned by `decompile(include_high_pcode=true)` and choose backward definitions or forward uses.

Follow enough callers, callees, data, and state to explain behavior rather than paraphrasing one function. Treat Ghidra functions as machine-body partitions, not automatic historical source functions.

## Improve the Program

When the user asks for analysis changes, call `apply_changes` directly. Group coherent edits so Ghidra applies and saves them as one native transaction. Use `reanalyze` only for an explicit range.

Annotate freely. Inspect more context before changes with broad downstream effects, such as signatures, calling conventions, function boundaries, memory layout, shared types, non-return behavior, and indirect-call references.

If Ghidra reports `project_in_use`, explain that another native writer owns the project. Leave lock handling to Ghidra.

Re-read or re-decompile affected code after consequential edits. Correct misleading changes with another atomic batch.

Read [TOOLS.md](references/TOOLS.md) when exact schemas or supported change kinds matter.

## Keep the Workbench Focused

Run project-specific imports, processor tests, compiler experiments, and repeatable bulk transformations through repository-owned Ghidra scripts or `analyzeHeadless`. Keep durable firmware-analysis facts in the Program and reproducible transformation logic in the repository.