mirror of
https://github.com/Significant-Gravitas/AutoGPT.git
synced 2026-04-30 03:00:41 -04:00
ab0b537cc7
### Changes 🏗️ The `find_block` AutoPilot tool was returning ~90K characters per response (10 blocks). The bloat came from including full JSON Schema objects (`input_schema`, `output_schema`) with all nested `$defs`, `anyOf`, and type definitions for every block. **What changed:** - **`BlockInfoSummary` model**: Removed `input_schema` (raw JSON Schema), `output_schema` (raw JSON Schema), and `categories`. Added `output_fields` (compact field-level summaries matching the existing `required_inputs` format). - **`BlockListResponse` model**: Removed `usage_hint` (info now in `message`). - **`FindBlockTool._execute()`**: Now extracts compact `output_fields` from output schema properties instead of including the entire raw schema. Credentials handling is unchanged. - **Test**: Added `test_response_size_average_chars_per_block` with realistic block schemas (HTTP, Email, Claude Code) to measure and assert response size stays under 2K chars/block. - **`CLAUDE.md`**: Clarified `dev` vs `master` branching strategy. **Result:** Average response size reduced from ~9,000 to ~1,300 chars per block (~85% reduction). This directly reduces LLM token consumption, latency, and API costs for AutoPilot interactions. ### Checklist 📋 #### For code changes: - [x] I have clearly listed my changes in the PR description - [x] I have made a test plan - [x] I have tested my changes according to the test plan: - [x] Verified models import and serialize correctly - [x] Verified response size: 3,970 chars for 3 realistic blocks (avg 1,323/block) - [x] Lint (`ruff check`) and type check (`pyright`) pass on changed files - [x] Frontend compatibility preserved: `blocks[].name` and `count` fields retained for `block_list` handler --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Toran Bruce Richards <toran.richards@gmail.com>
96 lines
3.6 KiB
Markdown
96 lines
3.6 KiB
Markdown
# CLAUDE.md
|
|
|
|
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
|
|
|
## Repository Overview
|
|
|
|
AutoGPT Platform is a monorepo containing:
|
|
|
|
- **Backend** (`backend`): Python FastAPI server with async support
|
|
- **Frontend** (`frontend`): Next.js React application
|
|
- **Shared Libraries** (`autogpt_libs`): Common Python utilities
|
|
|
|
## Component Documentation
|
|
|
|
- **Backend**: See @backend/CLAUDE.md for backend-specific commands, architecture, and development tasks
|
|
- **Frontend**: See @frontend/CLAUDE.md for frontend-specific commands, architecture, and development patterns
|
|
|
|
## Key Concepts
|
|
|
|
1. **Agent Graphs**: Workflow definitions stored as JSON, executed by the backend
|
|
2. **Blocks**: Reusable components in `backend/backend/blocks/` that perform specific tasks
|
|
3. **Integrations**: OAuth and API connections stored per user
|
|
4. **Store**: Marketplace for sharing agent templates
|
|
5. **Virus Scanning**: ClamAV integration for file upload security
|
|
|
|
### Environment Configuration
|
|
|
|
#### Configuration Files
|
|
|
|
- **Backend**: `backend/.env.default` (defaults) → `backend/.env` (user overrides)
|
|
- **Frontend**: `frontend/.env.default` (defaults) → `frontend/.env` (user overrides)
|
|
- **Platform**: `.env.default` (Supabase/shared defaults) → `.env` (user overrides)
|
|
|
|
#### Docker Environment Loading Order
|
|
|
|
1. `.env.default` files provide base configuration (tracked in git)
|
|
2. `.env` files provide user-specific overrides (gitignored)
|
|
3. Docker Compose `environment:` sections provide service-specific overrides
|
|
4. Shell environment variables have highest precedence
|
|
|
|
#### Key Points
|
|
|
|
- All services use hardcoded defaults in docker-compose files (no `${VARIABLE}` substitutions)
|
|
- The `env_file` directive loads variables INTO containers at runtime
|
|
- Backend/Frontend services use YAML anchors for consistent configuration
|
|
- Supabase services (`db/docker/docker-compose.yml`) follow the same pattern
|
|
|
|
### Branching Strategy
|
|
|
|
- **`dev`** is the main development branch. All PRs should target `dev`.
|
|
- **`master`** is the production branch. Only used for production releases.
|
|
|
|
### Creating Pull Requests
|
|
|
|
- Create the PR against the `dev` branch of the repository.
|
|
- Ensure the branch name is descriptive (e.g., `feature/add-new-block`)
|
|
- Use conventional commit messages (see below)
|
|
- Fill out the .github/PULL_REQUEST_TEMPLATE.md template as the PR description
|
|
- Run the github pre-commit hooks to ensure code quality.
|
|
|
|
### Reviewing/Revising Pull Requests
|
|
|
|
- When the user runs /pr-comments or tries to fetch them, also run gh api /repos/Significant-Gravitas/AutoGPT/pulls/[issuenum]/reviews to get the reviews
|
|
- Use gh api /repos/Significant-Gravitas/AutoGPT/pulls/[issuenum]/reviews/[review_id]/comments to get the review contents
|
|
- Use gh api /repos/Significant-Gravitas/AutoGPT/issues/9924/comments to get the pr specific comments
|
|
|
|
### Conventional Commits
|
|
|
|
Use this format for commit messages and Pull Request titles:
|
|
|
|
**Conventional Commit Types:**
|
|
|
|
- `feat`: Introduces a new feature to the codebase
|
|
- `fix`: Patches a bug in the codebase
|
|
- `refactor`: Code change that neither fixes a bug nor adds a feature; also applies to removing features
|
|
- `ci`: Changes to CI configuration
|
|
- `docs`: Documentation-only changes
|
|
- `dx`: Improvements to the developer experience
|
|
|
|
**Recommended Base Scopes:**
|
|
|
|
- `platform`: Changes affecting both frontend and backend
|
|
- `frontend`
|
|
- `backend`
|
|
- `infra`
|
|
- `blocks`: Modifications/additions of individual blocks
|
|
|
|
**Subscope Examples:**
|
|
|
|
- `backend/executor`
|
|
- `backend/db`
|
|
- `frontend/builder` (includes changes to the block UI component)
|
|
- `infra/prod`
|
|
|
|
Use these scopes and subscopes for clarity and consistency in commit messages.
|