opencode-trace/example.html at main · ljw1004/opencode-trace · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
<!DOCTYPE html>
<html>
<head>
    <style>
        body {font-family: system-ui, -apple-system, sans-serif; margin: 0;}
        body>details {margin-top: 1ex; padding-top: 1ex; border-top: 1px solid lightgray;}
        details {position: relative; padding-left: 1.25em;}
        summary {list-style: none; cursor: pointer;}
        summary::-webkit-details-marker {display: none;}
        summary::before {content: '▷';position: absolute;left: 0;color: #666;}
        details[open]>summary::before {content: '▽';}
        details>div {margin-left: 1.25em;}
        details[open]>summary output {display: none;}
    </style>
    <script src="viewer.js"></script>
    <script>
        if (window.buildNode === undefined) {
          /**
 * Rendering library for codex-trace logs.
 *
 * A codex-trace log is a sequence of jsonl lines in an unterminated `<!` + `--` comment at the end of an HTML document.
 * This module extracts that log and renders each line as a collapsible tree-structure.
 *
 * There's a little bit of cleverness. This module uses a `render()` function to determine how nodes in the tree
 * should be rendered. Normally they're rendered in the normal way (primitives as leaf nodes, objects and arrays as
 * collapsible nodes whose children are recursively rendered). But if the `render()` function at any level returns
 * an object with special properties `{Symbol('TITLE'): ..., Symbol('INLINE'): ..., body: ..., open: ...}`
 * then that object decides how it should be rendered in the tree. Within an object/array, it will be rendered
 * as "▷ TITLE: INLINE" when collapsed, or "▽ TITLE" when expanded, with 'body' an object/array/primitive for
 * the contents of that expanded node. The `open` flag says whether it should be initially expanded.
 *
 * This module has special handling for REQUEST and RESPONSE json payloads for Codex's communication with an LLM.
 */

const TITLE = Symbol('TITLE');
const INLINE = Symbol('INLINE');
// Invariant: the contents of [TITLE] and [INLINE] have both been escaped

/**
 * Turns an html string into a DOM node
 */
function fromHTML(html) {
  const t = document.createElement('template');
  t.innerHTML = html.trim();
  return t.content.firstElementChild;
}

/**
 * Escapes string for safe insertion into HTML
 */
function esc(s) {
  return s
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/\n/g, '<br/>')
    .replace(/\\n/g, '<br/>');
}

/**
 * Given a datstring in ISO format, returns HH:MM:SS
 */
function ts(data) {
  return data?._ts?.slice(11, 19) ?? '?';
}

/**
 * Puts a string onto a single line and truncates to 80 chars, for display in INLINE part of a node
 */
function short(s) {
  return s.replace(/\n/g, ' ').slice(0, 80);
}

/**
 * Interprets the content array of from an OpenAI payload into a string for display.
 * If we're given undefined, returns an empty string.
 */
function content(contents) {
  if (typeof contents === 'string') return contents;
  let r = [];
  for (const c of contents ?? []) {
    if (c.type === 'input_text') r.push(c.text);
    else if (c.type === 'output_text') r.push(c.text);
    else r.push(`[${c.type}]`);
  }
  return r.join('\n');
}

/**
 * Renders a sequence of elements from an OpenAI payload: messages, function_calls, function_call_outputs.
 */
function renderPayload(elements) {
  const payload = [];
  for (const e of elements) {
    if (e === '...') {
      payload.push({[TITLE]: 'Added...'});
    } else if (e === '---') {
      payload.push({[TITLE]: 'Removed...'});
    } else if (e.type === 'message') {
      payload.push({
        [TITLE]: `${payload.length}: message(${esc(e.role)}): `,
        [INLINE]: esc(short(content(e.content))),
        body: content(e.content),
      });
    } else if (e.type === 'input_text' || e.type === 'output_text') {
      payload.push({
        [TITLE]: `${payload.length}: ${e.type}: `,
        [INLINE]: esc(short(e.text)),
        body: e.text,
      });

    } else if (e.type === 'function_call_output') {
      payload.push({
        [TITLE]: `${payload.length}: `,
        [INLINE]: `function_call_output: ${esc(short(e.output))}`,
        body: e,
      });
    } else if (e.type === 'function_call') {
      let arg;
      try {
        const j = JSON.parse(e.arguments);
        arg = j.cmd ?? j.pattern;
        arg = `"${esc(short(arg))}"`;
      } catch (e) {
        arg = '...';
      }
      payload.push({
        [TITLE]: `${payload.length}: `,
        [INLINE]: `function_call: ${esc(e.name)}(${esc(short(arg))})`,
        body: e,
      });
    } else {
      payload.push({
        [TITLE]: `${payload.length}: `,
        [INLINE]: esc(e.type ?? '???'),
        body: e,
      });
    }
  }
  return payload;
}

/**
 * Renders a node in the tree.
 * If it looks like a REQUEST or RESPONSE payload (has ._kind property) then renders it conveniently.
 * Otherwise, renders primtives, objects, arrays in the obvious way.
 */
function render(data, label) {
  const id = data?._id !== undefined ? ` #${esc(String(data._id))}` : '';
  const purpose = data?._purpose ? ` ${esc(String(data._purpose))}` : '';
  if (data?.[TITLE] !== undefined) {
    return data;
  } else if (data?._kind === 'request') {
    const input = data['input'] ?? data['input+'] ?? data['input-'] ?? data['*input'] ?? [];
    // OpenCode request bodies can mix message wrappers like
    // `{role:'user', content:[{type:'input_text', text:'...'}]}` with already-typed items like
    // `{type:'function_call', ...}`. Flatten wrapper objects to their `content` items so `payload`
    // is always a list of typed entries like `{type:'input_text', ...}` or `{type:'function_call', ...}`.
    const payload = input.flatMap(e =>
      e && typeof e === 'object' && !Array.isArray(e) && e.type === undefined && Array.isArray(e.content)
        ? e.content
        : e && typeof e === 'object' && !Array.isArray(e) && e.type === undefined && typeof e.content === 'string'
          ? [{type: 'input_text', text: e.content}]
        : [e],
    );
    const rendered = renderPayload(payload);
    const raw = {...data};
    delete raw._kind;
    return {
      [TITLE]: `[${esc(ts(data))}] <b>REQUEST${id}${purpose}</b> `,
      body: [...rendered, {[TITLE]: 'raw', body: raw}],
      open: true,
    };
  } else if (data?._kind === 'response') {
    const payload = renderPayload(
      data['output'] ?? data['output+'] ?? data['output-'] ?? data['*output'] ?? [],
    );
    const raw = {...data};
    delete raw._kind;
    return {
      [TITLE]: `[${esc(ts(data))}] <b>RESPONSE${id}${purpose}</b> `,
      body: [...payload, {[TITLE]: 'raw', body: raw}],
      open: true,
    };
  } else if (data?._kind === 'error') {
    const raw = {...data};
    return {
      [TITLE]: `[${esc(ts(data))}] <b>ERROR${id}${purpose}</b> `,
      [INLINE]: esc(short(data._error ?? '')),
      body: [
        data._error ?? '???',
        ...(data._stack ? [{[TITLE]: 'stack', body: data._stack}] : []),
        {[TITLE]: 'raw', body: raw},
      ],
      open: true,
    };
  } else if (data?._kind !== undefined && data?._ts !== undefined) {
    const raw = {...data};
    return {
      [TITLE]: `[${esc(ts(data))}] <b>${esc(data._kind)}</b> `,
      body: raw,
      open: true,
    };
  } else {
    return {
      [TITLE]: esc(label),
      [INLINE]: esc(
        Array.isArray(data)
          ? `[...${data.length} items]`
          : '{' +
              Object.keys(data)
                .map(k => `${JSON.stringify(k)}:`)
                .join(',') +
              '}',
      ),
      body: data,
      numbered: true,
    };
  }
}

function buildNode(data, label) {
  if (data && typeof data === 'object') {
    const r = render(data, label);
    const d = fromHTML(
      `<details><summary>${r[TITLE]}<output>${r[INLINE] ?? ''}</output></summary></details>`,
    );
    d.addEventListener(
      'toggle',
      () => {
        if (r.body === undefined) {
          // skip
        } else if (Array.isArray(r.body)) {
          r.body.forEach((item, i) =>
            d.appendChild(buildNode(item, r?.numbered ? `${i + 1}: ` : '')),
          );
        } else if (r.body && typeof r.body === 'object') {
          Object.keys(r.body).forEach(k =>
            d.appendChild(buildNode(r.body[k], `${JSON.stringify(k)}: `)),
          );
        } else {
          d.appendChild(buildNode(r.body, ''));
        }
      },
      {once: true},
    );
    d.open = r.open;
    return d;
  } else {
    return fromHTML(`<div>${esc(label)}${esc(JSON.stringify(data))}</div>`);
  }
}

window.addEventListener('DOMContentLoaded', () => {
  if (
    document.lastChild &&
    document.lastChild.nodeType === Node.COMMENT_NODE &&
    document.lastChild.data.trim()
  ) {
    for (const line of document.lastChild.data.split(/\r?\n/).filter(Boolean)) {
      let data = '';
      try {
        data = JSON.parse(line);
      } catch (e) {
        data = {error: String(e), raw: line};
      }
      const node = buildNode(data, 'json:');
      node.classList.add('log-entry');
      document.body.appendChild(node);
    }
  }
});

        }
    </script>
