Skip to content

Add AI skill to check current repository against upstream APIs#1460

Open
timsaucer wants to merge 8 commits intoapache:mainfrom
timsaucer:feat/skill-check-upstream
Open

Add AI skill to check current repository against upstream APIs#1460
timsaucer wants to merge 8 commits intoapache:mainfrom
timsaucer:feat/skill-check-upstream

Conversation

@timsaucer
Copy link
Copy Markdown
Member

Copy link
Copy Markdown
Contributor

@kevinjqliu kevinjqliu left a comment

Choose a reason for hiding this comment

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

LGTM!

love to see this, i might adopt it for other projects 😄

@timsaucer
Copy link
Copy Markdown
Member Author

Thanks for the review @kevinjqliu ! I think this was really helpful to finding some missing functions. I'm sure we'll want to make changes to it, but I also think this is a good starting point.

timsaucer and others added 4 commits March 29, 2026 20:19
Document the full FFI type pipeline (Rust PyO3 wrapper → Protocol type →
Python wrapper → ABC base class → exports → example) and catalog which
upstream datafusion-ffi types are supported, which have been evaluated as
not needing direct exposure, and how to check for new gaps.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add "ffi types" to the argument-hint and description so users can invoke
the skill with `/check-upstream ffi types`. Also add pipeline verification
step to ensure each supported FFI type has the full end-to-end chain
(PyO3 wrapper, Protocol, Python wrapper with type hints, ABC, exports).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Section 7 (FFI Types) was incorrectly placed after the Output Format and
Implementation Pattern sections. Move it to sit after Section 6
(SessionContext Methods), consistent with the other checkable areas.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The supported FFI types list would go stale as new types are added.
Replace it with a grep instruction to discover them at check time,
keeping only the "evaluated and not requiring exposure" list which
captures rationale not derivable from code.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Functions exposed in Python (e.g., as aliases of other Rust bindings)
were being falsely reported as missing because they lacked a dedicated
#[pyfunction] in Rust. The user-facing API is the Python layer, so
coverage should be measured there.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@timsaucer
Copy link
Copy Markdown
Member Author

I'm going to hold off on merging this until I've run through all of those generated issues. I've already needed a couple of updates.

show_limit is covered by DataFrame.show() and with_param_values is
covered by SessionContext.sql(param_values=...), so neither needs
separate exposure.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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