Agently Playbook
Use this skill first when the request still starts from business goals, refactor goals, product behavior, or broad model-app language.
The user does not need to say Agently, TriggerFlow, or any other framework term. Generic asks such as "build an assistant", "help me design an internal tool", or "create a validator for common problems" should still start here when the owner layer is unresolved.
Requests that also mention a UI, a web page, a desktop shell, or a local model service such as Ollama should still start here when the request is fundamentally about shaping a model-powered tool rather than only wiring one narrow capability.
Workflow
- 1. Reduce the request into scenario and atomic goals.
- If the request is a project initialization or structure refactor, choose the owner layers, async boundary, and repo skeleton first.
- Choose the narrowest native Agently capability path.
- Name the concrete operations or primitives that should be used.
- Name the validation rule that proves the design stayed native-first.
Native-First Rules
- - default to async-first guidance for service code, streaming, TriggerFlow, and any path that may overlap work or benefit from cancellation
- treat sync APIs as wrappers for scripts, REPL use, or compatibility bridges unless the host truly requires sync-only integration
- when the request is a project-shape refactor, separate settings, prompts, services, domain contracts, workflow, and tests before discussing low-level implementation details
Capability Routing
- - model provider setup, settings-file-based model separation, or
${ENV.xxx}-backed settings loading -> INLINECODE1 - request-side prompt design, prompt placeholder injection, or config-file prompt bridge -> INLINECODE2
- output schema and reliability -> INLINECODE3
- response reuse, metadata, or streaming consumption -> INLINECODE4
- session continuity or restore -> INLINECODE5
- tools, MCP, FastAPIHelper,
auto_func, or KeyWaiter -> INLINECODE8 - embeddings, KB, or retrieval-to-answer -> INLINECODE9
- branching, concurrency, waiting/resume, mixed sync/async orchestration, event-driven fan-out, process-clarity refactors, runtime stream, or explicit multi-stage quality loops -> INLINECODE10
- migration choice between LangChain and LangGraph -> INLINECODE11
Anti-Patterns
- - do not skip this playbook when the owner layer is unresolved
- do not invent custom output parsers, retry loops, or orchestration first
- do not let sync-first sample code dictate the service architecture when the target is clearly async-capable
- do not split project initialization into a fake standalone framework surface before the owner layers are chosen
- do not treat multi-agent, judge, or review flows as separate framework surfaces before checking native Agently capabilities
Read Next
- - INLINECODE12
- INLINECODE13
Agently Playbook
当请求仍始于业务目标、重构目标、产品行为或广泛的模型应用语言时,请优先使用此技能。
用户无需提及Agently、TriggerFlow或任何其他框架术语。当所有者层尚未确定时,诸如构建一个助手、帮我设计一个内部工具或为常见问题创建一个验证器等通用请求仍应从此处开始。
当请求本质上涉及塑造一个由模型驱动的工具,而不仅仅是连接一个狭窄的功能时,提及UI、网页、桌面外壳或本地模型服务(如Ollama)的请求仍应从此处开始。
工作流程
- 1. 将请求分解为场景和原子目标。
- 如果请求是项目初始化或结构重构,请先选择所有者层、异步边界和仓库骨架。
- 选择最狭窄的原生Agently能力路径。
- 命名应使用的具体操作或原语。
- 命名证明设计保持原生优先的验证规则。
原生优先规则
- - 默认对服务代码、流式处理、TriggerFlow以及任何可能重叠工作或受益于取消的路径采用异步优先指导
- 将同步API视为脚本、REPL使用或兼容性桥接的包装器,除非主机真正需要仅同步集成
- 当请求是项目形状重构时,在讨论底层实现细节之前,先分离设置、提示、服务、领域契约、工作流和测试
能力路由
- - 模型提供者设置、基于设置文件的模型分离或${ENV.xxx}支持的设置加载 -> agently-model-setup
- 请求端提示设计、提示占位符注入或配置文件提示桥接 -> agently-prompt-management
- 输出模式和可靠性 -> agently-output-control
- 响应复用、元数据或流式消费 -> agently-model-response
- 会话连续性或恢复 -> agently-session-memory
- 工具、MCP、FastAPIHelper、auto_func或KeyWaiter -> agently-agent-extensions
- 嵌入、知识库或检索到答案 -> agently-knowledge-base
- 分支、并发、等待/恢复、混合同步/异步编排、事件驱动扇出、流程清晰度重构、运行时流或显式多阶段质量循环 -> agently-triggerflow
- LangChain和LangGraph之间的迁移选择 -> agently-migration-playbook
反模式
- - 当所有者层未解决时,不要跳过此操作手册
- 不要首先发明自定义输出解析器、重试循环或编排
- 当目标明显支持异步时,不要让同步优先的示例代码决定服务架构
- 在选择所有者层之前,不要将项目初始化拆分为虚假的独立框架表面
- 在检查原生Agently能力之前,不要将多代理、评判或审查流程视为独立的框架表面
继续阅读
- - references/capability-map.md
- references/project-framework.md