前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载导读GEMINI.md 是 Dillinger 仓库中用于约束 AI 助手Agent行为的 Maestro 配置文档v4.0它定义了Agent 如何被激活、如何加载技能、如何分类请求、如何分层执行规则的完整编排协议。读完本文你将掌握一套可复用的多层级 AI 开发编排框架——包括请求分类器、TIER 0/1/2 规则体系、Socratic Gate 提问门控、12 个验证脚本的调用矩阵以及 plan/ask/edit 三种工作模式的具体切换逻辑可直接迁移到任意 AI 辅助开发工作区。一、GEMINI.md 在仓库中的定位一份 Agent 行为宪法.agent/rules/GEMINI.md是 Dillinger 仓库中Antigravity KitAI 能力扩展工具包的全局规则文件其 frontmatter 声明trigger: always_on意味着所有 AI 会话都必须遵守。按照仓库中 .agent/ARCHITECTURE.md 的目录规划整套体系分为.agent/ ├── ARCHITECTURE.md # 体系总览16 个 Specialist Agents、40 个 Skills、11 个 Workflows ├── agents/ # 角色化 AI 专家代理 ├── skills/ # 领域知识模块 ├── workflows/ # Slash 命令流程 ├── rules/ # 全局规则GEMINI.md 即位于此处 └── .shared/ # 共享资源GEMINI.md 处于规则优先级最高层文档明确规定P0GEMINI.md P1Agent .md P2SKILL.md所有规则均具约束力。因此它在整个编排体系中扮演行为宪法的角色——任何 Agent 在执行任务前都必须先读取它及其引用的技能文件。二、核心协议AGENT SKILL PROTOCOL技能加载与执行强制流程文档开篇即声明最高优先级规则在实施任何改动之前必须阅读对应的 Agent 文件及其技能。整个流程可用文档中的流程图精确概括Agent activated → Check frontmatter skills: field │ └── For EACH skill: ├── Read SKILL.md (INDEX only) ├── Find relevant sections from content map └── Read ONLY those section files这条模块化技能加载协议强调选择性阅读Selective Reading不要读取技能文件夹内的所有文件而是先读SKILL.md索引再只读与用户请求匹配的章节文件。以仓库实际内容为例.agent/skills/clean-code/SKILL.md 定义了全局编码规范.agent/skills/brainstorming/SKILL.md 定义了苏格拉底式提问门控——Agent 只有在需要时才按需加载这些文件。配套的**执行协议Enforcement Protocol**要求 Agent 在激活时完成四件事✅ 阅读 Agent 文件内的所有规则✅ 检查 frontmatter 中的skills:列表✅ 加载每个技能的SKILL.md✅ 应用 Agent 与技能的全部规则。文档特别强调Read → Understand → Apply读→理解→应用是强制性的并给出了正反例对比❌ WRONG: Read agent file → Start coding ✅ CORRECT: Read → Understand WHY → Apply PRINCIPLES → Code三、请求分类器REQUEST CLASSIFIER行动前的第一步分流在采取任何动作之前AI 必须先对用户请求进行分类不同类别对应不同的激活层级与产出物请求类型触发关键词激活层级结果QUESTIONwhat is、how does、explain仅 TIER 0文本回复SURVEY/INTELanalyze、list files、overviewTIER 0 Explorer会话情报不产文件SIMPLE CODEfix、add、change单文件TIER 0 TIER 1精简内联编辑COMPLEX CODEbuild、create、implement、refactorTIER 0 TIER 1完整 Agent必须产出{task-slug}.mdDESIGN/UIdesign、UI、page、dashboardTIER 0 TIER 1 Agent必须产出{task-slug}.mdSLASH CMD/create、/orchestrate、/debug命令专属流程视情况而定这条分类器的设计意图很清晰越是复杂的请求越需要计划文件{task-slug}.md作为中间产物。仓库中 .agent/agents/project-planner.md 进一步落实了命名规范——计划文件根据任务动态命名如e-commerce site→./ecommerce-site.md、采用 kebab-case、最长 30 字符且严禁使用plan.md、PLAN.md这类通用命名位置固定在项目根目录而非 docs 目录。四、TIER 0始终生效的通用规则Universal RulesTIER 0 是Always Active层无论请求类型如何都必须遵守共包含五条子规则1. 语言处理Language Handling当用户输入非英语时① 内部先翻译以便更好理解② 用用户的语言回复与其沟通方式保持一致③代码注释与变量名保持英文。2. 干净代码Clean Code全局强制所有代码必须遵循 .agent/skills/clean-code/SKILL.md 的规则无例外。核心要求包括简洁直接、以解决方案为中心、不过度注释、不过度工程化同时强调自我文档化每位 Agent 负责在相关.md文件中记录自己的改动、全局测试强制遵循测试金字塔Unit Integration E2E以及 AAA 模式Arrange、Act、Assert、全局性能强制先测量再优化Web 需符合 Core Web VitalsDB 需优化查询、基础设施与安全强制遵循5 阶段部署流程Prepare、Backup、Deploy、Verify、Confirm/Rollback并始终核验环境变量与密钥安全。3. 文件依赖感知File Dependency Awareness修改任何文件前必须① 检查CODEBASE.md的文件依赖② 识别受影响文件③一起更新所有受影响文件防止留下破坏性引用。这与 clean-code 技能中编辑文件时必须同步修改其依赖方的规则互为呼应。4. 系统地图读取System Map Read强制要求会话开始必须阅读ARCHITECTURE.md以了解 Agents、Skills、Scripts 的全貌。同时明确路径感知规则Agents.agent/项目级Skills.agent/skills/项目级运行时脚本.agent/skills/skill/scripts/5. 读→理解→应用Read → Understand → Apply写代码前必须回答三个问题① 这个 Agent/技能的目标是什么② 我必须应用哪些原则③ 它与通用输出有何区别——本质上是防止 Agent 机械套用模板输出。五、TIER 1编写代码时的规则Code Rules1. 项目类型路由Project Type Routing当任务涉及编码时必须先确定项目类型并路由到正确的 Agent项目类型主 Agent技能MOBILEiOS、Android、RN、Fluttermobile-developermobile-designWEBNext.js、React webfrontend-specialistfrontend-designBACKENDAPI、server、DBbackend-specialistapi-patterns、database-design移动项目 frontend-specialist 错误移动项目只能使用mobile-developer。这一边界强制在 .agent/agents/orchestrator.md 中被进一步强化为完整的 Agent 边界表与文件类型所有权表如**/*.test.{ts,tsx,js}归 test-engineer、**/components/**归 frontend-specialist、**/api/**归 backend-specialist。2. 苏格拉底之门Socratic Gate全局强制提问每个用户请求在动用任何工具或实施之前都必须通过苏格拉底之门这是文档强调的强制步骤。其策略矩阵如下请求类型策略必需动作新功能 / 构建深度发现至少提出 3 个战略性提问代码编辑 / 缺陷修复上下文核对确认理解 提问影响面模糊 / 简单请求澄清询问目的、用户与范围完整编排守门人暂停子代理直到用户确认计划细节直接继续验证即使已给答案也要再问 2 个边界案例问题协议要点① 永不假设——哪怕只有 1% 不清晰也要问② 面对规格密集型请求用户列了一串答案不得跳过门控而应改问权衡Trade-offs或边界案例Edge Cases③ 在用户放行前不得调用子代理或写代码④ 完整协议参考 .agent/skills/brainstorming/SKILL.md。3. 最终检查清单协议Final Checklist Protocol当用户说出son kontrolleri yap、final checks、çalıştır tüm testleri等触发短语时进入最终检查阶段任务阶段命令目的手动审计python scripts/checklist.py .按优先级审计项目部署前python scripts/checklist.py . --url URL完整套件 性能 E2E执行顺序优先级为Security → Lint → Schema → Tests → UX → Seo → Lighthouse/E2E。规则有二① 任务未完成的定义——直到checklist.py返回成功才算完成② 若失败先修复 Critical 阻塞项Security/Lint。说明checklist.py脚本本身位于~/.claude/scripts/个人 AI 工具目录不在本仓库内但文档列出的 12 个领域脚本中security_scan.py 等已实际存在于本仓库的.agent/skills/目录下可由 Agent 通过python .agent/skills/skill/scripts/script.py直接调用。4. 可用脚本矩阵12 个验证脚本脚本所属技能使用时机security_scan.pyvulnerability-scanner每次部署dependency_analyzer.pyvulnerability-scanner每周 / 部署lint_runner.pylint-and-validate每次代码变更test_runner.pytesting-patterns逻辑变更后schema_validator.pydatabase-designDB 变更后ux_audit.pyfrontend-designUI 变更后accessibility_checker.pyfrontend-designUI 变更后seo_checker.pyseo-fundamentals页面变更后bundle_analyzer.pyperformance-profiling部署前mobile_audit.pymobile-design移动端变更后lighthouse_audit.pyperformance-profiling部署前playwright_runner.pywebapp-testing部署前 任何 Agent 与技能均可通过python .agent/skills/skill/scripts/script.py调用任意脚本。同时 .agent/skills/clean-code/SKILL.md 补充了脚本调用纪律每个 Agent 只能运行自己技能对应的脚本如 test-engineer 不得运行ux_audit.py且输出处理必须遵循读取输出 → 向用户总结 → 征求同意 → 修复 → 重跑的流程。5. Gemini 模式映射Mode Mapping模式Agent行为planproject-planner4 阶段方法论Phase 4 之前禁止写代码ask-专注理解持续提问editorchestrator执行先检查{task-slug}.mdPlan 模式4 阶段ANALYSIS→ 研究、提问PLANNING→ 生成{task-slug}.md、任务分解SOLUTIONING→ 架构与设计不写代码IMPLEMENTATION→ 代码 测试Edit 模式若是多文件或结构性改动 → 主动提议创建{task-slug}.md若是单文件修复 → 直接进行。仓库中 .agent/agents/project-planner.md 对该 4 阶段流程给出了更细化的实施优先级P0 基础层database-architect → security-auditor→ P1 核心层backend-specialist→ P2 UI 层frontend-specialist 或 mobile-developer二选一不可兼得→ P3 打磨层test-engineer、performance-optimizer、seo-specialist。六、TIER 2设计规则Design Rules参考层设计规则不在 GEMINI.md 正文中而是存放在专家 Agent 文件里文档只提供路由指引任务读取文件Web UI/UX.agent/agents/frontend-specialist.md移动端 UI/UX.agent/agents/mobile-developer.md这些 Agent 文件中包含的设计约束包括Purple Ban禁止紫色系主色、Template Ban禁止标准布局、反陈词滥调规则、深度设计思维协议。以 .agent/agents/frontend-specialist.md 为例其中明确列出了一系列自动拒绝触发器Automatic Rejection Triggers如安全分割布局Safe Split禁止 50/50、60/40 默认布局、玻璃陷阱Glass Trap禁止无实边框的backdrop-blur、Bento 陷阱禁止默认圆角网格收纳内容等。 设计任务必须打开并阅读 Agent 文件规则都在那里——这正是 TIER 2 采用引用式而非内嵌式的原因设计规则体量庞大按需加载比常驻内存更高效。七、快速参考QUICK REFERENCE8 大主代理与关键技能可用主代理8 个Agent领域与焦点orchestrator多代理协调与综合project-planner发现、架构与任务规划security-auditor网络安全总控审计 渗透 基础设施加固backend-specialist后端架构API 数据库 服务器/Docker 部署frontend-specialist前端与增长UI/UX SEO Edge/静态部署mobile-developer移动端专家跨平台 移动性能debugger系统性根因分析与缺陷修复game-developer游戏逻辑与资源与性能关键技能技能用途clean-code编码规范全局brainstorming苏格拉底式提问app-builder全栈编排frontend-designWeb UI 模式mobile-design移动端 UI 模式plan-writing{task-slug}.md格式threejs-mastery2025 3D WebR3F、WebGPUbehavioral-modes模式切换脚本位置脚本路径完整校验scripts/verify_all.py安全扫描security_scan.pyUX 审计ux_audit.pyfrontend-design 技能移动端审计mobile_audit.pymobile-design 技能Lighthouselighthouse_audit.pyperformance-profiling 技能Playwrightplaywright_runner.pywebapp-testing 技能八、从规则到落地与仓库编排体系的实际呼应GEMINI.md 并非孤立文本它与仓库内的 Agent 定义、技能与工作流形成了一套可运转的闭环。三点值得注意的实现印证1. 编排前必须先有计划文件。.agent/workflows/orchestrate.md 将编排严格限定为2 阶段Phase 1 仅允许project-planner创建 PLAN.md然后必须等待用户批准才能进入 Phase 2 并行实施而 .agent/agents/orchestrator.md 更是把缺少 PLAN.md 就调用专家代理定义为编排失败FAILED orchestration与 GEMINI.md 中COMPLEX CODE 必须产出{task-slug}.md的分类器规则一脉相承。2. 至少 3 个 Agent 才算编排。.agent/workflows/orchestrate.md 明确声明ORCHESTRATION MINIMUM 3 DIFFERENT AGENTS——少于 3 个代理只是委派而非编排完成前必须清点被调用的 Agent 数量单代理即判定编排失败。3. 验证脚本是完成的标准。GEMINI.md 规定任务未完成直到checklist.py返回成功而 .agent/agents/project-planner.md 的 Phase X 验证阶段进一步给出了可操作的命令序列npm run lint npx tsc --noEmit、python ~/.claude/skills/vulnerability-scanner/scripts/security_scan.py .、npm run build、npm run dev 手工测试并规定必须真正运行检查后才能把[ ]标记为[x]。九、结语这套协议解决的核心问题纵观全文GEMINI.md 的价值在于把AI 协作开发从自由发挥变成有纪律的流水线请求分类器决定投入的资源等级TIER 0 保证全局质量底线语言、干净代码、依赖意识TIER 1 保证专业分工与验证闭环项目路由、苏格拉底之门、脚本矩阵、模式映射TIER 2 通过按需引用保住设计原创性。对于在 Dillinger 这类中大型仓库中使用 AI 辅助开发的团队这套宪法 专家 技能 工作流的四层结构提供了一份可直接借鉴的 Agent 治理范本。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐Cog 仓库 AGENTS.md 深度解析面向 AI 编码代理的多语言开发协作指南Cog 仓库 AGENTS.md 深度解析面向 AI 编码代理的多语言开发协作指南 本文基于 Cog 仓库根目录下的 AGENTS.md https://liMLOps容器模型推理服务开发工具behavioral-modes 技能深度解析Dillinger 仓库的自适应 AI 操作模式与多智能体协作框架behavioral modes 技能深度解析Dillinger 仓库的自适应 AI 操作模式与多智能体协作框架 本文基于仓库 .agent/skills/b前端开发工具Feynman 多智能体研究编排AGENTS.md 仓库级协作契约与源码实现深度解析Feynman 多智能体研究编排AGENTS.md 仓库级协作契约与源码实现深度解析 本文以开源 AI 研究代理项目 Feynman 的仓库级协作文档 AGE上一篇仓颉SDK构建依赖工具版本大全LLVM、CMake、Ninja、Python要求完全对照表下一篇Android 省市区三级联动城市选择器 CityPicker 完整集成指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
