Can we set up the copilot action to use an ODK container?

[cmungall]

Or can we get it to use the ODK container? cc @matentzn

Originally posted by @cmungall in #5 (comment)

[cmungall]

Copying ai curation clinic notes:

Executive summary: “Co-pilot seems to work quite well (in CL)?”

We started with 2 goals:

• Try to let run copilot from within ODK
• Try to use a more deterministic approach to editing the ontology

We learned:

• It was not as easy as simply changing the base image of the copilot github action (we didnt see an obvious way to do this for DragonAI) to make it use odk (some broken paths to things copilot expects), but….
  …actually later in CL experiments we realised we could simply tell it using the run.sh wrapper! Problem solved 😄
• We updated the instructions for DragonAI to using ROBOT templates instead of the obo scripts Chris made.. and.. it seems to have worked? In any case this change was just experimental, so we reverted the instructions for the agent to use Chris approach again. This was just for testing: https://github.com/monarch-initiative/mondo/pull/9482/files (If any curator reads this, maybe check the PR and see how it looks like).

[github-actions]

Issue Summary: Integrating ODK Container with Copilot Actions

This issue explores the feasibility of configuring GitHub Copilot actions to leverage the Ontology Development Kit (ODK) container, which would provide AI agents with comprehensive ontology editing tools pre-installed.

Background Context

This question emerged from discussion on PR #5 about updating GitHub Actions setup documentation. The conversation revealed several key insights:

From the original discussion (#5):

• @matentzn confirmed that using the ODK container "would be best" because "All tools are in there that the AI might ever want to use. The tools are mostly well documented too."
• @caufieldjh suggested adapting the odk-ai repository to run as an MCP (Model Context Protocol) server
• @cmungall clarified that with Copilot, the agent infrastructure is already handled, so odk-ai adaptation might not be necessary

Technical Options Explored

1. Direct ODK Container Integration: Using the ODK container directly with GitHub Copilot actions
2. MCP Server Approach: Creating an MCP server that interfaces with the ODK container (as demonstrated in this LinkedIn article)

Current Status

• Related Issue Add documentation for using copilot #3 (closed): Successfully documented basic Copilot setup showing that scripts like obo-grep, obo-checkin, and obo-checkout can be made available to Copilot without API keys
• Related Issue Add documentation for using claude code hooks #6 (open): Covers Claude Code hooks documentation, which could be relevant for deterministic control
• The discussion in Update set-up-github-actions.md #5 was "moved to slack" due to technical complexity

Strategic Importance

The ODK container integration would be highly valuable because:

• Comprehensive Tooling: The odk-ai container extends the Ontology Development Kit and includes tools like ROBOT
• Domain Expertise: Pre-configured environment specifically designed for ontology development
• AI-Ready: Already optimized for AI-assisted ontology editing workflows

Recommendations for Implementation

1. Research Current Copilot Container Support: Investigate GitHub's latest documentation on container-based environments for Copilot agents
2. Prototype MCP Integration: Test the MCP server approach suggested by @caufieldjh
3. Document Successful Patterns: Once implemented, add comprehensive documentation to the how-tos section

This issue represents a significant opportunity to enhance AI-assisted ontology curation workflows by providing agents with specialized, well-documented ontology development tools.

[caufieldjh]

It was not as easy as simply changing the base image of the copilot github action (we didnt see an obvious way to do this for DragonAI) to make it use odk (some broken paths to things copilot expects), but….
…actually later in CL experiments we realised we could simply tell it using the run.sh wrapper! Problem solved 😄

Any record of those CL experiments? What I'm getting here is that the GH action needs to be configured to use the ODK image and the instructions need to explicitly say to use run.sh. Did that also require some description of what's in the ODK image?

[matentzn]

Sorry, wires crossed: when I said "we realised we could simply tell it using the run.sh" what I mean was that copilot all by itself figured out that it should be using run.sh, and tried using it as well.

The realisation came when we saw in the CL copilot log: https://github.com/obophenotype/cell-ontology/actions/runs/17074918795/job/48413600148#step:32:922

In any case, its on the agenda for next time to try and see if we can really get the action to do what is necessary. In particular we will probably have to install docker, but we will see.

[matentzn]

Did a quick experiment with ODK and copilot here

matentzn/ai-curation-testing#2 (comment)

Works without instructions. Indeed I don't get why it took copilot 4 minutes to use ODK, despite it being the first instruction in the instructions MD file

[matentzn]

https://github.com/matentzn/ai-curation-testing/blob/main/.github/copilot-instructions.md

[caufieldjh]

Wow, it really works!
Strange that the agent gets distracted by trying to find ROBOT locally when the instructions file is so clear about what to do instead.
The instructions file can take a applyTo argument in its frontmatter - https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions#using-one-or-more-instructionsmd-files-1
I wonder if that can help to prioritize the instructions (that is, beyond literally telling it "remember to follow the instructions" like you did)

[matentzn]

I now added warnings to read instructions first front right and center: matentzn/ai-curation-testing@0d38ee6

This made sure that copilot used robot through ODK in the first attempt..

• For some reason, copilot is not able to open an ontology from a PURL through docker (gets blocked). Weird