concept-design · diff
git:20260907.8e2e10b to git:20260907.6b18008
51 added, 96 removed. Audit A to A.
---
name: concept-design
- description: Models or reviews requirements as concepts (Daniel Jackson's concept design) defined by Purpose, OP, State, and Actions, then composes them with Syncs. Use this skill whenever the user asks to discuss requirements, review a concept model, or mentions 概念设计 / 概念建模; stop at model confirmation without producing PRD or code.
+ description: Generates and revises Daniel Jackson concept models from requirements with independent purposes, behavior specifications, and causal synchronizations. Use when the user requests 概念设计, 概念建模, or concept-design; generic requirement discussions do not require it.
+ metadata:
+ openclaw:
+ homepage: https://github.com/ontology-of-everything/SemanticSkills/tree/main/skills/concept-design
---
# 概念设计
- ## 目标
-
- 输入：需求、访谈记录或既有概念模型。输出：由独立 concepts 与 synchronizations 组成的概念模型（模板见「记法与模板」），停在模型确认——除非用户明确要求，不出 PRD、架构或代码。确认后交接：文档化 → `concept-prd`；代码落地 → `concept-implementation`；存量审计 → `concept-audit`。
-
- Concept 同时是用户为有效使用软件而掌握的**心理构造**，和与之对应的**连贯功能单元**；界面和术语表达概念，代码实现概念，都不是概念本身。本文是按 Daniel Jackson 的结构、判据与设计动作整理的操作循环，不冒充作者原文流程。
-
- ## 原则
-
- 1. 先确认 purpose 与边界，再确认名称和细节；全程区分已确认、推断与待决定。
- 2. 从具体场景自下而上找目的；表、页面、实体名、团队边界都不直接映射成 concept。
- 3. 概念规格零点名其他概念（`notes` 段除外）；共享对象用类型参数抽象（`Comment [Target]`）；跨概念行为只写在 sync。
- 4. State 与 actions 完整规定行为，OP 只解释本质；三者都不写界面、协议或表结构。
- 5. **Sync 是唯一的组合机制**：when 匹配已完成动作、where 只经 queries 读状态、then 只触发已声明动作（行为保持）；应用动作 = `Requesting` 入口触发的 sync；错误是可匹配输出，由错误 sync 处理。书（2021）的事务语义已被作者废弃，存量旧记法按现行改写。
- 6. **组合有结构**：sync 按 flow 分组（一个 `Requesting` 入口 = 一个 flow），组合层交付同步图（coordination graph）与依赖图两张图——前者说"谁触发谁"，后者说"没有谁就不能有谁"，不互相替代。
- 7. 被否决的候选与待决取舍全部进「排除与未决」表，不留空悬。
-
- ## 流程
-
- 重复 1–5 直到 misfits 消失，再进入 6。
-
- 1. **找需要**：受益者、misfit、现有做法、期望结果与约束；把"要什么"追问成"为什么"。完成：「需求与 Misfits」节可填。
- 2. **识别候选**：从具体场景找细粒度目的，优先熟悉、可复用的概念；边界不明先保留备选。完成：每个候选有一句 purpose。
- 3. **逐个刻画**：写 Name、Purpose、具体 OP，由 OP 推导 actions 与最小 state；删除行为不需要的 state，补齐必要 action；成立后把上下文对象参数化。完成：每个候选四节齐。
- 4. **批评边界**：读 `references/criteria.md`，按资格五条与四词逐个判断；结论只用 `保留 / 拆分 / 合并 / 参数化 / 降级为 type、action、implementation / 移至 sync / 待确认`。完成：每个候选有结论词。
- 5. **组合再设计**：读 `references/sync-notation.md`。
- - include 并实例化 concepts；
- - 按 flow 写 syncs：每个 `Requesting` 入口一个 flow，含成功路径与错误路径的响应 sync；
- - 画同步图：每条 sync 一条边 `[Concept.action] --(sync)--> [Concept.action]`；
- - 核查未被 sync 提及的动作是否有意排除；按欠同步、过同步、synergy、分解线索检视并用 tighten / loosen 调整；
- - 画依赖图（extrinsic）、枚举子集圈定 MVP。
-
- 完成：「命题」全部成立。
- 6. **呈现并确认**：按模板输出，请用户确认模型；不主动进入 PRD 或代码。
+ 把需求、访谈或既有模型转成独立 concepts、syncs、产品依赖与取舍。Concept 既是用户理解功能的心理构造，也对应连贯功能单元；页面、实体和代码模块不直接等同概念。以下是本仓对 Jackson 方法的操作化，不是作者规定的固定流程。
- ## 命题
+ 只要求建模时交付模型；用户同时要求 PRD/实现且取舍已明确时继续交接 `concept-prd` / `concept-implementation`，不重复索要确认。未安装伴生技能时交付可用模型与缺口，不假定其存在。
- 产出必须满足，每条可对照文本判真假：
+ ## 设计循环
- - 每个 concept 恰好一个 purpose；OP 至少一条场景，且以兑现该 purpose 的结局收尾。
- - 每个 concept 附四词结论（专一 / 完整 / 独立 / 熟悉），结论词出自流程第 4 步词表。
- - 规格只含 purpose / state / actions / operational principle（可选 notes）；除 notes 外不出现其他概念名，无 interactions / dependencies 段。
- - 每个 action 带 requires / ensures；错误是独立输出 case `(error: String)`；queries 以 `_` 开头且只读。
- - 每条 sync 满足行为保持：只调用概念已声明的动作、只经 queries 读状态；每条附组合理由或风险。
- - 每条 sync 恰好属于一个 flow；每个 `Requesting` 入口有成功与错误两条响应路径（或错误路径记入排除表）。
- - 同步图的边与 sync 块一一对应；每个可失败动作有错误 sync，或有意不处理并记入排除表。
- - 未被 sync 提及的动作均为有意排除并记入排除表。
- - 依赖图只含 extrinsic 依赖、无违反 Parnas 规则处；MVP 子集从图中圈定。
+ 1. **找需要**：从受益者、具体 misfit、现有做法、期望结果与约束识别目的；区分确认事实、推断和待决项。
+ 2. **刻画候选**：每个候选写一个 purpose、具体 principle、最小 state 与完整 actions。先用具体故事检验价值，再把外部身份抽象为类型参数。
+ 3. **批评边界**：读 [criteria.md](references/criteria.md)，检查资格与专一/完整/独立/熟悉；逐候选给理由和结论：保留、拆分、合并、参数化、降级为 type/action/implementation、移至 sync、待确认。
+ 4. **组合检验**：读 [sync-notation.md](references/sync-notation.md)，实例化 concepts，写成功、拒绝及后台联动；检查绑定、响应、并发与排除动作。分别派生同步图与 extrinsic 依赖图，圈定 MVP。
+ 5. **解决 misfits**：用 split/merge、unify/specialize、tighten/loosen 回到边界或组合；仍需产品判断的取舍进入未决表，不把“所有 misfits 消失”当作无限循环条件。
+ 6. **交付**：按下列结构呈现，核对完成条件。未决项只阻塞依赖它的部分。
- ## 记法与模板
+ ## 规格契约
- - **Purpose**：need-focused、specific、evaluable，恰好一个。
- - **OP**：少量端到端故事，只写 actions 与结果；先用具体对象写以检验价值，再改写为多态通用版。
- - **State**：为支持行为必须记住的事实，Alloy 风格关系式（`password: U -> String`）；User、Item 等实体通常是类型参数，不是顶层模块。
- - **Actions**：`动作 (入参: 类型) : (出参: 类型)` + requires / ensures，按输出模式拆 case；不拆成界面步骤。
- - **Queries**：`_getUser (session) : (user)`，只读不改 state，专供 sync 的 where 段。
- - **四词**：专一（多目的即 conflation → 拆分）、完整（只有片段即 fragmentation → 合并或补齐）、独立（无需引用其他 concept 即可理解）、熟悉（沿用已知概念；新概念须给出既有组合给不了的价值）。
+ - **purpose**：恰好一个可评价的需要；**principle**（operational principle/OP）：说明如何兑现目的的原型故事，可用 after/then。它是代表性行为，不是完整正确性规格。
+ - **state/actions** 完整定义允许行为、前置条件、效果及不变量；不混入页面步骤、协议、表布局。每个输出 case 说明条件与状态效果，错误不必固定为 String。
+ - 类型参数 `[T, ...]` 可零个或多个，是不假定字段的身份。定义不依赖其他概念；同名局部参数不是外部引用。可选 notes 记录应用背景，不能藏跨概念执行规则。
+ - `_` queries 是只读查询，集中列在 actions 节便于导航，但不产生动作完成事件。查询只返回已声明的绑定/case；无匹配不自动成为错误。
+ - 跨概念联动写 sync；where 经公开查询读状态，then 仅调用已声明动作。具体语法、flow 关联与行为保持检查见组合参考。
- 输出模板：
+ ## 输出结构
````markdown
## 需求与 Misfits
- - 用户 / 需要 / 问题 / 结果 / 约束
+ 用户 / 需要 / 现状 / 结果 / 约束；确认与推断
## Concepts
-
```text
- concept <Name> [<TypeParam>]
-
+ # concept Name [T, ...]
## purpose
- [恰好一个]
-
+ <一个需要>
+ ## principle
+ after <动作序列与条件>
+ then <目的兑现的结果>
## state
- - <字段>: <TypeParam> -> <类型>
-
+ <本概念需要记住的事实与约束>
## actions
- <动作> (<入参: 类型>) : (<出参: 类型>)
- requires [前置] ensures [效果]
- <动作> (<入参: 类型>) : (error: String)
- _<查询> (<入参>) : (<出参>)
-
- ## operational principle
- after <动作> (<参数>) : (<结果>)
- then <动作> (<参数>) : (<结果>)
-
- ## notes
- [可选：应用角色、类型参数实例化；不设 interactions / dependencies 段]
+ act (arg: T) : (result: R)
+ requires <允许条件>
+ ensures <效果与未改变的状态>
+ act (arg: T) : (error: E)
+ requires <失败条件>
+ ensures <失败效果>
+ _query (arg: T) : (result: R)
+ returns <只读绑定；空集/多结果语义>
```
-
- - 判断: 专一 / 完整 / 独立 / 熟悉（每概念附结论）
+ 专一 / 完整 / 独立 / 熟悉：<各自结论及理由>
## Synchronizations
- ```text
- app <应用名>
- include <Concept> [<Type>]
-
- // flow: <名>（入口 Requesting.<动作>）
- sync <名>
- when <Concept.action (参数)>
- where <Concept._query (参数) : (绑定)>
- then <Concept.action (参数)> // 组合理由 / 风险
- sync <名>Failed
- when ... where ... : (error) then Requesting.respond (error)
- ```
+ <app / include / sync；按入口或规则职责归组>
## 同步图
- [Concept.action] --(sync)--> [Concept.action]
+ <when 动作 → sync 节点 → then 动作；where 另标读取>
## 依赖图与子集
- - 依赖: C1 -> C2, ...（extrinsic，只在此处）
- - 子集: {MVP: ...} / {扩展: ...}
+ A → B 表示纳入 A 需要 B；<MVP 与其余约束>
## 排除与未决
- | 候选/问题 | 结论 | 理由/取舍 |
+ | 候选/动作/问题 | 结论 | 理由及影响 |
````
- ## 参考
+ ## 完成条件
- | 何时读 | 文件 |
- | --- | --- |
- | 流程第 4 步：资格五条、四词展开、组合后再查、误判速查表、design moves | `references/criteria.md` |
- | 流程第 5 步：sync 记法示例、因果语义规则、flow 与同步图结构、模式与信号、依赖图与子集 | `references/sync-notation.md` |
- | 需要核验判据出处或引用作者原文 | `references/sources.md` |
+ - 候选均有完整四节与边界结论；principle 能演示 purpose，state/actions 支持其行为。
+ - include 类型实例化、sync 动作/query、参数、输出与变量绑定逐一可解析；旧记法迁移保留原有行为，不能只替换关键字。
+ - 每个外部入口的可达结果有明确策略；需要响应时覆盖成功与拒绝，后台事件允许无响应。错误处理或有意不处理均可追踪。
+ - 同步图保留每条规则的多源合取和多目标；与产品依赖图区分。循环有终止或受控持续运行依据。
+ - 未暴露动作与产品取舍有理由；MVP 对依赖闭包成立，并核查剩余 sync、入口及所需外部资源；闭包本身不保证产品可用。
+
+ ## 按需参考
+
+ - 首次应用四节/组合，或核对多类型参数时读 [订位例](references/example-reserving.md)。它标明示例范围，不能当生产完整模型。
+ - 核验论文、历史语义或引用出处时读 [sources.md](references/sources.md)。