A small life hack for working with an agent that I've gotten very used to. Add some folder like ai/ to gitignore and in AGENTS.md leave some rules like this:
- `ai/` - directory for temporary agent files.
- Create Markdown files here for large responses (temporary documentation, analysis, reports).
- Name files with current date and time at the beginning: `YYYYMMDD_HHMM_file_name.md`
- Double-check the date using `date` before creating a file
Now every time you ask it to generate some report, it does it in the ai/ folder with ordered names so as not to get confused. Not spitting it into output, and not with random names in the project root, from where this "garbage" then needs to be cleaned before commits.
You get something like this:
- ai/
- 20251104_1820_illustrations_migration.md
- 20251106_1132_sdk_integration_analysis.md
- 20251107_1605_identification_dependencies.md
- 20251108_2245_webview_hooks_implementation.md
- 20251110_1027_game_module_analysis.md
For example, the last one was made by the prompt "analyze how the game module is currently used in the project, what dependencies it has, seems like it can be removed".
These reports are good in themselves for understanding some issue in the project. And they work great as a prompt for the next clean chat with an agent. Like, here are detailed reports A, B and C - do it. They're not important enough to push to the repo, of course, but they remain locally in history so you can refresh your memory. This is nice.
I'm almost sure this isn't the most correct approach from a process standpoint. Surely it's right to create a ticket in Jira, then make a separate branch for it and only create everything needed within that ticket. But I often don't work that way at all. I'm generating a bunch of ideas in parallel and it's important for me to remove all obstacles to this. The agent can analyze different questions in several terminal tabs in parallel. And for each such question I end up with artifacts that at minimum don't interfere, and rather help.
But, by the way, hot take: conveyor processes through Jira kill initiative and turn off technical imagination. That is, often for someone to formulate a useful technical ticket in Jira for you - you yourself need to analyze something as part of brainstorming with the team. Instead, developers learn to act only within the ticket. But you need to leave room in the conveyor to think.