Skip to content

Epic: next-wave AI workflow, governance, and contributor-control improvements #3691

Description

@cmungall

Background

PR #3690 established the new GitHub App + Claude Code OAuth path for Uberon AI workflows. This issue tracks the next wave of work now that the basic automation path is in place.

The goal here is not to blindly copy other repos, but to decide which patterns from GO / dismech / LinkML actually make sense for Uberon's ontology-editing and review workflow.

Background research

1. GO precedent for moving .claude/agents to .claude/skills

The GO repo already did this in:

The key rationale from that PR is highly relevant here:

  • skills load specialist instructions directly into the main conversation context
  • this avoids a pre-digestion / orchestration problem where a generalist coordinator short-circuits the specialist's intended analysis path before the specialist instructions are actually followed

This matches the current hypothesis for Uberon: there may be poor handoff and division of labor when initiating subagents for relatively general ontology-editing tasks.

Current Uberon agent files that would need review/migration:

  • .claude/agents/deep-research-specialist.md
  • .claude/agents/design-pattern-advisor.md
  • .claude/agents/identifier-validator.md
  • .claude/agents/metadata-checker.md
  • .claude/agents/ontology-reasoner.md
  • .claude/agents/task-coordinator.md

2. dismech has a broader agent-automation surface worth evaluating

Relevant dismech workflows include:

  • curation-scanner.yml (scheduled every 4 hours): scans unassigned curation issues/PRs and chooses one item to advance
  • post-review-agent.yml (daily): scans recent PR review comments and creates suggested fixes / replies / follow-up issues
  • stale-pr-reassign.yml (daily): reassigns stale PRs with unresolved requested changes to the AI agent
  • weekly-compliance.yaml (weekly): performs periodic quality-improvement work across low-performing files
  • claude-issue-triage.yml and claude-issue-summarize.yml
  • claude-code-review.yml

Representative links:

These should be treated as a menu of patterns, not a copy-paste target. Some of them assume a LinkML/dismech file structure and review cadence that Uberon does not share.

3. Contributor opt-out is probably worth designing explicitly

Now that Uberon has AI-triggered review / implementation capability, it may be useful to define a contributor-controlled opt-out mechanism for people who do not want AI review, AI implementation help, or automated reassignment on a given issue/PR.

This likely needs to be explicit and machine-readable (for example via label, PR metadata, or issue/PR body marker), and it should be clear which automations it disables.

4. LinkML's AI Covenant is a concrete governance reference

LinkML has an explicit AI Covenant here:

Key norms in that document:

  • contributors own all AI-assisted contributions and must understand / defend them
  • AI review tools are suggestions, not human review
  • PR owners may close AI comments at their discretion
  • AI systems should not autonomously participate in project discussions as an independent voice
  • disclosure matters especially when proposing fixes in unfamiliar code or when the origin of an idea matters for review quality

This is a useful concrete reference for deciding whether Uberon wants its own version of an AI-use policy / covenant.

Workstreams

1. Migrate .claude/agents to .claude/skills

Questions:

  • Which current Uberon agent definitions are actually specialized enough to work better as skills?
  • Which should be removed, merged, or renamed rather than migrated 1:1?
  • Should task-coordinator remain a role concept, or should that orchestration responsibility be removed in favor of direct skill invocation?

Deliverable:

  • proposed migration plan referencing the GO PR above
  • follow-up PR to move the surviving agent content into skills and update any repo instructions accordingly

2. Decide which dismech-style automations are worth porting to Uberon

Candidates to evaluate:

  • scheduled issue/PR scanning
  • post-review cleanup / suggested-fix bot behavior
  • stale PR reassignment / rescue
  • issue triage / summarization
  • periodic quality/compliance sweeps

Questions:

  • Which of these would actually reduce maintainer burden for Uberon?
  • Which would create noise or bad ontology edits if ported naively?
  • Which require additional repo conventions, labels, or branch-management rules first?

Deliverable:

  • shortlist of recommended automations for Uberon
  • explicit reject/defer list for patterns that do not fit this repo

3. Define an AI opt-out mechanism

Questions:

  • Should opt-out apply to review only, implementation only, or all AI automation?
  • Should opt-out be per issue/PR, per author, or both?
  • What is the least confusing marker: label, checkbox, body trailer, or something else?
  • How should opt-out interact with scheduled workflows and assignment-based triggers?

Deliverable:

  • concrete opt-out spec with exact semantics and workflow hooks

4. Evaluate adopting/adapting a LinkML-style AI covenant for Uberon

Questions:

  • Does Uberon want an explicit policy for AI-assisted contributions and AI-generated review?
  • If yes, should it be nearly verbatim from LinkML, or tailored for ontology-editing and GitHub-agent workflows?
  • If adopted, where should it live and which docs/templates/workflows should reference it?

Deliverable:

  • recommendation: adopt / adapt / defer
  • if adopted, follow-up PR adding the document and cross-links from repo docs/templates

Proposed acceptance criteria for this epic

  • Review the GO skills migration precedent and decide whether Uberon should follow it
  • Inventory and classify the current Uberon .claude/agents/* files
  • Review dismech automation workflows and recommend which ones are appropriate for Uberon
  • Define a contributor-facing AI opt-out mechanism
  • Evaluate whether Uberon should adopt a LinkML-style AI covenant
  • Break approved workstreams into specific follow-up issues / PRs

Notes

My recommendation is to treat this as an umbrella / design issue first, and then split implementation into smaller follow-ups once the repo owners are aligned on the intended behavior.

@dragon-ai-agent

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions