Community写作与编辑github.com

ainova-systems/intelligence-dev-packs

基于 Ainova Systems 最佳实践的软件工程智能包

intelligence-dev-packs 是什么?

该技能(Ainova Systems 智能开发包)专注于为软件项目搭建和维护一个名为“规范驱动文档基板”的共享知识库。它旨在作为人类和AI代理共同的参考层,为后续的规范创建与执行提供结构化的基础。技能的核心原则是安全且增量式地处理文档:从不删除现有内容,而是将其隔离并逐步重新分类;草稿文档会被标记为“推断”状态,直到项目所有者确认为“权威”。该技能支持任何已存在或全新的文档结构,它会优先学习并采用项目现有结构,仅当项目为绿地(全新)时才使用其AI优先的默认文档树结构(参考`references/docs-tree.md`)。其主要平台是任何基于Markdown的代码仓库,特别适合与Claude Code、Cursor或Codex等AI代理配合使用,通过机器可读的规则(如`rules/R-NNN`)和共享文档(模型、术语表、功能说明等)来约束和指导代理行为。工作流程包括:盘点现有文档、搭建缺失结构、安全迁移内容至`_inbox/`隔离区、从代码推导核心文档(如领域模型和术语表)、应用命名规范(kebab-case),最终等待所有者逐项确认。关键限制:它只处理代码中已结构化的信息,业务规则若存在于配置文件、数据库行或运行时扩展中则不可见,需通过功能测试或逐步迁入代码来处理。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add ainova-systems/intelligence-dev-packs

Installed? Explore more 写作与编辑 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

初始化规范驱动文档基板

搭建仓库的共享知识库——人类和代理都读取的层级——以便规范包的其他部分(spec-create、spec-execute)有地方写入。操作安全且具有增量性:不删除任何内容,草稿在确认前均为推断状态,所有内容在所有者批准前不具权威性。

解析目标结构(先学习,再配置,最后默认)——绝不强加

  1. 首先从项目学习。 如果仓库已有文档结构(docs/、Documentation/、文档规则、同层级功能文档),采用它——先搜索,阅读两个同级文档,模仿而非发明。成熟的现有结构优先于默认结构;不要重构已经正常工作的结构。
  2. 配置 在路径不明确时固定:specs_dir、features_dir、rules_dir、decisions_dir、spec_grouping。
  3. 绿地默认 = AI优先的文档树(参见 references/docs-tree.md):docs/ 目录下包含 model.md、glossary.md、rules/R-NNN-*.md、features/<feature>.md、specs/NNN-<feature>/{requirements,plan,tasks}.md、decisions/NNNN-*.md、architecture/、guides/、_inbox/。

分层模型(本技能所负责的内容)

按对代理的约束强度排序:代理遵循可执行检查的结果比遵循散文描述更可靠。

  • 层 A - 可执行约束(lint/边界/契约测试配置,tests/):最强。此处不涉及——需单独设置。
  • 层 B - 机器可读规则与架构知识(作为契约的规则 rules/R-NNN、依赖映射、决策日志)。spec-init 搭建这些文档;代理入口路由器(AGENTS.md)由同步引擎持有——本技能仅确保它指向文档树,绝不覆盖它。
  • 层 C - 共享知识库(模型、术语表、功能文档、规范、架构、指南)。spec-init 搭建并初始化这些文档。

步骤

  1. 盘点 现有文档:每个 *.md、Wiki 导出、图表、零散笔记。将每项分类为:模型 / 术语表 / 功能行为 / 流程 / 决策 / 架构 / 指南 / 未分类。
  2. 搭建 已解析的树结构——仅创建缺失部分(文件夹 + 一个 docs/README.md 索引)。绝不覆盖现有文档。
  3. 安全迁移——先隔离。 将所有先前存在的、未分类或遗留内容移动到 _inbox/(隔离区),使新结构成为唯一的权威源,然后逐项重新分类,并由所有者审查:“某功能如何工作”的笔记 -> features/,流程图 -> architecture/diagrams/,决策 -> decisions/。不删除任何内容;重新分类是逐项进行,从不批量自动操作。
  4. 从代码草拟核心文档,标记为 confirmed(已确认)/ inferred(推断):从类型和字段名推导领域模型(model.md)和术语表(glossary.md);根据代码当前的实际行为 + EARS 验收标准构建功能行为基线(features/);从实际导入构建依赖映射;提取代码已强制执行的候选编号业务规则(rules/R-NNN)。
  5. 应用命名原则。 文档根目录下的所有内容使用小写 kebab-case;有序系列使用零填充前缀(NNNN- ADR,NNN- 规范);一个概念一个名称,无同义词。唯一的大写文件是根目录下的 AGENTS.md 和 README.md(外部标准要求这些名称)。
  6. 所有者把关。 展示搭建的树结构、待重新分类的 _inbox/ 内容,以及草拟的文档。在所有者确认每个草稿前,没有内容具有权威性;所有内容在此之前保持 inferred 状态。

验证

  • 已解析的树结构存在;索引列出了它;每个先前存在的文件要么已重新分类,要么位于 _inbox/ 中(无一丢失);每个草拟的文档都标记了 confirmed/inferred;AGENTS.md 未被覆盖。

范围 / 交接

  • 在搭建的 specs/ 内创建变更规范——spec-create。
  • 层 A 可执行约束(lint、边界、契约测试)——不涉及;需单独设置。
  • 之后保持文档与代码同步——spec-audit-docs。

关键

  • 绝不要删除或覆盖现有文档——先隔离到 _inbox/,逐项重新分类,由所有者审查。
  • 绝不将默认树结构强加于正在工作的项目结构之上——先学习并采用。
  • 输出中需诚实说明的注意事项:本技能仅固定代码中已结构化的内容。存在于配置文件、数据库行或运行时注册的扩展中的业务规则,对静态推导不可见——请将其标记为功能测试或逐步迁入代码;绝不编造代码未展示的规则。

相关技能