git:20260922.41e492c to git:20261101.e8aa4fa

44 added, 57 removed. Audit A to A.

---

name: concept-design

- description: >-

- Use when the user explicitly invokes $concept-design. Completes a Daniel Jackson concept design

- with the user. Confirm the alignment, then write the design record.

+ description: "Generates concept designs from software needs. Use when explicitly invoked to define concepts, behavior, and synchronization."

metadata:

language: en

translation_of: concept-design-cn

openclaw:

- homepage: https://github.com/ontology-of-everything/concept-skills/tree/main/skills/en/concept-design

+ homepage: https://github.com/ontology-of-everything/concept-skills

---

- # Concept Design

+ # Concept design

- Complete the concept design with the user: confirm the three alignment sections, then write the

- design record. Run only on explicit `$concept-design` invocation. Continue into PRD or

- implementation only when already authorized. If `concept-prd` or `concept-implementation` is

- missing, deliver the model and name the missing step.

+ ## Goal

- ## Design principles

+ Turn a software need into a concept design the user can confirm. Run only on explicit

+ `$concept-design` invocation. Deliver a model and its unresolved decisions.

+ Continue to PRD or implementation when the user has authorized that work.

- - **Familiarity.** Use a familiar concept, or a variant of one, when it meets the need.

- - **Specificity.** Each concept serves one purpose. Do not add a second concept for the same purpose.

- - **Integrity.** Synchronization may exclude some of a concept's behavior. It may not make the

- concept do something its own specification disallows.

- - **Two arguments.** Contract → OP → concept purpose; concept selection and synchronizations →

- application scenarios → application purpose. Local validity does not prove overall fitness. The

- single-purpose criterion applies to concepts, not mechanically to applications.

- - **Evidence.** Source facts, and label inferences and open decisions. Absence of a counterexample

- is not proof. Pages, entities, and code modules are only candidate clues.

+ ## Principles

- ## Design process

+ Use requirements, examples, and inspected code as evidence. Separate facts, proposals, inference,

+ and open decisions. A page, entity, or file is only a candidate clue.

- Confirm each part with the user. Mark anything not yet confirmed as pending, and do not record it

- as a confirmed fact.

+ Check the concept contract, operational principle, and purpose together. Separately check whether concept selection

+ and synchronization fulfill application scenarios and purpose. One argument does not prove the other.

+ Apply the single-purpose criterion to concepts.

- 1. **Check facts** — With the user, identify beneficiaries, application purpose, current state,

- desired outcome, and constraints. In an existing system, trace actual entry points, state

- ownership, failure paths, and tests. Separate current from desired behavior. If the purpose is

- not yet stated, mark it open.

- 2. **Propose the inventory** — Write the concept inventory from `references/artifacts.md` and ask

- which concepts to include. After confirmation, write state and actions from

- `references/spec-format.md`. External identity is a type parameter with no assumed fields.

- 3. **Review seams** — Read `references/criteria.md`. Give all eight conclusions for each candidate.

- Leave disputes for the user to decide.

- 4. **Confirm scope, then compose** — Ask the user to confirm dependencies and subsets using

- `references/sync-notation.md`. Then write syncs from the specification contract, and check

- under-synchronization, over-synchronization, the synchronization diagram, and the MVP.

- 5. **Write the record** — Correct an evidenced misfit using the qualification standard. Write

- confirmed alignment into the design record. Keep pending items in exclusions and open decisions,

- and block only the portion that depends on them.

+ Reuse confirmed decisions. Confirm only unresolved choices affecting scope or behavior; continue

+ work independent of them and state what remains blocked.

- ## Design artifacts

+ ## Concepts

- Field rules are in `references/artifacts.md`.

+ - A concept has one purpose and its own state and actions. Its definition does not depend on

+ another concept. Use a familiar concept or a small variant when it meets the need.

+ - An operational principle, or OP, describes how typical actions fulfill the concept's purpose.

+ - A synchronization is an external rule that coordinates concept actions for an application.

+ It may restrict behavior but must respect each concept's contract.

- Alignment, confirmed with the user: concept inventory, application purpose and scenarios,

- dependencies and subsets.

+ ## Workflow

- Design record, written after confirmation: Concepts, Synchronizations, synchronization diagram,

- exclusions and open decisions.

+ 1. Establish beneficiaries, application purpose, current behavior, desired outcome, and constraints.

+ For existing software, inspect entries, state ownership, failures, and tests.

+ 2. Draft [the inventory and alignment](references/artifacts.md). Confirm included concepts, then use

+ [the specification contract](references/spec-format.md) for state and actions. External identities

+ are type parameters with no assumed fields.

+ 3. Apply all eight [qualification criteria](references/criteria.md). Record evidence and disputed

+ boundaries. Correct demonstrated mismatches between behavior and need.

+ 4. Use [composition checks](references/sync-notation.md) for rules, missing/excessive automation,

+ and the sync diagram. Confirm product dependencies and subsets, including purpose, entries,

+ remaining rules, and resources.

+ 5. Write confirmed decisions into the record. Keep pending concepts, assumptions, alternatives,

+ and their consequences in exclusions and open decisions.

- ## Standards

+ Read [the reservation example](references/example-reserving.md) for a walkthrough and

+ [sources](references/sources.md) for definitions. Load references only for the current step.

- | Standard | Use |

+ ## Examples

+ | Prefer | Avoid |

| --- | --- |

- | [Qualification](references/criteria.md) | whether a concept qualifies |

- | [Specification contract](references/spec-format.md) | how to write purpose, state, actions, OP, and synchronizations |

- | [Composition](references/sync-notation.md) | synchronization rules, the synchronization diagram, dependencies, and the MVP |

+ | Define Comment with a generic target identity; bind it to Post in the application. | Make Comment import Post or read its private state. |

+ | Explain how reserving and later claiming a slot fulfill a commitment. | Treat creating a database row as the complete reservation purpose. |

## Completion

- - Every alignment item has a confirmation mark. Pending items appear only under exclusions and open

- decisions, with the portion they block.

- - The concept purpose and the application purpose each have evidence of fulfillment, or are marked

- open.

- - An entry that requires a response states success and refusal. The synchronization diagram,

- dependencies, and MVP meet the composition standard. The specification meets the contract.

- For a first pass together, read `references/example-reserving.md`. For definitions and local

- conventions, read `references/sources.md`.

+ The record contains confirmed concepts, rules, a sync diagram, exclusions, and open decisions.

+ Show confirmation status and purpose arguments with their gaps. Required responses cover success

+ and refusal. The specification and composition checks pass.