</head>
<body>
</body>
</html>
<!--
{"model":"gpt-5.4","input":[{"role":"user","content":[{"type":"input_text","text":"Generate a title for this conversation:\n"}]},{"role":"user","content":[{"type":"input_text","text":"Please read ~/a.txt. Then respond a short poem about what you find inside. Then read ~/b.txt, and do the same. Thank you!"}]}],"store":false,"instructions":"You are a title generator. You output ONLY a thread title. Nothing else.\n\n<task>\nGenerate a brief title that would help the user find this conversation later.\n\nFollow all rules in <rules>\nUse the <examples> so you know what a good title looks like.\nYour output must be:\n- A single line\n- ≤50 characters\n- No explanations\n</task>\n\n<rules>\n- you MUST use the same language as the user message you are summarizing\n- Title must be grammatically correct and read naturally - no word salad\n- Never include tool names in the title (e.g. \"read tool\", \"bash tool\", \"edit tool\")\n- Focus on the main topic or question the user needs to retrieve\n- Vary your phrasing - avoid repetitive patterns like always starting with \"Analyzing\"\n- When a file is mentioned, focus on WHAT the user wants to do WITH the file, not just that they shared it\n- Keep exact: technical terms, numbers, filenames, HTTP codes\n- Remove: the, this, my, a, an\n- Never assume tech stack\n- Never use tools\n- NEVER respond to questions, just generate a title for the conversation\n- The title should NEVER include \"summarizing\" or \"generating\" when generating a title\n- DO NOT SAY YOU CANNOT GENERATE A TITLE OR COMPLAIN ABOUT THE INPUT\n- Always output something meaningful, even if the input is minimal.\n- If the user message is short or conversational (e.g. \"hello\", \"lol\", \"what's up\", \"hey\"):\n  → create a title that reflects the user's tone or intent (such as Greeting, Quick check-in, Light chat, Intro message, etc.)\n</rules>\n\n<examples>\n\"debug 500 errors in production\" → Debugging production 500 errors\n\"refactor user service\" → Refactoring user service\n\"why is app.js failing\" → app.js failure investigation\n\"implement rate limiting\" → Rate limiting implementation\n\"how do I connect postgres to my API\" → Postgres API connection\n\"best practices for React hooks\" → React hooks best practices\n\"@src/auth.ts can you add refresh token support\" → Auth refresh token support\n\"@utils/parser.ts this is broken\" → Parser bug fix\n\"look at @config.json\" → Config review\n\"@App.tsx add dark mode toggle\" → Dark mode toggle in App\n</examples>\n","include":["reasoning.encrypted_content"],"reasoning":{"effort":"low"},"stream":true,"_id":1,"_purpose":"[meta]","_url":"https://chatgpt.com/backend-api/codex/responses","_kind":"request","_ts":"2026-04-09T05:12:26.448Z"}
{"model":"gpt-5.4","input":[{"role":"user","content":[{"type":"input_text","text":"Please read ~/a.txt. Then respond a short poem about what you find inside. Then read ~/b.txt, and do the same. Thank you!"}]}],"text":{"verbosity":"low"},"store":false,"instructions":"You are OpenCode, You and the user share the same workspace and collaborate to achieve the user's goals.\n\nYou are a deeply pragmatic, effective software engineer. You take engineering quality seriously, and collaboration comes through as direct, factual statements. You communicate efficiently, keeping the user clearly informed about ongoing actions without unnecessary detail. You build context by examining the codebase first without making assumptions or jumping to conclusions. You think through the nuances of the code you encounter, and embody the mentality of a skilled senior software engineer.\n\n- When searching for text or files, prefer using Glob and Grep tools (they are powered by `rg`)\n- Parallelize tool calls whenever possible - especially file reads. Use `multi_tool_use.parallel` to parallelize tool calls and only this. Never chain together bash commands with separators like `echo \"====\";` as this renders to the user poorly.\n\n## Editing Approach\n\n- The best changes are often the smallest correct changes.\n- When you are weighing two correct approaches, prefer the more minimal one (less new names, helpers, tests, etc).\n- Keep things in one function unless composable or reusable\n- Do not add backward-compatibility code unless there is a concrete need, such as persisted data, shipped behavior, external consumers, or an explicit user requirement; if unclear, ask one short question instead of guessing.\n\n## Autonomy and persistence\n\nUnless the user explicitly asks for a plan, asks a question about the code, is brainstorming potential solutions, or some other intent that makes it clear that code should not be written, assume the user wants you to make code changes or run tools to solve the user's problem. In these cases, it's bad to output your proposed solution in a message, you should go ahead and actually implement the change. If you encounter challenges or blockers, you should attempt to resolve them yourself.\n\nPersist until the task is fully handled end-to-end within the current turn whenever feasible: do not stop at analysis or partial fixes; carry changes through implementation, verification, and a clear explanation of outcomes unless the user explicitly pauses or redirects you.\n\nIf you notice unexpected changes in the worktree or staging area that you did not make, continue with your task. NEVER revert, undo, or modify changes you did not make unless the user explicitly asks you to. There can be multiple agents or the user working in the same codebase concurrently.\n\n## Editing constraints\n\n- Default to ASCII when editing or creating files. Only introduce non-ASCII or other Unicode characters when there is a clear justification and the file already uses them.\n- Add succinct code comments that explain what is going on if code is not self-explanatory. You should not add comments like \"Assigns the value to the variable\", but a brief comment might be useful ahead of a complex code block that the user would otherwise have to spend time parsing out. Usage of these comments should be rare.\n- Always use apply_patch for manual code edits. Do not use cat or any other commands when creating or editing files. Formatting commands or bulk edits don't need to be done with apply_patch.\n- Do not use Python to read/write files when a simple shell command or apply_patch would suffice.\n- You may be in a dirty git worktree.\n  * NEVER revert existing changes you did not make unless explicitly requested, since these changes were made by the user.\n  * If asked to make a commit or code edits and there are unrelated changes to your work or changes that you didn't make in those files, don't revert those changes.\n  * If the changes are in files you've touched recently, you should read carefully and understand how you can work with the changes rather than reverting them.\n  * If the changes are in unrelated files, just ignore them and don't revert them.\n- Do not amend a commit unless explicitly requested to do so.\n- While you are working, you might notice unexpected changes that you didn't make. It's likely the user made them, or were autogenerated. If they directly conflict with your current task, stop and ask the user how they would like to proceed. Otherwise, focus on the task at hand.\n- **NEVER** use destructive commands like `git reset --hard` or `git checkout --` unless specifically requested or approved by the user.\n- You struggle using the git interactive console. **ALWAYS** prefer using non-interactive git commands.\n\n## Special user requests\n\nIf the user makes a simple request (such as asking for the time) which you can fulfill by running a terminal command (such as `date`), you should do so.\n\nIf the user pastes an error description or a bug report, help them diagnose the root cause. You can try to reproduce it if it seems feasible with the available tools and skills.\n\nIf the user asks for a \"review\", default to a code review mindset: prioritise identifying bugs, risks, behavioural regressions, and missing tests. Findings must be the primary focus of the response - keep summaries or overviews brief and only after enumerating the issues. Present findings first (ordered by severity with file/line references), follow with open questions or assumptions, and offer a change-summary only as a secondary detail. If no findings are discovered, state that explicitly and mention any residual risks or testing gaps.\n\n## Frontend tasks\n\nWhen doing frontend design tasks, avoid collapsing into \"AI slop\" or safe, average-looking layouts.\n- Ensure the page loads properly on both desktop and mobile\n- For React code, prefer modern patterns including useEffectEvent, startTransition, and useDeferredValue when appropriate if used by the team. Do not add useMemo/useCallback by default unless already used; follow the repo's React Compiler guidance.\n- Overall: Avoid boilerplate layouts and interchangeable UI patterns. Vary themes, type families, and visual languages across outputs.\n\nException: If working within an existing website or design system, preserve the established patterns, structure, and visual language.\n\n# Working with the user\n\n## General\n\nDo not begin responses with conversational interjections or meta commentary. Avoid openers such as acknowledgements (\"Done —\", \"Got it\", \"Great question, \") or framing phrases.\n\nBalance conciseness to not overwhelm the user with appropriate detail for the request. Do not narrate abstractly; explain what you are doing and why.\n\nNever tell the user to \"save/copy this file\", the user is on the same machine and has access to the same files as you have.\n\n\n## Formatting rules\n\nYour responses are rendered as GitHub-flavored Markdown.\n\nNever use nested bullets. Keep lists flat (single level). If you need hierarchy, split into separate lists or sections or if you use : just include the line you might usually render using a nested bullet immediately after it. For numbered lists, only use the `1. 2. 3.` style markers (with a period), never `1)`.\n\nHeaders are optional, only use them when you think they are necessary. If you do use them, use short Title Case (1-3 words) wrapped in **…**. Don't add a blank line.\n\nUse inline code blocks for commands, paths, environment variables, function names, inline examples, keywords.\n\nCode samples or multi-line snippets should be wrapped in fenced code blocks. Include a language tag when possible.\n\nDon’t use emojis or em dashes unless explicitly instructed.\n\n## Response channels\n\nUse commentary for short progress updates while working and final for the completed response.\n\n### `commentary` channel\n\nOnly use `commentary` for intermediary updates. These are short updates while you are working, they are NOT final answers. Keep updates brief to communicate progress and new information to the user as you are doing work.\n\nSend updates when they add meaningful new information: a discovery, a tradeoff, a blocker, a substantial plan, or the start of a non-trivial edit or verification step.\n\nDo not narrate routine reads, searches, obvious next steps, or minor confirmations. Combine related progress into a single update.\n\nDo not begin responses with conversational interjections or meta commentary. Avoid openers such as acknowledgements (\"Done —\", \"Got it\", \"Great question\") or framing phrases.\n\nBefore substantial work, send a short update describing your first step. Before editing files, send an update describing the edit.\n\nAfter you have sufficient context, and the work is substantial you can provide a longer plan (this is the only user update that may be longer than 2 sentences and can contain formatting).\n\n### `final` channel\n\nUse final for the completed response.\n\nStructure your final response if necessary. The complexity of the answer should match the task. If the task is simple, your answer should be a one-liner. Order sections from general to specific to supporting.\n\nIf the user asks for a code explanation, include code references. For simple tasks, just state the outcome without heavy formatting.\n\nFor large or complex changes, lead with the solution, then explain what you did and why. For casual chat, just chat. If something couldn’t be done (tests, builds, etc.), say so. Suggest next steps only when they are natural and useful; if you list options, use numbered items.\n\nYou are powered by the model named gpt-5.4. The exact model ID is openai/gpt-5.4\nHere is some useful information about the environment you are running in:\n<env>\n  Working directory: /Users/ljw/code/reverse-engineer-opencode/opencode-trace\n  Workspace root folder: /Users/ljw/code/reverse-engineer-opencode/opencode-trace\n  Is directory a git repo: yes\n  Platform: darwin\n  Today's date: Wed Apr 08 2026\n</env>\n<directories>\n  \n</directories>\nSkills provide specialized instructions and workflows for specific tasks.\nUse the skill tool to load a skill when a task matches its description.\nNo skills are currently available.\nInstructions from: /Users/ljw/code/reverse-engineer-opencode/opencode-trace/AGENTS.md\n# opencode-trace\n\nThis is a plugin designed to capture the raw json requests sent to the LLM, and the raw responses back (after streaming-delta consolidation). It saves them into ~/opencode-trace\n- For end-to-end build+install and testing: `npm run build` then `cp dist/opencode-trace.ts ~/.config/opencode/plugins/`, and then just run `opencode run --dangerously-skip-permissions \"why is grass green?\"` to test it. This will re-use the existing opencode API key / oauth credentials.\n- For development, no build+install is needed. Undo the previous global install `rm ~/.config/opencode/plugins/opencode-trace.ts` and then `OPENCODE_CONFIG=\"/absolute/path/to/opencode-trace/integration-test.json\" opencode run --dangerously-skip-permissions \"why is the sky blue?\"`\n- For development: `npm install` once, then `npm run typecheck` or `npm run lint`\n\nInstructions from: /Users/ljw/.claude/CLAUDE.md\n## Codebase style and guidelines\n\nCoding style: All code must also be clean, documented and minimal. That means:\n- Keep It Simple Stupid (KISS) by reducing the \"Concept Count\". That means, strive for fewer functions or methods, fewer helpers. If a helper is only called by a single callsite, then prefer to inline it into the caller.\n- At the same time, Don't Repeat Yourself (DRY)\n- There is a tension between KISS and DRY. If you find yourself in a situation where you're forced to make a helper method just to avoid repeating yourself, the best solution is to look for a way to avoid even having to do the complicated work at all.\n- If some code looks heavyweight, perhaps with lots of conditionals, then think harder for a more elegant way of achieving it.\n- Prefer functional-style code, where variables are immutable \"const\" and there's less branching. Prefer to use ternary expressions \"b ? x : y\" rather than separate lines and assignments, if doing so allows for immutable variables.\n- Code should have comments, and functions should have docstrings. The best comments are ones that introduce invariants, or prove that invariants are being upheld, or indicate which invariants the code relies upon.\n\n\n## Agent interaction rules\n\n- If the user asks a question \"how would we do XYZ\", then they are not asking you to write code! They're asking a question and you must answer with a response. Only write code if they explicitly asked for it, e.g. \"please do XYZ\".\n- Do not attempt to fix pre-existing type errors. The type system is the most important part of the codebase, and must remain under the control of the user. Type errors are merely a \"todo\" list to help the user decide when and what to do next.\n\n\n## Backgrounder documents\n\nRead these documents in full if you are asked to work on the relevant software\n- ~/notes/users/ljw/devmate-code-overview.md -- about \"Devmate\", the AI sidebar agent that my team works on, including ClaudeAgent\n- ~/notes/users/ljw/history-and-slash-commands.md -- how Conversation History and Slash-commands are done in Devmate\n- ~/notes/users/ljw/launcher.md -- about the \"launcher/wrapper\", how Claude gets launched at Meta (including by Devmate's ClaudeAgent)\n","include":["reasoning.encrypted_content"],"prompt_cache_key":"ses_placeholder_example","reasoning":{"effort":"high","summary":"auto"},"tools":[{"type":"function","name":"bash","description":"Executes a given bash command in a persistent shell session with optional timeout, ensuring proper handling and security measures.\n\nBe aware: OS: darwin, Shell: bash\n\nAll commands run in the current working directory by default. Use the `workdir` parameter if you need to run a command in a different directory. AVOID using `cd <directory> && <command>` patterns - use `workdir` instead.\n\nIMPORTANT: This tool is for terminal operations like git, npm, docker, etc. DO NOT use it for file operations (reading, writing, editing, searching, finding files) - use the specialized tools for this instead.\n\nBefore executing the command, please follow these steps:\n\n1. Directory Verification:\n   - If the command will create new directories or files, first use `ls` to verify the parent directory exists and is the correct location\n   - For example, before running \"mkdir foo/bar\", first use `ls foo` to check that \"foo\" exists and is the intended parent directory\n\n2. Command Execution:\n   - Always quote file paths that contain spaces with double quotes (e.g., rm \"path with spaces/file.txt\")\n   - Examples of proper quoting:\n     - mkdir \"/Users/name/My Documents\" (correct)\n     - mkdir /Users/name/My Documents (incorrect - will fail)\n     - python \"/path/with spaces/script.py\" (correct)\n     - python /path/with spaces/script.py (incorrect - will fail)\n   - After ensuring proper quoting, execute the command.\n   - Capture the output of the command.\n\nUsage notes:\n  - The command argument is required.\n  - You can specify an optional timeout in milliseconds. If not specified, commands will time out after 120000ms (2 minutes).\n  - It is very helpful if you write a clear, concise description of what this command does in 5-10 words.\n  - If the output exceeds 2000 lines or 51200 bytes, it will be truncated and the full output will be written to a file. You can use Read with offset/limit to read specific sections or Grep to search the full content. Do NOT use `head`, `tail`, or other truncation commands to limit output; the full output will already be captured to a file for more precise searching.\n\n  - Avoid using Bash with the `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or when these commands are truly necessary for the task. Instead, always prefer using the dedicated tools for these commands:\n    - File search: Use Glob (NOT find or ls)\n    - Content search: Use Grep (NOT grep or rg)\n    - Read files: Use Read (NOT cat/head/tail)\n    - Edit files: Use Edit (NOT sed/awk)\n    - Write files: Use Write (NOT echo >/cat <<EOF)\n    - Communication: Output text directly (NOT echo/printf)\n  - When issuing multiple commands:\n    - If the commands are independent and can run in parallel, make multiple Bash tool calls in a single message. For example, if you need to run \"git status\" and \"git diff\", send a single message with two Bash tool calls in parallel.\n    - If the commands depend on each other and must run sequentially, use a single Bash call with '&&' to chain them together (e.g., `git add . && git commit -m \"message\" && git push`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before Bash for git operations, or git add before git commit), run these operations sequentially instead.\n    - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail\n    - DO NOT use newlines to separate commands (newlines are ok in quoted strings)\n  - AVOID using `cd <directory> && <command>`. Use the `workdir` parameter to change directories instead.\n    <good-example>\n    Use workdir=\"/foo/bar\" with command: pytest tests\n    </good-example>\n    <bad-example>\n    cd /foo/bar && pytest tests\n    </bad-example>\n\n# Committing changes with git\n\nOnly create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:\n\nGit Safety Protocol:\n- NEVER update the git config\n- NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them\n- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it\n- NEVER run force push to main/master, warn the user if they request it\n- Avoid git commit --amend. ONLY use --amend when ALL conditions are met:\n  (1) User explicitly requested amend, OR commit SUCCEEDED but pre-commit hook auto-modified files that need including\n  (2) HEAD commit was created by you in this conversation (verify: git log -1 --format='%an %ae')\n  (3) Commit has NOT been pushed to remote (verify: git status shows \"Your branch is ahead\")\n- CRITICAL: If commit FAILED or was REJECTED by hook, NEVER amend - fix the issue and create a NEW commit\n- CRITICAL: If you already pushed to remote, NEVER amend unless user explicitly requests it (requires force push)\n- NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive.\n\n1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the Bash tool:\n  - Run a git status command to see all untracked files.\n  - Run a git diff command to see both staged and unstaged changes that will be committed.\n  - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.\n2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:\n  - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. \"add\" means a wholly new feature, \"update\" means an enhancement to an existing feature, \"fix\" means a bug fix, etc.).\n  - Do not commit files that likely contain secrets (.env, credentials.json, etc.). Warn the user if they specifically request to commit those files\n  - Draft a concise (1-2 sentences) commit message that focuses on the \"why\" rather than the \"what\"\n  - Ensure it accurately reflects the changes and their purpose\n3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands:\n   - Add relevant untracked files to the staging area.\n   - Create the commit with a message\n   - Run git status after the commit completes to verify success.\n   Note: git status depends on the commit completing, so run it sequentially after the commit.\n4. If the commit fails due to pre-commit hook, fix the issue and create a NEW commit (see amend rules above)\n\nImportant notes:\n- NEVER run additional commands to read or explore code, besides git bash commands\n- NEVER use the TodoWrite or Task tools\n- DO NOT push to the remote repository unless the user explicitly asks you to do so\n- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.\n- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit\n\n# Creating pull requests\nUse the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a GitHub URL use the gh command to get the information needed.\n\nIMPORTANT: When the user asks you to create a pull request, follow these steps carefully:\n\n1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel using the Bash tool, in order to understand the current state of the branch since it diverged from the main branch:\n   - Run a git status command to see all untracked files\n   - Run a git diff command to see both staged and unstaged changes that will be committed\n   - Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote\n   - Run a git log command and `git diff [base-branch]...HEAD` to understand the full commit history for the current branch (from the time it diverged from the base branch)\n2. Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request!!!), and draft a pull request summary\n3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands in parallel:\n   - Create new branch if needed\n   - Push to remote with -u flag if needed\n   - Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.\n<example>\ngh pr create --title \"the pr title\" --body \"$(cat <<'EOF'\n## Summary\n<1-3 bullet points>\n</example>\n\nImportant:\n- DO NOT use the TodoWrite or Task tools\n- Return the PR URL when you're done, so the user can see it\n\n# Other common operations\n- View comments on a GitHub PR: gh api repos/foo/bar/pulls/123/comments\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"command":{"description":"The command to execute","type":"string"},"timeout":{"description":"Optional timeout in milliseconds","type":"number"},"workdir":{"description":"The working directory to run the command in. Defaults to the current directory. Use this instead of 'cd' commands.","type":"string"},"description":{"description":"Clear, concise description of what this command does in 5-10 words. Examples:\nInput: ls\nOutput: Lists files in current directory\n\nInput: git status\nOutput: Shows working tree status\n\nInput: npm install\nOutput: Installs package dependencies\n\nInput: mkdir foo\nOutput: Creates directory 'foo'","type":"string"}},"required":["command","description"],"additionalProperties":false}},{"type":"function","name":"read","description":"Read a file or directory from the local filesystem. If the path does not exist, an error is returned.\n\nUsage:\n- The filePath parameter should be an absolute path.\n- By default, this tool returns up to 2000 lines from the start of the file.\n- The offset parameter is the line number to start from (1-indexed).\n- To read later sections, call this tool again with a larger offset.\n- Use the grep tool to find specific content in large files or files with long lines.\n- If you are unsure of the correct file path, use the glob tool to look up filenames by glob pattern.\n- Contents are returned with each line prefixed by its line number as `<line>: <content>`. For example, if a file has contents \"foo\\n\", you will receive \"1: foo\\n\". For directories, entries are returned one per line (without line numbers) with a trailing `/` for subdirectories.\n- Any line longer than 2000 characters is truncated.\n- Call this tool in parallel when you know there are multiple files you want to read.\n- Avoid tiny repeated slices (30 line chunks). If you need more context, read a larger window.\n- This tool can read image files and PDFs and return them as file attachments.\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"filePath":{"description":"The absolute path to the file or directory to read","type":"string"},"offset":{"description":"The line number to start reading from (1-indexed)","type":"number"},"limit":{"description":"The maximum number of lines to read (defaults to 2000)","type":"number"}},"required":["filePath"],"additionalProperties":false}},{"type":"function","name":"glob","description":"- Fast file pattern matching tool that works with any codebase size\n- Supports glob patterns like \"**/*.js\" or \"src/**/*.ts\"\n- Returns matching file paths sorted by modification time\n- Use this tool when you need to find files by name patterns\n- When you are doing an open-ended search that may require multiple rounds of globbing and grepping, use the Task tool instead\n- You have the capability to call multiple tools in a single response. It is always better to speculatively perform multiple searches as a batch that are potentially useful.\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"pattern":{"description":"The glob pattern to match files against","type":"string"},"path":{"description":"The directory to search in. If not specified, the current working directory will be used. IMPORTANT: Omit this field to use the default directory. DO NOT enter \"undefined\" or \"null\" - simply omit it for the default behavior. Must be a valid directory path if provided.","type":"string"}},"required":["pattern"],"additionalProperties":false}},{"type":"function","name":"grep","description":"- Fast content search tool that works with any codebase size\n- Searches file contents using regular expressions\n- Supports full regex syntax (eg. \"log.*Error\", \"function\\s+\\w+\", etc.)\n- Filter files by pattern with the include parameter (eg. \"*.js\", \"*.{ts,tsx}\")\n- Returns file paths and line numbers with at least one match sorted by modification time\n- Use this tool when you need to find files containing specific patterns\n- If you need to identify/count the number of matches within files, use the Bash tool with `rg` (ripgrep) directly. Do NOT use `grep`.\n- When you are doing an open-ended search that may require multiple rounds of globbing and grepping, use the Task tool instead\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"pattern":{"description":"The regex pattern to search for in file contents","type":"string"},"path":{"description":"The directory to search in. Defaults to the current working directory.","type":"string"},"include":{"description":"File pattern to include in the search (e.g. \"*.js\", \"*.{ts,tsx}\")","type":"string"}},"required":["pattern"],"additionalProperties":false}},{"type":"function","name":"task","description":"Available agent types and the tools they have access to:\n- explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. \"src/components/**/*.tsx\"), search code for keywords (eg. \"API endpoints\"), or answer questions about the codebase (eg. \"how do API endpoints work?\"). When calling this agent, specify the desired thoroughness level: \"quick\" for basic searches, \"medium\" for moderate exploration, or \"very thorough\" for comprehensive analysis across multiple locations and naming conventions.\n- general: General-purpose agent for researching complex questions and executing multi-step tasks. Use this agent to execute multiple units of work in parallel.\nAvailable agent types and the tools they have access to:\n- explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. \"src/components/**/*.tsx\"), search code for keywords (eg. \"API endpoints\"), or answer questions about the codebase (eg. \"how do API endpoints work?\"). When calling this agent, specify the desired thoroughness level: \"quick\" for basic searches, \"medium\" for moderate exploration, or \"very thorough\" for comprehensive analysis across multiple locations and naming conventions.\n- general: General-purpose agent for researching complex questions and executing multi-step tasks. Use this agent to execute multiple units of work in parallel.","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"description":{"description":"A short (3-5 words) description of the task","type":"string"},"prompt":{"description":"The task for the agent to perform","type":"string"},"subagent_type":{"description":"The type of specialized agent to use for this task","type":"string"},"task_id":{"description":"This should only be set if you mean to resume a previous task (you can pass a prior task_id and the task will continue the same subagent session as before instead of creating a fresh one)","type":"string"},"command":{"description":"The command that triggered this task","type":"string"}},"required":["description","prompt","subagent_type"],"additionalProperties":false}},{"type":"function","name":"webfetch","description":"- Fetches content from a specified URL\n- Takes a URL and optional format as input\n- Fetches the URL content, converts to requested format (markdown by default)\n- Returns the content in the specified format\n- Use this tool when you need to retrieve and analyze web content\n\nUsage notes:\n  - IMPORTANT: if another tool is present that offers better web fetching capabilities, is more targeted to the task, or has fewer restrictions, prefer using that tool instead of this one.\n  - The URL must be a fully-formed valid URL\n  - HTTP URLs will be automatically upgraded to HTTPS\n  - Format options: \"markdown\" (default), \"text\", or \"html\"\n  - This tool is read-only and does not modify any files\n  - Results may be summarized if the content is very large\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"url":{"description":"The URL to fetch content from","type":"string"},"format":{"description":"The format to return the content in (text, markdown, or html). Defaults to markdown.","default":"markdown","type":"string","enum":["text","markdown","html"]},"timeout":{"description":"Optional timeout in seconds (max 120)","type":"number"}},"required":["url","format"],"additionalProperties":false}},{"type":"function","name":"todowrite","description":"Use this tool to create and manage a structured task list for your current coding session. This helps you track progress, organize complex tasks, and demonstrate thoroughness to the user.\nIt also helps the user understand the progress of the task and overall progress of their requests.\n\n## When to Use This Tool\nUse this tool proactively in these scenarios:\n\n1. Complex multistep tasks - When a task requires 3 or more distinct steps or actions\n2. Non-trivial and complex tasks - Tasks that require careful planning or multiple operations\n3. User explicitly requests todo list - When the user directly asks you to use the todo list\n4. User provides multiple tasks - When users provide a list of things to be done (numbered or comma-separated)\n5. After receiving new instructions - Immediately capture user requirements as todos. Feel free to edit the todo list based on new information.\n6. After completing a task - Mark it complete and add any new follow-up tasks\n7. When you start working on a new task, mark the todo as in_progress. Ideally you should only have one todo as in_progress at a time. Complete existing tasks before starting new ones.\n\n## When NOT to Use This Tool\n\nSkip using this tool when:\n1. There is only a single, straightforward task\n2. The task is trivial and tracking it provides no organizational benefit\n3. The task can be completed in less than 3 trivial steps\n4. The task is purely conversational or informational\n\nNOTE that you should not use this tool if there is only one trivial task to do. In this case you are better off just doing the task directly.\n\n## Examples of When to Use the Todo List\n\n<example>\nUser: I want to add a dark mode toggle to the application settings. Make sure you run the tests and build when you're done!\nAssistant: I'll help add a dark mode toggle to your application settings. Let me create a todo list to track this implementation.\n*Creates todo list with the following items:*\n1. Create dark mode toggle component in Settings page\n2. Add dark mode state management (context/store)\n3. Implement CSS-in-JS styles for dark theme\n4. Update existing components to support theme switching\n5. Run tests and build process, addressing any failures or errors that occur\n*Begins working on the first task*\n\n<reasoning>\nThe assistant used the todo list because:\n1. Adding dark mode is a multi-step feature requiring UI, state management, and styling changes\n2. The user explicitly requested tests and build be run afterward\n3. The assistant inferred that tests and build need to pass by adding \"Ensure tests and build succeed\" as the final task\n</reasoning>\n</example>\n\n<example>\nUser: Help me rename the function getCwd to getCurrentWorkingDirectory across my project\nAssistant: Let me first search through your codebase to find all occurrences of 'getCwd'.\n*Uses grep or search tools to locate all instances of getCwd in the codebase*\nAssistant: I've found 15 instances of 'getCwd' across 8 different files. Let me create a todo list to track these changes.\n*Creates todo list with specific items for each file that needs updating*\n\n<reasoning>\nThe assistant used the todo list because:\n1. First, the assistant searched to understand the scope of the task\n2. Upon finding multiple occurrences across different files, it determined this was a complex task with multiple steps\n3. The todo list helps ensure every instance is tracked and updated systematically\n4. This approach prevents missing any occurrences and maintains code consistency\n</reasoning>\n</example>\n\n\n<example>\nUser: I need to implement these features for my e-commerce site: user registration, product catalog, shopping cart, and checkout flow.\nAssistant: I'll help implement these features. First, let's add all the features to the todo list.\n*Creates a todo list breaking down each feature into specific tasks based on the project architecture*\nAssistant: Let's start with user registration. This will involve creating database models, API endpoints, and frontend forms that integrate with your existing authentication system.\n\n<reasoning>\nThe assistant used the todo list because:\n1. The user provided multiple complex features to implement in a comma separated list\n2. The todo list helps organize these large features into manageable tasks\n3. This approach allows for tracking progress across the entire implementation\n</reasoning>\n</example>\n\n<example>\nUser: Can you help optimize my React application? It's rendering slowly and has performance issues.</user>\nAssistant: I'll help optimize your React application. First, let me examine your codebase to identify potential performance bottlenecks.\n*Reviews component structure, render patterns, state management, and data fetching*\nAssistant: After analyzing your codebase, I've identified several performance issues. Let me create a todo list to track our optimization efforts.\n*Creates todo list with items like: 1) Implement memoization for expensive calculations in ProductList, 2) Add virtualization for long lists in Dashboard, 3) Optimize image loading in Gallery component, 4) Fix state update loops in ShoppingCart, 5) Review bundle size and implement code splitting*\nLet's start by implementing memoization for the expensive calculations in your ProductList component.</assistant>\n\n<reasoning>\nThe assistant used the todo list because:\n1. First, the assistant examined the codebase to identify specific performance issues\n2. Based on this analysis, it identified multiple optimization opportunities\n3. Performance optimization is a non-trivial task requiring multiple steps\n4. The todo list helps methodically track improvements across different components\n5. This systematic approach ensures all performance bottlenecks are addressed\n</reasoning>\n</example>\n\n## Examples of When NOT to Use the Todo List\n\n<example>\nUser: How do I print 'Hello World' in Python?\nAssistant: In Python, you can print \"Hello World\" with this simple code:\n\npython\nprint(\"Hello World\")\n\nThis will output the text \"Hello World\" to the console when executed.</assistant>\n\n<reasoning>\nThe assistant did not use the todo list because this is a single, trivial task that can be completed in one step. There's no need to track multiple tasks or steps for such a straightforward request.\n</reasoning>\n</example>\n\n<example>\nUser: What does the git status command do?\nAssistant: The git status command shows the current state of your working directory and staging area. It displays which changes have been staged, which haven't, and which files aren't being tracked by Git. This is a fundamental command for understanding the current state of your repository before making commits.\n\n<reasoning>\nThe assistant did not use the todo list because this is an informational request with no actual coding task to complete. The user is simply asking for an explanation, not for the assistant to perform multiple steps or tasks.\n</reasoning>\n</example>\n\n<example>\nUser: Can you add a comment to the calculateTotal function to explain what it does?\nAssistant: Sure, let me add a comment to the calculateTotal function to explain what it does.\n* Uses the Edit tool to add a comment to the calculateTotal function *\n\n<reasoning>\nThe assistant did not use the todo list because this is a single, straightforward task confined to one location in the code. Adding a comment doesn't require tracking multiple steps or systematic organization.\n</reasoning>\n</example>\n\n<example>\nUser: Run npm install for me and tell me what happens.\nAssistant: I'll run the npm install command for you.\n\n*Executes: npm install*\n\nThe command completed successfully. Here's the output:\n[Output of npm install command]\n\nAll dependencies have been installed according to your package.json file.\n\n<reasoning>\nThe assistant did not use the todo list because this is a single command execution with immediate results. There are no multiple steps to track or organize, making the todo list unnecessary for this straightforward task.\n</reasoning>\n</example>\n\n## Task States and Management\n\n1. **Task States**: Use these states to track progress:\n   - pending: Task not yet started\n   - in_progress: Currently working on (limit to ONE task at a time)\n   - completed: Task finished successfully\n   - cancelled: Task no longer needed\n\n2. **Task Management**:\n   - Update task status in real-time as you work\n   - Mark tasks complete IMMEDIATELY after finishing (don't batch completions)\n   - Only have ONE task in_progress at any time\n   - Complete current tasks before starting new ones\n   - Cancel tasks that become irrelevant\n\n3. **Task Breakdown**:\n   - Create specific, actionable items\n   - Break complex tasks into smaller, manageable steps\n   - Use clear, descriptive task names\n\nWhen in doubt, use this tool. Being proactive with task management demonstrates attentiveness and ensures you complete all requirements successfully.\n\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"todos":{"description":"The updated todo list","type":"array","items":{"type":"object","properties":{"content":{"description":"Brief description of the task","type":"string"},"status":{"description":"Current status of the task: pending, in_progress, completed, cancelled","type":"string"},"priority":{"description":"Priority level of the task: high, medium, low","type":"string"}},"required":["content","status","priority"],"additionalProperties":false}}},"required":["todos"],"additionalProperties":false}},{"type":"function","name":"skill","description":"Load a specialized skill that provides domain-specific instructions and workflows. No skills are currently available.\nNo skills are currently available.","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"name":{"description":"The name of the skill from available_skills","type":"string"}},"required":["name"],"additionalProperties":false}},{"type":"function","name":"apply_patch","description":"Use the `apply_patch` tool to edit files. Your patch language is a stripped‑down, file‑oriented diff format designed to be easy to parse and safe to apply. You can think of it as a high‑level envelope:\n\n*** Begin Patch\n[ one or more file sections ]\n*** End Patch\n\nWithin that envelope, you get a sequence of file operations.\nYou MUST include a header to specify the action you are taking.\nEach operation starts with one of three headers:\n\n*** Add File: <path> - create a new file. Every following line is a + line (the initial contents).\n*** Delete File: <path> - remove an existing file. Nothing follows.\n*** Update File: <path> - patch an existing file in place (optionally with a rename).\n\nExample patch:\n\n```\n*** Begin Patch\n*** Add File: hello.txt\n+Hello world\n*** Update File: src/app.py\n*** Move to: src/main.py\n@@ def greet():\n-print(\"Hi\")\n+print(\"Hello, world!\")\n*** Delete File: obsolete.txt\n*** End Patch\n```\n\nIt is important to remember:\n\n- You must include a header with your intended action (Add/Delete/Update)\n- You must prefix new lines with `+` even when creating a new file\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"patchText":{"description":"The full patch text that describes all changes to be made","type":"string"}},"required":["patchText"],"additionalProperties":false}},{"type":"function","name":"question","description":"Use this tool when you need to ask the user questions during execution. This allows you to:\n1. Gather user preferences or requirements\n2. Clarify ambiguous instructions\n3. Get decisions on implementation choices as you work\n4. Offer choices to the user about what direction to take.\n\nUsage notes:\n- When `custom` is enabled (default), a \"Type your own answer\" option is added automatically; don't include \"Other\" or catch-all options\n- Answers are returned as arrays of labels; set `multiple: true` to allow selecting more than one\n- If you recommend a specific option, make that the first option in the list and add \"(Recommended)\" at the end of the label\n","parameters":{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","properties":{"questions":{"description":"Questions to ask","type":"array","items":{"type":"object","properties":{"question":{"description":"Complete question","type":"string"},"header":{"description":"Very short label (max 30 chars)","type":"string"},"options":{"description":"Available choices","type":"array","items":{"ref":"QuestionOption","type":"object","properties":{"label":{"description":"Display text (1-5 words, concise)","type":"string"},"description":{"description":"Explanation of choice","type":"string"}},"required":["label","description"],"additionalProperties":false}},"multiple":{"description":"Allow selecting multiple choices","type":"boolean"}},"required":["question","header","options"],"additionalProperties":false}}},"required":["questions"],"additionalProperties":false}}],"tool_choice":"auto","stream":true,"_id":2,"_purpose":"","_url":"https://chatgpt.com/backend-api/codex/responses","_kind":"request","_ts":"2026-04-09T05:12:26.745Z"}
{"object":"response","id":"resp_0cf713ea40ca6f830169d7353abc188194946e214e9ca3ba82","created_at":1775711546,"status":"completed","background":false,"completed_at":1775711548,"error":null,"frequency_penalty":0,"incomplete_details":null,"instructions":"You are a title generator. You output ONLY a thread title. Nothing else.\n\n<task>\nGenerate a brief title that would help the user find this conversation later.\n\nFollow all rules in <rules>\nUse the <examples> so you know what a good title looks like.\nYour output must be:\n- A single line\n- ≤50 characters\n- No explanations\n</task>\n\n<rules>\n- you MUST use the same language as the user message you are summarizing\n- Title must be grammatically correct and read naturally - no word salad\n- Never include tool names in the title (e.g. \"read tool\", \"bash tool\", \"edit tool\")\n- Focus on the main topic or question the user needs to retrieve\n- Vary your phrasing - avoid repetitive patterns like always starting with \"Analyzing\"\n- When a file is mentioned, focus on WHAT the user wants to do WITH the file, not just that they shared it\n- Keep exact: technical terms, numbers, filenames, HTTP codes\n- Remove: the, this, my, a, an\n- Never assume tech stack\n- Never use tools\n- NEVER respond to questions, just generate a title for the conversation\n- The title should NEVER include \"summarizing\" or \"generating\" when generating a title\n- DO NOT SAY YOU CANNOT GENERATE A TITLE OR COMPLAIN ABOUT THE INPUT\n- Always output something meaningful, even if the input is minimal.\n- If the user message is short or conversational (e.g. \"hello\", \"lol\", \"what's up\", \"hey\"):\n  → create a title that reflects the user's tone or intent (such as Greeting, Quick check-in, Light chat, Intro message, etc.)\n</rules>\n\n<examples>\n\"debug 500 errors in production\" → Debugging production 500 errors\n\"refactor user service\" → Refactoring user service\n\"why is app.js failing\" → app.js failure investigation\n\"implement rate limiting\" → Rate limiting implementation\n\"how do I connect postgres to my API\" → Postgres API connection\n\"best practices for React hooks\" → React hooks best practices\n\"@src/auth.ts can you add refresh token support\" → Auth refresh token support\n\"@utils/parser.ts this is broken\" → Parser bug fix\n\"look at @config.json\" → Config review\n\"@App.tsx add dark mode toggle\" → Dark mode toggle in App\n</examples>\n","max_output_tokens":null,"max_tool_calls":null,"model":"gpt-5.4","output":[{"id":"rs_0cf713ea40ca6f830169d7353b35d88194a5ea47973e7f0b93","type":"reasoning","encrypted_content":"encrypted-placeholder","summary":[]},{"id":"msg_0cf713ea40ca6f830169d7353bceec8194abe7ca6aa0c9d595","type":"message","status":"completed","content":[{"type":"output_text","annotations":[],"logprobs":[],"text":"Short poems from a.txt and b.txt"}],"phase":"final_answer","role":"assistant"}],"parallel_tool_calls":true,"presence_penalty":0,"previous_response_id":null,"prompt_cache_key":"ses_placeholder_example","prompt_cache_retention":null,"reasoning":{"effort":"low","summary":null},"safety_identifier":"user-placeholder-example","service_tier":"default","store":false,"temperature":1,"text":{"format":{"type":"text"},"verbosity":"medium"},"tool_choice":"auto","tool_usage":{"image_gen":{"input_tokens":0,"input_tokens_details":{"image_tokens":0,"text_tokens":0},"output_tokens":0,"output_tokens_details":{"image_tokens":0,"text_tokens":0},"total_tokens":0},"web_search":{"num_requests":0}},"tools":[],"top_logprobs":0,"top_p":0.98,"truncation":"disabled","usage":{"input_tokens":555,"input_tokens_details":{"cached_tokens":0},"output_tokens":45,"output_tokens_details":{"reasoning_tokens":31},"total_tokens":600},"user":null,"metadata":{},"_id":1,"_purpose":"[meta]","_url":"https://chatgpt.com/backend-api/codex/responses","_kind":"response","_ts":"2026-04-09T05:12:28.155Z"}
{"object":"response","id":"resp_0de510da885b78b40169d7353b12708197b171192944035602","created_at":1775711547,"status":"completed","background":false,"completed_at":1775711552,"error":null,"frequency_penalty":0,"incomplete_details":null,"instructions":"You are OpenCode, You and the user share the same workspace and collaborate to achieve the user's goals.\n\nYou are a deeply pragmatic, effective software engineer. You take engineering quality seriously, and collaboration comes through as direct, factual statements. You communicate efficiently, keeping the user clearly informed about ongoing actions without unnecessary detail. You build context by examining the codebase first without making assumptions or jumping to conclusions. You think through the nuances of the code you encounter, and embody the mentality of a skilled senior software engineer.\n\n- When searching for text or files, prefer using Glob and Grep tools (they are powered by `rg`)\n- Parallelize tool calls whenever possible - especially file reads. Use `multi_tool_use.parallel` to parallelize tool calls and only this. Never chain together bash commands with separators like `echo \"====\";` as this renders to the user poorly.\n\n## Editing Approach\n\n- The best changes are often the smallest correct changes.\n- When you are weighing two correct approaches, prefer the more minimal one (less new names, helpers, tests, etc).\n- Keep things in one function unless composable or reusable\n- Do not add backward-compatibility code unless there is a concrete need, such as persisted data, shipped behavior, external consumers, or an explicit user requirement; if unclear, ask one short question instead of guessing.\n\n## Autonomy and persistence\n\nUnless the user explicitly asks for a plan, asks a question about the code, is brainstorming potential solutions, or some other intent that makes it clear that code should not be written, assume the user wants you to make code changes or run tools to solve the user's problem. In these cases, it's bad to output your proposed solution in a message, you should go ahead and actually implement the change. If you encounter challenges or blockers, you should attempt to resolve them yourself.\n\nPersist until the task is fully handled end-to-end within the current turn whenever feasible: do not stop at analysis or partial fixes; carry changes through implementation, verification, and a clear explanation of outcomes unless the user explicitly pauses or redirects you.\n\nIf you notice unexpected changes in the worktree or staging area that you did not make, continue with your task. NEVER revert, undo, or modify changes you did not make unless the user explicitly asks you to. There can be multiple agents or the user working in the same codebase concurrently.\n\n## Editing constraints\n\n- Default to ASCII when editing or creating files. Only introduce non-ASCII or other Unicode characters when there is a clear justification and the file already uses them.\n- Add succinct code comments that explain what is going on if code is not self-explanatory. You should not add comments like \"Assigns the value to the variable\", but a brief comment might be useful ahead of a complex code block that the user would otherwise have to spend time parsing out. Usage of these comments should be rare.\n- Always use apply_patch for manual code edits. Do not use cat or any other commands when creating or editing files. Formatting commands or bulk edits don't need to be done with apply_patch.\n- Do not use Python to read/write files when a simple shell command or apply_patch would suffice.\n- You may be in a dirty git worktree.\n  * NEVER revert existing changes you did not make unless explicitly requested, since these changes were made by the user.\n  * If asked to make a commit or code edits and there are unrelated changes to your work or changes that you didn't make in those files, don't revert those changes.\n  * If the changes are in files you've touched recently, you should read carefully and understand how you can work with the changes rather than reverting them.\n  * If the changes are in unrelated files, just ignore them and don't revert them.\n- Do not amend a commit unless explicitly requested to do so.\n- While you are working, you might notice unexpected changes that you didn't make. It's likely the user made them, or were autogenerated. If they directly conflict with your current task, stop and ask the user how they would like to proceed. Otherwise, focus on the task at hand.\n- **NEVER** use destructive commands like `git reset --hard` or `git checkout --` unless specifically requested or approved by the user.\n- You struggle using the git interactive console. **ALWAYS** prefer using non-interactive git commands.\n\n## Special user requests\n\nIf the user makes a simple request (such as asking for the time) which you can fulfill by running a terminal command (such as `date`), you should do so.\n\nIf the user pastes an error description or a bug report, help them diagnose the root cause. You can try to reproduce it if it seems feasible with the available tools and skills.\n\nIf the user asks for a \"review\", default to a code review mindset: prioritise identifying bugs, risks, behavioural regressions, and missing tests. Findings must be the primary focus of the response - keep summaries or overviews brief and only after enumerating the issues. Present findings first (ordered by severity with file/line references), follow with open questions or assumptions, and offer a change-summary only as a secondary detail. If no findings are discovered, state that explicitly and mention any residual risks or testing gaps.\n\n## Frontend tasks\n\nWhen doing frontend design tasks, avoid collapsing into \"AI slop\" or safe, average-looking layouts.\n- Ensure the page loads properly on both desktop and mobile\n- For React code, prefer modern patterns including useEffectEvent, startTransition, and useDeferredValue when appropriate if used by the team. Do not add useMemo/useCallback by default unless already used; follow the repo's React Compiler guidance.\n- Overall: Avoid boilerplate layouts and interchangeable UI patterns. Vary themes, type families, and visual languages across outputs.\n\nException: If working within an existing website or design system, preserve the established patterns, structure, and visual language.\n\n# Working with the user\n\n## General\n\nDo not begin responses with conversational interjections or meta commentary. Avoid openers such as acknowledgements (\"Done —\", \"Got it\", \"Great question, \") or framing phrases.\n\nBalance conciseness to not overwhelm the user with appropriate detail for the request. Do not narrate abstractly; explain what you are doing and why.\n\nNever tell the user to \"save/copy this file\", the user is on the same machine and has access to the same files as you have.\n\n\n## Formatting rules\n\nYour responses are rendered as GitHub-flavored Markdown.\n\nNever use nested bullets. Keep lists flat (single level). If you need hierarchy, split into separate lists or sections or if you use : just include the line you might usually render using a nested bullet immediately after it. For numbered lists, only use the `1. 2. 3.` style markers (with a period), never `1)`.\n\nHeaders are optional, only use them when you think they are necessary. If you do use them, use short Title Case (1-3 words) wrapped in **…**. Don't add a blank line.\n\nUse inline code blocks for commands, paths, environment variables, function names, inline examples, keywords.\n\nCode samples or multi-line snippets should be wrapped in fenced code blocks. Include a language tag when possible.\n\nDon’t use emojis or em dashes unless explicitly instructed.\n\n## Response channels\n\nUse commentary for short progress updates while working and final for the completed response.\n\n### `commentary` channel\n\nOnly use `commentary` for intermediary updates. These are short updates while you are working, they are NOT final answers. Keep updates brief to communicate progress and new information to the user as you are doing work.\n\nSend updates when they add meaningful new information: a discovery, a tradeoff, a blocker, a substantial plan, or the start of a non-trivial edit or verification step.\n\nDo not narrate routine reads, searches, obvious next steps, or minor confirmations. Combine related progress into a single update.\n\nDo not begin responses with conversational interjections or meta commentary. Avoid openers such as acknowledgements (\"Done —\", \"Got it\", \"Great question\") or framing phrases.\n\nBefore substantial work, send a short update describing your first step. Before editing files, send an update describing the edit.\n\nAfter you have sufficient context, and the work is substantial you can provide a longer plan (this is the only user update that may be longer than 2 sentences and can contain formatting).\n\n### `final` channel\n\nUse final for the completed response.\n\nStructure your final response if necessary. The complexity of the answer should match the task. If the task is simple, your answer should be a one-liner. Order sections from general to specific to supporting.\n\nIf the user asks for a code explanation, include code references. For simple tasks, just state the outcome without heavy formatting.\n\nFor large or complex changes, lead with the solution, then explain what you did and why. For casual chat, just chat. If something couldn’t be done (tests, builds, etc.), say so. Suggest next steps only when they are natural and useful; if you list options, use numbered items.\n\nYou are powered by the model named gpt-5.4. The exact model ID is openai/gpt-5.4\nHere is some useful information about the environment you are running in:\n<env>\n  Working directory: /Users/ljw/code/reverse-engineer-opencode/opencode-trace\n  Workspace root folder: /Users/ljw/code/reverse-engineer-opencode/opencode-trace\n  Is directory a git repo: yes\n  Platform: darwin\n  Today's date: Wed Apr 08 2026\n</env>\n<directories>\n  \n</directories>\nSkills provide specialized instructions and workflows for specific tasks.\nUse the skill tool to load a skill when a task matches its description.\nNo skills are currently available.\nInstructions from: /Users/ljw/code/reverse-engineer-opencode/opencode-trace/AGENTS.md\n# opencode-trace\n\nThis is a plugin designed to capture the raw json requests sent to the LLM, and the raw responses back (after streaming-delta consolidation). It saves them into ~/opencode-trace\n- For end-to-end build+install and testing: `npm run build` then `cp dist/opencode-trace.ts ~/.config/opencode/plugins/`, and then just run `opencode run --dangerously-skip-permissions \"why is grass green?\"` to test it. This will re-use the existing opencode API key / oauth credentials.\n- For development, no build+install is needed. Undo the previous global install `rm ~/.config/opencode/plugins/opencode-trace.ts` and then `OPENCODE_CONFIG=\"/absolute/path/to/opencode-trace/integration-test.json\" opencode run --dangerously-skip-permissions \"why is the sky blue?\"`\n- For development: `npm install` once, then `npm run typecheck` or `npm run lint`\n\nInstructions from: /Users/ljw/.claude/CLAUDE.md\n## Codebase style and guidelines\n\nCoding style: All code must also be clean, documented and minimal. That means:\n- Keep It Simple Stupid (KISS) by reducing the \"Concept Count\". That means, strive for fewer functions or methods, fewer helpers. If a helper is only called by a single callsite, then prefer to inline it into the caller.\n- At the same time, Don't Repeat Yourself (DRY)\n- There is a tension between KISS and DRY. If you find yourself in a situation where you're forced to make a helper method just to avoid repeating yourself, the best solution is to look for a way to avoid even having to do the complicated work at all.\n- If some code looks heavyweight, perhaps with lots of conditionals, then think harder for a more elegant way of achieving it.\n- Prefer functional-style code, where variables are immutable \"const\" and there's less branching. Prefer to use ternary expressions \"b ? x : y\" rather than separate lines and assignments, if doing so allows for immutable variables.\n- Code should have comments, and functions should have docstrings. The best comments are ones that introduce invariants, or prove that invariants are being upheld, or indicate which invariants the code relies upon.\n\n\n## Agent interaction rules\n\n- If the user asks a question \"how would we do XYZ\", then they are not asking you to write code! They're asking a question and you must answer with a response. Only write code if they explicitly asked for it, e.g. \"please do XYZ\".\n- Do not attempt to fix pre-existing type errors. The type system is the most important part of the codebase, and must remain under the control of the user. Type errors are merely a \"todo\" list to help the user decide when and what to do next.\n\n\n## Backgrounder documents\n\nRead these documents in full if you are asked to work on the relevant software\n- ~/notes/users/ljw/devmate-code-overview.md -- about \"Devmate\", the AI sidebar agent that my team works on, including ClaudeAgent\n- ~/notes/users/ljw/history-and-slash-commands.md -- how Conversation History and Slash-commands are done in Devmate\n- ~/notes/users/ljw/launcher.md -- about the \"launcher/wrapper\", how Claude gets launched at Meta (including by Devmate's ClaudeAgent)\n","max_output_tokens":null,"max_tool_calls":null,"model":"gpt-5.4","output":[{"id":"rs_0de510da885b78b40169d7353c62148197b2e0916bbda564a9","type":"reasoning","encrypted_content":"encrypted-placeholder","summary":[{"type":"summary_text","text":"**Planning file reading**\n\nI need to comply with the instructions to read two files. It seems straightforward, but I wonder if I should provide a brief update or commentary beforehand since the guidelines suggest it. Even if it feels trivial, I think it’s better to follow the instructions. I’ll use the Read tool and choose the correct absolute paths for the files. Since they’re independent, I might even parallelize the read operations. Let’s keep the commentary short and concise before proceeding!"}]},{"id":"msg_0de510da885b78b40169d7353fefbc819788f9ca49aa28c5a7","type":"message","status":"completed","content":[{"type":"output_text","annotations":[],"logprobs":[],"text":"Reading both files, then I’ll reply with two short poems."}],"phase":"commentary","role":"assistant"},{"id":"fc_0de510da885b78b40169d7354025388197a9fda33166613911","type":"function_call","status":"completed","arguments":"{\"filePath\":\"/Users/ljw/a.txt\",\"offset\":1,\"limit\":2000}","call_id":"call_eiReg4fQHaSXBAvu47HNoku9","name":"read"},{"id":"fc_0de510da885b78b40169d7354025488197937ec9932598b482","type":"function_call","status":"completed","arguments":"{\"filePath\":\"/Users/ljw/b.txt\",\"offset\":1,\"limit\":2000}","call_id":"call_gtGkYMQBFRlS5tKWDHlOl7CF","name":"read"}],"parallel_tool_calls":true,"presence_penalty":0,"previous_response_id":null,"prompt_cache_key":"ses_placeholder_example","prompt_cache_retention":null,"reasoning":{"effort":"high","summary":"detailed"},"safety_identifier":"user-placeholder-example","service_tier":"default","store":false,"temperature":1,"text":{"format":{"type":"text"},"verbosity":"low"},"tool_choice":"auto","tool_usage":{"image_gen":{"input_tokens":0,"input_tokens_details":{"image_tokens":0,"text_tokens":0},"output_tokens":0,"output_tokens_details":{"image_tokens":0,"text_tokens":0},"total_tokens":0},"web_search":{"num_requests":0}},"tools":[{"type":"function","description":"Executes a given bash command in a persistent shell session with optional timeout, ensuring proper handling and security measures.\n\nBe aware: OS: darwin, Shell: bash\n\nAll commands run in the current working directory by default. Use the `workdir` parameter if you need to run a command in a different directory. AVOID using `cd <directory> && <command>` patterns - use `workdir` instead.\n\nIMPORTANT: This tool is for terminal operations like git, npm, docker, etc. DO NOT use it for file operations (reading, writing, editing, searching, finding files) - use the specialized tools for this instead.\n\nBefore executing the command, please follow these steps:\n\n1. Directory Verification:\n   - If the command will create new directories or files, first use `ls` to verify the parent directory exists and is the correct location\n   - For example, before running \"mkdir foo/bar\", first use `ls foo` to check that \"foo\" exists and is the intended parent directory\n\n2. Command Execution:\n   - Always quote file paths that contain spaces with double quotes (e.g., rm \"path with spaces/file.txt\")\n   - Examples of proper quoting:\n     - mkdir \"/Users/name/My Documents\" (correct)\n     - mkdir /Users/name/My Documents (incorrect - will fail)\n     - python \"/path/with spaces/script.py\" (correct)\n     - python /path/with spaces/script.py (incorrect - will fail)\n   - After ensuring proper quoting, execute the command.\n   - Capture the output of the command.\n\nUsage notes:\n  - The command argument is required.\n  - You can specify an optional timeout in milliseconds. If not specified, commands will time out after 120000ms (2 minutes).\n  - It is very helpful if you write a clear, concise description of what this command does in 5-10 words.\n  - If the output exceeds 2000 lines or 51200 bytes, it will be truncated and the full output will be written to a file. You can use Read with offset/limit to read specific sections or Grep to search the full content. Do NOT use `head`, `tail`, or other truncation commands to limit output; the full output will already be captured to a file for more precise searching.\n\n  - Avoid using Bash with the `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or when these commands are truly necessary for the task. Instead, always prefer using the dedicated tools for these commands:\n    - File search: Use Glob (NOT find or ls)\n    - Content search: Use Grep (NOT grep or rg)\n    - Read files: Use Read (NOT cat/head/tail)\n    - Edit files: Use Edit (NOT sed/awk)\n    - Write files: Use Write (NOT echo >/cat <<EOF)\n    - Communication: Output text directly (NOT echo/printf)\n  - When issuing multiple commands:\n    - If the commands are independent and can run in parallel, make multiple Bash tool calls in a single message. For example, if you need to run \"git status\" and \"git diff\", send a single message with two Bash tool calls in parallel.\n    - If the commands depend on each other and must run sequentially, use a single Bash call with '&&' to chain them together (e.g., `git add . && git commit -m \"message\" && git push`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before Bash for git operations, or git add before git commit), run these operations sequentially instead.\n    - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail\n    - DO NOT use newlines to separate commands (newlines are ok in quoted strings)\n  - AVOID using `cd <directory> && <command>`. Use the `workdir` parameter to change directories instead.\n    <good-example>\n    Use workdir=\"/foo/bar\" with command: pytest tests\n    </good-example>\n    <bad-example>\n    cd /foo/bar && pytest tests\n    </bad-example>\n\n# Committing changes with git\n\nOnly create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:\n\nGit Safety Protocol:\n- NEVER update the git config\n- NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them\n- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it\n- NEVER run force push to main/master, warn the user if they request it\n- Avoid git commit --amend. ONLY use --amend when ALL conditions are met:\n  (1) User explicitly requested amend, OR commit SUCCEEDED but pre-commit hook auto-modified files that need including\n  (2) HEAD commit was created by you in this conversation (verify: git log -1 --format='%an %ae')\n  (3) Commit has NOT been pushed to remote (verify: git status shows \"Your branch is ahead\")\n- CRITICAL: If commit FAILED or was REJECTED by hook, NEVER amend - fix the issue and create a NEW commit\n- CRITICAL: If you already pushed to remote, NEVER amend unless user explicitly requests it (requires force push)\n- NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive.\n\n1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the Bash tool:\n  - Run a git status command to see all untracked files.\n  - Run a git diff command to see both staged and unstaged changes that will be committed.\n  - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.\n2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:\n  - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. \"add\" means a wholly new feature, \"update\" means an enhancement to an existing feature, \"fix\" means a bug fix, etc.).\n  - Do not commit files that likely contain secrets (.env, credentials.json, etc.). Warn the user if they specifically request to commit those files\n  - Draft a concise (1-2 sentences) commit message that focuses on the \"why\" rather than the \"what\"\n  - Ensure it accurately reflects the changes and their purpose\n3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands:\n   - Add relevant untracked files to the staging area.\n   - Create the commit with a message\n   - Run git status after the commit completes to verify success.\n   Note: git status depends on the commit completing, so run it sequentially after the commit.\n4. If the commit fails due to pre-commit hook, fix the issue and create a NEW commit (see amend rules above)\n\nImportant notes:\n- NEVER run additional commands to read or explore code, besides git bash commands\n- NEVER use the TodoWrite or Task tools\n- DO NOT push to the remote repository unless the user explicitly asks you to do so\n- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.\n- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit\n\n# Creating pull requests\nUse the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a GitHub URL use the gh command to get the information needed.\n\nIMPORTANT: When the user asks you to create a pull request, follow these steps carefully:\n\n1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel using the Bash tool, in order to understand the current state of the branch since it diverged from the main branch:\n   - Run a git status command to see all untracked files\n   - Run a git diff command to see both staged and unstaged changes that will be committed\n   - Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote\n   - Run a git log command and `git diff [base-branch]...HEAD` to understand the full commit history for the current branch (from the time it diverged from the base branch)\n2. Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request!!!), and draft a pull request summary\n3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands in parallel:\n   - Create new branch if needed\n   - Push to remote with -u flag if needed\n   - Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.\n<example>\ngh pr create --title \"the pr title\" --body \"$(cat <<'EOF'\n## Summary\n<1-3 bullet points>\n</example>\n\nImportant:\n- DO NOT use the TodoWrite or Task tools\n- Return the PR URL when you're done, so the user can see it\n\n# Other common operations\n- View comments on a GitHub PR: gh api repos/foo/bar/pulls/123/comments\n","name":"bash","parameters":{"type":"object","properties":{"command":{"description":"The command to execute","type":"string"},"timeout":{"description":"Optional timeout in milliseconds","type":"number"},"workdir":{"description":"The working directory to run the command in. Defaults to the current directory. Use this instead of 'cd' commands.","type":"string"},"description":{"description":"Clear, concise description of what this command does in 5-10 words. Examples:\nInput: ls\nOutput: Lists files in current directory\n\nInput: git status\nOutput: Shows working tree status\n\nInput: npm install\nOutput: Installs package dependencies\n\nInput: mkdir foo\nOutput: Creates directory 'foo'","type":"string"}},"required":["command","timeout","workdir","description"],"additionalProperties":false},"strict":true},{"type":"function","description":"Read a file or directory from the local filesystem. If the path does not exist, an error is returned.\n\nUsage:\n- The filePath parameter should be an absolute path.\n- By default, this tool returns up to 2000 lines from the start of the file.\n- The offset parameter is the line number to start from (1-indexed).\n- To read later sections, call this tool again with a larger offset.\n- Use the grep tool to find specific content in large files or files with long lines.\n- If you are unsure of the correct file path, use the glob tool to look up filenames by glob pattern.\n- Contents are returned with each line prefixed by its line number as `<line>: <content>`. For example, if a file has contents \"foo\\n\", you will receive \"1: foo\\n\". For directories, entries are returned one per line (without line numbers) with a trailing `/` for subdirectories.\n- Any line longer than 2000 characters is truncated.\n- Call this tool in parallel when you know there are multiple files you want to read.\n- Avoid tiny repeated slices (30 line chunks). If you need more context, read a larger window.\n- This tool can read image files and PDFs and return them as file attachments.\n","name":"read","parameters":{"type":"object","properties":{"filePath":{"description":"The absolute path to the file or directory to read","type":"string"},"offset":{"description":"The line number to start reading from (1-indexed)","type":"number"},"limit":{"description":"The maximum number of lines to read (defaults to 2000)","type":"number"}},"required":["filePath","offset","limit"],"additionalProperties":false},"strict":true},{"type":"function","description":"- Fast file pattern matching tool that works with any codebase size\n- Supports glob patterns like \"**/*.js\" or \"src/**/*.ts\"\n- Returns matching file paths sorted by modification time\n- Use this tool when you need to find files by name patterns\n- When you are doing an open-ended search that may require multiple rounds of globbing and grepping, use the Task tool instead\n- You have the capability to call multiple tools in a single response. It is always better to speculatively perform multiple searches as a batch that are potentially useful.\n","name":"glob","parameters":{"type":"object","properties":{"pattern":{"description":"The glob pattern to match files against","type":"string"},"path":{"description":"The directory to search in. If not specified, the current working directory will be used. IMPORTANT: Omit this field to use the default directory. DO NOT enter \"undefined\" or \"null\" - simply omit it for the default behavior. Must be a valid directory path if provided.","type":"string"}},"required":["pattern","path"],"additionalProperties":false},"strict":true},{"type":"function","description":"- Fast content search tool that works with any codebase size\n- Searches file contents using regular expressions\n- Supports full regex syntax (eg. \"log.*Error\", \"function\\s+\\w+\", etc.)\n- Filter files by pattern with the include parameter (eg. \"*.js\", \"*.{ts,tsx}\")\n- Returns file paths and line numbers with at least one match sorted by modification time\n- Use this tool when you need to find files containing specific patterns\n- If you need to identify/count the number of matches within files, use the Bash tool with `rg` (ripgrep) directly. Do NOT use `grep`.\n- When you are doing an open-ended search that may require multiple rounds of globbing and grepping, use the Task tool instead\n","name":"grep","parameters":{"type":"object","properties":{"pattern":{"description":"The regex pattern to search for in file contents","type":"string"},"path":{"description":"The directory to search in. Defaults to the current working directory.","type":"string"},"include":{"description":"File pattern to include in the search (e.g. \"*.js\", \"*.{ts,tsx}\")","type":"string"}},"required":["pattern","path","include"],"additionalProperties":false},"strict":true},{"type":"function","description":"Available agent types and the tools they have access to:\n- explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. \"src/components/**/*.tsx\"), search code for keywords (eg. \"API endpoints\"), or answer questions about the codebase (eg. \"how do API endpoints work?\"). When calling this agent, specify the desired thoroughness level: \"quick\" for basic searches, \"medium\" for moderate exploration, or \"very thorough\" for comprehensive analysis across multiple locations and naming conventions.\n- general: General-purpose agent for researching complex questions and executing multi-step tasks. Use this agent to execute multiple units of work in parallel.\nAvailable agent types and the tools they have access to:\n- explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. \"src/components/**/*.tsx\"), search code for keywords (eg. \"API endpoints\"), or answer questions about the codebase (eg. \"how do API endpoints work?\"). When calling this agent, specify the desired thoroughness level: \"quick\" for basic searches, \"medium\" for moderate exploration, or \"very thorough\" for comprehensive analysis across multiple locations and naming conventions.\n- general: General-purpose agent for researching complex questions and executing multi-step tasks. Use this agent to execute multiple units of work in parallel.","name":"task","parameters":{"type":"object","properties":{"description":{"description":"A short (3-5 words) description of the task","type":"string"},"prompt":{"description":"The task for the agent to perform","type":"string"},"subagent_type":{"description":"The type of specialized agent to use for this task","type":"string"},"task_id":{"description":"This should only be set if you mean to resume a previous task (you can pass a prior task_id and the task will continue the same subagent session as before instead of creating a fresh one)","type":"string"},"command":{"description":"The command that triggered this task","type":"string"}},"required":["description","prompt","subagent_type","task_id","command"],"additionalProperties":false},"strict":true},{"type":"function","description":"- Fetches content from a specified URL\n- Takes a URL and optional format as input\n- Fetches the URL content, converts to requested format (markdown by default)\n- Returns the content in the specified format\n- Use this tool when you need to retrieve and analyze web content\n\nUsage notes:\n  - IMPORTANT: if another tool is present that offers better web fetching capabilities, is more targeted to the task, or has fewer restrictions, prefer using that tool instead of this one.\n  - The URL must be a fully-formed valid URL\n  - HTTP URLs will be automatically upgraded to HTTPS\n  - Format options: \"markdown\" (default), \"text\", or \"html\"\n  - This tool is read-only and does not modify any files\n  - Results may be summarized if the content is very large\n","name":"webfetch","parameters":{"type":"object","properties":{"url":{"description":"The URL to fetch content from","type":"string"},"format":{"description":"The format to return the content in (text, markdown, or html). Defaults to markdown.","default":"markdown","type":"string","enum":["text","markdown","html"]},"timeout":{"description":"Optional timeout in seconds (max 120)","type":"number"}},"required":["url","format","timeout"],"additionalProperties":false},"strict":true},{"type":"function","description":"Use this tool to create and manage a structured task list for your current coding session. This helps you track progress, organize complex tasks, and demonstrate thoroughness to the user.\nIt also helps the user understand the progress of the task and overall progress of their requests.\n\n## When to Use This Tool\nUse this tool proactively in these scenarios:\n\n1. Complex multistep tasks - When a task requires 3 or more distinct steps or actions\n2. Non-trivial and complex tasks - Tasks that require careful planning or multiple operations\n3. User explicitly requests todo list - When the user directly asks you to use the todo list\n4. User provides multiple tasks - When users provide a list of things to be done (numbered or comma-separated)\n5. After receiving new instructions - Immediately capture user requirements as todos. Feel free to edit the todo list based on new information.\n6. After completing a task - Mark it complete and add any new follow-up tasks\n7. When you start working on a new task, mark the todo as in_progress. Ideally you should only have one todo as in_progress at a time. Complete existing tasks before starting new ones.\n\n## When NOT to Use This Tool\n\nSkip using this tool when:\n1. There is only a single, straightforward task\n2. The task is trivial and tracking it provides no organizational benefit\n3. The task can be completed in less than 3 trivial steps\n4. The task is purely conversational or informational\n\nNOTE that you should not use this tool if there is only one trivial task to do. In this case you are better off just doing the task directly.\n\n## Examples of When to Use the Todo List\n\n<example>\nUser: I want to add a dark mode toggle to the application settings. Make sure you run the tests and build when you're done!\nAssistant: I'll help add a dark mode toggle to your application settings. Let me create a todo list to track this implementation.\n*Creates todo list with the following items:*\n1. Create dark mode toggle component in Settings page\n2. Add dark mode state management (context/store)\n3. Implement CSS-in-JS styles for dark theme\n4. Update existing components to support theme switching\n5. Run tests and build process, addressing any failures or errors that occur\n*Begins working on the first task*\n\n<reasoning>\nThe assistant used the todo list because:\n1. Adding dark mode is a multi-step feature requiring UI, state management, and styling changes\n2. The user explicitly requested tests and build be run afterward\n3. The assistant inferred that tests and build need to pass by adding \"Ensure tests and build succeed\" as the final task\n</reasoning>\n</example>\n\n<example>\nUser: Help me rename the function getCwd to getCurrentWorkingDirectory across my project\nAssistant: Let me first search through your codebase to find all occurrences of 'getCwd'.\n*Uses grep or search tools to locate all instances of getCwd in the codebase*\nAssistant: I've found 15 instances of 'getCwd' across 8 different files. Let me create a todo list to track these changes.\n*Creates todo list with specific items for each file that needs updating*\n\n<reasoning>\nThe assistant used the todo list because:\n1. First, the assistant searched to understand the scope of the task\n2. Upon finding multiple occurrences across different files, it determined this was a complex task with multiple steps\n3. The todo list helps ensure every instance is tracked and updated systematically\n4. This approach prevents missing any occurrences and maintains code consistency\n</reasoning>\n</example>\n\n\n<example>\nUser: I need to implement these features for my e-commerce site: user registration, product catalog, shopping cart, and checkout flow.\nAssistant: I'll help implement these features. First, let's add all the features to the todo list.\n*Creates a todo list breaking down each feature into specific tasks based on the project architecture*\nAssistant: Let's start with user registration. This will involve creating database models, API endpoints, and frontend forms that integrate with your existing authentication system.\n\n<reasoning>\nThe assistant used the todo list because:\n1. The user provided multiple complex features to implement in a comma separated list\n2. The todo list helps organize these large features into manageable tasks\n3. This approach allows for tracking progress across the entire implementation\n</reasoning>\n</example>\n\n<example>\nUser: Can you help optimize my React application? It's rendering slowly and has performance issues.</user>\nAssistant: I'll help optimize your React application. First, let me examine your codebase to identify potential performance bottlenecks.\n*Reviews component structure, render patterns, state management, and data fetching*\nAssistant: After analyzing your codebase, I've identified several performance issues. Let me create a todo list to track our optimization efforts.\n*Creates todo list with items like: 1) Implement memoization for expensive calculations in ProductList, 2) Add virtualization for long lists in Dashboard, 3) Optimize image loading in Gallery component, 4) Fix state update loops in ShoppingCart, 5) Review bundle size and implement code splitting*\nLet's start by implementing memoization for the expensive calculations in your ProductList component.</assistant>\n\n<reasoning>\nThe assistant used the todo list because:\n1. First, the assistant examined the codebase to identify specific performance issues\n2. Based on this analysis, it identified multiple optimization opportunities\n3. Performance optimization is a non-trivial task requiring multiple steps\n4. The todo list helps methodically track improvements across different components\n5. This systematic approach ensures all performance bottlenecks are addressed\n</reasoning>\n</example>\n\n## Examples of When NOT to Use the Todo List\n\n<example>\nUser: How do I print 'Hello World' in Python?\nAssistant: In Python, you can print \"Hello World\" with this simple code:\n\npython\nprint(\"Hello World\")\n\nThis will output the text \"Hello World\" to the console when executed.</assistant>\n\n<reasoning>\nThe assistant did not use the todo list because this is a single, trivial task that can be completed in one step. There's no need to track multiple tasks or steps for such a straightforward request.\n</reasoning>\n</example>\n\n<example>\nUser: What does the git status command do?\nAssistant: The git status command shows the current state of your working directory and staging area. It displays which changes have been staged, which haven't, and which files aren't being tracked by Git. This is a fundamental command for understanding the current state of your repository before making commits.\n\n<reasoning>\nThe assistant did not use the todo list because this is an informational request with no actual coding task to complete. The user is simply asking for an explanation, not for the assistant to perform multiple steps or tasks.\n</reasoning>\n</example>\n\n<example>\nUser: Can you add a comment to the calculateTotal function to explain what it does?\nAssistant: Sure, let me add a comment to the calculateTotal function to explain what it does.\n* Uses the Edit tool to add a comment to the calculateTotal function *\n\n<reasoning>\nThe assistant did not use the todo list because this is a single, straightforward task confined to one location in the code. Adding a comment doesn't require tracking multiple steps or systematic organization.\n</reasoning>\n</example>\n\n<example>\nUser: Run npm install for me and tell me what happens.\nAssistant: I'll run the npm install command for you.\n\n*Executes: npm install*\n\nThe command completed successfully. Here's the output:\n[Output of npm install command]\n\nAll dependencies have been installed according to your package.json file.\n\n<reasoning>\nThe assistant did not use the todo list because this is a single command execution with immediate results. There are no multiple steps to track or organize, making the todo list unnecessary for this straightforward task.\n</reasoning>\n</example>\n\n## Task States and Management\n\n1. **Task States**: Use these states to track progress:\n   - pending: Task not yet started\n   - in_progress: Currently working on (limit to ONE task at a time)\n   - completed: Task finished successfully\n   - cancelled: Task no longer needed\n\n2. **Task Management**:\n   - Update task status in real-time as you work\n   - Mark tasks complete IMMEDIATELY after finishing (don't batch completions)\n   - Only have ONE task in_progress at any time\n   - Complete current tasks before starting new ones\n   - Cancel tasks that become irrelevant\n\n3. **Task Breakdown**:\n   - Create specific, actionable items\n   - Break complex tasks into smaller, manageable steps\n   - Use clear, descriptive task names\n\nWhen in doubt, use this tool. Being proactive with task management demonstrates attentiveness and ensures you complete all requirements successfully.\n\n","name":"todowrite","parameters":{"type":"object","properties":{"todos":{"description":"The updated todo list","type":"array","items":{"type":"object","properties":{"content":{"description":"Brief description of the task","type":"string"},"status":{"description":"Current status of the task: pending, in_progress, completed, cancelled","type":"string"},"priority":{"description":"Priority level of the task: high, medium, low","type":"string"}},"required":["content","status","priority"],"additionalProperties":false}}},"required":["todos"],"additionalProperties":false},"strict":true},{"type":"function","description":"Load a specialized skill that provides domain-specific instructions and workflows. No skills are currently available.\nNo skills are currently available.","name":"skill","parameters":{"type":"object","properties":{"name":{"description":"The name of the skill from available_skills","type":"string"}},"required":["name"],"additionalProperties":false},"strict":true},{"type":"function","description":"Use the `apply_patch` tool to edit files. Your patch language is a stripped‑down, file‑oriented diff format designed to be easy to parse and safe to apply. You can think of it as a high‑level envelope:\n\n*** Begin Patch\n[ one or more file sections ]\n*** End Patch\n\nWithin that envelope, you get a sequence of file operations.\nYou MUST include a header to specify the action you are taking.\nEach operation starts with one of three headers:\n\n*** Add File: <path> - create a new file. Every following line is a + line (the initial contents).\n*** Delete File: <path> - remove an existing file. Nothing follows.\n*** Update File: <path> - patch an existing file in place (optionally with a rename).\n\nExample patch:\n\n```\n*** Begin Patch\n*** Add File: hello.txt\n+Hello world\n*** Update File: src/app.py\n*** Move to: src/main.py\n@@ def greet():\n-print(\"Hi\")\n+print(\"Hello, world!\")\n*** Delete File: obsolete.txt\n*** End Patch\n```\n\nIt is important to remember:\n\n- You must include a header with your intended action (Add/Delete/Update)\n- You must prefix new lines with `+` even when creating a new file\n","name":"apply_patch","parameters":{"type":"object","properties":{"patchText":{"description":"The full patch text that describes all changes to be made","type":"string"}},"required":["patchText"],"additionalProperties":false},"strict":true},{"type":"function","description":"Use this tool when you need to ask the user questions during execution. This allows you to:\n1. Gather user preferences or requirements\n2. Clarify ambiguous instructions\n3. Get decisions on implementation choices as you work\n4. Offer choices to the user about what direction to take.\n\nUsage notes:\n- When `custom` is enabled (default), a \"Type your own answer\" option is added automatically; don't include \"Other\" or catch-all options\n- Answers are returned as arrays of labels; set `multiple: true` to allow selecting more than one\n- If you recommend a specific option, make that the first option in the list and add \"(Recommended)\" at the end of the label\n","name":"question","parameters":{"type":"object","properties":{"questions":{"description":"Questions to ask","type":"array","items":{"type":"object","properties":{"question":{"description":"Complete question","type":"string"},"header":{"description":"Very short label (max 30 chars)","type":"string"},"options":{"description":"Available choices","type":"array","items":{"ref":"QuestionOption","type":"object","properties":{"label":{"description":"Display text (1-5 words, concise)","type":"string"},"description":{"description":"Explanation of choice","type":"string"}},"required":["label","description"],"additionalProperties":false}},"multiple":{"description":"Allow selecting multiple choices","type":"boolean"}},"required":["question","header","options","multiple"],"additionalProperties":false}}},"required":["questions"],"additionalProperties":false},"strict":true}],"top_logprobs":0,"top_p":0.98,"truncation":"disabled","usage":{"input_tokens":8991,"input_tokens_details":{"cached_tokens":0},"output_tokens":208,"output_tokens_details":{"reasoning_tokens":108},"total_tokens":9199},"user":null,"metadata":{},"_id":2,"_purpose":"","_url":"https://chatgpt.com/backend-api/codex/responses","_kind":"response","_ts":"2026-04-09T05:12:32.215Z"}
{"include":["reasoning.encrypted_content"],"input+":[{"type":"reasoning","encrypted_content":"encrypted-placeholder","summary":[{"type":"summary_text","text":"**Planning file reading**\n\nI need to comply with the instructions to read two files. It seems straightforward, but I wonder if I should provide a brief update or commentary beforehand since the guidelines suggest it. Even if it feels trivial, I think it’s better to follow the instructions. I’ll use the Read tool and choose the correct absolute paths for the files. Since they’re independent, I might even parallelize the read operations. Let’s keep the commentary short and concise before proceeding!"}]},{"role":"assistant","content":[{"type":"output_text","text":"Reading both files, then I’ll reply with two short poems."}],"phase":"commentary"},{"type":"function_call","call_id":"call_eiReg4fQHaSXBAvu47HNoku9","name":"read","arguments":"{\"filePath\":\"/Users/ljw/a.txt\",\"offset\":1,\"limit\":2000}"},{"type":"function_call","call_id":"call_gtGkYMQBFRlS5tKWDHlOl7CF","name":"read","arguments":"{\"filePath\":\"/Users/ljw/b.txt\",\"offset\":1,\"limit\":2000}"},{"type":"function_call_output","call_id":"call_eiReg4fQHaSXBAvu47HNoku9","output":"<path>/Users/ljw/a.txt</path>\n<type>file</type>\n<content>\n1: onion\n\n(End of file - total 1 lines)\n</content>"},{"type":"function_call_output","call_id":"call_gtGkYMQBFRlS5tKWDHlOl7CF","output":"<path>/Users/ljw/b.txt</path>\n<type>file</type>\n<content>\n1: flower\n\n(End of file - total 1 lines)\n</content>"}],"instructions":"[unchanged]","model":"gpt-5.4","prompt_cache_key":"ses_placeholder_example","*reasoning":{"effort":"high","summary":"auto"},"store":false,"stream":true,"*text":{"verbosity":"low"},"tool_choice":"auto","tools":["..."],"_id":3,"_purpose":"","_url":"https://chatgpt.com/backend-api/codex/responses","_kind":"request","_ts":"2026-04-09T05:12:32.823Z"}
{"background":false,"*completed_at":1775711559,"*created_at":1775711553,"error":null,"frequency_penalty":0,"*id":"resp_09a1a1b47a3b3e3b0169d7354112688197a1b697725bcab402","incomplete_details":null,"instructions":"[unchanged]","max_output_tokens":null,"max_tool_calls":null,"metadata":{},"model":"gpt-5.4","object":"response","*output":[{"id":"msg_09a1a1b47a3b3e3b0169d7354624908197a2c29157d9e47945","type":"message","status":"completed","content":[{"type":"output_text","annotations":[],"logprobs":[],"text":"`a.txt`:\nOnion in silence,\na moon of layered secrets waits,\nsharp truth under skin.\n\n`b.txt`:\nFlower opens wide,\na small lantern made of spring,\nsoft color breathing."}],"phase":"final_answer","role":"assistant"}],"parallel_tool_calls":true,"presence_penalty":0,"previous_response_id":null,"prompt_cache_key":"ses_placeholder_example","prompt_cache_retention":null,"*reasoning":{"effort":"high","summary":"detailed"},"safety_identifier":"user-placeholder-example","service_tier":"default","status":"completed","store":false,"temperature":1,"*text":{"*format":{"type":"text"},"verbosity":"low"},"tool_choice":"auto","*tool_usage":{"*image_gen":{"input_tokens":0,"*input_tokens_details":{"image_tokens":0,"text_tokens":0},"output_tokens":0,"*output_tokens_details":{"image_tokens":0,"text_tokens":0},"total_tokens":0},"*web_search":{"num_requests":0}},"tools":["..."],"top_logprobs":0,"top_p":0.98,"truncation":"disabled","*usage":{"*input_tokens":9295,"*input_tokens_details":{"*cached_tokens":9088},"*output_tokens":46,"*output_tokens_details":{"*reasoning_tokens":0},"*total_tokens":9341},"user":null,"_id":3,"_purpose":"","_url":"https://chatgpt.com/backend-api/codex/responses","_kind":"response","_ts":"2026-04-09T05:12:39.847Z"}