Skip to content

Add a generic agent-skills host with an access-aware preflight - #48

Open
kumo-isaac wants to merge 22 commits into
mainfrom
igutierrez/agent-skills-generic-host
Open

kumo-isaac wants to merge 22 commits into
mainfrom
igutierrez/agent-skills-generic-host

Conversation

@kumo-isaac

Copy link
Copy Markdown
Contributor

Summary

The kumo-data-science skill shipped only to Snowflake CoCo, and its "portable" core assumed Snowflake throughout. This adds a generic host for coding agents working beside the user (Claude Code, Codex). The host generates code for any of the six kumo.engine connectors: File, S3, GCS, BigQuery, Databricks and Snowflake. CoCo behavior is unchanged.

Access-aware preflight (new §0 in accept/preflight.md)

  • Before inferring structure, the agent checks that it can read source_scope with a read-only tool it already has. That can be a tool in the session, an authenticated CLI (aws, gcloud, bq, databricks, snow, duckdb) run against the scope itself, or Python with kumo.engine.
  • If none works, it sends one ask-back saying what it checked and offers two options: you provide access, or you paste the structure. It never asks for a credential value, signs in, or changes tool configuration.
  • A proposal built from pasted structure goes through the same gates. Key candidates it could not check against the data stay [inferred, unverified].
  • This is the agent's own access only. The generated code authenticates where it runs.

hosts/generic/

  • adapter.md covers source forms mapped to connectors, the access checks per system, destinations, and how the capability skills apply off Snowflake.
  • runtime.md covers:
    • a config cell where runtime-only values are placeholders that stop the run until filled in;
    • a connect step per connector using credentials already present in the environment;
    • destinations and a row-count read-back per connector.

Core changes

  • The core reaches its host only as hosts/<host>/. Source and destination forms are now defined by the host; batch inference no longer rejects s3:// and file destinations by itself.
  • kumo_finetuning_sdk.md gains §3.4 (non-Snowflake connectors) and §9.2 (destinations by connector), both read from the package source.
  • package_skill.py generic builds a 29-file package. New tests check that core files name no host, that each package ships only its own host, and that every adapter covers source scope, access and destinations.

Test plan

  • pytest agent-skills/tests: 161 passed (148 before).
  • package_skill.py --check: coco 30 files and generic 29 files, 0 unresolved references.
  • One headless Claude Code run with the generic package, on a BigQuery dataset it cannot read (bq absent). It checked its session tools, bq and Python, and stopped before the graph proposal with the access-or-details ask-back. It restated the four task fields, wrote no code, and quoted the correct build marker.
  • Not verified: no non-Snowflake connector, read-back or population staging has run end to end. runtime.md says so and tells the agent to tell the user. The next real test is FileConnector on Parquet exports of the eval schemas.
  • Intake and codegen evals on the generic package: not yet run.

Known gaps

  • The capability skills (persistence, populations, explanations, diagnostics, tuning) still assume the Snowflake registry, stage and session. The generic adapter tells the agent to report a Snowflake-only step as not covered rather than adapt it.
  • On the generic host, no population staging for BigQuery or Databricks; the agent offers the rows whose target is NULL instead.

🤖 Generated with Claude Code

The kumo-data-science skill shipped only to Snowflake CoCo, and its "portable" core assumed
Snowflake throughout. This adds a `generic` host for coding agents beside the user (Claude
Code, Codex) that generates code for any of the six kumo.engine connectors.

- Preflight §0: before inferring structure, the agent proves it can read source_scope with a
  read-only tool it already has. If not, it says what it checked and asks for access or for the
  structure, never for a credential.
- hosts/generic/: adapter (source forms, access checks per system, destinations) and runtime
  (config cell with placeholders, connect step, destinations and read-back per connector).
- Core no longer names a host; source and destination forms are host-defined. The SDK reference
  gains §3.4 (non-Snowflake connectors) and §9.2 (destinations by connector).
- package_skill.py builds `generic`; tests check that the core names no host, that each package
  ships only its own host, and that every adapter covers what the core defers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@copy-pr-bot

