domain-expert-configuration

Name: domain-expert-configuration
Author: dembrandt

27stars5forks

How to install domain-expert-configuration?

dembrandt/dembrandt-skills/domain-expert-configuration

$npx -y skills add dembrandt/dembrandt-skills --skill domain-expert-configuration

Installs into the current project.

Summary

Configuration UIs for domain experts — users who understand their field deeply but are not software developers — require domain language, sensible defaults, and grouping by professional concept rather than technical parameter. Use when designing settings panels, solver or algorit

Files · 1

View on GitHub

SKILL.md

1	# Domain Expert Configuration
2
3	A domain expert configuration UI exposes the parameters of a complex system — an optimisation algorithm, a planning engine, a simulation — to users who understand the problem domain deeply but have no knowledge of the system's internals.
4
5	The challenge: the system's parameters are defined in technical terms (weights, thresholds, flags, tolerances). The user thinks in domain terms (how long to wait, when to retry, how to group results). The UI must translate between these two vocabularies — always favouring the user's language.
6
7	---
8
9	## The Core Principle: Domain Language Over Technical Language
10
11	Every parameter label, tooltip, and error message should describe what the parameter means in the user's world, not what it does inside the system.
12
13	\| Technical label \| Domain label \|
14	\|---\|---\|
15	\| `max_concurrent_jobs` \| Maximum tasks running at once \|
16	\| `enable_auto_retry` \| Retry failed tasks automatically \|
17	\| `batch_allocation_threshold` \| Start a new batch after (% filled) \|
18	\| `request_timeout_ms` \| Maximum wait per request (seconds) \|
19	\| `enable_fuzzy_matching` \| Allow approximate matches \|
20
21	If you cannot write a domain label for a parameter, question whether the user should be exposed to it at all. Parameters that cannot be explained in domain terms belong in a developer configuration file, not in the user-facing UI.
22
23	---
24
25	## Grouping by Domain Concept
26
27	Parameters should be grouped by the aspect of the real-world problem they control — not by their technical category (booleans together, numbers together) and not alphabetically.
28
29	A processing tool might group as:
30
31	```
32	Processing limits
33	└─ Maximum tasks at once
34	└─ Maximum wait per request
35	└─ Memory ceiling
36
37	Matching rules
38	└─ Allow approximate matches
39	└─ Case sensitivity
40	└─ Required fields
41
42	Batching behaviour
43	└─ Batch fill threshold
44	└─ Maximum batches
45	```
46
47	Each group should have a short heading that describes what aspect of the task it controls, not what kind of parameter it is.
48
49	---
50
51	## Sensible Defaults
52
53	Every parameter must have a default that works correctly for the majority of cases. The user should be able to start with all defaults and get a reasonable result.
54
55	Show the default value: When a field is at its default, indicate this. When a user has changed a value away from the default, make it easy to reset.
56
57	```
58	Maximum wait per request [___30___ s] ← custom value
59	[↺ Reset to default (15 s)]
60
61	Batch fill threshold [_70_ %] (default) ← at default
62	```
63
64	Why this matters: Domain experts often do not know what value to enter for an unfamiliar parameter. If the field is blank with no hint, they will either skip it (leaving the system in an unknown state) or enter an arbitrary value. A visible default communicates "this is what the system assumes unless you tell it otherwise."
65
66	---
67
68	## Input Types Matched to Domain Semantics
69
70	Choose the input type based on what the parameter means, not just its data type.
71
72	\| Parameter nature \| Input type \| Example \|
73	\|---\|---\|---\|
74	\| Binary rule (on/off) \| Toggle switch \| "Retry automatically: [toggle]" \|
75	\| Constrained number with clear unit \| Number input with unit label \| "Max wait: [___] s" \|
76	\| Choice between n

People who liked this also viewed

6 picks

Type

domain-expert-configuration

27stars5forks

View on GitHub

How to install domain-expert-configuration?

dembrandt/dembrandt-skills/domain-expert-configuration

$npx -y skills add dembrandt/dembrandt-skills --skill domain-expert-configuration

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Domain Expert Configuration
2
3	A domain expert configuration UI exposes the parameters of a complex system — an optimisation algorithm, a planning engine, a simulation — to users who understand the problem domain deeply but have no knowledge of the system's internals.
4
5	The challenge: the system's parameters are defined in technical terms (weights, thresholds, flags, tolerances). The user thinks in domain terms (how long to wait, when to retry, how to group results). The UI must translate between these two vocabularies — always favouring the user's language.
6
7	---
8
9	## The Core Principle: Domain Language Over Technical Language
10
11	Every parameter label, tooltip, and error message should describe what the parameter means in the user's world, not what it does inside the system.
12
13	\| Technical label \| Domain label \|
14	\|---\|---\|
15	\| `max_concurrent_jobs` \| Maximum tasks running at once \|
16	\| `enable_auto_retry` \| Retry failed tasks automatically \|
17	\| `batch_allocation_threshold` \| Start a new batch after (% filled) \|
18	\| `request_timeout_ms` \| Maximum wait per request (seconds) \|
19	\| `enable_fuzzy_matching` \| Allow approximate matches \|
20
21	If you cannot write a domain label for a parameter, question whether the user should be exposed to it at all. Parameters that cannot be explained in domain terms belong in a developer configuration file, not in the user-facing UI.
22
23	---
24
25	## Grouping by Domain Concept
26
27	Parameters should be grouped by the aspect of the real-world problem they control — not by their technical category (booleans together, numbers together) and not alphabetically.
28
29	A processing tool might group as:
30
31	```
32	Processing limits
33	└─ Maximum tasks at once
34	└─ Maximum wait per request
35	└─ Memory ceiling
36
37	Matching rules
38	└─ Allow approximate matches
39	└─ Case sensitivity
40	└─ Required fields
41
42	Batching behaviour
43	└─ Batch fill threshold
44	└─ Maximum batches
45	```
46
47	Each group should have a short heading that describes what aspect of the task it controls, not what kind of parameter it is.
48
49	---
50
51	## Sensible Defaults
52
53	Every parameter must have a default that works correctly for the majority of cases. The user should be able to start with all defaults and get a reasonable result.
54
55	Show the default value: When a field is at its default, indicate this. When a user has changed a value away from the default, make it easy to reset.
56
57	```
58	Maximum wait per request [___30___ s] ← custom value
59	[↺ Reset to default (15 s)]
60
61	Batch fill threshold [_70_ %] (default) ← at default
62	```
63
64	Why this matters: Domain experts often do not know what value to enter for an unfamiliar parameter. If the field is blank with no hint, they will either skip it (leaving the system in an unknown state) or enter an arbitrary value. A visible default communicates "this is what the system assumes unless you tell it otherwise."
65
66	---
67
68	## Input Types Matched to Domain Semantics
69
70	Choose the input type based on what the parameter means, not just its data type.
71
72	\| Parameter nature \| Input type \| Example \|
73	\|---\|---\|---\|
74	\| Binary rule (on/off) \| Toggle switch \| "Retry automatically: [toggle]" \|
75	\| Constrained number with clear unit \| Number input with unit label \| "Max wait: [___] s" \|
76	\| Choice between n

People who liked this also viewed

6 picks

Type