Replies: 3 comments
-
|
Thanks for the question. Skill files are plain markdown, so feeding them to another model as reference would give reasonable output for most individual prompts. What doesn't transfer cleanly is the runtime layer: agent dispatch, skill loading, tool routing, hook wiring. Each CLI shapes those differently, so a port ends up closer to a rewrite of the orchestration than a copy of the content. As for why this one targets CC: it's just the runtime I'm on day-to-day, so that's what got built and maintained. There's also a Codex variant published separately as academic-research-skills-codex, in case that's useful. If you'd like to run the content against a different model, cloning the repo and using the skill files as a prompt library is totally reasonable. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, why not create a version for OpenCode? It is model-agnostic and would open up many more possibilities. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
I don't use OpenCode myself, and as a solo maintainer I'm already keeping two distributions in sync: this one and academic-research-skills-codex. Taking on a third runtime to maintain isn't something I can do. You're welcome to fork it and build an OpenCode adapter. The skill files are plain markdown, so that's a reasonable path if you want OpenCode support. The license (CC-BY-NC-4.0) allows non-commercial forks. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm curious why this project only works with Claude code. What is the fundamental limit to transplant this content to work with other LLM, such GPT 5.5? For example, if people copy the skill files and feed them as reference to GPT, GPT will return reasonable result, right?
Beta Was this translation helpful? Give feedback.
All reactions