copy-pr-bot Bot commented Oct 20, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 20, 2026 19:36 — with GitHub Actions Inactive
@coderabbitai

coderabbitai Bot commented Oct 20, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
Walkthrough

The changes add a generic host package for coding agents and define host-specific source access and runtime instructions. Core Kumo skill guidance and reference material now cover host-dependent source locations, destinations, and connector behavior. Packaging instructions and tests cover the generic host package and its adapter documentation.

Priority: Normal

Merge Risk: Moderate · previous review bac10

The generic host's static-scoring recipe gives the wrong connector for S3 and GCS sources, so those workflows would fail before prediction. The population-staging location guidance is also contradictory. These should be fixed before merge, along with the earlier open review concerns on the generic host guidance.

Pre-merge checks: Passed 2 · Inconclusive 1

Failed Failed checks: 1 inconclusive

Check name Status Explanation Resolution
Change Map Design Review Inconclusive The required PR conversation comment beginning <!-- kumo-pr-change-map --> is not available in the supplied review context or repository checkout. The checkout contains only the review guidance and … Provide the complete, current PR conversation comment beginning <!-- kumo-pr-change-map -->, including its Change map, linked problem or release requirement, focused verification, and stopping condition. Re-run the design review against t…
Passed Passed checks: 2 passed
Check name Status Explanation
Pr Size Passed The pull request changes 21 files in the review-scoped Git range. The limit is 40 files, so the PR size check passes.
Public Resource Access Passed No added or modified URL is present. The added package source references in agent-skills/skills/kumoai-reference/references/kumo_finetuning_sdk.md (lines 252–254 and 616–617) resolve to public sourc…
Full details: Public Resource Access

Explanation

No added or modified URL is present. The added package source references in agent-skills/skills/kumoai-reference/references/kumo_finetuning_sdk.md (lines 252–254 and 616–617) resolve to public source files in NVIDIA/kumo-engine; anonymous requests returned HTTP 200 for all nine referenced files. Added runtime package references also resolve through public PyPI entries. Internal repository paths exist in the reviewed tree. No inaccessible external resource reference was confirmed.

Full details: Change Map Design Review

Explanation

The required PR conversation comment beginning &lt;!-- kumo-pr-change-map --&gt; is not available in the supplied review context or repository checkout. The checkout contains only the review guidance and the PR diff; it does not contain the Change map table, its linked problem, or its stated verification and stopping condition. The PR description and objectives summarize the change, but they do not provide the comment required by this check, so necessity, abstraction-layer placement, and coverage cannot be assessed reliably.

Resolution

Provide the complete, current PR conversation comment beginning &lt;!-- kumo-pr-change-map --&gt;, including its Change map, linked problem or release requirement, focused verification, and stopping condition. Re-run the design review against that comment and the reviewed diff.

Finishing Touches: 💡 1
🛠️ Fix failing CI checks: 💡
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

Found by the generic-host codegen eval (kumo-ai/kumo_skill_dev, eval/generic/): 32 of 38 files
notebooks and 19 of 38 S3 notebooks named tables `x.parquet`, which carries the suffix into the
graph and the PQL; 19 and 18 rooted the output connector at the confirmed directory and wrote
`table_name='predictions'` one level below it.

- adapter §3: name file and object-store tables without their suffix.
- runtime §2: the same at the connect step.
- runtime §3: root the output connector at the destination's parent and name the last segment
  in output_paths, so predictions land at exactly the confirmed path.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 20, 2026 22:48 — with GitHub Actions Inactive
…rectory

