Integrate FlyDSL kernel authoring using its upstream skill

[danielholanda]

Note

Recreated from #266 by @coderfeli (Felix Li) so CI can run from a same-repo branch instead of a fork. All credit goes to @coderfeli: the commits are unchanged and keep their original authorship. Content and description below are identical to #266.

What

Integrate FlyDSL kernel authoring through an installable catalog entry that loads the existing skill in FlyDSL.

How

• Import the small source-owned entry point from ROCm/FlyDSL#1298, with federation provenance, a skill card, and evaluation cases.
• Reuse the user's FlyDSL checkout, or fetch one into their cache, then read the native skill. Its reference and examples remain maintained in FlyDSL.
• Add a README catalog/source link and an installation-and-review walkthrough.

This follows the source-owned entry-point approach used by Hyperloom in #213. Try this PR before it merges:

npx skills add \
  'coderfeli/skills/skills/flydsl-kernel-authoring#feat/federate-flydsl-kernel-authoring' \
  --skill flydsl-kernel-authoring --agent claude-code

Test

• Catalog structural, dataset, reference, manifest, and whitespace checks pass.
• CLI discovery, install, reinstall, and removal pass on Linux for Claude Code, Codex, Cursor, and Windsurf, in copy and symlink modes.
• Installation directly from the pushed PR branch passes for all four agents.
• Local routing: 15/15 cases pass with both FlyDSL entries installed; the revised pipeline prompt also passes a targeted rerun. The runner also registered built-in skills, so catalog CI should confirm routing in its own environment.
• Both behavioral cases pass (12/12 expectations) against a fresh FlyDSL checkout, verifying native-skill loading, runtime branch review, and pipeline state/LDS dominance. The pipeline expectation is based on the current frontend: explicit init preserves loop-carried state even with Python integer bounds. Validation is a source review, with no GPU execution claim.
• Upstream structural CI passes. The native FlyDSL skill is unchanged.

Before merge

FlyDSL product approval is still required by Federation guard, and fork workflows need maintainer approval. After the source entry point in ROCm/FlyDSL#1298 merges, switch the federation branch to main and re-import.

[github-actions]

Product repo approval required

No entry in .github/skill_owners.json covers these skills, so they cannot be federated yet:

• flydsl-kernel-authoring from ROCm/FlyDSL/skills/flydsl-kernel-authoring

1. Open a Product repo approval issue for ROCm/FlyDSL. If the repo is a super-repo of unrelated projects, name the project's directory instead, as owner/repo/sub/dir.
2. The engineering owner and the product release owner each comment /approve on it.
3. Merge the registry pull request that opens, then push here again.

Skills already in the catalog are unaffected; this applies to the ones this pull request adds.

[danielholanda]

Status

Closing for now, waiting for the following PRs to merge. After that, this PR can be simplified to simply mirror FlyDSL like all other skills.

FLyDLS PR#1305 - Ensure flydsl-kernel-authoring follows industry standard requirements/recommendations and passes our CI tests
FLyDLS PR#1304 - Add evals, skill cards, and test workflow