Add agent skill for adding c-api functions by bschoenmaeckers · Pull Request #8001 · RustPython/RustPython

bschoenmaeckers

28-28: ⚡ Quick win

Clarify "direct contract assumptions" terminology.

The phrase "direct contract assumptions" is ambiguous in the context of FFI safety. For AI agents implementing unsafe FFI code, clearer guidance would help prevent safety issues.

Consider rephrasing to be more explicit:

-7. Prefer direct contract assumptions over defensive null checks unless required by the established local style.
+7. Follow the C-API contract directly (e.g., assume non-null where documented) rather than adding defensive checks, unless existing capi modules show a different pattern.

This makes it clear that the guidance is about following documented C-API contracts, not about skipping safety checks arbitrarily.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.agents/skills/rustpython-capi-expansion/SKILL.md at line 28, Replace the
ambiguous phrase "direct contract assumptions" in SKILL.md with an explicit
wording that directs authors to follow the documented C-API/FFI contract
precisely (e.g., "follow documented C-API contracts and preconditions exactly")
and clarify that this guidance means trusting declared non-null/non-ownership
guarantees from the foreign API rather than omitting safety checks arbitrarily;
update the surrounding sentence to mention "FFI/C-API documented preconditions
(e.g., non-null pointers, lifetime/ownership rules)" so readers know the scope
and exceptions.

3-3: 💤 Low value

Consider shortening the description field.

The description spans 277 characters and mixes multiple concerns (what, where, when, and examples). Some YAML parsers or metadata systems may have length constraints. Consider moving detailed examples to the skill body and keeping the description focused on when to trigger this skill.

Example refactor:

-description: Implement missing RustPython C-API functions in crates/capi using the pyo3-ffi header split mapping (`pyo3-ffi/src/*.rs`, mirroring CPython C API headers). Use this whenever the user asks to add or port C-API functions (for example from setobject.h, dictobject.h, unicodeobject.h) or add capi tests.
+description: Implement missing RustPython C-API functions using pyo3-ffi header mappings. Triggered when user requests C-API function additions or capi tests.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.agents/skills/rustpython-capi-expansion/SKILL.md at line 3, The description
field is too long and mixes examples and implementation details; shorten it to a
single focused trigger statement (e.g., "Trigger when implementing RustPython
C-API functions in crates/capi using pyo3-ffi header mappings") and move
examples and file/path details (like "pyo3-ffi/src/*.rs", "crates/capi", and
example headers such as setobject.h, dictobject.h, unicodeobject.h) into the
SKILL.md body or examples section so the description stays concise and under
length limits.