GPU runs of the generic files notebooks (kumo_skill_dev eval/generic/run_gpu.py) failed every
static task with a staged population: pyarrow does not create the population directory, and
kumo-engine 1.0.0 rejects a population without TIMESTAMP when the entity table is timestamped
(kumo_finetuning_sdk.md §7.1 already says so; runtime §3.1 staged ENTITY1 only).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 00:05 — with GitHub Actions Inactive
The rerun's nov-sales-regression notebooks still staged ENTITY1 only: the example's 'drop if
there is none' read as optional. Decide from the entity Table's time_column.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 00:50 — with GitHub Actions Inactive
The Databricks GPU runs of the generic notebooks staged the static population with a
wait_timeout above Databricks' 50 s limit and without TIMESTAMP. §3.1 now covers Databricks:
CREATE TABLE AS through the confirmed SQL warehouse, wait <= 50 s, poll to completion.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 02:10 — with GitHub Actions Inactive
GPU reruns staged TIMESTAMP from a DATE column (booked_date); kumo-engine 1.0.0 reads only a
timestamp or int64 anchor and rejects date32. Cast it, in pyarrow and in the Databricks SQL.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 03:53 — with GitHub Actions Inactive
SageMaker runs of the generic S3 notebooks: 5 of 38 added an AWS_REGION or AWS_PROFILE
placeholder, which stops the run at the config guard; on a job role there is no profile to fill.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 05:36 — with GitHub Actions Inactive
SageMaker runs: 3 of 38 generic S3 notebooks still invented an AWS_REGION placeholder after
feefa6d, which stops them at the config guard. The SDK reference listed region= in the
signature with no word that it is normally left out; say so there and at the connect step.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 16:49 — with GitHub Actions Inactive
Codegen evals (CoCo and generic alike) lost 1-5 of 38 notebook-only cases to the 'add a
destination later' example written as a python code block, which is a code cell that writes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 17:21 — with GitHub Actions Inactive
…tionOutputConfig

Generic Databricks notebooks put binary_classification_threshold on PredictionOutputConfig in
6 of 42 cases (S3 2 of 112; files and CoCo 0), a TypeError at predict time. The reference gave
the signature but never said the config takes neither argument.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 21, 2026 22:42 — with GitHub Actions Inactive
@kumo-isaac

Copy link
Copy Markdown
Contributor Author

Eval results: generic host against CoCo

Harness: eval/generic/ on kumo-ai/kumo_skill_dev branch eval/generic-host. Both arms are
built from the same agent-skills/skills/ tree, run on the same cases, specs, comparator and judge,
on the same model (databricks-claude-opus-4-6, temperature 0). Judge: nemotron.

Codegen, first-try match against the reference specs (38 confirm cases)

