@yeaft/webchat-agent 0.1.1003 → 0.1.1005
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/yeaft/prompts.js +42 -2
- package/yeaft/templates/base.md +16 -0
- package/yeaft/templates/common-rules.md +16 -0
- package/yeaft/tools/route-forward.js +10 -5
package/package.json
CHANGED
package/yeaft/prompts.js
CHANGED
|
@@ -197,6 +197,7 @@ const PROMPTS = {
|
|
|
197
197
|
tools: (names) => `Available tools: ${names}`,
|
|
198
198
|
// DESIGN-PROMPT §3 ④ — Active Scope header
|
|
199
199
|
activeScopeHeader: '## active_scope',
|
|
200
|
+
multiVpRoutingHeader: '## multi_vp_routing',
|
|
200
201
|
sessionAnnouncementHeader: '[Session Announcement]',
|
|
201
202
|
// Project-doc (CLAUDE.md / AGENTS.md) header + one-liner intro. Both
|
|
202
203
|
// filenames are recognized: CLAUDE.md is this project's convention,
|
|
@@ -212,6 +213,7 @@ const PROMPTS = {
|
|
|
212
213
|
tools: (names) => `可用工具:${names}`,
|
|
213
214
|
// DESIGN-PROMPT §3 ④ — Active Scope header
|
|
214
215
|
activeScopeHeader: '## active_scope',
|
|
216
|
+
multiVpRoutingHeader: '## multi_vp_routing',
|
|
215
217
|
sessionAnnouncementHeader: '[会话公告]',
|
|
216
218
|
// 项目文档块:CLAUDE.md / AGENTS.md(与 Codex 通用命名兼容)。
|
|
217
219
|
projectDocHeader: '[项目文档]',
|
|
@@ -393,6 +395,9 @@ export function buildSystemPrompt({
|
|
|
393
395
|
const activeScopeBlock = renderActiveScope(activeScope, lang);
|
|
394
396
|
if (activeScopeBlock) parts.push(activeScopeBlock);
|
|
395
397
|
|
|
398
|
+
const multiVpRoutingBlock = renderMultiVpRouting(activeScope, lang);
|
|
399
|
+
if (multiVpRoutingBlock) parts.push(multiVpRoutingBlock);
|
|
400
|
+
|
|
396
401
|
return parts.join('\n\n');
|
|
397
402
|
}
|
|
398
403
|
|
|
@@ -490,7 +495,11 @@ function firstNonEmptyString(...values) {
|
|
|
490
495
|
}
|
|
491
496
|
|
|
492
497
|
function renderSessionMembersLine(members) {
|
|
493
|
-
|
|
498
|
+
return normalizeSessionMemberIds(members).join(', ');
|
|
499
|
+
}
|
|
500
|
+
|
|
501
|
+
function normalizeSessionMemberIds(members) {
|
|
502
|
+
if (!Array.isArray(members)) return [];
|
|
494
503
|
const clean = [];
|
|
495
504
|
const seen = new Set();
|
|
496
505
|
for (const member of members) {
|
|
@@ -500,7 +509,38 @@ function renderSessionMembersLine(members) {
|
|
|
500
509
|
seen.add(id);
|
|
501
510
|
clean.push(id);
|
|
502
511
|
}
|
|
503
|
-
return clean
|
|
512
|
+
return clean;
|
|
513
|
+
}
|
|
514
|
+
|
|
515
|
+
function renderMultiVpRouting(activeScope, lang) {
|
|
516
|
+
if (!activeScope || typeof activeScope !== 'object') return '';
|
|
517
|
+
const ownId = firstNonEmptyString(activeScope.sessionMember, activeScope.vpId);
|
|
518
|
+
const members = normalizeSessionMemberIds(activeScope.sessionMembers || activeScope.members);
|
|
519
|
+
const peers = ownId ? members.filter((member) => member !== ownId) : members;
|
|
520
|
+
if (peers.length === 0) return '';
|
|
521
|
+
|
|
522
|
+
const header = lang.multiVpRoutingHeader || '## multi_vp_routing';
|
|
523
|
+
if (lang === PROMPTS.zh) {
|
|
524
|
+
return [
|
|
525
|
+
header,
|
|
526
|
+
`当前 VP: ${ownId || 'unknown'}`,
|
|
527
|
+
`可转发 VP: ${peers.join(', ')}`,
|
|
528
|
+
'- 多 VP session 中,先主动感知这些 VP 的职责;不要假装只有你一个人在场。',
|
|
529
|
+
'- 当用户点名其他 VP、任务明显属于其他 VP、需要并行协作,或你需要另一个 VP 继续处理时,必须调用 `route_forward`。',
|
|
530
|
+
'- VP 自己写 @mention 不会触发路由;只有 `route_forward` 工具会真正把任务交给目标 VP。',
|
|
531
|
+
'- 如果要多人一起处理,调用 `route_forward`,`to` 可填目标 vpId 或 `all`;`text` 要包含明确任务和必要上下文。',
|
|
532
|
+
].join('\n');
|
|
533
|
+
}
|
|
534
|
+
|
|
535
|
+
return [
|
|
536
|
+
header,
|
|
537
|
+
`Current VP: ${ownId || 'unknown'}`,
|
|
538
|
+
`Forwardable VPs: ${peers.join(', ')}`,
|
|
539
|
+
'- In a multi-VP session, actively notice these peers and their likely responsibilities; do not behave as if you are alone.',
|
|
540
|
+
'- When the user names another VP, the task clearly belongs to another VP, parallel collaboration is needed, or another VP should continue the work, you MUST call `route_forward`.',
|
|
541
|
+
'- VP-written @mentions do not route anything; only the `route_forward` tool performs a real hand-off.',
|
|
542
|
+
'- For multi-person work, call `route_forward` with a target vpId or `all`; include the concrete task and required context in `text`.',
|
|
543
|
+
].join('\n');
|
|
504
544
|
}
|
|
505
545
|
|
|
506
546
|
/**
|
package/yeaft/templates/base.md
CHANGED
|
@@ -23,12 +23,20 @@ You are participating in the current session. Keep the user's context, answer fr
|
|
|
23
23
|
- **Design / UI:** focus on user path, clarity, consistency with the design system, and what should be removed.
|
|
24
24
|
- **Planning:** make the plan short and actionable, then start execution unless a blocking unknown requires user input.
|
|
25
25
|
|
|
26
|
+
## Communicating With the User
|
|
27
|
+
|
|
28
|
+
- User-facing text is for a person, not a console log. Write complete, readable sentences with enough context for the user to pick up the thread cold.
|
|
29
|
+
- Keep normal prose visually compact: group related sentences into short paragraphs, usually 2-4 sentences; insert a blank line only when the topic or structure changes.
|
|
30
|
+
- Avoid unexplained shorthand, internal labels, and line-by-line status dumps in the final answer. Use short progress updates only when they help the user follow long-running work.
|
|
31
|
+
|
|
26
32
|
## Output Format
|
|
27
33
|
|
|
28
34
|
- Use compact GitHub-flavored Markdown.
|
|
29
35
|
- Lead with the conclusion; do not write one sentence per paragraph.
|
|
30
36
|
- Use lists for parallel facts, not for every sentence.
|
|
31
37
|
- Use fenced code blocks only for code, commands, config, diffs, or logs, and include a language tag.
|
|
38
|
+
- Do not wrap ordinary prose, summaries, labels, headings, bullet lists, or single words in fenced code blocks.
|
|
39
|
+
- For inline references to files, commands, identifiers, statuses, or short literals, use inline code instead of a fenced block.
|
|
32
40
|
- Reference files with inline code, e.g. `agent/yeaft/prompts.js`.
|
|
33
41
|
- For development summaries, use `Changes / Validation / Risks` or the equivalent concise structure.
|
|
34
42
|
- For reviews, use `Conclusion / Findings / Validation`.
|
|
@@ -58,12 +66,20 @@ You are participating in the current session. Keep the user's context, answer fr
|
|
|
58
66
|
- **设计 / UI:** 关注用户路径、清晰度、设计系统一致性,以及哪些东西应该删除。
|
|
59
67
|
- **规划:** 计划要短且可执行;除非被阻塞,否则计划后继续执行。
|
|
60
68
|
|
|
69
|
+
## 和用户沟通
|
|
70
|
+
|
|
71
|
+
- 面向用户的文字是给人读的,不是控制台日志。使用完整、可读的句子,给足上下文,让用户中途回来也能接上。
|
|
72
|
+
- 普通说明保持紧凑美观:把相关句子合成短自然段,通常 2-4 句一段;只有话题或结构切换时才空行。
|
|
73
|
+
- 避免未解释的缩写、内部标签和一行一条的状态日志。只有长任务需要用户跟进时,才给简短进度更新。
|
|
74
|
+
|
|
61
75
|
## 输出格式
|
|
62
76
|
|
|
63
77
|
- 使用紧凑的 GitHub 风格 Markdown。
|
|
64
78
|
- 先给结论;不要一句话一段。
|
|
65
79
|
- 列表用于并列信息,不要把每句话都拆成 bullet。
|
|
66
80
|
- fenced code block 只用于代码、命令、配置、diff 或日志,并写语言标识。
|
|
81
|
+
- 不要把普通说明、摘要、标签、标题、列表或单个词包进 fenced code block。
|
|
82
|
+
- 文件路径、命令、标识符、状态值或短文本用 inline code,不要用 fenced code block。
|
|
67
83
|
- 文件路径用 inline code,例如 `agent/yeaft/prompts.js`。
|
|
68
84
|
- 开发总结用 `改动 / 验证 / 风险` 或等价的简洁结构。
|
|
69
85
|
- Review 用 `结论 / Findings / 验证`。
|
|
@@ -20,12 +20,20 @@
|
|
|
20
20
|
- **Design / UI:** describe the user path, the design-system fit, the interaction details, and the risk. Avoid generic visual slogans.
|
|
21
21
|
- **Planning:** write a short ordered plan, then continue executing unless the first step is genuinely blocked by missing user input.
|
|
22
22
|
|
|
23
|
+
## Communicating With the User
|
|
24
|
+
|
|
25
|
+
- User-facing text is for a person, not a console log. Write complete, readable sentences with enough context for the user to pick up the thread cold.
|
|
26
|
+
- Keep normal prose visually compact: group related sentences into short paragraphs, usually 2-4 sentences; insert a blank line only when the topic or structure changes.
|
|
27
|
+
- Avoid unexplained shorthand, internal labels, and line-by-line status dumps in the final answer. Use short progress updates only when they help the user follow long-running work.
|
|
28
|
+
|
|
23
29
|
## Output Format
|
|
24
30
|
|
|
25
31
|
- Use GitHub-flavored Markdown.
|
|
26
32
|
- Write normal explanations as compact natural paragraphs; do not split every sentence into its own paragraph.
|
|
27
33
|
- Use flat lists for parallel information; avoid deep nesting.
|
|
28
34
|
- Use fenced code blocks only for real code, commands, configs, diffs, logs, or exact text the user must copy. Always include a language tag.
|
|
35
|
+
- Do not wrap ordinary prose, summaries, labels, headings, bullet lists, or single words in fenced code blocks.
|
|
36
|
+
- For inline references to files, commands, identifiers, statuses, or short literals, use inline code instead of a fenced block.
|
|
29
37
|
- Reference files with inline code, for example `agent/yeaft/prompts.js`.
|
|
30
38
|
- For development completion, use: `Changed`, `Verified`, `Risk / next step`.
|
|
31
39
|
- For review, use: `Conclusion`, `Findings`, `Verification`.
|
|
@@ -70,12 +78,20 @@
|
|
|
70
78
|
- **设计 / UI:** 说明用户路径、设计系统匹配、交互细节和风险;避免空泛视觉口号。
|
|
71
79
|
- **规划:** 写短的有序计划,然后继续执行;只有第一步确实被用户信息阻塞时才停下来问。
|
|
72
80
|
|
|
81
|
+
## 和用户沟通
|
|
82
|
+
|
|
83
|
+
- 面向用户的文字是给人读的,不是控制台日志。使用完整、可读的句子,给足上下文,让用户中途回来也能接上。
|
|
84
|
+
- 普通说明保持紧凑美观:把相关句子合成短自然段,通常 2-4 句一段;只有话题或结构切换时才空行。
|
|
85
|
+
- 避免未解释的缩写、内部标签和一行一条的状态日志。只有长任务需要用户跟进时,才给简短进度更新。
|
|
86
|
+
|
|
73
87
|
## 输出格式
|
|
74
88
|
|
|
75
89
|
- 使用 GitHub 风格 Markdown。
|
|
76
90
|
- 普通说明写成紧凑自然段,不要一句话一段。
|
|
77
91
|
- 并列信息用扁平列表,避免深层嵌套。
|
|
78
92
|
- fenced code block 只用于真正的代码、命令、配置、diff、日志或用户需要精确复制的文本,并始终带语言标识。
|
|
93
|
+
- 不要把普通说明、摘要、标签、标题、列表或单个词包进 fenced code block。
|
|
94
|
+
- 文件路径、命令、标识符、状态值或短文本用 inline code,不要用 fenced code block。
|
|
79
95
|
- 文件路径用 inline code,例如 `agent/yeaft/prompts.js`。
|
|
80
96
|
- 开发完成汇报使用:`改动`、`验证`、`风险 / 下一步`。
|
|
81
97
|
- Review 使用:`结论`、`Findings`、`验证`。
|
|
@@ -27,16 +27,21 @@ import { defineTool } from './types.js';
|
|
|
27
27
|
|
|
28
28
|
export default defineTool({
|
|
29
29
|
name: 'RouteForward',
|
|
30
|
-
description: `Hand this turn off to another VP in the same
|
|
30
|
+
description: `Hand this turn off to another VP in the same session.
|
|
31
31
|
|
|
32
32
|
Use this tool — NOT free-text @mentions — to route a question or task to
|
|
33
33
|
another VP. VP-authored @mentions in chat text are NOT automatically routed
|
|
34
|
-
(the
|
|
35
|
-
|
|
34
|
+
(the coordinator only text-routes user messages); you must call RouteForward
|
|
35
|
+
for the hand-off to take effect.
|
|
36
|
+
|
|
37
|
+
In a multi-VP session, treat RouteForward as the required hand-off mechanism:
|
|
38
|
+
- If the user names another VP, call RouteForward to that vpId.
|
|
39
|
+
- If another VP clearly owns the domain or should continue the work, call RouteForward instead of only mentioning them.
|
|
40
|
+
- If the task needs parallel collaboration, call RouteForward with a target vpId or "all".
|
|
36
41
|
|
|
37
42
|
Arguments:
|
|
38
43
|
- to (string): target vpId, or the literal "all" to broadcast to every
|
|
39
|
-
other member of the
|
|
44
|
+
other member of the session (subject to the session fan-out cap).
|
|
40
45
|
- text (string): the message body to send on your behalf.
|
|
41
46
|
- reason (string, optional): short rationale for the forward, recorded on
|
|
42
47
|
the message meta for audit / UI display.
|
|
@@ -47,7 +52,7 @@ Rules:
|
|
|
47
52
|
- Forwards carry a causedBy chain; chains deeper than 10 hops are blocked
|
|
48
53
|
(chain_depth_exceeded).
|
|
49
54
|
- A single target may be forwarded to at most 8 times per 5-second window
|
|
50
|
-
per
|
|
55
|
+
per session (throttled).
|
|
51
56
|
|
|
52
57
|
Returns JSON: { ok, dispatched?, error?, detail? }.`,
|
|
53
58
|
parameters: {
|