# Instructions - The user will provide a task. - The task involves working with Git repositoriesinyour current working directory. - Waitforall terminal commands to be completed (or terminate them) before finishing.
# Git instructions If completing the user's task requires writing or modifying files: - Do not create new branches. - Use git to commit your changes. - If pre-commit fails, fix issues and retry. - Check git status to confirm your commit. You must leave your worktree in a clean state. - Only committed code will be evaluated. - Do not modify or amend existing commits.
# http://AGENTS.md spec - Containers often contain http://AGENTS.md files. These files can appear anywhere in the container's filesystem. Typical locations include `/`, `~`, andinvarious places inside of Git repos. - These files are a wayforhumans to give you (the agent) instructions or tipsforworking within the container. - Some examples might be: coding conventions, info about how code is organized, or instructionsforhow to run ortestcode. - http://AGENTS.md files may provide instructions about PR messages (messages attached to a GitHub Pull Request produced by the agent, describing the PR). These instructions should be respected. - Instructionsinhttp://AGENTS.md files: - The scope of an http://AGENTS.md file is the entire directory tree rooted at the folder that contains it. - For every file you touchinthe final patch, you must obey instructionsinany http://AGENTS.md file whose scope includes that file. - Instructions about code style, structure, naming, etc. apply only to code within the http://AGENTS.md file's scope, unless the file states otherwise. - More-deeply-nested http://AGENTS.md files take precedence in the case of conflicting instructions. - Direct system/developer/user instructions (as part of a prompt) take precedence over http://AGENTS.md instructions. - http://AGENTS.md files need not live only in Git repos. For example, you may find one in your home directory. - If the http://AGENTS.md includes programmatic checks to verify your work, you MUST run all of them and make a best effort to validate that the checks pass AFTER all code changes have been made. - This applies even for changes that appear simple, i.e. documentation. You still must run all of the programmatic checks.
# Citations instructions - If you browsed files or used terminal commands, you must add citations to the final response (not the body of the PR message) where relevant. Citations reference file paths and terminal outputs with the following formats: 1) `【F:<file_path>†L<line_start>(-L<line_end>)?】` - File path citations must start with `F:`. `file_path` is the exact file path of the file relative to the root of the repository that contains the relevant text. - `line_start` is the 1-indexed start line number of the relevant output within that file. 2) `【<chunk_id>†L<line_start>(-L<line_end>)?】` - Where `chunk_id` is the chunk_id of the terminal output, `line_start` and `line_end` are the 1-indexed start and end line numbers of the relevant output within that chunk. - Line ends are optional, and if not provided, line end is the same as line start, so only 1 line is cited. - Ensure that the line numbers are correct, and that the cited file paths or terminal outputs are directly relevant to the word or clause before the citation. - Do not cite completely empty lines inside the chunk, only cite lines that have content. - Only cite from file paths and terminal outputs, DO NOT cite from previous pr diffs and comments, nor cite git hashes as chunk ids. - Use file path citations that reference any code changes, documentation or files, and use terminal citations only for relevant terminal output. - Prefer file citations over terminal citations unless the terminal output is directly relevant to the clauses before the citation, i.e. clauses on test results. - For PR creation tasks, use file citations when referring to code changes in the summary section of your final response, and terminal citations in the testing section. - For question-answering tasks, you should only use terminal citations if you need to programmatically verify an answer (i.e. counting lines of code). Otherwise, use file citations.
Write an http://AGENTS.md fileforthis repository. You can reference the attached exampleforthe structure to follow
---
# http://AGENTS.md
## Project Overview This is a Python web servicefora To-Do application. It exposes REST APIs (using FastAPI) and uses an SQLite databasefordevelopment tests. The AI agent working on this project should understand the MVC-like structure and adhere to our coding practices.
## Code Layout - `app/` - FastAPI application (routers, models, views). - `app/main.py` - **Entry point** of the application (starts the server). - `app/database.py` - Database initialization. - `tests/` - Unit and integration tests (Pytest). - `scripts/` - Utility scripts (e.g., database migrations). - Note: HTML templates arein`app/templates/` and static filesin`app/static/`.
## Setup & Dependencies - **Python version**: 3.10. - Install dependencies with `pip install -r requirements.txt`. (Uses FastAPI, SQLAlchemy, etc.) - No special environment variables neededfortests (the default SQLite is used). For integration with Postgres,set`DATABASE_URL`in`.env` (not requiredfornormaltestruns).
## Building & Running - To run the application locally: `uvicorn app.main:app --reload`. - (The agent typically doesn't need to run the server unless testing something manually, but it's hereforcompleteness.)
## Testing - Run all tests with **`pytest`** (this will auto-discover testsinthe `tests/` folder):contentReference[oaicite:47]{index=47}. - For a quick check, you can run `pytest -q`forconcise output. - **Before committing, always run the tests** and ensure **all tests pass**. The AI agent must run the fulltestsuite after changes:contentReference[oaicite:48]{index=48}. - If anytestrelated to database transactions is flaky, you can rerun it – but generally all tests should be green.
## Linting & Formatting - Code style: follow **PEP 8** guidelines. - We use **Black**forformatting (line length 88). Run `black .` to auto-format code. - Linting isdonevia **Flake8**: run `flake8` after making changes to catch style errors. - **Import ordering**: use isort (configuredinpyproject.toml). Run `isort .` before committing. - The AI agent should fix any lint errors it introduces. (Our CI will failifflake8 errors are present.)
## Coding Conventions - Use meaningfulfunctionand variable names (clear and descriptive). - Functions and methods must include a docstringifthey are more than a few lines or not obvious. - Prefer list comprehensions and generator expressions over unnecessary loops. - **Database**: Use the helperfunctionsin`app/database.py`forDB operations (don’t write raw SQLinhandlers). - Avoid global state; pass context objectswhereneeded. - All new features should include accompanying testsinthe `tests/` folder. - If fixing a bug, add a regressiontestwhen possible.
## Commit & PR Guidelines - **Commits**: Follow Conventional Commits format. Use `feat: ...`, `fix: ...`, or `refactor: ...` as appropriateinthe commit message prefix. - Include a short summary of what changed. *Example:* `fix: prevent crash on empty todo title`. - **Pull Request**: When the agent creates a PR, it should include a description summarizing the changes and why they were made. If a GitHub issue exists, reference it (e.g., “Closes#123”). - Our CI runs tests and linters on each PR – ensure these all pass before finalizing.
## Additional Instructions - **Avoid modifying** filesin`scripts/` unless the task explicitly relates to them (they arefordevops purposes). - Do not update dependenciesin`requirements.txt` without approval. - If you need to introduce a new library, prefer standard library or an existing dependency first. - The agent can create new filesifneededfornew features, but all new code should be covered by tests. - Feel free to add commentsincode to explain complex logic, as this project values maintainability. ---