Arm Build Match
CoCo, Snowflake e6df3dbe 38/38
generic, S3 e6df3dbe 38/38
generic, Databricks tables e35d691b 38/38
generic, local files e6df3dbe 37/38 (the entity table's time_column was dropped once)

End to end on a GPU: train, predict, write, read back

The notebooks that matched their spec, from the latest full sweeps. All runs install
kumo-engine[...]==1.0.0 from PyPI. The repair loop sends each failing cell and its traceback back
to the model, up to 3 times.

Backend Platform Build First try After repair
local files (FileConnector) Databricks T4 8caea0e4 32/37 37/37
Databricks tables (DatabricksConnector, ambient identity) Databricks T4 8caea0e4 30/37 33/37
S3 (S3Connector, job role) SageMaker training jobs (T4, A10G, L4) feefa6da 31/34 34/34

These sweeps predate the last fixes. Of the first-try failures, these are fixed on this PR:
population staging (5a150873, 76cd6f7f, 7ed8896d), the S3 region placeholder (feefa6da,
ad5d7484) and the threshold on PredictionOutputConfig (e35d691b). The population cases pass
4/4 first try on 76cd6f7f, on both files and Databricks. A partial sweep on ad5d7484 was stopped
at S3 8/8 and files 19/19. No full GPU sweep has run on the head of this PR yet.

Intake (90 core cases, preflight results injected; build 23802ec3, not rerun since)

Arm Label Rubric
CoCo, Snowflake 80/90 43/90
generic, Snowflake 79/90 43/90
generic, S3 80/90 47/90
generic, access check fails (noaccess, 47 complete requests) 47/47 42/47

On the same Snowflake data, CoCo and generic disagree on 22 cases, split 11 each way: noise, not a
direction. The new access check (preflight §0) asks for access or for the structure 42/47 times;
the misses offered only the structure. Commits after 23802ec3 change only Step 2 files.

What each commit on this PR fixed, and where it was found

Commit Fix Found by
14a51ec2 bare file table names; write a path destination at exactly the confirmed path codegen (files 2/38 → 36/38)
8caea0e4, 5a150873, 76cd6f7f file population: create the directory, stage TIMESTAMP, cast it GPU runs
7ed8896d Databricks population through the statement API, wait_timeout ≤ 50 s GPU runs
feefa6da, ad5d7484 no region or profile placeholder for S3/GCS; region is optional SageMaker runs
e6df3dbe the later-destination example as text, not a python block codegen, CoCo included (32/38 → 38/38)
e35d691b threshold and top-k on predict, never on PredictionOutputConfig GPU runs (Databricks 34/38 → 38/38)

Open

  • A full GPU sweep on this PR's head, all three backends.
  • Intake rerun on the head (expected unchanged).
  • CoCo has no GPU baseline in this harness, so the end-to-end numbers are generic-only.
  • kumo_finetuning_sdk.md §7.1, the Snowflake population example, stages ENTITY1 only. kumo-engine
    1.0.0 rejects that for a timestamped entity, so CoCo likely fails that case too; it isn't measured
    here.

@kumo-isaac
kumo-isaac marked this pull request as ready for review October 22, 2026 19:27

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

Note

Quiet mode is enabled, so only the most important comments were posted inline. Other review comments are grouped below.

🟡 Other comments: 2
agent-skills/skills/kumoai-reference/references/graph_construction.md: 2

76-77: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Qualify the connector-independent workflow claim.

The workflow is shared, but connector contracts are not. Table names and path forms differ, and file and object-store connectors do not support sql(). State that the workflow is common while preserving these connector-specific limits.


149-149: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Use the documented CSV time-column contract.

For a CSV time column, Dtype.date alone is not the documented fix. Use Dtype.time with an explicit timestamp_format. Otherwise generated file-connector graphs can misparse or lose their timeline.


ℹ️ Review info
⚙️ Run configuration
📥 Commits

Reviewing files that changed from the base of the PR and between 341cf04 and e35d691.

📒 Files selected for processing: 21
  • agent-skills/DESIGN.md
  • agent-skills/README.md
  • agent-skills/scripts/package_skill.py
  • agent-skills/skills/hosts/generic/adapter.md
  • agent-skills/skills/hosts/generic/runtime.md
  • agent-skills/skills/hosts/snowflake-coco/adapter.md
  • agent-skills/skills/kumo-data-science/SKILL.md
  • agent-skills/skills/kumo-data-science/accept/batch_inference.md
  • agent-skills/skills/kumo-data-science/accept/intake_contract.md
  • agent-skills/skills/kumo-data-science/accept/preflight.md
  • agent-skills/skills/kumo-data-science/validate/examples/bad_request.md
  • agent-skills/skills/kumo-model-explanations/SKILL.md
  • agent-skills/skills/kumo-model-tuning/SKILL.md
  • agent-skills/skills/kumo-training-diagnostics/SKILL.md
  • agent-skills/skills/kumoai-reference/SKILL.md
  • agent-skills/skills/kumoai-reference/references/graph_construction.md
  • agent-skills/skills/kumoai-reference/references/kumo_finetuning_sdk.md
  • agent-skills/skills/kumoai-reference/references/outputs.md
  • agent-skills/skills/kumoai-reference/references/task_journeys.md
  • agent-skills/skills/kumoai-reference/references/troubleshooting_signals.md
  • agent-skills/tests/test_package_skill.py

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review.

Comment thread agent-skills/skills/hosts/generic/adapter.md Outdated
Comment thread agent-skills/skills/hosts/generic/runtime.md
Comment thread agent-skills/skills/hosts/generic/runtime.md Outdated
Comment thread agent-skills/skills/hosts/snowflake-coco/adapter.md
Comment thread agent-skills/skills/kumo-data-science/accept/intake_contract.md
- Access: an S3/GCS listing proves access, not structure; keep looking
  for a column reader, else ask for the structure.
- Path destinations end in '/', '.parquet' or '.csv'. File, S3 and GCS
  sinks all add '.parquet' to any other path (object_store_sink,
  connector.file), so the SDK reference's "FileConnector does not
  append" was wrong. Read back in the format the suffix names.
- Population staging reads the entity source in its own format (CSV or
  Parquet) and still writes Parquet.
- Binary threshold: 0.5 [default] at Node 1d unless the user gives one;
  predict requires it and has no default.
- batch_inference: a connector named alone is a source only on a host
  that accepts connector names.
- CoCo: a semantic view's connector scope is its base tables' schema.
- graph_construction: connector-specific naming and sql(); non-ISO time
  strings take timestamp_format with Dtype.date (Dtype.time is time of day).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 23, 2026 22:27 — with GitHub Actions Inactive
@kumo-isaac

Copy link
Copy Markdown
Contributor Author

@coderabbitai On the two graph_construction.md comments in your review body, both addressed in b5d5245:

  • Lines 76-77, connector-independent workflow: now says the workflow is shared, but table naming (identifier vs. a suffix-less path under a file connector's root) and connector.sql() differ by connector. Only Snowflake, Databricks and BigQuery run SQL (kumo/engine/connector/base.py:141).
  • Line 149, CSV time column: added timestamp_format= for non-ISO strings, but kept Dtype.date rather than Dtype.time. In this SDK Dtype.time is a time of day: pyarrow_to_dtype maps only pa.time* types to it and every timestamp to Dtype.date (kumo_core/types/conversions.py:130-134). The DiskGraph tests use a string column with stype=timestamp plus timestamp_format (kumo-core/tests/test_diskgraph.py:42), which is what Dtype.date + timestamp_format produces.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Note

Quiet mode is enabled, so only the most important comments were posted inline. Other review comments are grouped below.

🟡 Other comments: 2
agent-skills/skills/kumoai-reference/references/graph_construction.md: 1

152-155: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Resolve the timestamp contract before publishing this example.

The graph guidance recommends Dtype.date for CSV strings and timestamp_format, but the SDK reference and engine README prescribe Dtype.time for CSV timestamps. The SDK reference also marks timestamp_format as unverified. Verify Snowflake TEXT and CSV behavior separately, then align both references or mark the behavior as unverified.

agent-skills/skills/hosts/snowflake-coco/adapter.md: 1

97-98: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Map a connector-name scope to a connection identifier, not to database or schema_name.

Section 0 accepts "a connector name" as a source_scope form, but the closing paragraph of §6.1 says every source_scope is the connector's database and schema_name. A connector-name-only scope therefore cannot supply the <DB> and <schema> for the §6.1 scope query or the database and schema_name in the runtime.md §3 connector. The Snowflake host text does not say how to resolve that name. runtime.md §3 already uses CONNECTION_NAME as a separate connection identifier, so the name can serve that role. The database and schema must still come from the user.

🐛 Suggested fix
-The `source_scope` the user confirmed at intake is also the `database` / `schema_name` passed to
-the connector in `runtime.md` §3. For a semantic view, pass the database and schema its base
+When the user confirmed a database and schema, pass them as the `database` / `schema_name` to
+the connector in `runtime.md` §3. If the user confirmed only a connector name, use it only as the
+`connection_name` in `runtime.md` §3 and ask for the database and schema. For a semantic view, pass the database and schema its base

ℹ️ Review info
⚙️ Run configuration
📥 Commits

Reviewing files that changed from the base of the PR and between e35d691 and b5d5245.

📒 Files selected for processing: 8
  • agent-skills/skills/hosts/generic/adapter.md
  • agent-skills/skills/hosts/generic/runtime.md
  • agent-skills/skills/hosts/snowflake-coco/adapter.md
  • agent-skills/skills/kumo-data-science/SKILL.md
  • agent-skills/skills/kumo-data-science/accept/batch_inference.md
  • agent-skills/skills/kumo-data-science/accept/intake_contract.md
  • agent-skills/skills/kumoai-reference/references/graph_construction.md
  • agent-skills/skills/kumoai-reference/references/kumo_finetuning_sdk.md

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review.

Comment thread agent-skills/skills/hosts/generic/runtime.md
Each §3.1 recipe reads the entity table and writes the population in one
system, but the rule picked the recipe by the destination, so a source and
destination in different systems had no working branch. Stage in the
source's system instead; Node 1d asks for a location there when the
destination is elsewhere. CoCo is unchanged: its source and destination
are both Snowflake.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac

Copy link
Copy Markdown
Contributor Author

@Manushpm8 Follow-up on §3.1, fixed in bac10d9: the population is now staged in the source's system, whatever the destination. Each recipe (pyarrow for files/S3/GCS, the §7.1 SQL for Snowflake, the statement API for Databricks) already reads the entity table and writes the population inside one system, so choosing it by source makes every source/destination pair work without new code. Node 1d (kumo-data-science/SKILL.md) asks for a location in the source's system when the destination is elsewhere. A Databricks source reached through a cluster (no SQL warehouse) and a BigQuery source say staging is not covered and offer the NULL-target rows. CoCo is unchanged, since its source and destination are both Snowflake. Not run end to end on a mixed pair yet.

@kumo-isaac
kumo-isaac temporarily deployed to gha-kumo-workflow-tests October 26, 2026 18:18 — with GitHub Actions Inactive

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Note

Quiet mode is enabled, so only the most important comments were posted inline. Other review comments are grouped below.

Other comments: 1
agent-skills/skills/kumo-data-science/SKILL.md: 1

222-225: Minor · Data Integrity & Integration · Quick win

Resolve the population-staging location contradiction.

When the destination is in the source schema, Line 223 defaults to <DESTINATION>_POPULATION in that schema. Line 225 says never to stage in the source schema. State whether this location is allowed, then make the default and prohibition consistent.


Review info
Run configuration
Commits

Reviewing files that changed from the base of the PR and between 79d5f45 and bac10d9.

Files selected for processing: 2
  • agent-skills/skills/hosts/generic/runtime.md
  • agent-skills/skills/kumo-data-science/SKILL.md

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review.

Comment thread agent-skills/skills/hosts/generic/runtime.md Outdated
@kumo-isaac

Copy link
Copy Markdown
Contributor Author

@Manushpm8 Everything from your review at b5d5245 is addressed. Could you take another look?

Your point Fix
runtime.md:190 / :223 always select the entity time column f163844: TIMESTAMP is staged only when the entity table has a time column, in both the pyarrow and Databricks paths
§3.1 has no branch when source and destination are in different systems bac10d9: the population is staged in the source's system, so each recipe reads and writes in one system. Node 1d asks for a location there when the destination is elsewhere. CoCo is unchanged
kumo_finetuning_sdk.md:290 says Dtype.time 79d5f45: now Dtype.date
validate-pr wants a Change map Posted; validate-pr and PR change table pass

Two things to know: the §3.1 change hasn't been run end to end on a mixed source/destination pair yet, and a Databricks source reached through a cluster (no SQL warehouse) now reports population staging as not covered, like BigQuery. The connector pytest failure is still the BigQuery secrets, as you said.

…y client

runtime.md §3.1 said BigQuery population staging was not covered on the generic host. Stage it
like Databricks: CREATE OR REPLACE TABLE ... AS SELECT with ENTITY1 and, when the entity has a time
column, CAST(<time> AS TIMESTAMP) AS TIMESTAMP, waiting on the job, then a BigQueryConnector scoped
to the population's dataset.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 26, 2026 19:26 — with GitHub Actions Active
@kumo-isaac

Copy link
Copy Markdown
Contributor Author

Eval: generic host on GCS and BigQuery (skill e1ce213f; harness kumo-ai/kumo_skill_dev#49)

e1ce213f adds BigQuery population staging to hosts/generic/runtime.md §3.1. It uses CREATE OR REPLACE TABLE … AS SELECT through the BigQuery client, with ENTITY1 and CAST(<time> AS TIMESTAMP) AS TIMESTAMP, and waits on the job. Before this, §3.1 said BigQuery staging was "not covered". agent-skills/tests: 162 passed; package_skill.py --check: clean.

Data: the 4 eval schemas (31 tables) in gs://kumo-eval-skill and BigQuery kumo-engineering, with row counts verified.

arm intake label intake rubric codegen first try
generic/gcs 80/90 (89%) 50/90 (56%) 38/38
generic/bigquery 80/90 (89%) 47/90 (52%) 38/38
CoCo, Snowflake (10-20) 80/90 (89%) 43/90 (48%) 38/38

The intake label matches CoCo on both backends. Codegen has no hard fails; BigQuery has one soft diff (columns_dropped).

GPU (SageMaker) not run yet. It is waiting for a GCP credential for the jobs; results will follow in another comment.

Manushpm8
Manushpm8 previously approved these changes Oct 26, 2026

@Manushpm8 Manushpm8 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-reviewed at e1ce213. The three points from b5d5245 are fixed: TIMESTAMP is staged only when the entity table has a time column in the pyarrow, Databricks and BigQuery recipes; §3.1 stages in the source's system, so every source/destination pair has a working branch and Node 1d asks for a location there when the destination is elsewhere; kumo_finetuning_sdk.md:290 says Dtype.date. agent-skills/tests 162 pass and package_skill.py --check is clean for both hosts. The only red check is the two BigQuery permission tests missing secrets, same as main. One non-blocking nit inline on the population connector.

Comment thread agent-skills/skills/hosts/generic/runtime.md Outdated
FileConnector rejects a URI, so an S3 or GCS source failed after staging.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 26, 2026 20:37 — with GitHub Actions Active
@kumo-isaac
kumo-isaac enabled auto-merge (squash) October 26, 2026 20:42
kumo-isaac added a commit that referenced this pull request Oct 26, 2026
One conflict in accept/batch_inference.md's source_scope bullet, resolved by keeping #48's
connector-name qualifier and this branch's "a source not in the conversation is not missing".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 26, 2026 23:02 — with GitHub Actions Active
kumo-engine 1.0.0's BigQuery source backend raises when a connector names
no identity, though the connector's docstring says None defers to ambient
credentials. BigQueryIdentity() with no arguments is the ambient Google
credential, so naming it changes nothing else. Found by the generic-host
GPU eval on SageMaker (GCS with no identity passed; BigQuery failed at
table_names()).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 26, 2026 23:31 — with GitHub Actions Active
…med a billing project

The GPU eval found 5/38 BigQuery notebooks stopping at a
'<BIGQUERY_BILLING_PROJECT>' placeholder no user asked for.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 27, 2026 07:05 — with GitHub Actions Active
…oject, never a placeholder

The GPU eval found 7/38 notebooks leaving PROJECT_ID as a fill-in
('the GCP project billed for queries') although the conversation confirmed
kumo-engineering.<dataset>, and 9/38 adding a billing placeholder.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 27, 2026 15:45 — with GitHub Actions Active
Manushpm8
Manushpm8 previously approved these changes Oct 27, 2026

@Manushpm8 Manushpm8 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-approve at 1178a6d. The changes since e1ce213 (population connector picked from the path, BigQuery identity and project scope, the populations rules) match the SDK, and all my threads are resolved. One non-blocking nit inline in the SDK reference. Also: the SKILL.md description is 1188 characters and the Agent Skills spec caps description at 1024; #111 grows it further, so trim it in whichever lands first.

| `SnowflakeConnector` | `artifact_type=` + `table_name=` (bare name) | connector scoped to the destination database and schema; §9.1 |
| `FileConnector`, `S3Connector`, `GCSConnector` | `output_paths={'predictions': ..., 'embeddings': ...}` — the keys select the artifacts — or `artifact_type=` + `table_name=` | do not combine the two forms; a path ending in `/` is a directory and must be empty; otherwise one file, written in the format its `.parquet` or `.csv` suffix names, and `.parquet` is added when it has neither — by all three connectors; paths are relative to a rooted connector, full URIs for a rootless one |
| `BigQueryConnector` | `artifact_type=` + `table_name=` (unqualified table ID in its dataset) | predictions and embeddings only — not a model `export_config` and not a `Trainer.load_from_connector` source |
| `DatabricksConnector` | `artifact_type=` + `table_name='<schema>__kumo__<table>'` | the schema must be the connector's own; a bare table name fails; writes stage through the volume `<catalog>.<schema>._kumo_staging`, created on first use |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking: "a bare table name fails" is not right. kumo_databricks/output.py within_schema prefixes a bare table_name with the connector's schema_name, so table_name='<table>' works and lands as <schema>__kumo__<table>. Keep the row, say the prefix is applied for you. The same sentence is in #111's hosts/databricks-genie/runtime.md §4.

@kumo-isaac

Copy link
Copy Markdown
Contributor Author

Generic host on GCS and BigQuery: GPU results (SageMaker)

Each notebook ran as a SageMaker training job (T4, A10G, L4), with up to 3 repair turns. Google auth goes through Workload Identity Federation from the SageMaker role to kumo-skill-eval@kumo-engineering; no key is involved, since org policy forbids keys.

backend skill commit codegen match GPU, first try GPU, after repair without uc30 (first / after)
GCS 25c5c4e3 38/38 37/38 37/38 28/28 / 28/28
BigQuery 1178a6dc 38/38 23/38 29/38 23/28 / 28/28

In each backend, 1 case is a harness error: a dependency download was cut off at job start, so the notebook never ran. Intake is unchanged (generic_intake 57b7d3e5cbef at every commit): label 80/90 on both backends.

Skill changes from this run, all on #48:

  • 4f974c52: BigQuery connectors pass identity=kumo.BigQueryIdentity(). Without an identity, kumo-engine 1.0.0 raises names no identity, and none exists in this process, even though the BigQueryConnector docstring says None defers to ambient credentials. GCS has no such issue.
  • 25c5c4e3 → 1178a6dc: PROJECT_ID and DATASET_ID are the two parts of the confirmed project.dataset, never placeholders. Before this, 7/38 notebooks left PROJECT_ID = '<YOUR_GCP_PROJECT>' ("the project billed for queries"); now 0. A BILLING_PROJECT_ID placeholder still stops 6/38 on the first try, and one repair turn fixes each of them.

SDK bug, uc30 on BigQuery (10 cases): the BigQuery source samples with SELECT * ... LIMIT n, i.e. the head of the table. The first 10,000 rows of rig_status_events.operating_region are null (2% overall), so the column gets no statistics, and building the table raises cannot be resolved ... no statistics. The same data passes on GCS.

Details: eval/results/2026-10-26-generic-gcp.md on kumo-ai/kumo_skill_dev#49.

§1 exempted S3 and GCS from runtime-only constants but not BigQuery, so
6/38 BigQuery notebooks added a '<BILLING_PROJECT_ID>' placeholder and
stopped at the fill-in guard. BigQuery joins the exemption: it bills to
the confirmed dataset's project.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kumo-isaac
kumo-isaac deployed to gha-kumo-workflow-tests October 27, 2026 22:02 — with GitHub Actions Active
@kumo-isaac

Copy link
Copy Markdown
Contributor Author

Generic host, BigQuery GPU re-run on skill 23dae049 (§1: BigQuery joins S3 and GCS in the config-cell exemption, so the notebook adds no billing constant)

n codegen match GPU first try GPU after repair (≤3)
BigQuery, 23dae049 38 38/38 27/38 30/38
BigQuery, 1178a6dc (before) 38 38/38 23/38 29/38
BigQuery without uc30, 23dae049 28 28/28 27/28 28/28
BigQuery without uc30, 1178a6dc 28 28/28 23/28 28/28
  • A billing placeholder appears in executed code in 1/38 notebooks, down from 6/38. That notebook is videoamp-complete-terse-with-output, and one repair turn fixes it. Five replies still mention an optional billing placeholder in their prose, though their code has none.
  • uc30 (10 cases) still fails on the SDK's BigQuery head-of-table sampling. The first 10,000 rows of operating_region are null, so the column gets no statistics. GCS passes on the same data.
  • One harness error: a dependency download was cut off at job start.

Details: eval/results/2026-10-26-generic-gcp.md on kumo-ai/kumo_skill_dev#49.

This branch was successfully deployed

1 active deployment
gha-kumo-workflow-tests — 6f3cdab6 Deployed Oct 27, 2026 by kumo-isaac via import #891
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants