chaitin
产品需要支撑类似curosrrule的功能或者全局内置提示词功能。
自定义系统提示词
全局规则作为基础：.roo/rules/ 中的规则定义了项目的基础编码规范、风格等 模式特定规则作为补充：.roo/rules-{mode}/ 中的规则针对特定模式进行优化
1. 针对不同模式的特定规则
.roo/
├── rules/
│ ├── rules.md # 全局规则
│ └── rules-code/ # Code 模式特定规则
│ ├── frontend.md
│ └── backend.md
├── rules-architect/ # Architect 模式特定规则
│ └── architecture.md
└── rules-debug/ # Debug 模式特定规则
└── debugging.md
2. For Example
rules/rules.md
# 项目开发规则
## 通用指导原则
1. **代码质量优先**：始终编写清晰、可维护的代码
2. **测试驱动**：新功能必须包含相应的测试
3. **文档完善**：重要功能需要编写文档
## 技术栈偏好
- **前端**：React + TypeScript + Tailwind CSS
- **后端**：Node.js + Express + TypeScript
- **数据库**：PostgreSQL
- **测试**：Jest + React Testing Library
## 代码规范
- 使用 ESLint 和 Prettier 保持代码风格一致
- 函数长度不超过 50 行
- 文件长度不超过 300 行
- 使用有意义的变量和函数名
## 项目特定要求
- 所有 API 响应必须包含错误处理
- 使用环境变量管理配置
- 遵循 RESTful API 设计原则
rules-architect/architecture.md
# 架构设计指导提示词
## 系统概述
- 系统名称: [填写系统名称]
- 主要功能: [简要描述系统核心功能]
- 预期用户量: [预估用户规模]
## 技术选型要求
- 编程语言: [Python/Java/Go等]
- 数据库: [关系型/NoSQL/其他]
- 框架选择: [列出候选框架]
- 部署环境: [云服务/本地/混合]
## 架构设计原则
1. 可扩展性: [描述扩展性需求]
2. 可用性: [SLA要求]
3. 安全性: [安全合规要求]
4. 性能: [预期QPS/响应时间]
## 组件设计
- 核心模块划分: [列出主要模块]
- 模块交互方式: [同步/异步/事件驱动]
- 数据流设计: [描述关键数据流]
## 非功能性需求
- 监控告警: [监控指标要求]
- 日志记录: [日志级别和存储]
- 容灾备份: [RTO/RPO要求]
## 交付物要求
- 架构图类型: [C4/部署图/序列图]
- 文档输出: [架构决策记录/API文档]
自定义系统提示词
全局规则作为基础：.roo/rules/ 中的规则定义了项目的基础编码规范、风格等 模式特定规则作为补充：.roo/rules-{mode}/ 中的规则针对特定模式进行优化
1. 针对不同模式的特定规则
.roo/ ├── rules/ │ ├── rules.md # 全局规则 │ └── rules-code/ # Code 模式特定规则 │ ├── frontend.md │ └── backend.md ├── rules-architect/ # Architect 模式特定规则 │ └── architecture.md └── rules-debug/ # Debug 模式特定规则 └── debugging.md
2. For Example
rules/rules.md
项目开发规则
通用指导原则
- 代码质量优先：始终编写清晰、可维护的代码
- 测试驱动：新功能必须包含相应的测试
- 文档完善：重要功能需要编写文档
技术栈偏好
- 前端：React + TypeScript + Tailwind CSS
- 后端：Node.js + Express + TypeScript
- 数据库：PostgreSQL
- 测试：Jest + React Testing Library
代码规范
- 使用 ESLint 和 Prettier 保持代码风格一致
- 函数长度不超过 50 行
- 文件长度不超过 300 行
- 使用有意义的变量和函数名
项目特定要求
- 所有 API 响应必须包含错误处理
- 使用环境变量管理配置
- 遵循 RESTful API 设计原则 rules-architect/architecture.md
架构设计指导提示词
系统概述
- 系统名称: [填写系统名称]
- 主要功能: [简要描述系统核心功能]
- 预期用户量: [预估用户规模]
技术选型要求
- 编程语言: [Python/Java/Go等]
- 数据库: [关系型/NoSQL/其他]
- 框架选择: [列出候选框架]
- 部署环境: [云服务/本地/混合]
架构设计原则
- 可扩展性: [描述扩展性需求]
- 可用性: [SLA要求]
- 安全性: [安全合规要求]
- 性能: [预期QPS/响应时间]
组件设计
- 核心模块划分: [列出主要模块]
- 模块交互方式: [同步/异步/事件驱动]
- 数据流设计: [描述关键数据流]
非功能性需求
- 监控告警: [监控指标要求]
- 日志记录: [日志级别和存储]
- 容灾备份: [RTO/RPO要求]
交付物要求
- 架构图类型: [C4/部署图/序列图]
- 文档输出: [架构决策记录/API文档]
请问 @LydiaCai1203 这个已经支持了吗？我刚刚试了没有效果，有版本限制吗？
我是 MonkeyCode AI 编程助手，你可以在 GitHub 任意仓库的任意 Issue 或 PR 中 at @monkeycode-ai 来呼唤我。
GitHub Issue 深度评估报告
1. 整体摘要 (Executive Summary)
该 Issue 请求为产品增加类似 curosrrule 的功能或全局内置提示词功能。需求描述较为简略，缺乏具体使用场景和实现细节。建议进一步明确功能需求和使用场景，以便更好地评估和实现。
2. 详细评估 (Detailed Assessment)
| 评估维度 | 评分 (1-5) | 评估说明 |
|---|---|---|
| 清晰度 | 2 | 需求描述较为模糊，仅提到需要支持类似 curosrrule 的功能或全局内置提示词功能，未明确具体实现方式和功能细节。 |
| 完整性 | 2 | 缺乏具体的使用场景、解决的痛点以及预期的价值说明。评论中虽有相关讨论，但仍未提供足够的信息来完整评估。 |
| 可复现性/可行性 | 3 | 功能请求在当前架构下实现具有一定可行性，但需要进一步明确需求和设计方案。 |
3. 分类与优先级 (Classification & Priority)
- 建议标签:
feature-request,needs-more-info,backend - 严重等级:
Minor - 建议优先级:
Medium
4. 影响与风险 (Impact & Risks)
- 影响范围: 此功能可能影响后端提示词管理和前端用户交互模块。
- 潜在风险: 实现过程中可能需要调整现有提示词管理逻辑，存在一定的集成风险。
5. 行动建议 (Actionable Suggestions)
- 对提交者的回应:
- 感谢您提出的功能请求。
- 为了更好地理解和评估您的需求，能否请您补充以下信息：
- 该功能的具体使用场景是什么？
- 您期望通过该功能解决什么问题？
- 是否有参考的实现方案或具体的功能细节描述？
- 对维护团队的建议:
- 下一步: 等待提交者补充更多信息，然后进一步评估实现方案。
- 初步解决方案构想:
- 设计一套规则定义语言或格式，允许用户定义全局或模式特定的提示词规则。
- 在后端实现规则解析和应用逻辑，确保在不同模式下能正确应用相应的提示词。
