You're given a task to write a collection of rules, context and guidelines on the repository you're provided. Please gather context on the following categories, then write an AGENTS.md file in the root of the repository.
- General Rules: These are general rules any developer/agent should follow when writing code. It should contain rules such as "When creating new XYZ functions, always first search in the XYZ/ directory to see if one exists, and if not, create it and place it in an existing or new file". Additionally, here is where you'd include context about scripts which are commonly executed, such as linter and formatter scripts.
- Repository Structure: This section is where you'll include high level context about how the repository is laid out, any highly useful and not overly obvious information about how the directories/files are structured, different apps/packages/services inside the repository, etc. Do not include every last detail about the repository contents, only a high level technical overview on the repository structure.
- Dependencies and Installation: This section should include high level context about how to install dependencies, where to install them, package managers, etc. Do not include overly verbose context in this section as most repositories typically have straightforward dependency management.
- Testing Instructions: A general guide on testing in this repository. It should include context such as testing frameworks, roughly what types of modules should be tested, how to run tests, and any other context a developer wouldn't be able to infer by looking at test files on how to write & run tests. Do not include every last detail about testing in this section, only the most used/important context necessary to run tests.
- Pull request formatting: Rules and guidelines around how to format pull request titles and descriptions. This should only be populated if you find specific instructions in the repository around how to format pull request titles and descriptions. If the repository does not have specific instructions, leave this section empty. The agent will already generate well thought out titles and descriptions, so unless there are special rules specific to this repository, leave this section empty.
Ensure each category is properly wrapped in opening and closing XML tags. The tags to use are as follows:
<general_rules>
</general_rules>
<repository_structure>
</repository_structure>
<dependencies_and_installation>
</dependencies_and_installation>
<testing_instructions>
</testing_instructions>
<pull_request_formatting>
</pull_request_formatting>
It is incredibly important that you ALWAYS wrap your sections in the opening and closing XML tags. Failure to do so will result in an invalid file and will not be accepted.
The file should not contain any other content besides those tags, and the rules/context/instructions they contain. Ensure your rules are thoughtful, concise and actually useful to a developer who's never contributed to the repository before. You can think of it as a more structured and directed CONTRIBUTING.md file.
With all of this in mind, please explore the repository and write this single AGENTS.md file with the rules/context/instructions gathered!
Agent Context
{
"tasks": [
{
"id": "f5fec807-6a5c-4cd8-988d-8431a872b21c",
"taskIndex": 0,
"request": "[original issue]\n**Create AGENTS.md Repository Guidelines Document**\nYou're given a task to write a collection of rules, context and guidelines on the repository you're provided. Please gather context on the following categories, then write an `AGENTS.md` file in the root of the repository.\n\n- **General Rules**: These are general rules any developer/agent should follow when writing code. It should contain rules such as \"When creating new XYZ functions, always first search in the XYZ/ directory to see if one exists, and if not, create it and place it in an existing or new file\". Additionally, here is where you'd include context about scripts which are commonly executed, such as linter and formatter scripts.\n- **Repository Structure**: This section is where you'll include high level context about how the repository is laid out, any highly useful and not overly obvious information about how the directories/files are structured, different apps/packages/services inside the repository, etc. Do not include every last detail about the repository contents, only a high level technical overview on the repository structure.\n- **Dependencies and Installation**: This section should include high level context about how to install dependencies, where to install them, package managers, etc. Do not include overly verbose context in this section as most repositories typically have straightforward dependency management. \n- **Testing Instructions**: A general guide on testing in this repository. It should include context such as testing frameworks, roughly what types of modules should be tested, how to run tests, and any other context a developer wouldn't be able to infer by looking at test files on how to write & run tests. Do not include every last detail about testing in this section, only the most used/important context necessary to run tests.\n- **Pull request formatting**: Rules and guidelines around how to format pull request titles and descriptions. This should only be populated if you find specific instructions in the repository around how to format pull request titles and descriptions. If the repository does not have specific instructions, leave this section empty. The agent will already generate well thought out titles and descriptions, so unless there are special rules specific to this repository, leave this section empty.\n\nEnsure each category is properly wrapped in opening and closing XML tags. The tags to use are as follows:\n\n\n\n\n\n\n\n\n\n\n\nIt is incredibly important that you ALWAYS wrap your sections in the opening and closing XML tags. Failure to do so will result in an invalid file and will not be accepted.\n\nThe file should not contain any other content besides those tags, and the rules/context/instructions they contain. Ensure your rules are thoughtful, concise and actually useful to a developer who's never contributed to the repository before. You can think of it as a more structured and directed `CONTRIBUTING.md` file.\n\nWith all of this in mind, please explore the repository and write this single `AGENTS.md` file with the rules/context/instructions gathered!",
"title": "Create AGENTS.md repository guidelines document with comprehensive development rules and context",
"createdAt": 1756423830919,
"completed": false,
"planRevisions": [
{
"revisionIndex": 0,
"plans": [
{
"index": 0,
"plan": "Create the `AGENTS.md` file in the root directory with comprehensive guidelines covering general rules, repository structure, dependencies, testing, and pull request formatting based on the gathered repository context",
"completed": false
},
{
"index": 1,
"plan": "**General Rules section**: Include rules about searching existing directories before creating new functions (e.g., checking `src/Api/Model/` for models, `src/Site/Controller/` for controllers), using pnpm as the package manager, running Prettier formatting via `pnpm exec lint-staged` pre-commit hooks, following TypeScript/AngularJS 1.8 patterns with `.component.ts` files implementing `angular.IController`, using PHP namespaces following PSR-4 autoloading (`Site\\` and `Api\\` namespaces), and utilizing the Makefile commands like `make dev`, `make e2e-tests`, `make unit-tests` for common development tasks",
"completed": false
},
{
"index": 2,
"plan": "**Repository Structure section**: Document the multi-technology stack with PHP backend (Silex framework) in `src/` directory, AngularJS 1.8 frontend in `src/angular-app/`, SvelteKit next-generation app in `next-app/`, Docker-based development environment with docker-compose, MongoDB database, Webpack bundling configuration, and the separation between `bellows` (core framework) and `languageforge` (application-specific) modules",
"completed": false
},
{
"index": 3,
"plan": "**Dependencies and Installation section**: Cover pnpm as the primary package manager (with pnpm-lock.yaml), Composer for PHP dependencies in `src/composer.json`, Docker and docker-compose for containerized development, Node.js >=18 requirement, and the `make build` command for initial setup",
"completed": false
},
{
"index": 4,
"plan": "**Testing Instructions section**: Document Playwright for E2E tests (run with `make e2e-tests` or `pnpm exec playwright test`), PHPUnit for PHP unit tests (run with `make unit-tests`), test files located in `test/e2e/` and `test/php/` directories, VSCode debugging configuration available for both PHP and Playwright tests, and the requirement to add tests for new features as specified in the PR template checklist",
"completed": false
},
{
"index": 5,
"plan": "**Pull Request Formatting section**: Include the specific requirements from `.github/pull_request_template.md` - must reference issue with 'Fixes #_issue_', include description with motivation and context, provide screenshots for UI changes, complete the checklist including labeling PR with bug/feature/engineering/security fix/testing, perform self-review, review title & description for squashed commit message, comment hard-to-understand code, add tests, and provide testing instructions for staging environment verification",
"completed": false
}
],
"createdAt": 1756423830919,
"createdBy": "agent"
}
],
"activeRevisionIndex": 0
}
],
"activeTaskIndex": 0
}
[
"Create the `AGENTS.md` file in the root directory with comprehensive guidelines covering general rules, repository structure, dependencies, testing, and pull request formatting based on the gathered repository context",
"**General Rules section**: Include rules about searching existing directories before creating new functions (e.g., checking `src/Api/Model/` for models, `src/Site/Controller/` for controllers), using pnpm as the package manager, running Prettier formatting via `pnpm exec lint-staged` pre-commit hooks, following TypeScript/AngularJS 1.8 patterns with `.component.ts` files implementing `angular.IController`, using PHP namespaces following PSR-4 autoloading (`Site\\` and `Api\\` namespaces), and utilizing the Makefile commands like `make dev`, `make e2e-tests`, `make unit-tests` for common development tasks",
"**Repository Structure section**: Document the multi-technology stack with PHP backend (Silex framework) in `src/` directory, AngularJS 1.8 frontend in `src/angular-app/`, SvelteKit next-generation app in `next-app/`, Docker-based development environment with docker-compose, MongoDB database, Webpack bundling configuration, and the separation between `bellows` (core framework) and `languageforge` (application-specific) modules",
"**Dependencies and Installation section**: Cover pnpm as the primary package manager (with pnpm-lock.yaml), Composer for PHP dependencies in `src/composer.json`, Docker and docker-compose for containerized development, Node.js >=18 requirement, and the `make build` command for initial setup",
"**Testing Instructions section**: Document Playwright for E2E tests (run with `make e2e-tests` or `pnpm exec playwright test`), PHPUnit for PHP unit tests (run with `make unit-tests`), test files located in `test/e2e/` and `test/php/` directories, VSCode debugging configuration available for both PHP and Playwright tests, and the requirement to add tests for new features as specified in the PR template checklist",
"**Pull Request Formatting section**: Include the specific requirements from `.github/pull_request_template.md` - must reference issue with 'Fixes #_issue_', include description with motivation and context, provide screenshots for UI changes, complete the checklist including labeling PR with bug/feature/engineering/security fix/testing, perform self-review, review title & description for squashed commit message, comment hard-to-understand code, add tests, and provide testing instructions for staging environment verification"
]
