Feature Request
Problem
What problem does this solve?
Implement project-wide user message, serving as project development regulations.
实现一个项目级用户提示词，可作为项目开发规则。
The project-wide message could include but not limited to:
- Code habits & general rules within the project (how to name classes? when to introduce helper methods?).
- Architectural structure, and critical decisions made in the past, so the agent understands the project better (for larger projects, the agent won’t need to repeatedly read and analyze code or memory to understand what’s going on, at least it could reads less).
- Other routines we might want the agent to follow (see example in use case).
这个项目级的提示语应该包括但不限于：
- 当前项目中的代码习惯和通用规则。（对象/类名如何命名？什么情况下应该另起新方法？）
- 项目架构和重要的历史决策，这样Agent能更好的理解项目结构。（Agent不用每次都重复查阅项目代码或着记忆，至少可以少查一点）
- 其他我们希望执行的例行任务。（见Use Case中的示例）
Solution
The project-wide message should work like a permanent user input: it is inserted to the user message every time. Otherwise, it could work like a selectable skill (similar but not the same), so we can pick and chose what to tell the agent.
项目级的提示词应该常设的用户输入：可以是每次都默认拼接到用户输入里，也可以像是一个可选的技能（类似但不一样），这样我们能选择应用哪些规则。
Use Case
Say we are writing in Java, and we don’t have the project-wide message. My input would be:
@context
Add a new endpoint in the controller called “/checkStatus“. It should take a parameter "workflow_id" and return the current status of that workflow
It should call the "WorkflowStatus" interface to look up the workflow status.
The workflow related configs are in @config.yml
--------------------------- This is what I need to do right now -----------------------------
- The endpoint should not contain any work logic. It should only handle the HTTP request.
- Project modules:
src/main/java/com/example/project/workflow/Workflow.java => The workflow interface
src/main/java/com/example/project/workflow/WorkflowManager.java => Handle work logic
src/main/java/com/example/project/workflow/impl/WorkflowImpl.java => The implementation
src/main/java/com/example/project/db/workflow/WorkflowStautsDTO.java => Table structure
src/common/config.yml => project configuration
...
- Ensure code readability after edit, refactor to helper if the method is too long.
---------------------------------------------------------------------------------------------
What I’m doing right now is saving this in a markdown file. Whenever I’m working with workflows, I simply copy & paste this into the input box, or add the markdown to the context (@project_rules.md).
Usually, the rules section will have more content than my instruction.
以Java为例，如果没有项目级提示词。我的输入会是：
@context
在controller里新增一个"/checkStatus"端点。入参为"workflow_id"，返回该workflow的当前状态。
应该调用"WorkflowStatus"接口来查询workflow状态。
workflow相关的配置在 @config.yml
----------------------------------------- 现在的办法 -----------------------------------------
- 端点不应该包含任何业务逻辑，只负责处理HTTP请求。
- 项目模块：
src/main/java/com/example/project/workflow/Workflow.java => workflow接口
src/main/java/com/example/project/workflow/WorkflowManager.java => 处理业务逻辑
src/main/java/com/example/project/workflow/impl/WorkflowImpl.java => 接口实现
src/main/java/com/example/project/db/workflow/WorkflowStautsDTO.java => 表结构
src/main/resources/workflow-config.yml => 工作流相关配置
...
- 确保代码可读性，方法过长时应该另起新的辅助方法
---------------------------------------------------------------------------------------------
我现在的做法是把这些存到一个markdown文件里。每次做workflow相关的工作时，直接复制粘贴到输入框，或者把这个markdown加到上下文里（@project_rules.md）。
通常这些限定规则会比指令本身内容更多。
What I’m observing right now:
In complicated projects, agent often stick to as few files as possible (both reading & editing code, mainly because of the search → grep → edit behavior), and this has some problems:
- The agent will try to add large chunks of code in the same place.
- It might miss already implemented code that could be reused (usually util functions).
// The agent will try to do:
public void someFunction(Object param) {
// 0 readability
if (...) {
...;
}
if (...) {
...;
...;
} else {
...;
...
}
...;
...;
if (...) {
...;
}
return ...
// Instead of:
public void someFunction(Object param) {
verifyParam(param);
checkWorkflowStatus();
handleSomethingElse();
return
}
public verifyParam ...
我现在观察到的现象：
项目结构比较复杂的时候，Agent经常会尽可能少的改动文件（读/改代码都会，主要是因为搜索 → grep → 修改的操作习惯），这样会有几个问题：
- Agent会在同一个地方新增一大块代码
- 有可能会重复实现已有的代码功能（通常是辅助函数）。
If we add project-wide messages, even just simple bullet points, there will be a huge difference:
- Every module in the project has its own service/ impl/ folders, make sure to modify or make addition accordingly.
- Common helpers are under utils/, such as path handling and format conversion.
- Make sure to update API documentations when adding new endpoints.
- There are logging related functions and enumerations under logging/ and logging/enum, be sure to import or make additions
- The maximum number of lines for functions/methods is 100 lines, include helper functions when needed.
- New features and bug fixes need to be updated to the latest release note under pre-release/
如果新增一个项目级提示词，哪怕只是简单列几点，都会有很大区别：
- 项目中每个功能模块都有自己的 service/ impl/ 等文件夹，新增或改动功能时注意分类
- 常用的辅助方法在 utils/，包括路径处理、格式转换等功能
- 新增端点时需要更新API文档
- logging/ 和 logging/enum 下有日志相关方法和枚举值，注意引用或新增
- 方法/函数长度上限为100行，注意确保代码可读性。必要时另起辅助方法。
- 功能更新和bug修复需要记录到 pre-release/ 下最新的版本更新日志
To sum things up: add a customizable, permanent user message that the agent can see all the time. Preferably a set of selectable rules/common phrases.
一句话：新增一个可自定义的、常设的提示词，让Agent随时可见。如果能做成一系列可选的规则/常用语更好。
P.S. When I say the “Agent”, I mean most of the Qoder co-op modes: Agents, Experts, and Quest Mode. It’s just that the more credits you are spending, the less frequent the above problems are to occur (still happens in Ultimate and Quest mode).
P.S. 以上提到"Agent"的时候，我指的是大部分Qoder支持的协作模式：Agent、Experts、Quest等模式。只是花的credits越多，上面提到的问题出现频率就越低（但是Ultimate和Quest模式都还是会遇到）。
Priority
-
High - Blocking issue -
Medium - Important improvement -
Low - Nice to have
Additional Info
(Optional: screenshots, examples, links)