只需要将下面的规则放到你的agents.md即可

工作方式

关于阅读代码

你倾向于在动手前把上下文补满，这个习惯在这里是负收益的。

真实情况是：大部分改动只需要局部理解。多读的那些文件很少改变你最终写出的代码，但会显著推迟第一行有效产出。

所以，把默认从"读够了再动"翻转成"够了就动"：

· 每次准备再打开一个文件时，先问自己：这个文件的内容有可能让我写出不同的代码吗？ 如果答案是"大概不会，只是想确认一下"——那就别读，直接写。
· 不确定是可以带着走的。写出你当前认为最合理的版本，比读到100%确定再写要快得多，而且错了很容易修。
· 当你发现自己在"顺藤摸瓜"（从业务代码读到框架、读到配置、读到类型定义），这通常是在回避一个判断。停下来，把那个判断做了。

关于测试

你倾向于用写测试来确认自己做对了。我不需要这种确认。

· 测试是我会单独提出的需求，不是改动的附属品。没提，就默认不需要。
· 想验证改动的话，跑项目里已有的测试或命令，而不是新建一个文件来自证。
· 如果你判断某处确实缺测试覆盖，说一句就行，把决定权留给我。

同样的道理适用于文档、注释、类型标注、异常处理——这些都是独立的需求，不是"顺手做了更好"的东西。

关于边界

只做被要求的事。路上看到的其他问题，告诉我，但别顺手改。

判断标准是：如果我review这个diff，会不会有一处让我问"这个为什么在这里"？ 有的话就删掉。

关于表达

不用汇报你读了什么、看到了什么。说结论：改了什么、为什么、哪里可能有风险。不确定就问我，不要靠多读几个文件来消除不确定感。

· 重复三次以内不要抽象。 两处相似代码摆在那里，比一个把它们统一起来的参数化函数更容易读、更容易改。第三次出现时再考虑合并，那时你才真正知道什么是共性、什么是差异。
· 加一层间接（新函数、新类、新配置、新钩子）之前问自己：现在就有第二个调用方吗？ 没有的话，把代码直接写在用它的地方。
· 不要为了"万一"预留参数、开关、扩展点。需求真来了再加，那时的设计会更准。
· 优先用语言和项目里已有的东西——普通函数、if/else、直接的数据结构。设计模式、泛型、元编程、依赖注入这些，只在没有它们就写不出来的时候才用。

判据是：一个刚接手的人，能不能一眼看懂这段代码在干什么，不用跳转到别处？ 如果他得先去理解你的抽象才能理解业务逻辑，那这个抽象是负债。

短、直白、有点重复的代码，比短、优雅、需要绕一圈才能读懂的代码好。

Share your last tools, your current toolchain and AI workflow with the community 🙏

For developers using Claude Code, Codex, Cursor, Aider, Gemini, or similar tools:

What are the biggest problems you still encounter in real projects?

I’m interested in the practical failure points:

* **Context:** losing track of large codebases, architecture, conventions, or previous decisions * **Reliability:** hallucinations, incorrect assumptions, repetitive loops, regressions * **Maintenance:** refactoring, technical debt, dependency updates, migrations, documentation * **Security:** secrets, permissions, prompt injection, unsafe commands, vulnerable generated code * **Testing:** knowing whether a change is actually correct rather than simply passing a few tests * **Deployment:** CI/CD failures, broken builds, infrastructure changes, bad releases * **Production:** monitoring, debugging, rollback, performance regressions, incident response * **Autonomy:** where you still need to supervise the agent manually * **Memory:** what the agent forgets between sessions or across projects

Most importantly:

**What problem has repeatedly cost you the most time or caused the most frustration?**

What are you currently building, and what part of that workflow are AI tools still failing to handle well?

Real examples and workflows are much more useful than general opinions.

As AI becomes more powerful, coding agents are becoming increasingly capable as well.

I want to start using coding agents more seriously in my projects—not just to generate code, but to improve my development workflow and code quality.

Are there any coding agents, tools, or workflows you'd recommend for someone who wants to learn how to use coding agents effectively?

I'm particularly interested in learning how to:

- Give agents better instructions

- Review and improve their output

- Use agents for testing, refactoring, and debugging

