agently-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Agently Design

Use this Skill for cross-owner design and audit. It produces ownership and handoff contracts; it does not become a scheduler, TriggerFlow definition, TaskDAG, retry engine, or RuntimeEvent protocol.

For iterative design or review, show current items and a timestamped, versioned change log at the response head; distinguish decisions from applied and verified changes. Read Multi-Round Collaboration.

使用本 Skill 进行跨所有者的设计与审计。它用于产出所有权与交接契约，而不是充当调度器、TriggerFlow 定义、TaskDAG、重试引擎或 RuntimeEvent 协议。

对于迭代式设计或评审，应在回复开头展示当前事项清单以及带时间戳和版本号的变更日志；区分已作出的决策、已应用的变更和已验证的变更。阅读 Multi-Round Collaboration。

Project Stage and Scope

Infer whether the task is a new design, a partial implementation, or a production review from the available assets and evidence. Explain the basis briefly and read Project Stages for the matching questions and deliverable. Ask only for missing facts that materially change the design. Start with the business goal, constraints, and simplest sufficient solution; do not introduce a model where an exact query or deterministic program suffices. This does not permit substituting keyword rules for semantic judgment.

Do not assume a model, SDK, or framework has already been selected. For an unselected or explicitly different stack, express contracts in neutral roles first and respect that stack; apply Agently owner/API mappings only when Agently is in scope. This design review alone does not authorize a framework migration. Unresolved product/project shape still routes through

agently

; cross-owner design belongs here, while a resolved single-request or runtime question stays with its existing mechanism owner.

根据现有资产和证据，判断任务属于新设计、部分实现还是生产评审。简要说明判断依据，并阅读 Project Stages 中对应阶段的问题和交付物。仅询问会实质影响设计的缺失事实。从业务目标、约束条件和最简充分方案入手；当精确查询或确定性程序已经足够时，不要引入模型。不得因此用关键词规则取代语义判断。

不要假设已经选定某个模型、SDK 或框架。对于尚未选定或明确采用其他技术栈的方案，先使用中立角色表达契约，并遵循相应技术栈；仅当 Agently 在当前范围内时，才应用 Agently 所有者/API 映射。仅进行此项设计审查，并不代表已授权进行框架迁移。产品或项目形态尚未明确时，仍应交由

agently

处理；跨所有者的设计属于本 Skill，而已经明确的单次请求或运行时问题则继续由现有机制所有者负责。

Core Workflow

State the business decisions and completion invariants.
Classify each decision as model-owned semantic work, host-owned deterministic work, or a hybrid bounded-enum/key decision.
Assign every decision, state, effect, and wait to one existing owner.
Draw request-time value dependencies and execution-time event dependencies before choosing APIs.
Combine ordered fields in one ModelRequest only when later fields need no observation created after dispatch. Split after Actions, system access, approval, artifact readback, or host computation needed by a later model decision.
Derive each prompt/output field from an authorized consumer and declare its type, constraints, visibility, retention, and failure behavior.
Design evidence, canonical identity joins, lifecycle, convergence, pressure, and observation before implementation.
For an audit, reconstruct the observed topology and identify the earliest divergent node or edge rather than inferring root cause from final output. When DevTools evidence or reviewer comments are available, read them through the review workflow, verify the source evidence, and return rerun findings to the original review.
Hand concrete implementation to the mechanism-owning Skill.

明确业务决策和完成性不变量。
将每项决策归类为模型负责的语义工作、Host 负责的确定性工作，或混合型有界枚举/键决策。
将每项决策、状态、效果和等待操作分配给唯一一个现有所有者。
在选择 API 前，绘制请求阶段的值依赖关系和执行阶段的事件依赖关系。
仅当后续字段不需要派发后才产生的观察结果时，才将有序字段合并到一个 ModelRequest 中。在 Action、系统访问、审批、产物回读或后续模型决策所需的 Host 计算之后进行拆分。
依据授权消费者推导每个 prompt/output 字段，并声明其类型、约束、可见性、保留策略和失败行为。
在实现前设计证据、规范身份关联、生命周期、收敛机制、压力处理和观测机制。
对于审计，重建观察到的拓扑，找出最早发生偏离的节点或边，而不是根据最终输出推断根因。如果有 DevTools 证据或评审意见，应通过 review workflow 读取，核验源证据，并将重跑发现反馈给原始审查。
将具体实现工作移交给机制所属的 Skill。

Required Topology Contract

For experiment reports and design documents, when the task instructions are not in English, prefer a complete document in that instruction language; a bilingual version is also acceptable. An explicit requested output language takes precedence. Apply this to the document itself, not only the chat summary. Preserve code, identifiers, raw prompts and evidence as needed; their language does not determine the surrounding report language.

