(minor) Feedback on conda-forge skill

[maresb]

Hey, I'm very interested in your conda-forge skill, and I wanted to provide some feedback for potential improvement based on a simple use case of creating a pytensor-distributions staged recipe conda-forge/staged-recipes#32479

It went mostly smoothly, but I noticed that the agent hit a few points of confusion along the way.

Consider your experience as an LLM creating this PR and using the conda-forge skill. What information would have made this process easier? I am considering revising the conda-forge skill.

I also got some feedback from ocefpaf regarding testing both min and current Python versions for Python recipes. In parallel I'm looking into making the corresponding change in conda-recipe-manager that would effectively downstream it to here.

Answer:

---

Here's my reflection on friction points and what would have helped:

1. The v1 about field names aren't documented in the skill

I hit a build failure because I used doc_url and dev_url (the v0/meta.yaml names), and rattler-build rejected them. The v1 format uses documentation and repository instead. The skill's Python example template doesn't include these fields at all, and the skill never lists the valid about fields. A small note like "v1 uses documentation and repository instead of doc_url/dev_url" would have saved a round-trip.

2. The example recipe template could be more complete

The Python example in example-recipe-python.md omits schema_version: 1, the context.python_min override, documentation/repository in about, and python_version in the test section. These are all things grayskull generates correctly, but if I were writing a recipe from scratch (or validating grayskull's output), the template would be my reference. Having a fully "canonical" example that includes all common fields would reduce guesswork.

3. Grayskull output is good enough that the skill could say "trust it more"

Grayskull produced a nearly perfect recipe — the only thing I changed was adding documentation/repository URLs. The skill currently positions grayskull as a starting point and emphasizes manual rules (SHA256 computation, SPDX licenses, etc.), but for the common case of a well-maintained PyPI package, grayskull already handles all of that. A note like "For Python packages, grayskull's v1 output typically handles checksums, license detection, pinning conventions, and build backend selection correctly — focus your review on the about metadata and verifying dependencies" would help calibrate effort.

4. The --variant python_min=3.11 value should match the recipe, not always be 3.10

The skill says to pass --variant python_min=3.10 for noarch builds. But since this recipe overrides python_min to 3.11 in its context, the variant override is actually unnecessary (the context value takes precedence). This interaction is confusing. It would help to clarify: "Pass --variant python_min=<VALUE> matching whatever python_min your recipe needs. If the recipe already sets python_min in context, the variant override is unnecessary."

5. No guidance on when the repo is already cloned/forked

The skill starts with gh repo fork ... --clone=true, but in this session I was already inside a cloned staged-recipes repo. I had to mentally skip that step. A small note like "If you're already in a staged-recipes clone, just create a branch" would make the flow more natural for the common case.

6. Minor: the skill doesn't mention cleaning up output/ after a successful build

After rattler-build build, an output/ directory with cached sources and built packages is left behind. It's gitignored, but worth noting so the LLM doesn't accidentally commit it or get confused by its presence.

In summary, the highest-value additions would be:

• Document the v1-specific about field names (documentation, repository instead of doc_url, dev_url)
• Make the Python example template fully canonical (include schema_version, python_min override, documentation/repository, python_version in tests)
• Clarify the python_min variant override behavior (when it's needed vs. when the recipe context handles it)

[moritzwilksch]

Thank you for the feedback, very valuable to have some failure modes written out like this. Would you be willing to open a PR?