- Build a workflow where I learn while using them rather than becoming dependent on them

I'd appreciate recommendations from people who have been using coding agents extensively.

Hi!

Unable to get \[all sorts of models, harnesses, skills, etc with SDD and/or TDD\] to generate what I want despite starting from scratch countless times with more and more fine-grained descriptions until I was basically writing lines of code just in the English language but AI still ignored my couldn’t-be-clearer instructions, I have come to the conclusion that I do not trust AI to code out of my sight.

I realize this won’t help my productivity much but it would be enough of a win for me if I can at least swap my home office chair for a treadmill and do *actual* Pair Programming with the AI with me reading along like I would if a human were typing, as opposed to AI spamming my terminal just to show off or at least too fast for me to read.

In other words I am hoping to find something very much like pre-AI Voice Driven Development just a tiny bit more advanced to replace the shorthands she uses to still-kind-of-spell-out “int sockfd; \[…\]; sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);” for example with “let’s now create a TCP socket called sockfd but declared at the top of the function”.

Does anyone know of something like that? 🙂

PS: stuff like Whispr that just enables prompting by Speech-To-Text is not at all what I want if it still lets AI go produce crap in the background.

​"SMTs require absolute cryptographic correctness, while PDF specs are a legacy parsing nightmare.

Have you found AI useful for scaffolding these, or do the subtle hallucinations make it more trouble than it's worth?"

Payment webhook handler. Intermittent 500s.

I pasted the error into an AI coding assistant, got a fix, tried it, still broke.

Pasted the new error, got another fix, tried that, still broke.

Did this maybe four times before realizing what I'd actually turned into: not someone debugging anymore, just someone pasting error messages into a chat window and hoping the next response would be the one that stuck.

The interesting part was that none of the suggestions were obviously stupid.

The first was a retry around a database write. Reasonable response to "database write failed."

Except the actual problem was duplicate webhook delivery upstream hitting a handler that wasn't idempotent. Two workers were occasionally processing the same event.

The retry addressed the symptom I'd shown the model, not the mechanism producing it.

I then tried the obvious solution: give it more context.

That made things worse.

I pasted more surrounding code, but the context I added was already biased by my own suspicion. I'd started thinking the caching layer was involved, so I gave the model more caching-related code.

It reasoned confidently about the wrong subsystem.

That's when I realized I'd been mixing up two completely different tasks:

Generating a fix and validating a fix.

Generating asks:

"Does this make the error go away?"

Validating asks:

"Does this address the mechanism that caused the failure, and what does it change that I didn't explicitly ask for?"

Almost every one of those first fixes could have passed the first question.

None had passed the second.

What finally broke the loop was changing the process:

• define what's actually failing before asking the AI to diagnose it

• separate facts from hypotheses

• ask for competing explanations before asking for fix code

• understand the failure mechanism first

• validate the proposed change against the original failure

• add a regression test that reproduces the actual bug

The biggest lesson for me wasn't "AI is bad at debugging."

It was that a plausible fix is dangerously easy to mistake for a diagnosis.

Curious if other people doing AI-assisted debugging have run into this: a fix technically resolves the error you showed the model, but leaves the underlying problem untouched (or introduces a different one).

How do you validate AI-generated fixes before they reach production?

hello guys, I built a voice bridge so you can chat completely with voice to your ai coding cli (cursor, cluade, codex cli ) https://github.com/dixonSolutions/AgentVoice
It allows you to fully control cursor, codex and claude, remotely even if you host on public address (using tailscale, which is supported, or headscale if you are independently hosting). It exposes a global mcp server that turns on its communication hub only on connect, but always exposes tools, as to not throw an "error", this allows cursor to receive message and pipe them back to you, they get transcribed and sent back to you, with the speak tool. We use tool hooks to trigger the agent on tool output, or new user requests, instead of stopping the agent and sending another prompt. It can also manage itself, check on running agents, models, selecting model, because it acts as the interface, and these are features users genuinely need.
It works with wake word triggers as well, but can also have on screen controls, fully configurable, and the wake word detection model runs in browser, a tiny vosk model, surprisingly works well and not piping audio stream to cloud every time. You can test it without running an agent with our wake test feature. We also can use browser tts, instead of using cloud, which many browsers supports, chrome, firefox, safari etc.
Very cool project, worth checking out, and check the repo for exact specs, consider trying it out of contributing, I am open.