Use collaborative review when it can answer the developer's question about model-node definitions, execution effects, data completeness/redundancy, or model/Host division of work; do not require the phrase "Prompt review". First show the whole in-scope flow, highlighting model nodes, their duties and input/output handoffs alongside Host work. Read

references/model-request-topology.md

for the question-to-evidence checks. Use the existing topology, not another ledger; a drawing alone does not prove runtime correctness or quality. Group related node tables for comparison under

../agently-request/references/prompt-management.md

: up to three logical nodes may share a reply, and tightly coupled larger groups are allowed. Clear scope can be shown with its details in the same reply. Preserve consequential-change confirmation and revisit only affected responsibilities/handoffs after revision.

Every non-trivial linear, branching, concurrent, or looped application needs:

an owner/invariant ledger;
a planned node ledger with each ModelRequest or host stage and its boundary reason;
a value/event edge ledger with exact producer, validation, and consumer;
a production-necessity ledger for every requested node, field, and artifact.

Use small project-defined reference data at a handoff only when it enables an independent consumer, parallel development, replay, local validation, or fault localization. Mark simulated data honestly and prove that real producer output can replace it. Do not invent a universal handoff packet.

Treat a non-terminal model result as a stage-scoped contribution: it must satisfy its local contract and create observable progress, but it does not need to claim whole-task completion. Unknown or deferred work remains explicit; terminal results and irreversible effects still require full acceptance.

对于实验报告和设计文档，如果任务指令不是英语，应优先提供使用该指令语言的完整文档；也可以提供双语版本。明确要求使用的输出语言具有最高优先级。此要求适用于文档本身，而不仅是聊天摘要。按需保留代码、标识符、原始 prompt 和证据；它们的语言不决定报告主体语言。

当协作审查能够回答开发者关于模型节点定义、执行效果、数据完整性或冗余，以及模型与 Host 分工的问题时，应采用协作审查；不要求用户使用“Prompt review”这一表述。首先展示完整的范围内流程，突出模型节点、它们的职责和输入/输出交接，并同时呈现 Host 工作。阅读

references/model-request-topology.md

，执行从问题到证据的检查。使用现有拓扑，不要另建台账；仅有流程图并不能证明运行时正确性或质量。可在

../agently-request/references/prompt-management.md

下对相关节点表进行分组比较：最多三个逻辑节点可以共享一次回复，也允许存在紧密耦合的更大节点组。范围明确时，可以在同一次回复中连同相关细节一并展示。保留对重要变更的确认机制，并在修订后仅重新检查受影响的职责和交接。

每个非简单的线性、分支、并发或循环应用都需要：

所有者/不变量台账；
计划节点台账，其中包含每个 ModelRequest 或 Host 阶段及其边界原因；
值/事件边台账，其中包含准确的生产者、验证方式和消费者；
生产必要性台账，其中涵盖每个请求涉及的节点、字段和工件。

仅当小型且由项目定义的参考数据能够支持独立消费、并行开发、重放、本地验证或故障定位时，才在交接中使用这些数据。应如实标注模拟数据，并证明真实生产者输出可以替换它们。不要设计通用交接包。

将非终态的模型结果视为阶段范围内的贡献：它必须满足本地契约并产生可观察的进展，但无需宣称整个任务已经完成。未知或延期的工作必须保持明确；终态结果和不可逆效果仍需完整验收。

Read by Design Question

Owner matrix, project layers, terminology, state/storage, and stable flow versus submitted DAG:
```
references/system-boundaries.md
```
.
Model-node definitions, effect tuning, data-flow correctness/redundancy, flow-first review, prompt/output contracts, same-response consumption, fan-out, joins, and
```
instant
```
:
```
references/model-request-topology.md
```
.
Full planned-versus-observed value/signal audit:
```
references/execution-topology-validation.md
```
.
TaskContext packages, TaskWorkspace/RecordStore evidence, trusted selection keys, refs, citations, snapshots, and fail-closed joins:
```
references/information-and-evidence-design.md
```
.
Concurrency, retries, repair, replan, approval, pause/resume, cancellation, close, pressure, and planned long-form section generation:
```
references/lifecycle-and-pressure-design.md
```
.
RuntimeEvents, lineage, request telemetry, model-quality review, and experiment comparison:
```
references/observability-and-validation.md
```
.

After ownership is clear:

