ci: add agnix validation to CI

[avifenesh]

Summary

• Add .agnix.toml configuration with repo-specific false positive suppressions
• Add agnix validation job to CI pipeline via reusable ci-agnix.yml workflow
• Validates agent configurations (CLAUDE.md, AGENTS.md, skills, hooks, MCP, plugins) on push and PR

Test plan

• CI passes with agnix validation step
• No false positive warnings in agnix output

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces agnix validation into the continuous integration pipeline. The primary goal is to automatically check the integrity and correctness of agent configurations, ensuring higher code quality and preventing potential issues by catching errors early in the development cycle.

Highlights

• .agnix.toml configuration: Added a new .agnix.toml configuration file, including repository-specific false positive suppressions.
• CI pipeline integration: Integrated an agnix validation job into the CI pipeline using a reusable ci-agnix.yml workflow.
• Agent configuration validation: Enabled validation of agent configurations (CLAUDE.md, AGENTS.md, skills, hooks, MCP, plugins) on push and pull requests.

Changelog

• .agnix.toml
  • Created the initial .agnix.toml configuration file.
  • Configured agnix severity to "Warning" and excluded node_modules and .git directories.
  • Disabled the "XP-003" rule, noting it as intentional for cross-platform research documentation.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/ci.yml

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces agnix validation by adding the .agnix.toml configuration file. The configuration is a good start, but I have a suggestion regarding the global disabling of the XP-003 rule. To make the validation more robust, it would be better to scope the rule suppression to the specific file that causes the false positive, if agnix supports such configuration. This will prevent unintentionally hiding real issues in other parts of the codebase.

_{Note: Security Review has been skipped due to the limited scope of the PR.}

[gemini-code-assist]

Globally disabling the XP-003 rule for an issue in a single file (lib/cross-platform/RESEARCH.md) could hide valid findings in other files. It's recommended to investigate if agnix supports more granular rule suppression, such as per-file or in-code comments. Applying the suppression only where it's needed would make your CI validation more robust.