quality-baseline
Skill4 starsChanged 4 days agoMITView on GitHub
通用开发质量底线：结构清晰、易维护、界面统一、操作一致、动效合适；明确契约客观核对，主观视觉与体验交人工。Triggers: 质量底线, 代码结构, 升级维护, 界面统一, 外观一致, 操作逻辑, 动画效果, 代码评审, 重构, 新增页面, 新增组件
1 other project uses a version of this.
Adopted by
Most recently taken up by
- G-HunterAi/openclaw-skillstheir own version, first seen Apr 5, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- G-HunterAi/openclaw-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- dsh/AGENTS.mdAGENTS.md
- android-apk-download-verifySkill
- auto-skill-creatorSkill
- docs-stale-auditSkill
- dsh-turn-failure-diagnosisSkill
- git-branch-consolidationSkill
- opencode-oauth-context-capSkill
- opencode-share-kitSkill
- phased-refactor-and-reportSkill
- plan-reviewSkill
- powershell-utf8-safetySkill
- test-verificationSkill
- white-bear-safe-rulesSkill
- windows-openssh-serverSkill
The file
Files
通用开发质量底线
<role>
适用于所有 opencode 项目的默认开发纪律，验证范围按改动风险选择。
五项原则互相约束，先找两全方案再取舍。
</role>五项原则与适用场合
| 原则 | 主要适用场合 | 自查要点 |
| 代码结构清晰 | 一切代码，尤其共享/复用模块、新增页面与库文件、大型改造 | 单一来源不复制；分层职责；命名清晰 |
| 升级维护方便 | 同上，优先考虑后续演进升级，兼顾后续维护者 | 易理解、易测试、易回滚；避免过度抽象；防止只做眼下最易实现、不预留升级余地 |
| 界面外观统一 | 前端页面/组件/JS 生成 DOM | 颜色间距用 CSS 变量；组件走共享样式；弹窗/表单/按钮用统一组件 |
| 操作逻辑一致 | 交互逻辑：弹窗、确认/删除、表单校验、折叠展开 | 同一语义角色同一操作方式；不同角色可不同；不牺牲可用性 |
| 动画效果合适 | 涉及动效的开发：loading、展开收起、过渡 | 跟随系统规范；不喧宾夺主；不用 emoji 充当图标 |
使用纪律
- 开发原则默认适用：代码改动遵循五项原则，侧重点由改动决定；验收投入按下方分工与测试总控选择。
- 按任务类型自查：
- 纯前端 UI 改动 → 重点看「界面外观 / 操作逻辑 / 动画效果」。
- 共享库与重构 → 重点看「代码结构 / 升级维护」。
- 大型改造 → 全部五项 + 分阶段规范（
phased-refactor-and-report）。
- 互相约束，先找两全方案：
- 界面统一与结构清晰冲突 → 提炼共享模块复用，而非复制组件代码。
- 代码结构与升级维护方便冲突 → 按当前需求最小清晰结构设计，按需再抽象。
- 动画与统一冲突 → 跟随项目动效规范，不喧宾夺主。
- 一致性与可用性冲突 → 按语义角色区分操作方式，以用户方便、符合直觉为先。
- 项目级规范优先：项目 AGENTS.md 的具体规范（前端样式规范、共享组件清单、Loading 规范等）更具体，冲突时以项目规范为准；项目无对应规范时才退回本通用底线。
验收分工
- 明确的组件、样式变量、交互和动效参数按项目契约客观核对。
- 美观、协调、动效自然度、使用舒适度等主观项目由人工验收。AI 可给建议，修改依据来自明确要求或可复现缺陷。
- 测试范围与停止条件统一遵循
test-verification；截图按具体定位、取证或用户要求选用。主观项目按需列为未验证（待人工）。
关键检查模式（按改动选择）
- 新 UI 是否复用项目共享组件/变量，而非复制内联样式？
- 新交互是否与项目已有交互方式一致（弹窗/确认/表单）？
- 新交互是否按语义角色区分操作（如输入区 vs 触发器），而非一刀切统一？
- 新模块是否放共享库目录，而非页面内重复实现？
- 动效是否跟随项目动画规范，而非临时内联？
- 是否为了美观/炫技引入了影响可维护性的复杂度？
- 是否只选了眼下最容易的实现方式，而没有预留后续升级/扩展余地？
红线兜底
- 界面外观统一优先：先找共享组件/共享样式/CSS 变量，找不到再按项目规范新建，样式不内联、emoji 不作图标。
- 结构适度：按当前需求的最小清晰结构设计，避免过度抽象导致简单功能复杂化。
- 复用优先：页面功能先在共享库/共享样式里找，找到即复用、单一来源。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.