one request family routes to
```
agently-request
```
;
AgentExecution plugins/final policies, Action, MCP, ExecutionResource, TaskWorkspace, RecordStore, service, or telemetry mechanics route to
```
agently-runtime
```
;
developer-owned executable orchestration routes to
```
agently-triggerflow
```
;
explicit submitted TaskDAG data remains a low-frequency
```
agently
```
advanced reference rather than a standalone default Skill;
source-framework mapping routes to
```
agently-migration
```
.

所有者矩阵、项目分层、术语、状态/存储，以及稳定流与已提交 DAG 的对比：
```
references/system-boundaries.md
```
。
模型节点定义、效果调优、数据流正确性/冗余、以流程为中心的审查、prompt/output 契约、同一回复内消费、扇出、连接和
```
instant
```
：
```
references/model-request-topology.md
```
。
完整的计划值/信号与实际值/信号审计：
```
references/execution-topology-validation.md
```
。
TaskContext 包、TaskWorkspace/RecordStore 证据、可信选择键、refs、引用、快照和 fail-closed 连接：
```
references/information-and-evidence-design.md
```
。
并发、重试、修复、重新规划、审批、暂停/恢复、取消、关闭、压力和计划中的长篇章节生成：
```
references/lifecycle-and-pressure-design.md
```
。
RuntimeEvents、血缘、请求遥测、模型质量评审和实验对比：
```
references/observability-and-validation.md
```
。

所有权明确后：

单一请求族交由
```
agently-request
```
处理；
AgentExecution 插件/最终策略、Action、MCP、ExecutionResource、TaskWorkspace、RecordStore、服务或遥测机制交由
```
agently-runtime
```
处理；
开发者拥有的可执行编排交由
```
agently-triggerflow
```
处理；
显式提交的 TaskDAG 数据仍作为
```
agently
```
的低频高级参考，而不是独立的默认 Skill；
源框架映射交由
```
agently-migration
```
处理。

Non-Negotiable Boundaries

Model participation alone does not justify another request. Split only for a real decision, evidence, consumer, authorization, retry, lifecycle, or parallelism boundary.
A ModelRequest is a dispatch-time snapshot. Provisional
```
instant
```
output may update UI or start cancelable/idempotent preparation, but cannot inject that preparation's result back into the running request.
Give the model one host-issued selection key plus relevant facts. Host code validates the offered key and reconstructs canonical ids and metadata.
If a selection can cross cache, queue, retry, persistence, or replay, bind it to host-owned semantic-request lineage and validate freshness before lookup.
Every model-satisfiable business rule reaches the producer before its first attempt. Deliberately hidden security or integrity gates remain host-owned and need explicit failure/terminal policy.
Do not request hidden chain-of-thought. Keep only bounded task-specific process fields with an explicit consumer and retention contract.

仅凭模型参与并不足以证明需要额外发起一次请求。只有在真实决策、证据、消费者、授权、重试、生命周期或并行边界处才应拆分请求。
ModelRequest 是派发时的快照。临时的
```
instant
```
输出可以更新 UI 或启动可取消/幂等的准备工作，但不能将该准备结果重新注入正在运行的请求。
向模型提供一个由 Host 签发的选择键以及相关事实。Host 代码负责验证所提供的键，并重建规范 ID 和元数据。
如果选择操作可能跨越缓存、队列、重试、持久化或重放，应将其绑定到 Host 所有的语义请求血缘，并在查询前验证新鲜度。
每条模型可满足的业务规则都必须在首次尝试前传递给生产者。有意隐藏的安全或完整性门禁仍由 Host 负责，并需要明确的失败/终止策略。
不要请求隐藏的思维链。仅保留有界的任务特定过程字段，并明确其消费者和保留契约。

Completion Gate

Before implementation, confirm that every invariant has one owner, every request boundary has a reason, every output field has an authorized consumer, every provisional path has invalidation behavior, every loop has progress and terminal rules, every cross-boundary identity has freshness/correlation, and every validation rule has a declared producer or deliberately hidden host gate.

Do not replace semantic routing, relevance, planning, or quality judgment with keywords, regex, tokenization, or local score tables. Do not add a parallel execution topology beside TriggerFlow or TaskDAG.

在实现前，确认每个不变量都有唯一所有者，每个请求边界都有明确原因，每个输出字段都有授权消费者，每条临时路径都有失效处理行为，每个循环都有进展规则和终止规则，每个跨边界身份都有新鲜度/相关性校验，并且每条验证规则都有已声明的生产者或有意隐藏的 Host 门禁。

不要使用关键词、正则表达式、分词或本地评分表来取代语义路由、相关性判断、规划或质量判断。不要在 TriggerFlow 或 TaskDAG 之外再添加平行的执行拓扑。