// Generates a Markdown bug report for an IBM watsonx.data integration session. User can invoke directly. The agent may propose it (and must wait for explicit acceptance) only after exhausting recovery options on a failure. Skip for non-watsonx.data integration sessions.
| name | di-agent-bug-report |
| description | Generates a Markdown bug report for an IBM watsonx.data integration session. User can invoke directly. The agent may propose it (and must wait for explicit acceptance) only after exhausting recovery options on a failure. Skip for non-watsonx.data integration sessions. |
Captures the current AI-agent session into a Markdown report so the watsonx.data integration skill authors can debug what went wrong (or confirm what worked) while the agent was creating, running, or managing a watsonx.data integration pipeline. The skill is agent-agnostic — do not assume any specific AI runtime, model, or session-file layout.
Manual: the user explicitly asks to report a bug or files a bug report. Proceed directly — no confirmation needed.
Automatic (proposed, never silent — once per session, only after exhausting options): the agent itself was unable to complete a watsonx.data integration intent and proposes this skill. Strict triggering rules:
di-agent-* knowledge skills, queried the relevant lookup/diagnostic MCP tools, attempted reasonable corrections to the flow/job, and the failure still stands. Conditions that qualify as "exhausted" include:
failed / errored logs and re-running with the obvious fix did not help,A session counts as watsonx.data integration-related when any of the following are true:
di-agent- prefix was used,mcp__ibm-agentic-data-integration__*),--name <filename> (optional) — override the output filename. Written under agent/bug_reports/; basename only. .md is appended if missing. Reject path separators and ... When omitted, use the default name (see Invariant 3).ibm-watsonx-data-integration-agent-skills/agent/bug_reports/watsonx_di_agent_bug_report_<YYYY-MM-DD>_<HH-MM-SS>_<session_name>.md, where <HH-MM-SS> is the local 24-hour time and <session_name> is a short AI-generated slug summarizing the user's initial intent — lowercase, hyphen-separated, ASCII letters/digits only, ≤6 words, no skill names as filler. With --name, write to .../bug_reports/<filename>.md instead. Create bug_reports/ if missing. If the target exists, ask before overwriting.session_date, session_time: today's date and current local time (formats per Invariant 3).session_name: slug derived from the opening user prompts (rules per Invariant 3).agent_session_id: the host agent runtime's session identifier. Try, in order: (1) the runtime's active transcript / log file — common patterns include ~/.claude/projects/<encoded-cwd>/<uuid>.jsonl (Claude Code), ~/.cursor/..., or any path the runtime advertises in its docs; if a matching <uuid>.jsonl exists and is the most-recently-modified, use the UUID from the filename; (2) a runtime-introspection / whoami tool, if the host exposes one. If neither resolves, record null and note which sources were tried. Never invent or guess.session_info: call the watsonx.data integration get_session_info MCP tool and capture its full output verbatim. Render the raw key/value payload (one bullet per field) into the Session Info section directly above generated_at. Do not try to extract a single id — pass through whatever the tool returns. If the tool is unavailable or errors, record one bullet **Session Info:** _tool unavailable._ and continue.llm: name and version of the LLM powering the host agent runtime (e.g. claude-opus-4-7, claude-sonnet-4-6, gpt-5.1). Use the model identifier the runtime states in its own system prompt — the LLM knows what it is running on. If self-identification is not possible, fall back to a runtime-introspection tool or a model-related environment variable. Record as <name>-<version>; record null only if none of these resolve.--name value (sanitized, .md appended) or the default from Invariant 3.Single chronological section combining every entry of the session. Walk the conversation in order and append one numbered entry per user message, assistant text response, skill invocation, and tool call. All entries share one numbering sequence, ordered strictly by when they occurred — turns and tool calls interleave naturally.
Per-entry shapes:
User / assistant turn — bold pseudo-heading followed directly by a fenced text block holding the PII-redacted body. Verbatim only: render the actual text character-for-character (modulo PII redaction). No summaries, no paraphrasing, no bracketed narration like [Invoked X skill, then …]. For assistant turns, include the user-visible prose only — strip internal reasoning and raw tool-call JSON. If an assistant turn had no user-visible text (tool calls only), skip it — do not invent prose.
**N. turn — <User | Assistant>**
```text
<verbatim PII-redacted text of the turn, line breaks preserved>
Skill or tool call — bold pseudo-heading with kind, name, status, then **Input:** and **Output:** bullets.
**N. <skill | tool> — `<name>` — status: <ok | error | unknown>**
- **Input:** <one-line summary — never the full payload>
- **Output:**
```text
<result, truncated to ~2000 chars; `_No output._` if none; failure messages go here>
Notes:
entry N).Required. Job-run status in the transcript only reports completed / failed plus a short summary — not enough to diagnose what actually happened. Before finalizing Description (step 4), call the following watsonx.data integration MCP tools whenever the relevant inputs are available from the session. Skip a tool only when its inputs are missing; never block on a failure; record each attempt (including errors) as its own transcript entry.
get_job_run_logs — full log stream and event history for the latest job run. Cite specific warnings/errors (e.g. implicit type conversions, partition counts, per-stage in → out row counts) in the Description.retrieve_datastage_flow_code — the stored definition of the submitted flow, so the report reflects what actually ran (column types, predicates, joins).The Description must be informed by these tool outputs — do not write the diagnosis from the surface-level run status alone.
Produces the Description section. Classify using the transcript (step 2) plus diagnostic data (step 3):
success; say so explicitly.success with an explanatory Description.Description length: hard cap of 5–6 sentences. State the outcome and the direct reason — what failed, where (cite transcript entries as entry N), and what the evidence says. No background, no narrative, no restating what the user asked for.
Create ibm-watsonx-data-integration-agent-skills/agent/bug_reports/ if missing, then write using the template below.
Formatting rules:
# IBM watsonx.data integration Agent Bug Report. No leading YAML/Markdown frontmatter, no leading --- separator, no blank lines, no shebang, no metadata block above the H1. The file starts with the H1 and nothing else.---) anywhere in the document. Section boundaries are conveyed by ## headings alone — Markdown --- lines render as horizontal rules and clutter the output.# for the title, ## for sections. No ### anywhere — use bold pseudo-headings.**Input:**, **Output:**, etc.).Template:
# IBM watsonx.data integration Agent Bug Report
**Outcome:** [success | failure]
## Session Info
- **Agent Session ID:** `[uuid or null]`
- **LLM:** `[name-version, e.g. claude-opus-4-7, or null]`
- **`get_session_info`:** [render each field returned by the tool as its own indented bullet, verbatim — e.g. `session_id`, `client_type`, etc. If the tool errored or was unavailable, write `_tool unavailable._` instead.]
- **Generated at:** [ISO-8601 timestamp]
## Description
[5–6 sentences max. State the outcome and the direct reason — what failed, where (cite transcript entries as `entry N`), and what the evidence says. No background, no fixes.]
## Transcript
**1. turn — User**
```text
[PII-redacted user message text, verbatim.]
```
**2. turn — Assistant**
```text
[PII-redacted assistant prose reply, verbatim.]
```
**3. [skill | tool] — `[name]` — status: [ok | error | unknown]**
- **Input:** [one-line summary]
- **Output:**
```text
[result, truncated to ~2000 chars; `_No output._` if none. Failure message goes here.]
```
[...continue numbering chronologically; turns and tool calls interleave...]
After writing, print: the absolute file path, the outcome, and the count of transcript entries. Do not echo the full report back.
success.failure, Description cites the missed lookup.Reference for creating DataStage (batch) flows with the watsonx.data integration SDK. The SDK is verbose and permits exhaustive stage and property access: use it to author flows pyflow's compact DSL can't express, and to edit or optimize existing DataStage flows, including ones bootstrapped with pyflow.
Complete API spec for pyflow, IBM's LLM-only Python DSL for authoring new batch or streaming flows on DataStage or StreamSets. The compact surface is built for high LLM authoring reliability — bootstrap here first, and fall back to the verbose engine-specific SDK only when pyflow cannot express a needed feature.
Q&A reference for the DataStage parallel engine — parallelism, partitioning theory, APT configuration files, concurrent job execution, restart/recovery, disk/resource tuning, dataset performance, flow optimization (partitioning/sorting/memory), and per-stage semantics. Use for conceptual engine questions and stage property lookups regardless of authoring tool.
Reference for StreamSets Data Collector engines and StreamSets environments — StreamSets environment configuration, StreamSets engine deployment (Docker/Podman), StreamSets job execution, StreamSets engine communication methods (tunneling/direct), StreamSets high availability and failover, StreamSets monitoring and resource management. Use ONLY when the user explicitly mentions StreamSets, Data Collector, or a StreamSets-specific concern.
Use when the user asks to generate a Substrait query plan, create a Substrait plan from natural language, convert a data query to Substrait JSON, write a Substrait DSL pipeline, translate a data request into a query plan, process a test entry from a JSONL dataset. Covers writing DSL code, calling MCP tools (compile_substrait_dsl, get_substrait_dsl_examples, load_test_entry), and self-correcting on compile errors. Trigger on: "generate substrait", "generate substrait dsl", "generate functional plan", "generate fp", "process entry", "run entry", "generate dsl".