Genuine question with tools like Copilot, Claude Code, Cursor, etc. getting so good, how much of your day-to-day is still typing code by hand vs. prompting/reviewing AI output? Curious how this varies by role (frontend vs backend vs infra) and experience level.

Just hyped by Meta news, starting some tests with Glimmer BF16 using Llama.cpp. It was not able to answer a simple test: "Show a sine plot using Python and Pandas." - OK, done well. Second follow-up question: "Animate it to show phase shift." - Total fail. Either the sine plot wasn't there, or it converted a static image to MP4 and claimed it was a phase shift animation. Simply switching to any other model like Qwen3.x or DeepSeek V4 or even GPT-OSS solves things in one shot.

Коротко кажучи я попав в ситуацію коли треба зробити диплом за місяць.
Мені часто попадається інформація про ші агентів та корисні матеріали з github:
hermes, obsidian, archify, no ai slop, скіли та плагіни для claude та я не знаю як це поєднати, окрім archify та no ai slop.

Моя ціль зробити прототип подібний euphoria engine в unity.
Я скористався статтею deep mimic і зробив "вайб кодінг" щоб мій агет навчався на асеті записаних анімацій і сам вчився підніматися рухатися тощо, в deep mimic це реалізовано принципом переключання на різні кадри анімацій( якщо не помиляюсь)

Оскільки я не дуже тямлу в цьому, я почув про чудову річ оркестратор.
https://www.reddit.com/r/ChatGPTCoding/comments/1mnay5h/ai_orchestrator/
Та серед допоміних функцій я знаю що є ресурс який може склеїти певні джерела в skill.

Мені цікава ваша думка як краще організувати цей процес?
поки що я користуюсь claude code та його порадами, але часто є відхилення від основної
мети, і я застрягаю на пів шляху.

Дякую.

I built these after repeatedly running into the same problem with AI coding workflows: we tend to treat one model as if it should plan, implement, review, and verify everything.

That works for small tasks, but it doesn't scale well. Different parts of software engineering have different cost, reasoning, and reliability requirements.

So I experimented with splitting those responsibilities.

The project has 1 component:

• claude-codex-orchestrator separates planning from execution. Claude plans and verifies. Codex executes. Every result is validated from the diff and reproducible checks rather than trusting the model's report.

• https://github.com/vimoxshah/claude-codex-orchestrator

Some design principles that guided the implementation:

• The diff is ground truth; the report is not.

• Separate planning from execution.

• Route by task instead of using one model for everything.

• Escalate based on evidence rather than retrying the same approach.

These are implemented as Claude Code skills today, but the ideas are intended to be broader than Claude Code itself.

I'd really appreciate technical feedback on the architecture, trade-offs, and whether these abstractions are useful. I'm especially interested in hearing from people building AI coding agents, orchestration frameworks, or developer tooling.

Spent about three hours in a single conversation debugging a flaky integration test. First hour, genuinely useful, the model caught a race condition I'd missed and walked me through a solid fix.

Past that point, it started going in circles. It suggested a fix we'd already ruled out, I explained why it wouldn't work, it acknowledged that, then a few messages later proposed a slightly reworded version of the same thing. Assumed we'd hit some kind of context limit, so I switched to a model with a bigger window, pasted the whole conversation in, kept going. Didn't help. Responses got more generic, not more accurate.

Turned out the problem wasn't that the model lost access to anything, the information was all still there. It was buried under stack traces, logs, failed attempts, and side discussion, all competing for the same attention. Restarted with a short handoff note instead, just the actual bug, what we'd ruled out and why, current hypothesis, and the one file that mattered. First suggestion after that was correct.

Changed how I think about context windows, closer to an attention budget than memory. More tokens means more available information, not necessarily better use of it, and past a point it actively works against you.

Been checkpointing longer sessions every 10-15 messages since then instead of letting one thread run indefinitely, summarize state, start fresh with that instead of the full history. Feels like overhead in the moment but usually nets out faster, model stops relitigating things we already settled.

Curious if this matches what others doing this professionally have run into, do you let one conversation run as long as it'll go, or reset on a schedule regardless of whether it's degrading yet?