[kalil0321]

Why

The agent skill (#147) is only mentioned in the README, and the JSON docs don't say that script_path now always exists on status: ok (#148).

What

• New docs page cli/coding-agents: install line, what the agent does step by step, and when it uses your Chrome (including Chrome's connection prompt). Linked from Installation and Scripted usage.
• script_path in the Scripted usage table and the README JSON table: exists whenever status is ok; a run without a client reports engine_failure.

Verification

• pnpm build passes; the new page renders and every internal link on it resolves to a built page.

---

Summary by cubic

Adds docs for the agent skill and documents that script_path always exists when status is "ok".

• New clickhouse/cli/coding-agents page covers installation, step-by-step behavior, and when the skill connects to your Chrome (including the connection prompt).
• Links to the new page from Installation and Scripted usage.
• script_path in the README and Scripted usage tables now guarantees existence on status: "ok"; a run without a client reports engine_failure.

^{Written for commit 45bfd01. Summary will update on new commits.}

Confidence Score: 4/5

The confirmed documentation mismatch is non-blocking; the reviewed scope contains no issue that must prevent merging.

Findings

1.  Dry runs generate no client ▶

Fix with agent prompt

### Issue 1
website/content/docs/cli/scripted-usage.mdx:109
The guarantee also covers `agent --dry-run --json`, which returns `status: "ok"` with `script_path: null` when its checks pass. This page documents that command just above the table. Wrapper authors could therefore mistake a successful setup check for proof that a client exists. This is a non-blocking documentation mismatch: limit the guarantee to completed capture or engineering runs, and qualify the matching `README.md` row too.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds a coding-agent guide and links it from Installation and Scripted usage.

• A new guide shows coding agents how to use the CLI.
• The JSON docs now tie success to an existing client path.

This documentation mismatch is non-blocking. No blocking issue was found in the reviewed scope.

_{Reviews (1) · Last reviewed commit: "Document the agent skill and the script_..." · Reviewed by Greptile}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-28T22:14:19.639801Z	45bfd01	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[cubic-dev-ai]

1 issue found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="README.md">

<violation number="1" location="README.md:172">
P2: `agent --json` can still return `status: "ok"` with `script_path: null`, so this documents an invariant the CLI does not enforce. Make the null-path case an `engine_failure` before documenting this guarantee, or soften the table entry.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: agent --json can still return status: "ok" with script_path: null, so this documents an invariant the CLI does not enforce. Make the null-path case an engine_failure before documenting this guarantee, or soften the table entry.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At README.md, line 172:

<comment>`agent --json` can still return `status: "ok"` with `script_path: null`, so this documents an invariant the CLI does not enforce. Make the null-path case an `engine_failure` before documenting this guarantee, or soften the table entry.</comment>

<file context>
@@ -169,7 +169,7 @@ Pass `--no-interactive` (and/or `--json`) to skip prompts. With `--json`, stdout
 | `mode`           | `string` \| `null`  | `"auto"`, `"chrome-mcp"`, or `"agent-browser"`.                                        |
 | `har_path`       | `string` \| `null`  | Captured HAR.                                                          |
-| `script_path`    | `string` \| `null`  | Generated client.                                                      |
+| `script_path`    | `string` \| `null`  | Generated client; exists whenever `status` is `"ok"`.                 |
 | `usage`          | `object`            | `{input_tokens, output_tokens, total_cost}`.                           |
 | `error`          | `string` \| `null`  | When `status == "error"`.                                              |
</file context>

[greptile-apps]

Dry runs generate no client

The guarantee also covers agent --dry-run --json, which returns status: "ok" with script_path: null when its checks pass. This page documents that command just above the table. Wrapper authors could therefore mistake a successful setup check for proof that a client exists. This is a non-blocking documentation mismatch: limit the guarantee to completed capture or engineering runs, and qualify the matching README.md row too.

Artifacts

Evidence from the check

• The executed Python harness invokes the real CLI against base and head, captures responses, and asserts successful checks, a null script path, and early exit; no CLI functions are mocked.

Command output from the check

• Ran the reproduction against the base revision and captured source, commands, JSON, tracing, and passing assertions; a successful dry run already returned a null script path.

Command output from the check

• Ran the same reproduction against the supplied head and captured the changed documentation alongside JSON and passing assertions; the new guarantee contradicts the unchanged successful dry-run behavior.

_{Ran code and verified through TREX}

Prompt To Fix With AI

This is a comment left during a code review.
Path: website/content/docs/cli/scripted-usage.mdx
Line: 109

Comment:
**Dry runs generate no client**

The guarantee also covers `agent --dry-run --json`, which returns `status: "ok"` with `script_path: null` when its checks pass. This page documents that command just above the table. Wrapper authors could therefore mistake a successful setup check for proof that a client exists. This is a non-blocking documentation mismatch: limit the guarantee to completed capture or engineering runs, and qualify the matching `README.md` row too.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 45bfd012b9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Exclude dry runs from the script existence guarantee

For agent --dry-run --json, a successful preflight returns status: "ok" with script_path: null: _build_dry_run_payload explicitly constructs that response, and the command exits without generating a client. Since this page also documents dry runs, the unconditional existence guarantee can mislead wrappers into treating a successful preflight as a generated artifact. Qualify the guarantee as applying to completed capture/engineering runs, and retain the preflight exception in both JSON tables.

Useful? React with 👍 / 👎.