Two files, one repository
Significant-Gravitas/AutoGPT ships 3 formats across 12 indexed files. The question worth asking is whether the second one says anything the first does not.
| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 6 | 10 | 0% |
| Commands | 0 | 7 | 4 | 0% |
| Section tags | 3 | 2 | 4 | 33% |
What each file covers
Sections
0 shared · 6 only in A · 10 only in B- − AutoGPT Platform Contribution Guide
- − Directory overview
- − Code style
- − Frontend guidelines:
- − Testing
- − Pull requests
- + AutoGPT Platform
- + Repository Overview
- + Component Documentation
- + Key Concepts
- + Environment Configuration
- + Branching Strategy
- + Creating Pull Requests
- + Test-Driven Development (TDD)
- + Reviewing/Revising Pull Requests
- + Conventional Commits
Commands
0 shared · 7 only in A · 4 only in B- − poetry run format
- − pnpm format
- − pnpm generate:api
- − poetry run test
- − pnpm test:unit
- − pnpm test
- − pnpm test-ui
- + gh pr create --title "..." --body-file "$PR_BODY" --base dev
- + gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginate
- + gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate
- + gh api repos/Significant-Gravitas/AutoGPT/issues/{N}/comments
Section tags
3 shared · 2 only in A · 4 only in B- − code-style
- − do-not
- + setup
- + testing-strategy
- + ui
- + docs
- test
- architecture
- git-pr
Line diff
Significant-Gravitas/AutoGPT · AGENTS.md
@@ −1 @@
1# AutoGPT Platform Contribution Guide
2
3This guide provides context for coding agents when updating the **autogpt_platform** folder.
4
5## Directory overview
6
7- `autogpt_platform/backend` – FastAPI based backend service.
8- `autogpt_platform/autogpt_libs` – Shared Python libraries.
9- `autogpt_platform/frontend` – Next.js + Typescript frontend.
10- `autogpt_platform/docker-compose.yml` – development stack.
11
12See `docs/content/platform/getting-started.md` for setup instructions.
13
14## Code style
15
16- Format Python code with `poetry run format`.
17- Format frontend code using `pnpm format`.
18
19## Frontend guidelines:
20
21See `/frontend/CONTRIBUTING.md` for complete patterns. Quick reference:
22
231. **Pages**: Create in `src/app/(platform)/feature-name/page.tsx`
24 - Add `usePageName.ts` hook for logic
25 - Put sub-components in local `components/` folder
262. **Components**: Structure as `ComponentName/ComponentName.tsx` + `useComponentName.ts` + `helpers.ts`
27 - Use design system components from `src/components/` (atoms, molecules, organisms)
28 - Never use `src/components/__legacy__/*`
293. **Data fetching**: Use generated API hooks from `@/app/api/__generated__/endpoints/`
30 - Regenerate with `pnpm generate:api`
31 - Pattern: `use{Method}{Version}{OperationName}`
324. **Styling**: Tailwind CSS only, use design tokens, Phosphor Icons only
335. **Testing**: Integration tests (Vitest + RTL + MSW) are the default (~90%, page-level). Playwright for E2E critical flows. Storybook for design system components. See `autogpt_platform/frontend/TESTING.md`
346. **Code conventions**: Function declarations (not arrow functions) for components/handlers
35
36- Component props should be `interface Props { ... }` (not exported) unless the interface needs to be used outside the component
37- Separate render logic from business logic (component.tsx + useComponent.ts + helpers.ts)
38- Colocate state when possible and avoid creating large components, use sub-components ( local `/components` folder next to the parent component ) when sensible
39- Avoid large hooks, abstract logic into `helpers.ts` files when sensible
40- Use function declarations for components, arrow functions only for callbacks
41- No barrel files or `index.ts` re-exports
42- Avoid comments at all times unless the code is very complex
43- Do not use `useCallback` or `useMemo` unless asked to optimise a given function
44- Do not type hook returns, let Typescript infer as much as possible
45- Never type with `any`, if not types available use `unknown`
46
47## Testing
48
49- Backend: `poetry run test` (runs pytest with a docker based postgres + prisma).
50- Frontend integration tests: `pnpm test:unit` (Vitest + RTL + MSW, primary testing approach).
51- Frontend E2E tests: `pnpm test` or `pnpm test-ui` for Playwright tests.
52- See `autogpt_platform/frontend/TESTING.md` for the full testing strategy.
53
54Always run the relevant linters and tests before committing.
55Use conventional commit messages for all commits (e.g. `feat(backend): add API`).
56Types: - feat - fix - refactor - ci - dx (developer experience)
57Scopes: - platform - platform/library - platform/marketplace - backend - backend/executor - frontend - frontend/library - frontend/marketplace - blocks
58
59## Pull requests
60
61- Use the template in `.github/PULL_REQUEST_TEMPLATE.md`.
62- Rely on the pre-commit checks for linting and formatting
63- Fill out the **Changes** section and the checklist.
64- Use conventional commit titles with a scope (e.g. `feat(frontend): add feature`).
65- Keep out-of-scope changes under 20% of the PR.
66- Ensure PR descriptions are complete.
67- For changes touching `data/*.py`, validate user ID checks or explain why not needed.
68- If adding protected frontend routes, update `frontend/lib/supabase/middleware.ts`.
69- Use the linear ticket branch structure if given codex/open-1668-resume-dropped-runs
70
Significant-Gravitas/AutoGPT · autogpt_platform/AGENTS.md
@@ +1 @@
1# AutoGPT Platform
2
3This file provides guidance to coding agents when working with code in this repository.
4
5## Repository Overview
6
7AutoGPT Platform is a monorepo containing:
8
9- **Backend** (`backend`): Python FastAPI server with async support
10- **Frontend** (`frontend`): Next.js React application
11- **Shared Libraries** (`autogpt_libs`): Common Python utilities
12
13## Component Documentation
14
15- **Backend**: See @backend/AGENTS.md for backend-specific commands, architecture, and development tasks
16- **Frontend**: See @frontend/AGENTS.md for frontend-specific commands, architecture, and development patterns
17
18## Key Concepts
19
201. **Agent Graphs**: Workflow definitions stored as JSON, executed by the backend
212. **Blocks**: Reusable components in `backend/backend/blocks/` that perform specific tasks
223. **Integrations**: OAuth and API connections stored per user
234. **Store**: Marketplace for sharing agent templates
245. **Virus Scanning**: ClamAV integration for file upload security
25
26### Environment Configuration
27
28#### Configuration Files
29
30- **Backend**: `backend/.env.default` (defaults) → `backend/.env` (user overrides)
31- **Frontend**: `frontend/.env.default` (defaults) → `frontend/.env` (user overrides)
32- **Platform**: `.env.default` (Supabase/shared defaults) → `.env` (user overrides)
33
34#### Docker Environment Loading Order
35
361. `.env.default` files provide base configuration (tracked in git)
372. `.env` files provide user-specific overrides (gitignored)
383. Docker Compose `environment:` sections provide service-specific overrides
394. Shell environment variables have highest precedence
40
41#### Key Points
42
43- All services use hardcoded defaults in docker-compose files (no `${VARIABLE}` substitutions)
44- The `env_file` directive loads variables INTO containers at runtime
45- Backend/Frontend services use YAML anchors for consistent configuration
46- Supabase services (`db/docker/docker-compose.yml`) follow the same pattern
47
48### Branching Strategy
49
50- **`dev`** is the main development branch. All PRs should target `dev`.
51- **`master`** is the production branch. Only used for production releases.
52- Exception: **LLM-catalog-only diffs** (`backend/data/llm_registry/catalog.py`) may use a `hotfix/*` branch targeting `master` for incident-speed changes (model kills, routing swaps) — CD deploys on merge. See `docs/platform/contributing/managing-llm-models.md`.
53
54### Creating Pull Requests
55
56- Create the PR against the `dev` branch of the repository.
57- **Split PRs by concern** — each PR should have a single clear purpose. For example, "usage tracking" and "credit charging" should be separate PRs even if related. Combining multiple concerns makes it harder for reviewers to understand what belongs to what.
58- Ensure the branch name is descriptive (e.g., `feature/add-new-block`)
59- Use conventional commit messages (see below)
60- **Structure the PR description with Why / What / How** — Why: the motivation (what problem it solves, what's broken/missing without it); What: high-level summary of changes; How: approach, key implementation details, or architecture decisions. Reviewers need all three to judge whether the approach fits the problem.
61- Fill out the .github/PULL_REQUEST_TEMPLATE.md template as the PR description
62- Always use `--body-file` to pass PR body — avoids shell interpretation of backticks and special characters:
63 ```bash
64 PR_BODY=$(mktemp)
65 cat > "$PR_BODY" << 'PREOF'
66 ## Summary
67 - use `backticks` freely here
68 PREOF
69 gh pr create --title "..." --body-file "$PR_BODY" --base dev
70 rm "$PR_BODY"
71 ```
72- Run the github pre-commit hooks to ensure code quality.
73
74### Test-Driven Development (TDD)
75
76When fixing a bug or adding a feature, follow a test-first approach:
77
781. **Write a failing test first** — create a test that reproduces the bug or validates the new behavior, marked with `@pytest.mark.xfail` (backend) or `.fixme` (Playwright). Run it to confirm it fails for the right reason.
792. **Implement the fix/feature** — write the minimal code to make the test pass.
803. **Remove the xfail marker** — once the test passes, remove the `xfail`/`.fixme` annotation and run the full test suite to confirm nothing else broke.
81
82This ensures every change is covered by a test and that the test actually validates the intended behavior.
83
84### Reviewing/Revising Pull Requests
85
86Use `/pr-review` to review a PR or `/pr-address` to address comments.
87
88When fetching comments manually:
89- `gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginate` — top-level reviews
90- `gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate` — inline review comments (always paginate to avoid missing comments beyond page 1)
91- `gh api repos/Significant-Gravitas/AutoGPT/issues/{N}/comments` — PR conversation comments
92
93### Conventional Commits
94
95Use this format for commit messages and Pull Request titles:
96
97**Conventional Commit Types:**
98
99- `feat`: Introduces a new feature to the codebase
100- `fix`: Patches a bug in the codebase
101- `refactor`: Code change that neither fixes a bug nor adds a feature; also applies to removing features
102- `ci`: Changes to CI configuration
103- `docs`: Documentation-only changes
104- `dx`: Improvements to the developer experience
105
106**Recommended Base Scopes:**
107
108- `platform`: Changes affecting both frontend and backend
109- `frontend`
110- `backend`
111- `infra`
112- `blocks`: Modifications/additions of individual blocks
113
114**Subscope Examples:**
115
116- `backend/executor`
117- `backend/db`
118- `frontend/builder` (includes changes to the block UI component)
119- `infra/prod`
120
121Use these scopes and subscopes for clarity and consistency in commit messages.
122
@@ −1 +1 @@
1−# AutoGPT Platform Contribution Guide
1+# AutoGPT Platform
22
3−This guide provides context for coding agents when updating the **autogpt_platform** folder.
3+This file provides guidance to coding agents when working with code in this repository.
44
5−## Directory overview
5+## Repository Overview
66
7−- `autogpt_platform/backend` – FastAPI based backend service.
8−- `autogpt_platform/autogpt_libs` – Shared Python libraries.
9−- `autogpt_platform/frontend` – Next.js + Typescript frontend.
10−- `autogpt_platform/docker-compose.yml` – development stack.
7+AutoGPT Platform is a monorepo containing:
118
12−See `docs/content/platform/getting-started.md` for setup instructions.
9+- **Backend** (`backend`): Python FastAPI server with async support
10+- **Frontend** (`frontend`): Next.js React application
11+- **Shared Libraries** (`autogpt_libs`): Common Python utilities
1312
14−## Code style
13+## Component Documentation
1514
16−- Format Python code with `poetry run format`.
17−- Format frontend code using `pnpm format`.
15+- **Backend**: See @backend/AGENTS.md for backend-specific commands, architecture, and development tasks
16+- **Frontend**: See @frontend/AGENTS.md for frontend-specific commands, architecture, and development patterns
1817
19−## Frontend guidelines:
18+## Key Concepts
2019
21−See `/frontend/CONTRIBUTING.md` for complete patterns. Quick reference:
20+1. **Agent Graphs**: Workflow definitions stored as JSON, executed by the backend
21+2. **Blocks**: Reusable components in `backend/backend/blocks/` that perform specific tasks
22+3. **Integrations**: OAuth and API connections stored per user
23+4. **Store**: Marketplace for sharing agent templates
24+5. **Virus Scanning**: ClamAV integration for file upload security
2225
23−1. **Pages**: Create in `src/app/(platform)/feature-name/page.tsx`
24− - Add `usePageName.ts` hook for logic
25− - Put sub-components in local `components/` folder
26−2. **Components**: Structure as `ComponentName/ComponentName.tsx` + `useComponentName.ts` + `helpers.ts`
27− - Use design system components from `src/components/` (atoms, molecules, organisms)
28− - Never use `src/components/__legacy__/*`
29−3. **Data fetching**: Use generated API hooks from `@/app/api/__generated__/endpoints/`
30− - Regenerate with `pnpm generate:api`
31− - Pattern: `use{Method}{Version}{OperationName}`
32−4. **Styling**: Tailwind CSS only, use design tokens, Phosphor Icons only
33−5. **Testing**: Integration tests (Vitest + RTL + MSW) are the default (~90%, page-level). Playwright for E2E critical flows. Storybook for design system components. See `autogpt_platform/frontend/TESTING.md`
34−6. **Code conventions**: Function declarations (not arrow functions) for components/handlers
26+### Environment Configuration
3527
36−- Component props should be `interface Props { ... }` (not exported) unless the interface needs to be used outside the component
37−- Separate render logic from business logic (component.tsx + useComponent.ts + helpers.ts)
38−- Colocate state when possible and avoid creating large components, use sub-components ( local `/components` folder next to the parent component ) when sensible
39−- Avoid large hooks, abstract logic into `helpers.ts` files when sensible
40−- Use function declarations for components, arrow functions only for callbacks
41−- No barrel files or `index.ts` re-exports
42−- Avoid comments at all times unless the code is very complex
43−- Do not use `useCallback` or `useMemo` unless asked to optimise a given function
44−- Do not type hook returns, let Typescript infer as much as possible
45−- Never type with `any`, if not types available use `unknown`
28+#### Configuration Files
4629
47−## Testing
30+- **Backend**: `backend/.env.default` (defaults) → `backend/.env` (user overrides)
31+- **Frontend**: `frontend/.env.default` (defaults) → `frontend/.env` (user overrides)
32+- **Platform**: `.env.default` (Supabase/shared defaults) → `.env` (user overrides)
4833
49−- Backend: `poetry run test` (runs pytest with a docker based postgres + prisma).
50−- Frontend integration tests: `pnpm test:unit` (Vitest + RTL + MSW, primary testing approach).
51−- Frontend E2E tests: `pnpm test` or `pnpm test-ui` for Playwright tests.
52−- See `autogpt_platform/frontend/TESTING.md` for the full testing strategy.
34+#### Docker Environment Loading Order
5335
54−Always run the relevant linters and tests before committing.
55−Use conventional commit messages for all commits (e.g. `feat(backend): add API`).
56−Types: - feat - fix - refactor - ci - dx (developer experience)
57−Scopes: - platform - platform/library - platform/marketplace - backend - backend/executor - frontend - frontend/library - frontend/marketplace - blocks
36+1. `.env.default` files provide base configuration (tracked in git)
37+2. `.env` files provide user-specific overrides (gitignored)
38+3. Docker Compose `environment:` sections provide service-specific overrides
39+4. Shell environment variables have highest precedence
5840
59−## Pull requests
41+#### Key Points
6042
61−- Use the template in `.github/PULL_REQUEST_TEMPLATE.md`.
62−- Rely on the pre-commit checks for linting and formatting
63−- Fill out the **Changes** section and the checklist.
64−- Use conventional commit titles with a scope (e.g. `feat(frontend): add feature`).
65−- Keep out-of-scope changes under 20% of the PR.
66−- Ensure PR descriptions are complete.
67−- For changes touching `data/*.py`, validate user ID checks or explain why not needed.
68−- If adding protected frontend routes, update `frontend/lib/supabase/middleware.ts`.
69−- Use the linear ticket branch structure if given codex/open-1668-resume-dropped-runs
43+- All services use hardcoded defaults in docker-compose files (no `${VARIABLE}` substitutions)
44+- The `env_file` directive loads variables INTO containers at runtime
45+- Backend/Frontend services use YAML anchors for consistent configuration
46+- Supabase services (`db/docker/docker-compose.yml`) follow the same pattern
47+
48+### Branching Strategy
49+
50+- **`dev`** is the main development branch. All PRs should target `dev`.
51+- **`master`** is the production branch. Only used for production releases.
52+- Exception: **LLM-catalog-only diffs** (`backend/data/llm_registry/catalog.py`) may use a `hotfix/*` branch targeting `master` for incident-speed changes (model kills, routing swaps) — CD deploys on merge. See `docs/platform/contributing/managing-llm-models.md`.
53+
54+### Creating Pull Requests
55+
56+- Create the PR against the `dev` branch of the repository.
57+- **Split PRs by concern** — each PR should have a single clear purpose. For example, "usage tracking" and "credit charging" should be separate PRs even if related. Combining multiple concerns makes it harder for reviewers to understand what belongs to what.
58+- Ensure the branch name is descriptive (e.g., `feature/add-new-block`)
59+- Use conventional commit messages (see below)
60+- **Structure the PR description with Why / What / How** — Why: the motivation (what problem it solves, what's broken/missing without it); What: high-level summary of changes; How: approach, key implementation details, or architecture decisions. Reviewers need all three to judge whether the approach fits the problem.
61+- Fill out the .github/PULL_REQUEST_TEMPLATE.md template as the PR description
62+- Always use `--body-file` to pass PR body — avoids shell interpretation of backticks and special characters:
63+ ```bash
64+ PR_BODY=$(mktemp)
65+ cat > "$PR_BODY" << 'PREOF'
66+ ## Summary
67+ - use `backticks` freely here
68+ PREOF
69+ gh pr create --title "..." --body-file "$PR_BODY" --base dev
70+ rm "$PR_BODY"
71+ ```
72+- Run the github pre-commit hooks to ensure code quality.
73+
74+### Test-Driven Development (TDD)
75+
76+When fixing a bug or adding a feature, follow a test-first approach:
77+
78+1. **Write a failing test first** — create a test that reproduces the bug or validates the new behavior, marked with `@pytest.mark.xfail` (backend) or `.fixme` (Playwright). Run it to confirm it fails for the right reason.
79+2. **Implement the fix/feature** — write the minimal code to make the test pass.
80+3. **Remove the xfail marker** — once the test passes, remove the `xfail`/`.fixme` annotation and run the full test suite to confirm nothing else broke.
81+
82+This ensures every change is covered by a test and that the test actually validates the intended behavior.
83+
84+### Reviewing/Revising Pull Requests
85+
86+Use `/pr-review` to review a PR or `/pr-address` to address comments.
87+
88+When fetching comments manually:
89+- `gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginate` — top-level reviews
90+- `gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate` — inline review comments (always paginate to avoid missing comments beyond page 1)
91+- `gh api repos/Significant-Gravitas/AutoGPT/issues/{N}/comments` — PR conversation comments
92+
93+### Conventional Commits
94+
95+Use this format for commit messages and Pull Request titles:
96+
97+**Conventional Commit Types:**
98+
99+- `feat`: Introduces a new feature to the codebase
100+- `fix`: Patches a bug in the codebase
101+- `refactor`: Code change that neither fixes a bug nor adds a feature; also applies to removing features
102+- `ci`: Changes to CI configuration
103+- `docs`: Documentation-only changes
104+- `dx`: Improvements to the developer experience
105+
106+**Recommended Base Scopes:**
107+
108+- `platform`: Changes affecting both frontend and backend
109+- `frontend`
110+- `backend`
111+- `infra`
112+- `blocks`: Modifications/additions of individual blocks
113+
114+**Subscope Examples:**
115+
116+- `backend/executor`
117+- `backend/db`
118+- `frontend/builder` (includes changes to the block UI component)
119+- `infra/prod`
120+
121+Use these scopes and subscopes for clarity and consistency in commit messages.
70122
