@yugoo-design/dsh-design-skills-web-app 0.1.2 → 0.2.2
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/bundles/ai_agent_capabilities/locales/en-US.json +1 -1
- package/bundles/ai_agent_capabilities/locales/zh-CN.json +1 -1
- package/bundles/business_data/locales/en-US.json +1 -1
- package/bundles/business_data/locales/zh-CN.json +1 -1
- package/bundles/business_rules/locales/en-US.json +1 -1
- package/bundles/business_rules/locales/zh-CN.json +1 -1
- package/bundles/design_style/locales/en-US.json +1 -1
- package/bundles/design_style/locales/zh-CN.json +1 -1
- package/bundles/flow_design/locales/en-US.json +1 -1
- package/bundles/flow_design/locales/zh-CN.json +1 -1
- package/bundles/function_modules/locales/en-US.json +1 -2
- package/bundles/function_modules/locales/zh-CN.json +1 -2
- package/bundles/function_modules/panel.yaml +1 -1
- package/bundles/integration_design/locales/en-US.json +1 -1
- package/bundles/integration_design/locales/zh-CN.json +1 -1
- package/bundles/notification_design/locales/en-US.json +1 -1
- package/bundles/notification_design/locales/zh-CN.json +1 -1
- package/bundles/page_design/locales/en-US.json +1 -1
- package/bundles/page_design/locales/zh-CN.json +1 -1
- package/bundles/quality_acceptance/locales/en-US.json +1 -1
- package/bundles/quality_acceptance/locales/zh-CN.json +1 -1
- package/bundles/research/SKILL.md +38 -4
- package/bundles/research/locales/en-US.json +1 -1
- package/bundles/research/locales/zh-CN.json +1 -1
- package/bundles/research/reference/artifact-contract.md +31 -0
- package/bundles/research/reference/preview.json +1 -1
- package/bundles/research/skill.yaml +1 -1
- package/bundles/research/validation.yaml +3 -0
- package/bundles/role_access/locales/en-US.json +1 -1
- package/bundles/role_access/locales/zh-CN.json +1 -1
- package/bundles/smart_questions/locales/en-US.json +1 -1
- package/bundles/smart_questions/locales/zh-CN.json +1 -1
- package/bundles/web_app_prd_assembly/locales/en-US.json +1 -1
- package/bundles/web_app_prd_assembly/locales/zh-CN.json +1 -1
- package/bundles/whiteboard/locales/en-US.json +1 -1
- package/bundles/whiteboard/locales/zh-CN.json +1 -1
- package/kits/web_app/kit.yaml +1 -1
- package/kits/web_app/mindset.md +1 -1
- package/package.json +1 -1
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
"newAgent": "New Agent",
|
|
6
6
|
"numberedAgent": "New Agent {index}",
|
|
7
7
|
"empty": "Add an Agent and reference Skills and tools as needed.",
|
|
8
|
-
"guidance": "
|
|
8
|
+
"guidance": "Check whether the Agent goals, responsibilities and tools fit together, and whether capabilities are missing or unnecessary. Saving here records the design; it does not install or run tools.",
|
|
9
9
|
"name": "Name",
|
|
10
10
|
"description": "Responsibility and goal",
|
|
11
11
|
"functionRefs": "Related functions",
|
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
"newAgent": "新 Agent",
|
|
6
6
|
"numberedAgent": "新 Agent {index}",
|
|
7
7
|
"empty": "添加一个 Agent,按需引用技能和工具。",
|
|
8
|
-
"guidance": "
|
|
8
|
+
"guidance": "核对 Agent 的目标、能力分工和工具是否匹配,有无缺失或不必要的能力;这里保存的是设计,不会安装或执行工具。",
|
|
9
9
|
"name": "名称",
|
|
10
10
|
"description": "职责与目标",
|
|
11
11
|
"functionRefs": "关联功能",
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"bundleDescription": "- **Capability**: define the durable business things a Web App remembers, the information kept for each thing, user-visible states, and grounded associations or subtype inheritance between object types.\n- **Resolves**: S/T gaps where users must find, distinguish, update, or track lasting things but their meaning and information are unclear.\n- **Candidate when**: the product must remember the same business thing across actions or visits, or the user asks what information or custom fields to keep.\n- **Do not infer**: pages, actions, workflow steps, reports, filters, database tables, API payloads, and state-change behavior are not business things. Type relationships belong here; workflow transitions and instance provenance do not.\n- **Output**: a native `business_data` panel with ordered business things, information fields, optional states, and one relationship model shared by the form and canvas.",
|
|
3
3
|
"objects": "Business objects", "object": "business object", "relations": "Object relationships", "relation": "relationship",
|
|
4
4
|
"empty": "Add the first business object this product needs to remember and manage.",
|
|
5
|
-
"guidance": "
|
|
5
|
+
"guidance": "Check that the things, fields and states the product needs to record are complete and that their relationships match reality. The relationship canvas and forms edit the same design.",
|
|
6
6
|
"graphHint": "Cards represent object types; arrows point from source to target. Inheritance connects a subtype to its parent, not containment or instance provenance.",
|
|
7
7
|
"parents": "Parent definitions", "parentHint": "Only local information is edited below. Shared information stays with its parent types.", "reverse": "Swap endpoints",
|
|
8
8
|
"createSubtype": "Add subtype", "createSubtypeTitle": "Create a subtype",
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"bundleDescription": "- **能力**:定义 Web App 持久记忆的业务事物、信息和用户可见状态,以及对象类型间有依据的关联与继承。\n- **解决**:用户需要查找、区分、更新或跟踪持久事物,但其含义和信息不明确时的 S/T 类缺口。\n- **适用时机**:产品需要跨操作或跨访问记住同一业务事物,或用户询问应保留哪些信息或自定义字段。\n- **不要推断**:页面、操作、流程步骤、报表、筛选器、数据库表、API 载荷和状态变化行为都不是业务事物;类型间关系属于本切片,流程转换和实例来源不属于。\n- **输出**:对象、信息、状态与关系共用 canonical 的原生表单/关系画布 `business_data` 面板。",
|
|
3
3
|
"objects": "业务对象", "object": "业务对象", "relations": "对象关系", "relation": "关系",
|
|
4
4
|
"empty": "添加产品需要长期保存和管理的第一个业务对象。",
|
|
5
|
-
"guidance": "
|
|
5
|
+
"guidance": "核对产品需要记录的事物、字段和状态是否齐全,关系是否符合实际;关系画布与表单修改的是同一份设计。",
|
|
6
6
|
"graphHint": "方框表示对象类型,箭头由起点指向终点。类型继承由子类型指向父类型,不表示包含或实例来源。",
|
|
7
7
|
"parents": "沿用父类型的定义与信息", "parentHint": "下方仅维护本类型自己的信息;共享信息在父类型原处修改。", "reverse": "交换双方",
|
|
8
8
|
"createSubtype": "添加子类型", "createSubtypeTitle": "创建子类型",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check which conditions lead to which result, looking for ambiguity, conflicts or omissions. Unconditional rules may leave the condition empty.",
|
|
3
3
|
"bundleDescription": "- **Capability**: turn product decisions into independent rules that name relevant conditions or inputs and deterministic outcomes.\n- **Resolves**: S/T gaps where reasonable implementations could differ without a qualification, validation, calculation, threshold, automation, or exception.\n- **Candidate when**: an action, business thing, flow branch, price, limit, approval, or eligibility decision needs deterministic behavior.\n- **Do not infer**: ordinary step order, role permission, field definition, page layout, UI copy, and technical implementation are not automatically business rules.\n- **Output**: a native `business_rules` panel with an ordered list of editable rules.",
|
|
4
4
|
"empty": "No business rules yet. Add one to explain when and how the product should respond.",
|
|
5
5
|
"rules": "Business rules",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "检查每条规则在什么条件下产生什么结果,是否有歧义、冲突或遗漏;无条件适用的规则可不填条件。",
|
|
3
3
|
"bundleDescription": "- **能力**:把产品决策转化为独立规则,明确相关条件或输入以及确定性结果。\n- **解决**:缺少资格、校验、计算、阈值、自动化或异常定义会导致合理实现产生差异时的 S/T 类缺口。\n- **适用时机**:操作、业务事物、流程分支、价格、限制、审批或资格判断需要确定行为。\n- **不要推断**:普通步骤顺序、角色权限、字段定义、页面布局、UI 文案和技术实现并不自动属于业务规则。\n- **输出**:包含有序可编辑规则列表的原生 `business_rules` 面板。",
|
|
4
4
|
"empty": "还没有业务规则。先添加一条,说明在什么情况下产品应该怎样处理。",
|
|
5
5
|
"rules": "业务规则",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Judge whether the visual style fits the users and context, and whether text and actions are clear. Check the preview after adjustments; structural or component-language changes require regeneration after saving.",
|
|
3
3
|
"bundleDescription": "- **Capability**: visual direction for a web/mobile product — palette, typography, component language, and one representative UI preview.\n- **Resolves**: S/T gaps in visual hierarchy, component language, and reviewable interface direction; visible feedback may also add U evidence.\n- **Candidate when**: the user explicitly asks for visual direction, one representative screen is the smallest useful way to settle a material product decision, or the user has explicitly requested high-fidelity pages and the project has no visual baseline.\n- **Do not infer**: website, page, or app alone does not make visual work mandatory; an explicit high-fidelity Page request is an output dependency rather than keyword inference.\n- **Output**: `design_style` panel, generated `DESIGN.md`, generated `tokens.css`, and one representative HTML preview.",
|
|
4
4
|
"config.colors.primary": "Primary",
|
|
5
5
|
"config.colors.primaryLight": "Primary light",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "对照目标用户和使用场景,判断视觉风格是否合适、文字和操作是否清晰;调整后查看预览,结构或组件语言变更需保存后重新生成。",
|
|
3
3
|
"bundleDescription": "- **能力**:为 Web/移动产品确定视觉方向,包括色板、字体、组件语言和一个代表性 UI 预览。\n- **解决**:视觉层级、组件语言和可审阅界面方向中的 S/T 类缺口;可见反馈也可能补充 U 类证据。\n- **适用时机**:用户明确要求视觉方向、一个代表性页面是确定重要产品决策的最小有用方式,或已明确请求高保真页面但项目尚无视觉基线。\n- **不要推断**:仅仅提到网站、页面或应用,并不意味着必须进行视觉设计;明确请求高保真页面属于输出依赖,不是关键词推断。\n- **输出**:`design_style` 面板、生成的 `DESIGN.md`、`tokens.css` 和一个代表性 HTML 预览。",
|
|
4
4
|
"config.colors.primary": "主色",
|
|
5
5
|
"config.colors.primaryLight": "主色浅色",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Follow the flow to check who owns each step, whether branch conditions are clear and how exceptions are handled. Adjust steps, connections or rules that do not fit.",
|
|
3
3
|
"bundleDescription": "- **Capability**: product-process design — BPMN per material process with human/system responsibility, triggers, handoffs, and outcomes.\n- **Resolves**: S/T gaps by making established actors, product automation, ordered states, branches, triggers, and observable outcomes inspectable.\n- **Candidate when**: roles, approvals, handoffs, exceptions, or an explicitly material journey need an agreed process contract.\n- **Do not infer**: ordinary clicks or a vague product idea do not justify inventing actors, policy branches, or a BPMN diagram.\n- **Output**: `flow_design` panel — one BPMN per material product process; every diagram exposes what the system actually does.",
|
|
4
4
|
"empty":"Process plans and diagrams appear here.", "processes":"Business flows", "process":"Process", "title":"Name", "description":"Description",
|
|
5
5
|
"tier":"Value tier", "core":"Core", "business":"Business", "auxiliary":"Auxiliary", "type":"Flow structure", "linear":"Sequential", "approval":"Approval", "parallel":"Parallel", "event":"Event-driven",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "沿流程核对每一步由谁负责、分支条件是否清楚,以及异常如何处理;调整不合理的步骤、连线或规则。",
|
|
3
3
|
"bundleDescription": "- **能力**:面向产品流程进行设计,为每个重要流程建立包含人员/系统职责、触发、交接和结果的 BPMN。\n- **解决**:让已确定的角色、产品自动化、状态顺序、分支、触发条件和可观察结果可审阅,从而补齐 S/T 类缺口。\n- **适用时机**:角色、审批、交接、异常或明确重要的用户旅程需要形成一致的流程约定。\n- **不要推断**:普通点击路径或模糊的产品想法,不足以凭空编造角色、策略分支或 BPMN 图。\n- **输出**:每个重要产品流程一张 BPMN 的 `flow_design` 面板,每张图都明确系统实际做什么。",
|
|
4
4
|
"empty":"流程计划和流程图将在这里展示。", "processes":"业务流程", "process":"流程", "title":"名称", "description":"流程说明",
|
|
5
5
|
"tier":"价值层级", "core":"核心流程", "business":"业务流程", "auxiliary":"辅助流程", "type":"流程结构", "linear":"顺序", "approval":"审批", "parallel":"并行", "event":"事件驱动",
|
|
@@ -6,8 +6,7 @@
|
|
|
6
6
|
"source": "Origin", "ai": "AI proposal", "user": "User added", "reason": "Notes", "references": "Pinned sources",
|
|
7
7
|
"situation": "Usage scenario", "behaviors": "Core behaviors", "behavior": "Behavior", "inputs": "Inputs", "input": "Input",
|
|
8
8
|
"outputs": "Outcomes", "output": "Outcome", "limits": "Scope boundaries", "limit": "Boundary", "exceptions": "Exception handling", "exception": "Exception", "condition": "Condition", "response": "System response",
|
|
9
|
-
"guidance": "
|
|
10
|
-
"applicationMindMap": "Application Functional Mind Map",
|
|
9
|
+
"guidance": "Check that the functions cover what users need to accomplish. Look for omissions, overlap or excess scope, and adjust descriptions and priorities.",
|
|
11
10
|
"createRequest": "Please add the following function",
|
|
12
11
|
"createSubmit": "Add with AI",
|
|
13
12
|
"detailsAndEvidence": "Function details"
|
|
@@ -6,8 +6,7 @@
|
|
|
6
6
|
"source": "来源", "ai": "AI 提出", "user": "用户添加", "reason": "备注", "references": "关联来源",
|
|
7
7
|
"situation": "使用场景", "behaviors": "核心行为", "behavior": "行为", "inputs": "输入", "input": "输入",
|
|
8
8
|
"outputs": "结果", "output": "结果", "limits": "范围边界", "limit": "边界", "exceptions": "异常处理", "exception": "异常情况", "condition": "发生条件", "response": "处理方式",
|
|
9
|
-
"guidance": "
|
|
10
|
-
"applicationMindMap": "应用功能脑图",
|
|
9
|
+
"guidance": "检查功能是否覆盖用户要完成的事情,有无遗漏、重复或超出范围;调整不准确的说明和优先级。",
|
|
11
10
|
"createRequest": "请新增以下功能",
|
|
12
11
|
"createSubmit": "AI 智能添加",
|
|
13
12
|
"detailsAndEvidence": "功能详情"
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check what each external connection exchanges, why it is needed and what happens on failure. Add actual interface references, without entering real secrets.",
|
|
3
3
|
"bundleDescription": "- **Capability**: design each product-relevant external connection as a complete new Plugin, with concise product-side notes.\n- **Resolves**: S/T gaps around which external capability the product needs, how the Agent accesses and uses it, and what the product does when the connection succeeds or fails.\n- **Candidate when**: a product behavior depends on an external API, webhook, SDK, MCP tool, third-party component, device, or team-operated system.\n- **Do not infer**: never invent vendor behavior, URL, credential, endpoint, or field-level API contract.\n- **Output**: `integration_design` panel — one editable Plugin-style connection record plus product-side remarks for every external capability.",
|
|
4
4
|
"empty": "No integrations yet. Add connection instructions and product-side rules as needed.",
|
|
5
5
|
"integrations": "System integrations",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "核对每个外部连接要交换什么、为何需要,以及失败时如何处理;补充真实接口资料,不填写真实密钥。",
|
|
3
3
|
"bundleDescription": "- **能力**:把每项与产品相关的外部连接设计成完整的新 Plugin,并附上简洁的产品侧说明。\n- **解决**:产品需要哪种外部能力、Agent 如何访问和使用它,以及连接成功或失败时产品如何处理等 S/T 类缺口。\n- **适用时机**:产品行为依赖外部 API、Webhook、SDK、MCP 工具、第三方组件、设备或团队运营的系统。\n- **不要推断**:绝不凭空编造供应商行为、URL、凭证、端点或字段级 API 约定。\n- **输出**:`integration_design` 面板,为每项外部能力提供一条可编辑的 Plugin 风格连接记录和产品侧备注。",
|
|
4
4
|
"empty": "还没有系统集成。根据产品需要添加接入说明和业务规则。",
|
|
5
5
|
"integrations": "系统集成",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check that the trigger, recipients and channel are appropriate and that the message helps them take the next action. Previewing content does not send a notification.",
|
|
3
3
|
"bundleDescription": "- **Capability**: decide when an established business moment should proactively reach which people, through which human channel, with what useful message and next action.\n- **Resolves**: S/T gaps where a user could miss a material approval, deadline, exception, handoff, or completed result while not looking at the relevant page.\n- **Candidate when**: an established flow contains waiting, handoff, deadline, exception, or material status change and somebody must know or act without already being on that page.\n- **Do not infer**: every state change needs a notification; page feedback, dashboards, reports, exports, audit history, machine webhooks, and final marketing copy belong elsewhere.\n- **Output**: `notification_design` panel — an ordered, editable set of proactive notification moments.",
|
|
4
4
|
"empty": "Add a notification: when it appears, who receives it, which channel is used and what it says.",
|
|
5
5
|
"notifications": "Notifications",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "核对触发时机、接收人和渠道是否合适,信息能否帮助对方采取下一步行动;内容预览不会发送通知。",
|
|
3
3
|
"bundleDescription": "- **能力**:确定已经建立的业务时刻应在何时、通过哪种人工渠道、向哪些人主动发送什么有用信息和下一步操作。\n- **解决**:用户未停留在相关页面时可能错过重要审批、截止日期、异常、交接或完成结果的 S/T 类缺口。\n- **适用时机**:已建立的流程包含等待、交接、截止、异常或重要状态变化,且有人必须及时知晓或行动。\n- **不要推断**:并非每次状态变化都需要通知;页面反馈、仪表盘、报表、导出、审计历史、机器 Webhook 和最终营销文案不属于这里。\n- **输出**:包含一组有序、可编辑的主动通知时刻的 `notification_design` 面板。",
|
|
4
4
|
"empty": "添加一个通知时刻,说明何时、向谁、通过什么渠道传达什么信息。",
|
|
5
5
|
"notifications": "通知时刻",
|
|
@@ -29,6 +29,6 @@
|
|
|
29
29
|
"hotspotLabel": "Source hotspot label",
|
|
30
30
|
"members": "Pages in group",
|
|
31
31
|
"map": "Page map",
|
|
32
|
-
"guidance": "
|
|
32
|
+
"guidance": "Walk through the user task and check that page content, actions and navigation form a coherent path without gaps or dead ends. Map positions and groups only organize the view.",
|
|
33
33
|
"shared": "Shared specification"
|
|
34
34
|
}
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check whether each acceptance item has a clear situation and an observable passing result. Add a checking method only when it is unclear; test code is not required.",
|
|
3
3
|
"bundleDescription": "- **Capability**: define the small set of observable requirements that tell users and the delivery team when established product behavior and material quality are good enough to accept.\n- **Resolves**: T gaps where an important function, rule, flow, page, or integration has no concrete passing result, or a material quality expectation remains vague.\n- **Candidate when**: the user asks for acceptance criteria, quality requirements, non-functional requirements, or a clear definition of done for product behavior.\n- **Do not infer**: business rules, missing product behavior, test code, release governance, project plans, risk registers, or a generic enterprise NFR checklist do not belong here.\n- **Output**: `quality_acceptance` panel — one editable ordered list of acceptance requirements.",
|
|
4
4
|
"empty": "Add an acceptance requirement: describe the situation and the outcome that counts as success.",
|
|
5
5
|
"requirements": "Acceptance requirements",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "检查每项验收是否有明确情境和可观察的通过结果,能否据此判断做对了;检查方法不明显时再补充,无需编写测试代码。",
|
|
3
3
|
"bundleDescription": "- **能力**:定义一小组可观察的要求,让用户和交付团队判断既定产品行为及重要质量是否足以验收。\n- **解决**:重要功能、规则、流程、页面或集成缺少具体通过结果,或重要质量期望仍模糊时的 T 类缺口。\n- **适用时机**:用户要求验收标准、质量要求、非功能要求,或产品行为清晰的完成定义。\n- **不要推断**:业务规则、缺失的产品行为、测试代码、发布治理、项目计划、风险登记表或泛化的企业 NFR 清单不属于这里。\n- **输出**:包含有序验收要求列表的可编辑 `quality_acceptance` 面板。",
|
|
4
4
|
"empty": "添加一项验收要求,说明在什么情况下,出现什么结果才算通过。",
|
|
5
5
|
"requirements": "验收要求",
|
|
@@ -41,7 +41,11 @@ working copy. They never use host filesystem or shell access.
|
|
|
41
41
|
|
|
42
42
|
- **Plan.** Maintain the complete plan state in `research/research.json`: rounds
|
|
43
43
|
with directions (`title` + `research_points`) and deterministic direct
|
|
44
|
-
artifact paths for new work.
|
|
44
|
+
artifact paths for new work. Preserve explicit source limits, allowed source
|
|
45
|
+
types, product scope and exclusions in the affected direction's existing
|
|
46
|
+
`research_points`, alongside its questions, so the saved plan retains the
|
|
47
|
+
complete brief across confirmation, delegation and serial takeover. Do not
|
|
48
|
+
invent a limit when the user supplied none. The Producer updates its working copy and calls
|
|
45
49
|
`design_publish({action:"handoff"})` to enter the independently configured gate,
|
|
46
50
|
and the runtime presents `开始调研` / `Start Research`; the user may revise
|
|
47
51
|
the plan before starting it.
|
|
@@ -149,6 +153,34 @@ the current product or requested exploration. Express this in the existing
|
|
|
149
153
|
`research_points`, not extra plan fields. Broad landscape research can discover
|
|
150
154
|
useful questions; it need not pretend the user has already chosen a solution.
|
|
151
155
|
|
|
156
|
+
### Honor the user's evidence bounds
|
|
157
|
+
|
|
158
|
+
The user's source limit is an acceptance condition for the requested output,
|
|
159
|
+
separate from the Host's tool/time/token budget. Carry the complete current
|
|
160
|
+
constraint into every Worker brief. Before serial research or taking over a
|
|
161
|
+
failed Worker, reread the saved direction and apply the same constraint; a failed
|
|
162
|
+
attempt does not permit a larger source set or broader product scope.
|
|
163
|
+
|
|
164
|
+
For a limit on report sources, count distinct cited document URLs across the
|
|
165
|
+
findings and its `信息来源` section, not domains, repeated citations or search
|
|
166
|
+
result counts. For example, “at most two first-party sources per direction”
|
|
167
|
+
permits at most two distinct first-party document URLs in that direction's
|
|
168
|
+
findings and matching `source_urls`. It does not mean two websites with unlimited
|
|
169
|
+
pages, nor two new sources in addition to retained ones. A limit on pages opened
|
|
170
|
+
or tool calls instead applies before retrieval; follow the user's actual wording.
|
|
171
|
+
|
|
172
|
+
Before integrating a Worker receipt or publishing serial findings, inspect the
|
|
173
|
+
landed report against the current direction's questions and bounds. If it exceeds
|
|
174
|
+
the source limit, keep the strongest permitted evidence and revise or qualify
|
|
175
|
+
every claim that depended on a removed source. Update inline links, the source
|
|
176
|
+
list and `source_urls` together; trimming only JSON or the bibliography does not
|
|
177
|
+
repair an over-budget report. Regenerate the affected round conclusion from the
|
|
178
|
+
accepted findings without adding external sources. If the permitted evidence
|
|
179
|
+
cannot support the requested answer, keep that limitation explicit rather than
|
|
180
|
+
silently adding a source. Report the actual per-direction source counts and any
|
|
181
|
+
unmet bound in the handoff. Ordinary Bundle validation does not mechanically
|
|
182
|
+
interpret these free-text constraints; passing it never waives this review.
|
|
183
|
+
|
|
152
184
|
Apply the same evidence standard to every statement, including headings,
|
|
153
185
|
table cells, chart labels and recommendation reasons:
|
|
154
186
|
- An observation says only what the source establishes, within its context.
|
|
@@ -399,7 +431,8 @@ For each direction:
|
|
|
399
431
|
1. Cover every `research_points` bullet from more than one useful search angle.
|
|
400
432
|
Stop when credible retrieved evidence supports a useful answer, or when the
|
|
401
433
|
Host's configured tool/time/token budget is exhausted. The Host owns those
|
|
402
|
-
limits;
|
|
434
|
+
runtime limits; the user's evidence/output bounds still apply to both Worker
|
|
435
|
+
and serial execution. This Skill Body does not promise a fixed number of search or fetch
|
|
403
436
|
calls. If important evidence remains missing at the configured boundary,
|
|
404
437
|
leave the gap explicit instead of extending the run indefinitely.
|
|
405
438
|
2. Open the most authoritative hits with `web_fetch` when available — search
|
|
@@ -410,8 +443,9 @@ For each direction:
|
|
|
410
443
|
writes and repairs that exact path; the Producer reads the file, checks the
|
|
411
444
|
receipt, and updates the direction state.
|
|
412
445
|
|
|
413
|
-
When delegating a direction, include this bounded-evidence policy,
|
|
414
|
-
direction's `research_points`,
|
|
446
|
+
When delegating a direction, include this bounded-evidence policy, the user's
|
|
447
|
+
explicit source/scope constraints, all of that direction's `research_points`,
|
|
448
|
+
and the complete findings contract below in the
|
|
415
449
|
Worker prompt. Search depth must not depend on whether the Producer performs the
|
|
416
450
|
direction itself or delegates it.
|
|
417
451
|
|
|
@@ -1,3 +1,3 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check whether the findings answer your question, then whether the key sources support them. Point out weak evidence or directions that need further investigation.",
|
|
3
3
|
"bundleDescription": "- **Capability**: external information gathering — market context, competitor analysis, business background, reference targets (\"what is X\").\n- **Resolves**: U gaps caused by uncertain external facts, reference products, domain conventions, regulations, or current landscape.\n- **Candidate when**: reliable external evidence would materially change a product decision and a confident answer would otherwise require guessing.\n- **Do not infer**: a named product, an unfamiliar word, or a request for a bounded draft does not by itself require a research round. Analysis explicitly requested as input to a later imitation/build does require research.\n- **Output**: `research` panel — sourced findings, their design implications and evidence limits, persisted to design state.","title":"Research","empty":"No research plan yet. Describe the external question to investigate in the conversation."}
|
|
@@ -1,3 +1,3 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "先看结论是否回答了你的问题,再核对关键来源能否支持它;指出证据不足或需要继续调查的方向。",
|
|
3
3
|
"bundleDescription": "- **能力**:收集外部信息,包括市场背景、竞品分析、业务背景和参考对象(“X 是什么”)。\n- **解决**:由不确定的外部事实、参考产品、领域惯例、法规或当前市场格局造成的 U 类缺口。\n- **适用时机**:可靠的外部证据会实质影响产品决策,而直接给出确定答案将依赖猜测。\n- **不要推断**:仅仅出现产品名、生词或要求范围明确的草案,并不需要启动调研;明确要求为后续仿制或构建提供分析时则需要调研。\n- **输出**:包含有来源的发现、设计启示和证据局限并持久化到设计状态的 `research` 面板。","title":"调研分析","empty":"暂无调研计划。请在对话中描述需要核查的外部问题。"}
|
|
@@ -8,6 +8,37 @@ Canonical state: `research/research.json`. Findings: `research/{round_id}/{direc
|
|
|
8
8
|
|
|
9
9
|
Use `artifact_kind: "research_direction"`, round-scoped `artifact_id: "{round_id}/{direction_id}"` and the exact findings file for delegation or serial focus. Conclusion focus uses `research_conclusion`, round ID and the exact conclusion file. Each author writes/repairs its artifact; the Producer reads findings for actual synthesis, updates the corresponding refs and sources, then validates and publishes the integrated round. A reference is accepted only after the file exists. There is no separate research script; use the ordinary Bundle validation.
|
|
10
10
|
|
|
11
|
+
## User bounds and evidence acceptance
|
|
12
|
+
|
|
13
|
+
For authorized research or revision, preserve explicit source limits, allowed
|
|
14
|
+
source types, product scope and exclusions in the affected direction's existing
|
|
15
|
+
`research_points`. They accompany the questions in every Worker brief and remain
|
|
16
|
+
binding when the Producer takes over a failed Worker. Host runtime budgets do
|
|
17
|
+
not relax those output constraints, and no source limit is implied when none was
|
|
18
|
+
requested.
|
|
19
|
+
|
|
20
|
+
A report-source cap counts distinct cited document URLs, including inline
|
|
21
|
+
citations and the `信息来源` list; repeated use of one URL counts once, while two
|
|
22
|
+
pages on one site count as two sources. The final source list and `source_urls`
|
|
23
|
+
must match the report's used sources. A retrieved search-result list is not the
|
|
24
|
+
report's accepted source set. If a figure uses a separate asset URL, retain its
|
|
25
|
+
link to the cited source document rather than treating an unexplained asset as
|
|
26
|
+
new evidence. An explicit limit on pages opened or tool calls applies to retrieval
|
|
27
|
+
instead; follow the user's stated unit and scope.
|
|
28
|
+
|
|
29
|
+
The Producer checks these bounds against the actual findings before acceptance
|
|
30
|
+
and again before publication, for both delegated and serial output. Repair an
|
|
31
|
+
excess by revising claims and links together; never hide extra evidence by only
|
|
32
|
+
shortening the bibliography or JSON. A conclusion cites only sources retained in
|
|
33
|
+
accepted findings. If the bounded evidence is insufficient, explain the gap
|
|
34
|
+
without silently exceeding the cap. Report actual per-direction source counts
|
|
35
|
+
and unmet constraints. The existing schema and declared rules do not infer a
|
|
36
|
+
numeric limit from free text, so structural validation is not proof of compliance.
|
|
37
|
+
|
|
38
|
+
Restoring existing research preserves its observed sources and provenance;
|
|
39
|
+
report an apparent historical mismatch instead of deleting evidence to satisfy
|
|
40
|
+
a newly requested limit without an authorized revision.
|
|
41
|
+
|
|
11
42
|
## Findings Markdown
|
|
12
43
|
|
|
13
44
|
User-facing report, not a raw JSON payload:
|
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
"D-PREVIEW-001": {
|
|
9
9
|
"direction_id": "D-PREVIEW-001",
|
|
10
10
|
"title": "从保存到再次阅读的使用场景",
|
|
11
|
-
"research_points": ["了解材料难以再次找到的典型情境。", "比较按标题查找与按主题整理的使用边界。"],
|
|
11
|
+
"research_points": ["了解材料难以再次找到的典型情境。", "比较按标题查找与按主题整理的使用边界。", "合成约束示例:本方向报告最多引用 2 个不同的一手来源文档;不足之处明确说明。"],
|
|
12
12
|
"findings_file": null
|
|
13
13
|
},
|
|
14
14
|
"D-PREVIEW-002": {
|
|
@@ -3,6 +3,9 @@
|
|
|
3
3
|
# declared below. Citation provenance and report quality are reviewed by the
|
|
4
4
|
# executing Agent against SKILL.md, not by a separate citation/report driver
|
|
5
5
|
# declared in this Bundle. A successful validation is not proof of grounding.
|
|
6
|
+
# Explicit per-direction source/scope bounds in research_points are also
|
|
7
|
+
# Agent-reviewed against the actual report; these rules do not infer numeric
|
|
8
|
+
# source limits from free text. Passing them does not waive the user's bounds.
|
|
6
9
|
#
|
|
7
10
|
# Contract summary:
|
|
8
11
|
# - Every accepted direction has a direct `findings_file` and non-empty file.
|
|
@@ -35,7 +35,7 @@
|
|
|
35
35
|
"parentRole": "Source role",
|
|
36
36
|
"inheritanceReason": "Evidence for inheritance (optional)",
|
|
37
37
|
"addChildRole": "Add child role",
|
|
38
|
-
"guidance": "
|
|
38
|
+
"guidance": "Check what each role can do and which data it can access, looking for excessive or missing permissions. Set one source role only when reuse is needed; grants remain independent.",
|
|
39
39
|
"graphHint": "Connect the child to its source role. Return to details for local permissions and read-only inherited sources.",
|
|
40
40
|
"inheritanceHelp": "Inherited permissions retain their original applicability, confirmation and identity verification. Role assignment and conflict precedence are not inherited."
|
|
41
41
|
}
|
|
@@ -35,7 +35,7 @@
|
|
|
35
35
|
"parentRole": "来源角色",
|
|
36
36
|
"inheritanceReason": "继承依据(可选)",
|
|
37
37
|
"addChildRole": "添加子角色",
|
|
38
|
-
"guidance": "
|
|
38
|
+
"guidance": "检查各角色能做什么、作用于哪些数据,是否存在权限过多或遗漏;仅在确需复用时指定一个来源角色,授予规则仍独立。",
|
|
39
39
|
"graphHint": "从子角色连向来源角色;返回详情查看本角色权限及只读的继承来源。",
|
|
40
40
|
"inheritanceHelp": "继承权限保留原适用条件与确认、身份验证要求;不会继承角色授予规则,也不自动决定冲突优先级。"
|
|
41
41
|
}
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check whether the questions reflect your intent, then answer or correct them. Explain uncertainty or leave it open; earlier rounds remain available to review.",
|
|
3
3
|
"bundleDescription": "- **Capability**: maintain coherent product background and evolving context through editable questions and answers.\n- **Resolves**: understanding of users, needs, value, scenarios and boundaries, plus relevant context not owned by another design facet.\n- **Candidate when**: exploring requirements, reconstructing product background, revising existing understanding or clarifying context necessary for the current result; not a technical inventory or fixed questionnaire.\n- **Do not infer**: a short request, low score, or missing detail alone does not authorize questioning when a useful draft or grounded default is what the user requested.\n- **Output**: `smart_questions` panel — editable question cards with rendered options and answers.",
|
|
4
4
|
"configuration": "Application Development Configuration",
|
|
5
5
|
"empty": "There are no questions to answer.",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "确认问题中的理解是否符合你的意图,再回答或纠正;不确定的地方可以说明或留空,历史轮次可回看。",
|
|
3
3
|
"bundleDescription": "- **能力**:持续维护连贯的产品背景与关键上下文,并在需要时通过可编辑问题向用户取证。\n- **解决**:产品为谁、在何种场景解决什么问题、带来什么价值及其边界;补充其他设计维度不适合承载但影响整体理解的上下文。\n- **适用时机**:探索需求、重建产品背景、修订已有理解或澄清当前结果的关键缺口;不是技术盘点或固定问卷。\n- **不要推断**:需求简短、清晰度分数较低或细节缺失,并不意味着可以提问;用户需要可用草案或有依据的默认值时应直接推进。\n- **输出**:可编辑问题卡、选项和答案组成的 `smart_questions` 面板。",
|
|
4
4
|
"configuration": "应用开发配置",
|
|
5
5
|
"empty": "当前没有待回答的问题。",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check that the PRD reflects the agreed scope and key decisions. Follow source labels back to the original design when something is wrong, or request a revision in the conversation.",
|
|
3
3
|
"bundleDescription": "- **Capability**: generate or update one development-ready Web App PRD from current design evidence and user material.\n- **Resolves**: the delivery gap where product, design, engineering, test, and operations still lack one shared implementation-ready specification.\n- **Candidate when**: the user asks to generate, export, update, or inspect a complete PRD.\n- **Do not infer**: PRD assembly is an on-demand delivery action, not a required design gate and not permission to mutate owner Bundles.\n- **Output**: one stable canonical `prd.html`; Git retains history.",
|
|
4
4
|
"contents": "Contents", "empty": "No PRD yet. Ask in the conversation to generate or revise the complete PRD.",
|
|
5
5
|
"pending": "Pending confirmation", "legend": "Purple rail: temporary completion to keep the PRD coherent; not yet confirmed by the user",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "核对 PRD 是否准确表达已确认的范围和关键决策;发现偏差时通过来源标签回到原设计,或在对话中提出修订。",
|
|
3
3
|
"bundleDescription": "- **能力**:从当前设计证据和用户材料生成或修改一份可直接用于研发的完整 Web App PRD。\n- **解决**:产品仍缺少一份各交付角色都能直接理解、审阅和实施的统一需求文档。\n- **适用时机**:用户要求生成、导出、修改或查看完整 PRD。\n- **不要推断**:PRD 整合是按需交付动作,不是必经设计关卡,也不允许修改证据所属 Bundle。\n- **输出**:唯一稳定的 canonical `prd.html`;Git 保留历史修订。",
|
|
4
4
|
"contents": "文档目录", "empty": "暂无 PRD。可以在对话中要求生成或修订完整 PRD。",
|
|
5
5
|
"pending": "待确认", "legend": "紫色左轨:为保持 PRD 结构完整而临时补全,尚待用户确认",
|
|
@@ -1,3 +1,3 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "Check whether the ideas and relationships in the drawing are clear. Add text, shapes or connections where something is missing; create another topic when the questions are distinct.",
|
|
3
3
|
"bundleDescription": "Draw and revise topic-based diagrams together using text, shapes and connectors; explore ideas without replacing formal flows or page designs.","empty":"Create a topic to start drawing together.","boards":"Whiteboards","board":"Topic","id":"ID","title":"Topic title","file":"Scene file","new":"New topic"}
|
|
@@ -1,3 +1,3 @@
|
|
|
1
1
|
{
|
|
2
|
-
"guidance": "
|
|
2
|
+
"guidance": "检查图中的想法和关系是否表达清楚,用文字、图形或连线补上遗漏;需要区分不同问题时可新增主题。",
|
|
3
3
|
"bundleDescription": "按主题共同绘制和修改文字、图形与连线;用于开放探索,不替代业务流程或页面设计的正式产物。","empty":"新建一个主题,开始共同绘制。","boards":"自由白板","board":"主题","id":"标识","title":"主题名称","file":"场景文件","new":"新主题"}
|
package/kits/web_app/kit.yaml
CHANGED
|
@@ -14,7 +14,7 @@ mounts:
|
|
|
14
14
|
# Research markets, competitors and domain context, with sources and design implications.
|
|
15
15
|
- bindingKey: research
|
|
16
16
|
name: research
|
|
17
|
-
version: "1.
|
|
17
|
+
version: "1.1"
|
|
18
18
|
|
|
19
19
|
# 功能模块:将产品目标与使用场景展开为可逐项推敲的功能卡片。
|
|
20
20
|
# Turn product goals and scenarios into function cards that can be reviewed individually.
|
package/kits/web_app/mindset.md
CHANGED
package/package.json
CHANGED
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
"directory": "packages/skills-web-app"
|
|
6
6
|
},
|
|
7
7
|
"name": "@yugoo-design/dsh-design-skills-web-app",
|
|
8
|
-
"version": "0.
|
|
8
|
+
"version": "0.2.2",
|
|
9
9
|
"license": "Apache-2.0",
|
|
10
10
|
"type": "module",
|
|
11
11
|
"description": "Self-contained web_app Design Kit: Mindset, Bundle manifests, references, and ordinary Agent-facing scripts.",
|