docs: restructure AI documentation into .agents and .claude directories#726
docs: restructure AI documentation into .agents and .claude directories#726kabir wants to merge 1 commit intoa2aproject:mainfrom
Conversation
kabir
commented
Mar 11, 2026
- Move skills to .agents/skills for universal agent access
- Create .claude/architecture with EventQueue deep-dive docs
- Add CLAUDE.md symlink to AGENTS.md for auto-discovery
- Link .claude/skills to .agents/skills for Claude compatibility
- Protect .claude/settings.local.json in .gitignore
- Move skills to .agents/skills for universal agent access - Create .claude/architecture with EventQueue deep-dive docs - Add CLAUDE.md symlink to AGENTS.md for auto-discovery - Link .claude/skills to .agents/skills for Claude compatibility - Protect .claude/settings.local.json in .gitignore Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! 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 focuses on restructuring the AI documentation to enhance organization and accessibility. It introduces dedicated directories for agents and Claude-specific documentation, improves skill management, provides a deep dive into the EventQueue architecture, and ensures Claude compatibility. Additionally, it protects local configuration files from being committed. Highlights
Changelog
Activity
Using Gemini Code AssistThe 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
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 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
|
|
Warning Gemini is experiencing higher than usual traffic and was unable to create the review. Please try again in a few hours by commenting |
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request significantly restructures the project's documentation, moving skill definitions and adding extensive new deep-dive documents for the EventQueue architecture. The new documentation is well-organized and detailed. My review focuses on ensuring the accuracy of the technical descriptions and code examples within these new documents. I've identified a few areas where the code snippets could be aligned more closely with the actual implementation to prevent potential confusion for developers.
| if (event instanceof Message || isFinalEvent(event)) { | ||
| if (!interrupted) { | ||
| cleanup(queue, task, false); // Immediate: wait for agent, close queue | ||
| } else { | ||
| cleanup(queue, task, true); // Async: close in background (AUTH_REQUIRED case) | ||
| } | ||
| } |
There was a problem hiding this comment.
The logic presented in "Non-Streaming Cleanup Decision" for choosing between immediate and async cleanup doesn't directly map to the implementation in DefaultRequestHandler.java. The actual cleanup is initiated via cleanupProducer in a finally block and is always asynchronous. The decision logic in the documentation could be confusing for developers trying to trace the code. It would be beneficial to clarify that this is a conceptual model or align it more closely with the implementation.
| private void cleanup(EventQueue queue, Task task, boolean async) { | ||
| Runnable cleanupTask = () -> { | ||
| agentFuture.join(); // Wait for agent to finish | ||
| queue.close(); // Close ChildQueue (triggers Level 2 check) | ||
| }; | ||
|
|
||
| if (async) { | ||
| CompletableFuture.runAsync(cleanupTask, executor); | ||
| } else { | ||
| cleanupTask.run(); | ||
| } | ||
| } |
There was a problem hiding this comment.
The code snippet for cleanup in the "Cleanup Implementation" section does not accurately reflect the implementation in DefaultRequestHandler.java. The actual method is cleanupProducer, and it uses CompletableFuture.allOf to wait for agent and consumption futures, rather than a simple agentFuture.join(). This simplification could be misleading about the asynchronous nature of the cleanup. Please consider updating the snippet to better represent the implementation.
| public void enqueueEvent(Event event) { | ||
| super.enqueueEvent(event); // Enqueue to MainEventBus | ||
| children.forEach(child -> child.internalEnqueueEvent(event)); // Copy to ChildQueues | ||
| if (enqueueHook != null) { | ||
| enqueueHook.onEnqueue(event); // Replication hook | ||
| } | ||
| } |
There was a problem hiding this comment.
The code snippet for MainQueue.enqueueEvent in the "Tapping (Multiple Consumers)" scenario is misleading. It suggests that events are immediately distributed to child queues upon calling enqueueEvent. However, the actual implementation is asynchronous: enqueueEvent submits the event to the MainEventBus, and a separate MainEventBusProcessor thread persists the event before distributing it to child queues. This asynchronicity is a core part of the architecture, and the documentation should reflect it to avoid confusion.