Skip to content

skill(connect): add Output Contract (Global Contract 6) #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
0xeb merged 1 commit into from
Jun 23, 2026
Merged

skill(connect): add Output Contract (Global Contract 6) #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions plugins/ghidrasql/skills/connect/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,12 @@ See [references/cost-model.md](references/cost-model.md) for the full table with
| Local rename / type apply over-propagates through reused decompiler temporaries | The decompiler shares storage between source-level variables that happen to use the same register/stack slot, so `apply_type_local` (or a direct `decomp_lvars` UPDATE) on one site can change unrelated locals. Mitigation: back the local out to a neutral type (e.g. `char *`) and keep the recovered struct on prototypes; verify in `pseudocode` after each edit |
| Pointer-return signature update fails with `Can't parse name: *fn` | Ghidra's CParser tokenises `<type> *fn(...)` differently from `<type>* fn(...)`. Workaround: use `char* fn` form (asterisk on the type, not the name). Same applies to `void **`, `int *`, etc. |

### 6. Output

- **Selection** — decide *whether and how much* to surface from user intent. Answer questions directly ("biggest is `main`, 135 bytes"); show supporting rows only when they help the user verify; don't dump full tables unprompted; never surface data fetched only as an intermediate reasoning step.
- **Fidelity** — when you *do* present code/data, show the real artifact (decompilation, actual rows), never a paraphrase.
- **Mechanics** — the HTTP `/query` response is a JSON envelope (`{success, results:[{columns,rows,...}]}`). Consume it directly and render in your reply. Do **not** pipe responses through `python`/`jq` to pre-render a table — that discards the `success`/`elapsed_ms`/`error` fields and makes you reason over a lossy view. The CLI (`-q`/`-f`) already prints a table. Reserve `jq`/`python` for extracting a value to feed a later query. (For direct terminal/pipe use the server can emit `?format=text|csv|tsv`; as an agent, consume `json`.)

## Pre-flight

If `GHIDRA_INSTALL_DIR` is set in the environment, the CLI auto-fills `--ghidra` from it and rejects `--url` as conflicting. For any `--url`-mode invocation either prefix with `unset GHIDRA_INSTALL_DIR;` or use `env -u GHIDRA_INSTALL_DIR ghidrasql --url ...`.
Expand Down