You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wrap operator-question choices instead of ellipsizing them
The overlay was collapsing long option labels with a middle ellipsis, so interview and permission choices became unreadable. Choices now wrap to a shared height.
ask_operator rejects labels over 48 characters and the interview skill puts trade-offs in the transcript, not in the option string.
Copy file name to clipboardExpand all lines: plugins/corbits-skills/skills/interview/SKILL.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,9 +37,9 @@ Each question is one `ask_operator` call: `question` (string) plus `options` (ar
37
37
38
38
**Quality bar for options:**
39
39
40
-
- Mutually exclusive and concrete — not "yes / no / maybe"
40
+
- Mutually exclusive **short labels** — not "yes / no / maybe"
41
41
- Each option a real, defensible choice — not a strawman
42
-
-Put trade-offs in the option string itself ("simpler but less flexible", "consistent with existing patterns") — `options` are strings, not `{ label, description }` objects
42
+
-Trade-offs, rationale, and context go in the **preceding transcript reply**, then `ask_operator`with a brief question and brief labels. Do not put essays in the option string — `options` are strings, not `{ label, description }` objects
43
43
- Ground options in the topic and context — do not invent generic options when concrete ones exist
44
44
- Combination options only when the dimension genuinely permits more than one answer
45
45
- If you have a recommendation, put it first and label it
@@ -90,34 +90,34 @@ After emitting the findings, stop. Do not load other skills, invoke other agents
90
90
91
91
**Invocation:**`use_skill(name="interview")` with the topic in the conversation, or `/interview notification system; backend is Node/Postgres, internal users only, must integrate with existing auth`
**Round 1** (three parallel `ask_operator` calls — independent dimensions, so ask together). Trade-offs belong in the transcript before the calls, not in the labels — e.g. "critical vs activity vs re-engagement; never-miss vs real-time vs per-event opt-in; in-app vs email vs webhook."
94
94
95
95
```
96
96
ask_operator({
97
97
question: "What is the primary goal of the notification system?",
98
98
options: [
99
-
"Alert on critical events — Errors, security issues, SLA breaches",
100
-
"Keep users informed of activity — Mentions, replies, updates",
101
-
"Drive user re-engagement — Digests, reminders, summaries"
99
+
"Alert on critical events",
100
+
"Keep users informed of activity",
101
+
"Drive user re-engagement"
102
102
]
103
103
})
104
104
105
105
ask_operator({
106
106
question: "If you had to pick one, which matters most?",
107
107
options: [
108
-
"Reliability of delivery (recommended) — Never miss a notification, even if delayed",
109
-
"Latency — Real-time, even if some are dropped under load",
110
-
"User control — Fine-grained per-event opt-in/out"
108
+
"Reliability of delivery (recommended)",
109
+
"Latency",
110
+
"User control"
111
111
]
112
112
})
113
113
114
114
ask_operator({
115
115
question: "Which delivery channels do you want?",
116
116
options: [
117
-
"In-app — Notification center in the UI",
118
-
"Email — Per-event or digest",
117
+
"In-app",
118
+
"Email",
119
119
"In-app + Email",
120
-
"Webhook — Outbound HTTP to a user-configured endpoint",
0 commit comments