Hi folks, To follow on from the initial AGENTS.md file discussed in earlier emails, I have fleshed out further skills files. Looking to the future, there are projects which are automating significant parts of their maintainer processes. Airflow now automates a lot of security triage. Micronaut is experimenting with using microcode to automate the triaging and fixing of Micronaut issues.
I don't think we currently have the same urgency for triaging and fixing issues as Airflow and Micronaut. So, I set a smaller goal of potentially automating the discovery of issues that are in our backlog that are already fixed. This requires understanding which issues include some kind of reproducer and then how to run the reproducer on various Groovy (and potentially JDK) versions. This already has reasonable complexity as some issues only arise when run with indy, or with certain system properties, or many other things. I have asked for AI assistant in putting together the skills we'd need on the path to that goal. I have cross-checked some of the content but it still needs further review. In particular, some parts of e.g. GOVERNANCE.md state what we might like to do, not necessarily what we religiously do as a project today. Before progressing further, I think it is worth others seeing where this is heading and deciding which bits we want to take on board as a project. When preparing the files, I asked AI to give priority to documentation for humans (first list below) and then the skills for AI should reference those documents. The rest of the document summarise the current state of play. If we have specific parts to discuss, I'd suggest we split off separate discussion emails. Eventually, I will try to further automate the above mentioned goal. This isn't necessarily something the project needs to take on board yet. I am keen to do this to provide feedback to some other AI initiatives happening in parallel within other parts of the ASF. So I might try to set up microcode, or parts of the airflow setup at some point. The summary of files for humans: * CONTRIBUTING.md — contributor workflow (build, tests, fix workflow, JIRA mechanics, triage, PR submission, AI tooling pointer) * ARCHITECTURE.md — codebase structure (layout, compilation pipeline, extension points, code conventions, generated code, build infrastructure, public API package boundaries) * COMPATIBILITY.md — stability semantics (tiers, breaking-change definition, deprecation, japicmp check, SPI surface) * GOVERNANCE.md — decision-making (Apache Way, channels, consensus, review modes, wait periods, releases) The summary of the skill files: * groovy-build — AI guardrails for Gradle build changes; cites ARCHITECTURE.md's Build infrastructure section. * groovy-fix-workflow — AI guardrails for implementing a JIRA-tracked fix; hand-back to a committer, no autonomous PR or merge. * groovy-internals — AI guardrails for compiler and runtime changes (parser, AST, type checker, transforms, class generation). * groovy-jira — AI guardrails for working with JIRA; drafts only, no autonomous posting or transitions. * groovy-reassess — Bulk reassessment campaign over old JIRA issues; classifies and reports, never mutates. * groovy-reproducer — Per-issue extraction and running of reproducer code from a JIRA report. * groovy-skills — Meta-skill for authoring SKILL.md files. * groovy-tests — AI guardrails for writing tests; regression tests must fail on master before the fix. * groovy-triage — AI guardrails for first-pass triage of JIRA issues and PRs; advisory output only. * groovysh — AI guardrails for the groovy-groovysh subproject (JLine forks, terminal-aware tests). These files have been committed to master on a COMMIT-THEN-REVIEW basis. Feedback welcome. Cheers, Paul.
